웹 인증: 공개 키 자격 증명에 접근하는 API

1. 소개

이 섹션은 규범적이지 않습니다.

이 명세서는 강력하며, 보증된 스코프된 공개 키 기반 자격 증명을 웹 애플리케이션이 생성하고 사용할 수 있게 하는 API를 정의하며, 사용자를 강하게 인증하기 위한 목적을 가집니다. 공개 키 자격 증명은 WebAuthn 인증기에 의해 WebAuthn 신뢰당사자의 요청에 따라 생성 및 저장되며, 사용자 동의가 전제됩니다. 이후에는 공개 키 자격 증명은 해당 오리진이 속한 신뢰당사자만 접근할 수 있습니다. 이러한 스코프는 준수 사용자 에이전트와 인증기가 공동으로 적용합니다. 또한, 신뢰당사자 간의 프라이버시가 보장됩니다. 신뢰당사자는 다른 스코프의 신뢰당사자에 속한 자격 증명의 속성이나 존재 여부조차 감지할 수 없습니다.

신뢰당사자는 사용자가 참여하는 두 가지 별개의 절차에서 Web 인증 API를 사용합니다. 첫 번째는 등록으로, 공개 키 자격 증명이 인증기에서 생성되고, 해당 스코프로 신뢰당사자와 현재 사용자의 계정에 연결됩니다(계정은 이미 존재하거나 이 시점에 생성될 수 있습니다). 두 번째는 인증으로, 신뢰당사자에게 인증 주장이 제시되어 해당 공개 키 자격 증명을 등록한 사용자의 존재와 동의를 증명합니다. 기능적으로, Web 인증 API는 PublicKeyCredential을 포함하며, 이는 Credential Management API [CREDENTIAL-MANAGEMENT-1]를 확장하고, navigator.credentials.create()와 navigator.credentials.get()에서 사용할 수 있도록 합니다. 등록에는 전자가, 인증에는 후자가 사용됩니다.

전반적으로, 준수 인증기는 공개 키 자격 증명을 보호하며, 사용자 에이전트와 상호작용하여 Web 인증 API를 구현합니다. 준수 인증기의 구현은 (a) 범용 컴퓨팅 장치에서 실행되는 소프트웨어, (b) 온-디바이스 보안 실행 환경, 신뢰 플랫폼 모듈(TPM), 또는 보안 요소(SE)에서, (c) 디바이스 외부에서 가능합니다. 디바이스 내에서 구현되는 인증기는 플랫폼 인증기라 하며, 디바이스 외부에서 구현되는 인증기(로밍 인증기)는 USB, 블루투스 저전력(BLE), 근거리 통신(NFC) 등의 전송 방식을 통해 접근할 수 있습니다.

1.1. 명세 로드맵

많은 W3C 명세가 주로 사용자 에이전트 개발자와 웹 애플리케이션 개발자(즉, "웹 저자")를 대상으로 하지만, 웹 인증의 특성상 이 명세는 아래에 설명된 여러 대상자가 올바르게 사용해야 합니다.

모든 대상자는 § 1.2 사용 사례, § 1.3 API 사용 예시 시나리오, § 4 용어에서 시작해야 하며, [WebAuthnAPIGuide]의 튜토리얼도 참고해야 합니다. 그 외, 이 문서의 주요 대상 그룹은 다음과 같습니다:

신뢰당사자 웹 애플리케이션 개발자, 특히 신뢰당사자 웹 애플리케이션 로그인 플로우, 계정 복구 플로우, 사용자 계정 데이터베이스 관리 등에 책임이 있는 개발자.
웹 프레임워크 개발자
- 위 두 대상자는 특히 § 7 신뢰당사자 작업을 참고해야 합니다. § 5 Web 인증 API의 소개도 도움이 될 수 있으나, 이 섹션은 사용자 에이전트 개발자를 위한 것이며 웹 애플리케이션 개발자 대상이 아닙니다. 또한, 인증기 보증을 검증하려면 § 6.5 보증과 § 8 정의된 보증 문서 형식도 참고해야 합니다. § 9 WebAuthn 확장과 § 10 정의된 확장은 확장 기능을 사용할 때 유용합니다. 마지막으로 § 13.4 신뢰당사자 보안 고려사항과 § 14.6 신뢰당사자 프라이버시 고려사항을 읽고 본인 애플리케이션과 사용자에 적용되는 챌린지를 고려해야 합니다.
사용자 에이전트 개발자
OS 플랫폼 개발자(플랫폼 인증기 API, WebAuthn 클라이언트 인스턴스화 등 플랫폼 별 API 설계 및 구현 책임자)
- 위 두 대상자는 § 5 Web 인증 API를 아주 꼼꼼히 읽고, 확장 기능을 지원하려면 § 9 WebAuthn 확장도 참고해야 합니다. § 14.5 클라이언트 프라이버시 고려사항도 세심히 읽어야 합니다.
인증기 개발자. 이 독자들은 § 6 WebAuthn 인증기 모델, § 8 정의된 보증 문서 형식, § 9 WebAuthn 확장, § 10 정의된 확장을 특히 주목해야 합니다. § 13.3 인증기 보안 고려사항과 § 14.4 인증기 프라이버시 고려사항도 세심히 읽어야 합니다.

참고: Web 인증 API 자체와 더불어, 이 명세서는 암호학적 요청-응답 프로토콜—WebAuthn/FIDO2 프로토콜—을 정의합니다. 이 프로토콜은 WebAuthn 신뢰당사자 서버와 인증기 사이에서 이루어지며, 신뢰당사자의 요청에는 챌린지와 기타 입력 데이터가 포함되어 인증기로 전달됩니다. 요청은 HTTPS, 신뢰당사자 웹 애플리케이션, WebAuthn API, 그리고 사용자 에이전트와 인증기 간의 플랫폼별 통신 채널 조합을 통해 전달됩니다. 인증기는 디지털 서명된 인증기 데이터 메시지와 기타 출력 데이터를 반환하며, 이는 동일한 경로를 통해 신뢰당사자 서버로 전달됩니다. 프로토콜 세부사항은 인증 또는 등록 작업이 신뢰당사자에 의해 호출되는지에 따라 다릅니다. 그림 1, 그림 2도 참고하세요.

Web 인증 배포의 종단간 보안을 위해 각 구성요소—신뢰당사자 서버, 클라이언트, 인증기—의 역할과 § 13 보안 고려사항, § 14 프라이버시 고려사항이 모든 대상자에게 이해되는 것이 매우 중요합니다.

1.2. 사용 사례

아래 사용 사례 시나리오에서는 두 가지 매우 다른 유형의 인증기를 활용하는 예와 추가 시나리오를 설명합니다. 샘플 코드 등을 포함한 추가 시나리오는 § 1.3 API 사용 예시 시나리오에서 다룹니다.

1.2.1. 등록

휴대폰에서:
- 사용자가 브라우저에서 example.com에 접속하여 기존 계정으로 로그인하거나(기존 방식인 비밀번호 등), 새 계정을 생성합니다.
- 휴대폰에서 "이 디바이스를 example.com에 등록하시겠습니까?"라는 안내가 표시됩니다.
- 사용자가 동의합니다.
- 휴대폰이 사전에 설정된 인증 제스처(PIN, 생체 정보 등)를 요청하고, 사용자가 이를 입력합니다.
- 웹사이트에 "등록 완료" 메시지가 표시됩니다.

1.2.2. 인증

노트북 또는 데스크탑에서:
- 사용자가 휴대폰을 노트북/데스크탑과 블루투스로 페어링합니다.
- 사용자가 브라우저에서 example.com에 접속하여 로그인 절차를 시작합니다.
- 브라우저에서 "이 작업을 휴대폰에서 완료하세요."라는 메시지가 표시됩니다.
이후 휴대폰에서:
- 사용자가 "example.com에 로그인하세요."라는 알림 또는 프롬프트를 봅니다.
- 사용자가 해당 알림/프롬프트를 선택합니다.
- 사용자에게 example.com 계정 목록(예: "Mohamed로 로그인 / 张三로 로그인")이 표시됩니다.
- 사용자가 신원을 선택하고 인증 제스처(PIN, 생체 정보 등) 요청을 받고 이를 입력합니다.
다시 노트북에서:
- 웹페이지에 선택된 사용자가 로그인된 상태가 표시되고 로그인 페이지로 이동합니다.

1.2.3. 새 디바이스 등록

이 시나리오는 신뢰당사자가 로밍 인증기(예: USB 보안키)와 플랫폼 인증기(예: 내장 지문 센서)를 조합하여 사용자가 아래와 같이 활용할 수 있도록 하는 방법을 설명합니다:

사용자는 "주 인증기"로 로밍 인증기를 사용하여 새로운 클라이언트 디바이스(예: 노트북, 데스크탑)나 플랫폼 인증기가 없는 클라이언트 디바이스에서 인증을 수행합니다.
플랫폼 인증기가 있는 클라이언트 디바이스에서는 플랫폼 인증기로 손쉽고 강력하게 재인증할 수 있습니다.

참고: 계정에 여러 인증기를 등록하는 방식은 계정 복구에도 유용합니다.

먼저, 플랫폼 인증기가 없는 데스크탑 컴퓨터에서:
- 사용자가 브라우저에서 example.com에 접속하여 기존 방식(비밀번호 등)으로 로그인하거나 새 계정을 생성합니다.
- 사용자가 계정 보안 설정에서 "보안 키 등록"을 선택합니다.
- 웹사이트가 USB 보안 키를 꽂으라고 안내하고, 사용자는 이를 연결합니다.
- USB 보안 키가 깜빡이며 버튼을 누르라는 신호를 주고, 사용자는 버튼을 누릅니다.
- 웹사이트에 "등록 완료" 메시지가 표시됩니다.
참고: 이 컴퓨터에는 플랫폼 인증기가 없으므로, 웹사이트는 사용자가 사이트에서 상호작용할 때마다 USB 보안 키를 제시하도록 요구할 수 있습니다. 이는 사이트의 재량입니다.
이후, 플랫폼 인증기가 있는 노트북에서:
- 사용자가 브라우저에서 example.com에 접속하여 로그인 절차를 시작합니다.
- 웹사이트가 USB 보안 키를 꽂으라고 안내합니다.
- 사용자가 이전에 등록한 USB 보안 키를 꽂고 버튼을 누릅니다.
- 웹사이트에 사용자가 로그인된 상태가 표시되고, 로그인 페이지로 이동합니다.
- 웹사이트에서 "이 컴퓨터를 example.com에 등록하시겠습니까?"라는 안내가 표시됩니다.
- 사용자가 동의합니다.
- 노트북이 사전에 설정된 인증 제스처(PIN, 생체 정보 등)를 요청하고, 사용자가 입력합니다.
- 웹사이트에 "등록 완료" 메시지가 표시됩니다.
- 사용자가 로그아웃합니다.
다시 노트북에서:
- 사용자가 브라우저에서 example.com에 접속하여 로그인 절차를 시작합니다.
- 웹사이트에 "컴퓨터의 안내에 따라 로그인 작업을 완료하세요."라는 메시지가 표시됩니다.
- 노트북이 인증 제스처(PIN, 생체 정보 등)를 요청하고, 사용자가 입력합니다.
- 웹사이트에 사용자가 로그인된 상태가 표시되고, 로그인된 페이지로 이동합니다.

1.2.4. 기타 사용 사례와 구성

다양한 추가 사용 사례와 구성도 가능합니다(다음에 한정되지 않음):

사용자가 노트북에서 example.com에 접속하여 휴대폰에서 자격 증명을 생성·등록하는 과정을 안내받습니다.
사용자가 USB 또는 USB+NFC/BLE 연결 옵션이 있는 독립적인 로밍 인증기(예: "fob")를 준비하고, 노트북 또는 휴대폰에서 브라우저로 example.com에 접속해 fob에 자격 증명을 생성·등록하는 과정을 안내받습니다.
신뢰당사자가 사용자의 인증 제스처를 요청하여 결제 등 단일 거래 또는 금융 거래를 승인하도록 합니다.

1.3. API 사용 예시 시나리오

이 섹션은 규범적이지 않습니다.

이 섹션에서는 공개 키 자격 증명의 라이프사이클에서 일어나는 몇 가지 사건을, 이 API를 사용하는 샘플 코드와 함께 살펴봅니다. 이는 예시 플로우일 뿐이며 API 사용 범위를 제한하지 않습니다.

앞서 섹션과 마찬가지로, 이 플로우는 자체 디스플레이가 있는 일차 인증용 로밍 인증기를 사용하는 사례에 집중합니다. 예를 들어 스마트폰이 그 예입니다. 이 API는 클라이언트 플랫폼의 구현에 따라 다른 인증기 유형도 지원합니다. 예를 들어, 이 플로우는 클라이언트 디바이스에 내장된 인증기에도 수정 없이 적용됩니다. 또한, 자체 디스플레이가 없는 인증기(스마트 카드와 유사)에도 특정 구현 고려 사항에 따라 적용할 수 있습니다. 특히 클라이언트 플랫폼이 인증기 대신 프롬프트를 표시해야 하며, 인증기는 클라이언트 플랫폼이 모든 자격 증명을 열거할 수 있도록 허용해야 하므로, 클라이언트가 적합한 프롬프트 정보를 표시할 수 있습니다.

1.3.1. 등록

이것은 새로운 자격 증명이 생성되어 서버에 등록되는 최초 플로우입니다. 이 플로우에서 WebAuthn 신뢰당사자는 플랫폼 인증기 또는 로밍 인증기에 대한 선호가 없습니다.

사용자가 example.com에 방문하면 스크립트가 실행됩니다. 이때 사용자는 이미 기존 사용자명/비밀번호, 추가 인증기, 또는 신뢰당사자가 허용하는 다른 방식으로 로그인했을 수도 있습니다. 또는 새 계정을 생성하는 중일 수도 있습니다.
신뢰당사자 스크립트가 아래 코드 스니펫을 실행합니다.
클라이언트 플랫폼이 인증기를 검색 및 탐색합니다.
클라이언트가 인증기에 연결하며, 필요한 경우 페어링 작업을 수행합니다.
인증기가 사용자에게 생체 정보 또는 기타 인증 제스처를 입력하는 UI를 표시합니다.
인증기가 클라이언트에 응답을 반환하고, 클라이언트는 다시 신뢰당사자 스크립트에 응답을 반환합니다. 사용자가 인증기를 선택하거나 인증에 동의하지 않으면 적절한 오류가 반환됩니다.
새 자격 증명이 생성된 경우,
- 신뢰당사자 스크립트가 새로 생성된 자격 증명 공개 키를 서버에 전송하며, 인증기의 출처 및 특성에 대한 보증 등 추가 정보를 함께 전송합니다.
- 서버는 자격 증명 공개 키를 데이터베이스에 저장하고 사용자 및 인증 특성과 연관시키며, 나중에 사용할 수 있도록 친숙한 이름도 저장합니다.
- 스크립트는 자격 증명 ID와 같은 데이터를 로컬에 저장하여, 사용자의 향후 UX를 개선하기 위해 자격 증명 선택 범위를 좁힐 수 있습니다.

새 키를 생성 및 등록하는 샘플 코드는 다음과 같습니다:

...코드 동일...

1.3.2. 사용자 검증 플랫폼 인증기로 등록

이것은 WebAuthn 신뢰당사자가 사용자 검증 플랫폼 인증기로 공개 키 자격 증명 생성에 특별히 관심이 있을 때의 예시 플로우입니다.

사용자가 example.com에 방문하여 로그인 버튼을 클릭하면 login.example.com으로 리디렉션됩니다.
사용자가 사용자명과 비밀번호를 입력하여 로그인합니다. 로그인에 성공하면 다시 example.com으로 리디렉션됩니다.
신뢰당사자 스크립트가 아래 코드 스니펫을 실행합니다.
1. 사용자 에이전트가 사용자 검증 플랫폼 인증기가 있는지 확인합니다. 없으면 이 플로우를 종료합니다.
2. 신뢰당사자가 사용자가 이를 통해 자격 증명을 생성할지 묻습니다. 아니오라면 플로우를 종료합니다.
3. 사용자 에이전트 또는 운영체제가 적절한 UI를 표시하며, 사용자가 사용 가능한 플랫폼 인증기로 자격 증명을 생성하도록 안내합니다.
4. 자격 증명 생성에 성공하면 신뢰당사자 스크립트가 새 자격 증명을 서버로 전달합니다.

...코드 동일...

1.3.3. 인증

이미 등록된 자격 증명을 가진 사용자가 웹사이트에 방문하여 해당 자격 증명으로 인증하고자 할 때의 플로우입니다.

사용자가 example.com에 방문하면 스크립트가 실행됩니다.
스크립트가 클라이언트에 인증 주장을 요청하며, 사용자를 위한 허용 자격 증명 선택 범위를 최대한 좁힙니다. 이는 등록 후 로컬에 저장된 데이터나, 사용자명 프롬프트 등 다양한 방법으로 얻을 수 있습니다.
신뢰당사자 스크립트가 아래 코드 스니펫 중 하나를 실행합니다.
클라이언트 플랫폼이 인증기를 검색 및 탐색합니다.
클라이언트가 인증기에 연결하며, 필요한 경우 페어링 작업을 수행합니다.
인증기가 사용자에게 알림을 표시하여 주의가 필요함을 알립니다. 알림을 열면, 사용자에게 계정 정보와 함께 허용 자격 증명 선택 메뉴와 해당 키를 요청하는 오리진 정보를 표시합니다.
인증기가 사용자로부터 생체 정보 또는 기타 인증 제스처를 입력받습니다.
인증기가 클라이언트에 응답을 반환하고, 클라이언트는 다시 신뢰당사자 스크립트에 응답을 반환합니다. 사용자가 자격 증명을 선택하거나 인증에 동의하지 않으면 적절한 오류가 반환됩니다.
주장이 성공적으로 생성되고 반환된 경우,
- 스크립트가 주장을 서버로 전송합니다.
- 서버가 주장을 검사하고 자격 증명 ID를 추출한 뒤, 데이터베이스에서 등록된 자격 증명 공개 키를 조회하여 주장 서명을 검증합니다. 유효하면, 주장의 자격 증명 ID에 연관된 신원을 조회하여 인증합니다. 만약 자격 증명 ID가 서버에서 인식되지 않으면(예: 비활성화로 인해 등록 해제됨) 인증이 실패합니다. 각 신뢰당사자는 이를 각기 다르게 처리합니다.
- 서버가 인증 성공 시 페이지 반환, 인증 쿠키 설정 등 필요한 작업을 수행합니다.

신뢰당사자 스크립트에 선택 범위를 좁힐 수 있는 힌트(로컬 저장 데이터 등)가 없다면, 인증을 수행하는 샘플 코드는 다음과 같습니다:

...코드 동일...

반면, 신뢰당사자 스크립트에 선택 범위를 좁힐 수 있는 힌트가 있다면, 인증을 수행하는 샘플 코드는 다음과 같습니다. 이 샘플은 Credential Properties Extension 사용법도 함께 보여줍니다.

...코드 동일...

1.3.4. 인증 작업 중단

아래 예시는 개발자가 AbortSignal 파라미터를 사용하여 자격 증명 등록 작업을 중단하는 방법을 보여줍니다. 인증 작업에도 동일하게 적용됩니다.

...코드 동일...

1.3.5. 폐기

다음은 자격 증명을 폐기해야 할 수 있는 여러 상황입니다. 이 모든 과정은 서버 측에서 처리되며, 여기 명세된 API의 지원이 필요하지 않습니다.

가능성 #1 -- 사용자가 자격 증명을 분실로 신고
- 사용자가 server.example.net에 접속하여 인증 후 분실/도난 인증기 신고 링크를 클릭합니다.
- 서버가 등록된 자격 증명 목록을 등록 시 설정한 친숙한 이름과 함께 보여줍니다.
- 사용자가 자격 증명을 선택하면 서버가 데이터베이스에서 해당 자격 증명을 삭제합니다.
- 이후 신뢰당사자 스크립트는 이 자격 증명을 허용 목록에 포함하지 않으며, 해당 자격 증명으로 서명된 주장은 거부됩니다.
가능성 #2 -- 서버가 비활동성으로 자격 증명을 등록 해제
- 서버가 유지보수 중 데이터베이스에서 자격 증명을 삭제합니다.
- 이후 신뢰당사자 스크립트는 이 자격 증명을 허용 목록에 포함하지 않으며, 해당 자격 증명으로 서명된 주장은 거부됩니다.
가능성 #3 -- 사용자가 인증기에서 자격 증명을 삭제
- 사용자가 인증기별 방법(예: 디바이스 설정 UI)을 사용하여 인증기에서 자격 증명을 삭제합니다.
- 이후 이 자격 증명은 어떠한 선택 프롬프트에도 표시되지 않으며, 주장을 생성할 수 없습니다.
- 이후 서버가 비활동성으로 해당 자격 증명을 등록 해제합니다.

1.4. 플랫폼별 구현 지침

이 명세서는 일반적인 경우에 Web 인증을 어떻게 사용하는지 정의합니다. 특정 플랫폼 지원(예: 앱)과 함께 Web 인증을 사용할 때에는, 추가 지침과 제한사항을 위해 플랫폼별 문서와 가이드를 참고하는 것이 권장됩니다.

2. 준수

이 명세서는 세 가지 준수 클래스를 정의합니다. 각 클래스는 해당 클래스의 준수 멤버가 다른 클래스의 비준수 또는 악의적 멤버에 대해 안전하도록 규정되어 있습니다.

2.1. 사용자 에이전트

사용자 에이전트는 § 5 Web 인증 API에 기술된 대로 동작해야 준수로 간주됩니다. 준수 사용자 에이전트는 본 명세서에 제시된 알고리즘의 결과와 구별되지 않는 한, 원하는 방식으로 알고리즘을 구현할 수 있습니다.

준수 사용자 에이전트는 또한 이 명세서의 IDL 조각을 "Web IDL" 명세서에 기술된 대로 준수 구현이어야 합니다. [WebIDL]

2.1.1. DOMString 타입으로서의 열거형

열거형 타입은 Web IDL의 다른 부분에서 참조되지 않습니다. 이는 명세서 및 구현을 업데이트하지 않고도 다른 값이 사용될 수 있도록 하기 위함입니다. 클라이언트 플랫폼과 신뢰당사자가 알 수 없는 값을 처리하는 것이 하위 호환성에 중요합니다. 이 명세서의 열거형은 문서화와 레지스트리 용도로 존재합니다. 열거형이 다른 곳에서 표현될 때는 DOMString 타입으로 지정되며, 예를 들어 transports에서 사용됩니다.

2.2. 인증기

WebAuthn 인증기는 § 6 WebAuthn 인증기 모델에 정의된 작업을 제공해야 하며, 해당 작업은 명세된 대로 동작해야 합니다. 이는 인증기가 준수 사용자 에이전트에 의해 사용될 수 있도록 하는 기능 및 보안 요구사항입니다.

§ 1.2 사용 사례에서 설명한 것처럼, 인증기는 사용자 에이전트 하위의 운영체제, 외부 하드웨어, 또는 둘의 조합으로 구현될 수 있습니다.

2.2.1. FIDO U2F와의 하위 호환성

인증기가 § 8.6 FIDO U2F 보증 문서 형식만 지원하는 경우 사용자 핸들을 저장할 메커니즘이 없으므로, 반환되는 userHandle은 항상 null입니다.

2.3. WebAuthn 신뢰당사자

WebAuthn 신뢰당사자는 § 7 WebAuthn 신뢰당사자 작업에서 기술한 대로 동작해야 이 명세서가 제공하는 모든 보안 이점을 얻을 수 있습니다. 자세한 내용은 § 13.4.1 WebAuthn 신뢰당사자를 위한 보안 이점을 참고하세요.

2.4. 모든 준수 클래스

위 준수 클래스의 모든 멤버가 수행하는 CBOR 인코딩은 CTAP2 표준 CBOR 인코딩 형식을 사용해야 합니다. 위 준수 클래스의 모든 디코더는 CTAP2 표준 CBOR 인코딩 형식으로 올바르게 인코딩되지 않은 CBOR을 거부해야 하며, 중복된 맵 키가 있는 메시지도 거부해야 합니다.

3. 의존성

이 명세서는 아래와 참조에 의해 정의된 용어에 열거된 여러 다른 기본 명세에 의존합니다.

Base64url 인코딩: Base64url 인코딩은 [RFC4648] 섹션 5에서 정의된 URL 및 파일명 안전 문자 집합을 사용하는 base64 인코딩을 의미하며, 섹션 3.2에서 허용한 대로 끝의 '=' 문자는 모두 생략되고, 줄 바꿈·공백·기타 추가 문자가 포함되지 않습니다.
CBOR: 이 명세서의 여러 구조(보증 문서, 확장 등)는 Compact Binary Object Representation(CBOR) [RFC8949]의 CTAP2 표준 CBOR 인코딩 형식으로 인코딩되며, [FIDO-CTAP]에서 정의합니다.
CDDL: 이 명세서는 CBOR 인코딩 데이터의 구문을 CBOR 데이터 정의 언어(CDDL) [RFC8610]로 설명합니다.
COSE: CBOR 객체 서명 및 암호화(COSE) [RFC8152]. 이 명세서에 의해 구축된 IANA COSE 알고리즘 레지스트리 [IANA-COSE-ALGS-REG]도 사용됩니다.
자격 증명 관리: 이 문서에서 기술한 API는 Credential 개념을 확장한 것으로, [CREDENTIAL-MANAGEMENT-1]에서 정의합니다.
DOM: DOMException 및 이 명세서에서 사용하는 DOMException 값은 [DOM4]에서 정의합니다.
ECMAScript: %ArrayBuffer%는 [ECMAScript]에서 정의합니다.
HTML: 브라우징 컨텍스트, 오리진, 불투명 오리진, 튜플 오리진, 관련 설정 객체, 그리고 등록 가능한 도메인 접미사이거나 동일 여부의 개념은 [HTML]에서 정의합니다.
URL: 동일 사이트 개념은 [URL]에서 정의합니다.
Web IDL: 이 명세서의 많은 인터페이스 정의와 모든 IDL은 [WebIDL]에 의존합니다. Web IDL 표준의 업데이트 버전은 Promise를 지원하며, 이는 이제 새로운 웹 API에서 비동기 상호작용을 위한 권장 메커니즘입니다.
FIDO AppID: 호출 애플리케이션의 FacetID 결정 알고리즘 및 호출자의 FacetID가 AppID에 대해 권한이 있는지 결정 알고리즘(AppID 확장에서만 사용)은 [FIDO-APPID]에서 정의합니다.

이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 등의 키워드는 [RFC2119]에서 설명된 대로 해석해야 합니다.

4. 용어

Attestation

일반적으로 attestation은 증언, 확인, 인증의 역할을 하는 진술입니다. WebAuthn 맥락에서 attestation은 authenticator 및 그가 생성한 데이터의 출처를 증명하는 데 사용됩니다. 예를 들어 credential ID, credential key pair, 서명 카운터 등입니다. attestation statement는 attestation object 내에 registration 중 전달됩니다. § 6.5 Attestation 및 그림 6도 참고하세요. client가 attestation statement와 AAGUID 부분을 attestation object로 Relying Party에 전달하는 방식은 attestation conveyance에서 설명합니다.

Attestation Certificate

attestation key pair에 대한 X.509 인증서로, authenticator가 제조 및 기능을 attest할 때 사용합니다. registration 시점에, authenticator는 attestation private key로 Relying Party별 credential public key(및 추가 데이터)를 서명하여 authenticatorMakeCredential 작업으로 반환합니다. Relying Party는 attestation public key를 attestation certificate에서 받아 attestation signature를 검증합니다. self attestation의 경우 authenticator는 별도의 attestation key pair나 attestation certificate가 없습니다. 자세한 내용은 self attestation 참고.

Authentication

Authentication Ceremony

ceremony로, 사용자와 사용자의 client(최소 하나의 authenticator 포함)가 협력하여 Relying Party에게 사용자가 기존에 등록한 credential private key를 제어함을 암호학적으로 증명합니다(자세한 설명은 Registration 참조). 여기에는 사용자 존재 테스트 또는 사용자 검증이 포함됩니다.

WebAuthn authentication ceremony는 § 7.2 인증 주장 검증에서 정의되며, Relying Party가 navigator.credentials.get()에 publicKey 인자를 전달하여 시작합니다. § 5 Web 인증 API 및 § 1.3.3 인증의 구현 예시도 참고하세요.

Authentication Assertion

Assertion

AuthenticatorAssertionResponse 객체로, authenticator가 authenticatorGetAssertion 작업 결과로 반환합니다.

이는 [CREDENTIAL-MANAGEMENT-1] 명세의 단일 사용 credentials과 대응됩니다.

Authenticator

WebAuthn Authenticator

하드웨어 또는 소프트웨어에 존재하는 암호학적 엔티티로, 사용자 등록과 이후 등록된 공개 키 자격 증명의 소유 주장, 그리고 필요시 사용자 검증까지 Relying Party의 요청에 따라 수행합니다. Authenticator는 유형 및 보안 특성 정보를 attestation을 통해 등록 중에 보고할 수 있습니다.

WebAuthn Authenticator는 로밍 인증기, 클라이언트 디바이스에 통합된 전용 하드웨어 서브시스템, 혹은 클라이언트 또는 클라이언트 디바이스의 소프트웨어 구성 요소일 수 있습니다.

일반적으로 authenticator는 한 명의 사용자만을 가정합니다. 여러 명의 자연인이 하나의 authenticator에 접근하는 경우, 해당 authenticator 맥락에서는 같은 사용자로 간주합니다. 만약 authenticator 구현이 분리된 영역별로 여러 사용자를 지원한다면, 각 영역은 독립적인 authenticator로 간주하며, 영역 간 자격 증명은 공유되지 않습니다.

Authorization Gesture

authorization gesture는 사용자가 인증기와 물리적으로 상호작용하는 것으로, ceremony의 일부입니다. 예를 들어 등록 또는 인증과 같은 경우가 있습니다. 사용자가 이러한 authorization gesture를 수행함으로써 동의를 제공(즉, 인증 ceremony 진행을 승인)하게 됩니다. 만약 사용된 authenticator가 지원한다면 사용자 검증이 포함될 수 있고, 그렇지 않으면 단순한 사용자 존재 테스트일 수도 있습니다.

Biometric Recognition

생체 및 행동적 특성에 근거하여 개인을 자동으로 인식하는 것 [ISOBiometricVocabulary].

Biometric Authenticator

biometric recognition을 구현한 authenticator입니다.

Bound credential

public key credential source 또는 public key credential이 자신의 managing authenticator에 바인딩된 경우를 의미합니다. 즉, 그 managing authenticator만 해당 public key credential sources에 대한 assertion을 생성할 수 있습니다.

Ceremony

ceremony [Ceremony]는 네트워크 프로토콜의 개념을 확장한 것으로, 컴퓨터 노드와 함께 인간 노드가 있고 사용자 인터페이스·사람 간 소통·데이터가 담긴 물리적 오브젝트 전달 등이 포함됩니다. 프로토콜에선 out-of-band인 것이 ceremony에선 in-band입니다. 본 명세서에서 등록과 인증이 ceremony에 해당하며, authorization gesture가 그 구성 요소가 되는 경우가 많습니다.

Client

WebAuthn Client

이 문서에서는 간단히 client라고도 합니다. 준수 사용자 에이전트도 참고. WebAuthn Client는 일반적으로 사용자 에이전트에 구현된 중개 엔티티입니다(전체 또는 일부). Web 인증 API의 기반이 되며, [[Create]](origin, options, sameOriginWithAncestors), [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드를 구현합니다. 인증기 작업의 입력을 준비하고 결과를 Web 인증 API 호출자에게 반환합니다.

WebAuthn Client는 WebAuthn Client Device에서 실행되며, 서로 구분됩니다.

Client Device

WebAuthn Client Device

WebAuthn Client가 실행되는 하드웨어(예: 스마트폰, 노트북, 데스크탑)와 그 운영체제입니다.

WebAuthn Client 디바이스와 client의 차이는 다음과 같습니다:

하나의 client device는 여러 client(브라우저 구현 등)를 지원할 수 있고, 이들은 모두 해당 authenticator에 접근 가능
플랫폼 인증기는 client device에 바인딩되며, WebAuthn Client에 바인딩되지 않습니다.

client device와 client가 합쳐져 client platform을 이룹니다.

Client Platform

client device와 client가 합쳐져 client platform이 됩니다. 하나의 하드웨어 디바이스는 다양한 운영체제나 client를 실행함으로써 각기 다른 client platform에 속할 수 있습니다.

클라이언트 측

이는 일반적으로 사용자의 클라이언트 플랫폼, 인증기, 그리고 이를 모두 연결하는 모든 것을 의미합니다.

클라이언트 측 검색 가능한 공개 키 자격 증명 소스

클라이언트 측 검색 가능한 자격 증명

검색 가능한 자격 증명

[DEPRECATED] 레지던트 자격 증명

[DEPRECATED] 레지던트 키

참고: 기존에는 클라이언트 측 검색 가능한 자격 증명이 레지던트 자격 증명 또는 레지던트 키로 불렸습니다. ResidentKey와 residentKey라는 용어는 WebAuthn API와 인증기 모델(예: 딕셔너리 멤버 이름, 알고리즘 변수명, 작업 파라미터 등)에서 널리 사용되어, 하위 호환성을 위해 이름 변경이 이루어지지 않았습니다. 또한 레지던트 키는 여기서 클라이언트 측 검색 가능한 자격 증명과 동일한 의미로 정의됩니다.

클라이언트 측 검색 가능한 공개 키 자격 증명 소스(줄여서 검색 가능한 자격 증명이라고 함)는 공개 키 자격 증명 소스 중 검색 가능하며, 인증 절차에서 신뢰당사자가 자격 증명 ID를 제공하지 않을 때 사용할 수 있습니다. 즉, 신뢰당사자가 navigator.credentials.get() 호출 시 비어 있는 allowCredentials 인자를 전달하는 경우입니다. 즉, 신뢰당사자가 반드시 먼저 사용자를 식별할 필요가 없습니다.

결과적으로 검색 가능한 자격 증명 지원 인증기는 RP ID만으로 검색 가능한 자격 증명에 대한 assertion signature를 생성할 수 있으며, 이는 공개 키 자격 증명 소스가 인증기 또는 클라이언트 플랫폼에 저장되어야 함을 의미합니다. 이는 서버 측 공개 키 자격 증명 소스와 대조되며, 서버 측 자격 증명 소스는 인증기에 RP ID와 자격 증명 ID를 모두 전달해야 하지만, 클라이언트 측에 공개 키 자격 증명 소스를 저장할 필요는 없습니다.

참고: 클라이언트 측 자격 증명 저장 방식 및 비검색 자격 증명도 참고하세요.

참고: 클라이언트 측 검색 가능한 자격 증명은 인증 절차에서 자격 증명 ID가 제공되는 경우에도 사용할 수 있습니다. 즉, navigator.credentials.get() 호출 시 비어 있지 않은 allowCredentials 인자를 전달하는 경우에도 사용할 수 있습니다.

준수 사용자 에이전트

기저 클라이언트 디바이스와 협력하여 Web 인증 API 및 본 명세서의 알고리즘을 구현하고, 인증기와 신뢰당사자 간의 통신을 처리하는 사용자 에이전트입니다.

자격 증명 ID

확률적으로 고유한 바이트 시퀀스로, 공개 키 자격 증명 소스와 그 인증 주장을 식별합니다.

자격 증명 ID는 인증기에 의해 두 가지 형태로 생성됩니다:

최소 16 바이트, 최소 100 비트의 엔트로피를 포함하거나
공개 키 자격 증명 소스에서 자격 증명 ID나 변경 가능한 항목을 제외하고 암호화하여, 해당 관리 인증기만 복호화할 수 있도록 하는 것. 이 방식은 인증기를 거의 무상태로 만들 수 있으며, 필요한 상태 저장을 신뢰당사자가 담당합니다.

참고: [FIDO-UAF-AUTHNR-CMDS]에는 "보안 가이드라인" 하단에 암호화 기법 안내가 포함되어 있습니다.

신뢰당사자는 이 두 가지 자격 증명 ID의 형태를 구분할 필요가 없습니다.

자격 증명 키 쌍

자격 증명 개인 키

자격 증명 공개 키

사용자 공개 키

자격 증명 키 쌍은 인증기가 생성하며, 특정 스코프의 WebAuthn 신뢰당사자에 귀속됩니다. 이는 공개 키 자격 증명의 핵심 부분입니다.

자격 증명 공개 키는 자격 증명 키 쌍의 공개 키 부분입니다. 자격 증명 공개 키는 신뢰당사자에게 등록 절차 중 반환됩니다.

자격 증명 개인 키는 자격 증명 키 쌍의 개인 키 부분입니다. 자격 증명 개인 키는 특정 인증기 — 즉 관리 인증기 —에 바인딩되며, 인증기 소유자에게조차 외부로 노출되어서는 안 됩니다.

참고로 자체 보증의 경우 자격 증명 키 쌍이 보증 키 쌍으로도 사용됩니다. 상세 사항은 자체 보증 참고.

참고: 자격 증명 공개 키는 FIDO UAF [UAFProtocol] 및 FIDO U2F [FIDO-U2F-Message-Formats], 그리고 본 명세서의 일부 관련 부분에서 사용자 공개 키로 불리기도 합니다.

자격 증명 속성

자격 증명 속성은 공개 키 자격 증명 소스의 특성(예: 클라이언트 측 검색 가능한 자격 증명 또는 서버 측 자격 증명 여부 등)을 의미합니다.

사람 친화성

사람 친화적인 식별자는 일반적인 사용자가 기억하고 재생산하기 쉬운 형태를 의미하며, 무작위 비트 시퀀스와 같은 식별자와 대비됩니다 [EduPersonObjectClassSpec].

비검색 자격 증명

이는 자격 증명 중 자격 증명 ID를 allowCredentials에 반드시 제공해야 하는 경우를 의미하며, navigator.credentials.get() 호출 시 클라이언트 측 검색 가능하지 않습니다. 서버 측 자격 증명도 참고하세요.

공개 키 자격 증명 소스

자격 증명 소스 ([CREDENTIAL-MANAGEMENT-1])는 인증기가 인증 주장을 생성할 때 사용합니다. 공개 키 자격 증명 소스는 다음 구조체 항목으로 구성됩니다:

type: 값은 PublicKeyCredentialType이며, 기본값은 public-key입니다.
id: 자격 증명 ID입니다.
privateKey: 자격 증명 개인 키입니다.
rpId: 신뢰 당사자 식별자로, 본 공개 키 자격 증명 소스가 스코프되는 신뢰 당사자입니다.
userHandle: 본 공개 키 자격 증명 소스가 생성될 때 연관된 사용자 핸들입니다. 이 항목은 null일 수 있습니다.
otherUI: 선택적 항목으로, 인증기가 UI에 정보를 제공할 때 사용합니다. 예를 들어 사용자의 displayName 등이 있을 수 있습니다. otherUI는 변경 가능한 항목이며, 공개 키 자격 증명 소스에 바인딩되어 otherUI가 업데이트되지 못하도록 하면 안 됩니다.

authenticatorMakeCredential 작업은 공개 키 자격 증명 소스를 생성하여 관리 인증기에 관리 인증기로 바인딩하고, 자격 증명 개인 키에 연관된 자격 증명 공개 키를 반환합니다. 신뢰 당사자는 이 자격 증명 공개 키로 인증 주장을 검증할 수 있습니다.

공개 키 자격 증명

일반적으로 자격 증명(credential)이란 한 엔티티가 다른 엔티티에게 자신을 인증(authenticate)하기 위해 제시하는 데이터입니다 [RFC4949]. 공개 키 자격 증명은 다음 중 하나를 의미합니다: 공개 키 자격 증명 소스, 보증(attested)된 자격 증명 공개 키(공개 키 자격 증명 소스에 해당), 또는 인증 주장. 어떤 의미인지는 보통 문맥에 따라 결정됩니다.

참고: 이것은 의도적 위반(willful violation)입니다 [RFC4949]. 영어에서 "credential"은 a) 진술을 증명하기 위해 제시되는 것, b) 여러 번 사용되는 것의 두 뜻을 모두 가집니다. 공개 키 시스템에서는 하나의 데이터로 두 기준을 모두 안전하게 달성할 수 없습니다. [RFC4949]는 credential을 여러 번 사용할 수 있는 것(공개 키)으로 정의하지만, 본 명세서는 영어 의미의 유연성을 채택합니다. 이 명세서는 [RFC4949] credential 관련 데이터를 식별할 때 더 구체적인 용어를 사용합니다:

"Authentication information" (개인 키 포함 가능): 공개 키 자격 증명 소스
"Signed value": 인증 주장
[RFC4949] "credential": 자격 증명 공개 키 또는 보증 객체(attestation object)

등록 시점에 인증기가 비대칭 키 쌍을 생성하고, 개인 키 부분과 신뢰 당사자 정보를 공개 키 자격 증명 소스에 저장합니다. 공개 키 부분은 신뢰 당사자에 반환되어 현재 사용자의 계정과 함께 저장됩니다. 이후 신뢰 당사자(RP ID로 식별됨)만 공개 키 자격 증명을 인증 절차에서 get() 메서드로 사용할 수 있습니다. 신뢰 당사자는 저장된 자격 증명 공개 키를 사용해 반환된 인증 주장을 검증합니다.

속도 제한

속도 제한(throttling)은 인증기가 연속된 인증 실패 시도 횟수를 제한하여 무차별 대입(brute force) 공격을 방지하는 방식입니다. 제한에 도달하면, 인증기는 시도할 때마다 지연을 기하급수적으로 늘리거나, 현재 인증 방식 사용을 비활성화하고 다른 인증 요소를 제공할 수 있습니다. 속도 제한은 사용자 검증의 일부로 자주 구현됩니다.

등록

등록 절차

ceremony로, 사용자, 신뢰 당사자, 그리고 사용자의 클라이언트(최소 하나의 인증기 포함)가 협력하여 공개 키 자격 증명을 생성하고 사용자의 신뢰 당사자 계정과 연결합니다. 여기에는 사용자 존재 테스트 또는 사용자 검증이 포함됩니다. 등록 절차에 성공하면, 사용자는 인증 절차로 인증받을 수 있습니다.

WebAuthn 등록 절차는 § 7.1 새 자격 증명 등록에서 정의되며, 신뢰 당사자가 navigator.credentials.create() 메서드에 publicKey 인자를 전달하여 시작합니다. § 5 Web 인증 API 및 § 1.3.1 등록의 구현 예시도 참고하세요.

신뢰 당사자

WebAuthn 신뢰 당사자 참고.

신뢰 당사자 식별자

RP ID

WebAuthn API 맥락에서, 신뢰 당사자 식별자는 유효한 도메인 문자열로, 특정 WebAuthn 신뢰 당사자를 식별합니다. 등록 또는 인증 절차가 해당 신뢰 당사자를 위해 수행됩니다. 공개 키 자격 증명은 등록된 동일한 엔티티(RP ID로 식별됨)에서만 인증에 사용할 수 있습니다.

기본적으로 WebAuthn 작업의 RP ID는 호출자의 origin의 유효 도메인으로 설정됩니다. 호출자가 지정한 RP ID 값이 등록 가능한 도메인 접미사이거나 동일해야 하며, origin의 유효 도메인과 일치해야 합니다. § 5.1.3 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 메서드 및 § 5.1.4 기존 자격 증명으로 주장 생성 - PublicKeyCredential의 [[Get]](options) 메서드도 참고하세요.

참고: RP ID는 호스트의 도메인 이름 기반입니다. 스킴이나 포트는 포함하지 않으며, origin과 구분됩니다. 공개 키 자격 증명의 RP ID는 그 스코프를 결정합니다. 즉, 어떤 오리진에서 해당 공개 키 자격 증명을 사용할 수 있는지 적용 가능한 오리진 집합을 결정합니다:

RP ID는 origin의 유효 도메인과 같거나, 등록 가능한 도메인 접미사여야 합니다.
origin의 스킴은 반드시 https여야 합니다.
origin의 포트는 제한되지 않습니다.

예를 들어, 오리진이 https://login.example.com:1337인 신뢰 당사자의 경우, 유효한 RP ID는 login.example.com(기본값), example.com이며, m.login.example.com이나 com은 유효하지 않습니다.

이는 광범위하게 배포된 ambient credential(예: 쿠키, [RFC6265])의 동작과 맞추기 위함입니다. "same-origin" 제한보다 더 완화된 점에 유의하세요(document.domain setter보다 완화됨).

이러한 오리진 값 제한은 WebAuthn 클라이언트에 적용됩니다.

WebAuthn API를 모방해 웹이 아닌 플랫폼(예: 네이티브 모바일 앱)에서 WebAuthn 공개 키 자격 증명을 지원하는 명세는 호출자와 신뢰 당사자 식별자 바인딩에 대해 다른 규칙을 정의할 수 있습니다. 단, RP ID 구문은 반드시 유효한 도메인 문자열 또는 URI [RFC3986], [URL]을 따라야 합니다.

서버 측 공개 키 자격 증명 소스

서버 측 자격 증명

[DEPRECATED] 비상주 자격 증명

참고: 기존에는 서버 측 자격 증명이 비상주 자격 증명으로 불렸습니다. 하위 호환성을 위해 WebAuthn API와 인증기 모델의 이름 중 resident가 포함된 부분은 변경되지 않았습니다.

서버 측 공개 키 자격 증명 소스(줄여서 서버 측 자격 증명)는 공개 키 자격 증명 소스 중 인증 절차에서 신뢰 당사자가 자격 증명 ID를 navigator.credentials.get()의 allowCredentials 인자로 제공해야만 사용할 수 있는 것입니다. 즉, 신뢰 당사자가 자격 증명의 저장·검색을 관리하고, 사용자를 먼저 식별해 자격 증명 ID를 찾아 제공해야 합니다.

클라이언트 측에 공개 키 자격 증명 소스를 저장할 필요는 서버 측 자격 증명에는 없습니다. 이는 클라이언트 측 검색 가능한 자격 증명과 대조됩니다. 후자는 사용자를 먼저 식별하지 않아도 자격 증명 ID를 navigator.credentials.get()에 제공할 수 있습니다.

참고: 서버 측 자격 증명 저장 방식 및 비검색 자격 증명도 참고하세요.

사용자 존재 테스트

사용자 존재 테스트는 인증 제스처의 단순한 형태로, 사용자가 인증기와(보통은) 터치 등으로 상호작용하면 Boolean 결과를 얻는 기술적 과정입니다(다른 방식도 있을 수 있음). 이는 사용자 검증이 아니며, 생체 인식이나 비밀번호/PIN 등 공유 비밀을 사용하지 않습니다.

사용자 동의

사용자 동의란 사용자가 요청받는 내용을 동의한다는 의미이며, 프롬프트를 읽고 이해하는 것도 포함합니다. 인증 제스처는 ceremony의 구성 요소로 자주 사용되며, 사용자 동의를 나타냅니다.

사용자 핸들

사용자 핸들은 신뢰 당사자가 user.id 값으로 지정하며, 특정 공개 키 자격 증명을 신뢰 당사자의 특정 사용자 계정에 매핑하는 데 사용합니다. 인증기는 매핑을 통해 RP ID와 사용자 핸들 쌍을 공개 키 자격 증명 소스에 매핑합니다.

사용자 핸들은 최대 64바이트의 불투명한 바이트 시퀀스이며, 사용자가 직접 볼 수 있도록 설계되지 않았습니다.

사용자 검증

인증기가 로컬로 authenticatorMakeCredential 및 authenticatorGetAssertion 작업 실행을 승인하는 기술적 과정입니다. 사용자 검증은 다양한 인증 제스처(터치+PIN, 비밀번호, 생체 인식(예: 지문) 등)로 시작할 수 있습니다 [ISOBiometricVocabulary]. 목적은 개별 사용자를 구별하는 것입니다.

사용자 검증은 신뢰 당사자에게 사용자의 구체적인 신원을 제공하지 않습니다. 그러나 동일 자격 증명으로 두 번 이상 사용자 검증 ceremony를 수행했다면, 두 ceremony 모두 같은 사용자가 수행한 것임을 의미합니다. 단, 동일 사용자가 항상 동일한 자연인이라는 보장은 없습니다. 여러 명의 자연인이 하나의 인증기에 접근할 수도 있기 때문입니다.

참고: 자연인 구별은 클라이언트 플랫폼과 인증기의 기능에 크게 좌우됩니다. 예를 들어, 일부 디바이스는 한 명이 사용하도록 설계되었지만 여러 사람이 지문을 등록하거나 동일 PIN을 알게 되어 동일 신뢰 당사자 계정에 접근할 수 있습니다.

참고: authenticatorMakeCredential 및 authenticatorGetAssertion 호출은 인증기가 관리하는 키 재료 사용을 암시합니다.

또한 보안을 위해 사용자 검증과 자격 증명 개인 키 사용은 모두 인증기를 정의하는 논리적 보안 경계 내에서 이루어져야 합니다.

사용자 검증 절차는 무차별 대입 공격 방지를 위해 속도 제한을 구현할 수 있습니다.

사용자 존재 확인

UP

사용자 존재 테스트가 성공적으로 완료되면, 사용자는 "존재함"으로 간주됩니다.

사용자 검증됨

UV

사용자 검증 절차가 성공적으로 끝나면, 사용자는 "검증됨"으로 간주됩니다.

WebAuthn 신뢰 당사자

웹 애플리케이션이 Web 인증 API를 사용하여 등록 및 인증을 수행합니다.

신뢰 당사자 구현은 일반적으로 Web 인증 API를 클라이언트에서 호출하는 클라이언트 측 스크립트와, 신뢰 당사자 작업 등 애플리케이션 로직을 실행하는 서버 측 구성 요소로 이루어집니다. 두 구성 요소 간 통신은 반드시 HTTPS 또는 이에 준하는 전송 보안을 사용해야 하며, 그 외 부분은 본 명세서 범위 밖입니다.

참고: 신뢰 당사자라는 용어는 X.509, OAuth 등 다른 맥락에서도 자주 쓰이지만, 한 맥락에서 신뢰 당사자 역할을 한다고 해서 다른 맥락에서도 반드시 신뢰 당사자가 되는 것은 아닙니다. 본 명세서에서 WebAuthn 신뢰 당사자는 보통 신뢰 당사자로 줄여 쓰며, WebAuthn 맥락의 신뢰 당사자를 명시적으로 지칭합니다. 실제 구현에서는 WebAuthn 맥락이 OAuth 등 더 넓은 맥락에 포함될 수도 있습니다.

5. 웹 인증 API

이 섹션은 공개 키 자격 증명의 생성 및 사용을 위한 API를 규범적으로 명세합니다. 기본 개념은 자격 증명이 사용자에게 속하며, 관리는 WebAuthn 인증기가 맡고, WebAuthn 신뢰 당사자는 클라이언트 플랫폼을 통해 상호작용합니다. 신뢰 당사자 스크립트는 (사용자의 동의 하에) 브라우저에 새로운 자격 증명을 생성해 이후 신뢰 당사자가 사용할 수 있게 요청할 수 있습니다. 아래 그림 참고.

스크립트는 또한 기존 자격 증명을 이용한 인증 작업에 대해 사용자 권한을 요청할 수 있습니다. 아래 그림 참고.

이러한 모든 작업은 인증기 내에서 수행되며, 클라이언트 플랫폼이 사용자를 대신해 중재합니다. 스크립트는 자격 증명 자체에는 절대 접근하지 못하며, 자격 증명에 대한 정보를 객체 형태로만 받게 됩니다.

위의 스크립트 인터페이스 외에도, 인증기는(혹은 동반 클라이언트 소프트웨어가) 관리용 사용자 인터페이스를 구현할 수 있습니다. 이러한 인터페이스는 예를 들어 인증기를 초기화하거나 현재 상태를 확인하는 데 사용할 수 있습니다. 즉, 이는 브라우저가 히스토리, 저장된 비밀번호, 쿠키 등 사용자 상태 관리를 위해 제공하는 UI와 유사합니다. 자격 증명 삭제와 같은 인증기 관리 동작은 이런 사용자 인터페이스의 책임이며, 일부러 API에서 스크립트에 노출하지 않았습니다.

이 API의 보안 속성은 클라이언트와 인증기가 협력하여 제공합니다. 인증기는 자격 증명을 보유 및 관리하며, 모든 작업을 특정 스코프의 오리진에 한정하며, 응답에 오리진을 포함시킴으로써 다른 오리진에서 재사용(replay)되지 못하게 합니다. 구체적으로, § 6.3 인증기 작업에서 정의된 대로, 요청자의 전체 오리진이 새로운 자격 증명 생성 시 생성되는 보증 객체 및 모든 WebAuthn 자격 증명 주장에 포함 및 서명됩니다.

또한 사용자 프라이버시 보호 및 악의적 신뢰 당사자가 다른 신뢰 당사자의 공개 키 자격 증명 존재 여부를 탐지하는 것을 막기 위해, 각각의 자격 증명은 스코프된 신뢰 당사자 식별자 또는 RP ID에 귀속됩니다. 클라이언트는 모든 작업에 대해 이 RP ID를 인증기에 제공합니다. 인증기는 신뢰 당사자가 만든 자격 증명이 동일 RP ID 요청에서만 사용될 수 있도록 보장합니다. 오리진과 RP ID를 분리함으로써, 하나의 신뢰 당사자가 여러 오리진을 운영하는 경우에도 API를 사용할 수 있게 됩니다.

클라이언트는 이러한 보안 조치를 지원하기 위해 각 작업마다 신뢰 당사자의 오리진 및 RP ID를 인증기에 제공합니다. 이는 WebAuthn 보안 모델의 핵심이므로, 사용자 에이전트는 보안 컨텍스트에서만 이 API를 노출합니다. 특히 웹 컨텍스트에서는, TLS 등 오류 없는 안전한 전송을 통해 접근한 경우에만 해당됩니다.

웹 인증 API는 이후 섹션에 제시된 Web IDL 조각의 합집합으로 정의됩니다. 통합된 IDL 목록은 IDL 색인에서 볼 수 있습니다.

5.1. `PublicKeyCredential` 인터페이스

PublicKeyCredential

모든 현행 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera미지원Edge79+

Edge (레거시)18IE미지원

Android용 Firefox60+iOS Safari13.3+Android용 Chrome70+Android WebView70+Samsung Internet미지원Opera Mobile미지원

PublicKeyCredential 인터페이스는 Credential [CREDENTIAL-MANAGEMENT-1]에서 상속되며, 새 자격 증명이 생성되거나, 새로운 주장이 요청될 때 호출자에게 반환되는 속성을 포함합니다.

PublicKeyCredential/getClientExtensionResults

모든 현행 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera미지원Edge79+

Edge (레거시)18IE미지원

Android용 Firefox60+iOS Safari13.3+Android용 Chrome70+Android WebView70+Samsung Internet미지원Opera Mobile미지원

PublicKeyCredential/rawId

모든 현행 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera미지원Edge79+

Edge (레거시)18IE미지원

Android용 Firefox60+iOS Safari13.3+Android용 Chrome70+Android WebView70+Samsung Internet미지원Opera Mobile미지원

[SecureContext, Exposed=Window]
interface PublicKeyCredential : Credential {
    [SameObject] readonly attribute ArrayBuffer              rawId;
    [SameObject] readonly attribute AuthenticatorResponse    response;
    AuthenticationExtensionsClientOutputs getClientExtensionResults();
};

id

이 속성은 Credential에서 상속된 것이지만, PublicKeyCredential은 Credential의 getter를 오버라이드하여, 객체의 [[identifier]] 내부 슬롯에 담긴 데이터를 base64url 인코딩 형식으로 반환합니다.

rawId

이 속성은 ArrayBuffer 객체를 반환하며, [[identifier]] 내부 슬롯에 담겨 있습니다.

PublicKeyCredential/response 모든 현행 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera미지원Edge79+ Edge (레거시)18IE미지원 Android용 Firefox60+iOS Safari13.3+Android용 Chrome70+Android WebView70+Samsung Internet미지원Opera Mobile미지원 response, 타입 AuthenticatorResponse, 읽기전용

이 속성에는 인증기가 클라이언트의 요청에 대해 반환하는 응답이 담깁니다. 새 공개 키 자격 증명 생성 시 또는 인증 주장 생성 시 모두 해당. PublicKeyCredential 객체가 create() 결과로 생성된 경우, 이 값은 AuthenticatorAttestationResponse이고, get() 결과로 생성된 경우, 이 값은 AuthenticatorAssertionResponse입니다.

getClientExtensionResults()

이 연산은 [[clientExtensionsResults]] 값을 반환하며, 이는 맵 타입으로 확장 식별자 → 클라이언트 확장 출력 쌍이 들어 있습니다. 이 값은 확장의 클라이언트 확장 처리에서 생성됩니다.

[[type]]

PublicKeyCredential 인터페이스 객체의 [[type]] 내부 슬롯 값은 문자열 "public-key"입니다.

참고: 이는 type 속성 getter를 통해 반영되며, 해당 getter는 Credential에서 상속됩니다.

[[discovery]]

PublicKeyCredential 인터페이스 객체의 [[discovery]] 내부 슬롯 값은 "remote"입니다.

[[identifier]]

이 내부 슬롯에는 자격 증명 ID가 저장됩니다. 이 값은 인증기가 선택합니다. 자격 증명 ID는 자격 증명을 조회하는 데 사용되며, 동일 타입의 모든 인증기 전체에서 높은 확률로 전역 유일해야 합니다.

참고: 이 API는 해당 식별자의 형식이나 길이를 제한하지 않으나, 인증기가 키를 고유하게 선택할 수 있을 만큼 충분해야 합니다. 예를 들어, 온보드 저장소가 없는 인증기는 대칭 키로 래핑된 자격 증명 개인 키를 포함하는 식별자를 생성할 수 있습니다.

[[clientExtensionsResults]]

이 내부 슬롯에는 신뢰 당사자가 navigator.credentials.create() 또는 navigator.credentials.get() 호출 시 요청한 클라이언트 확장 처리 결과가 들어 있습니다.

PublicKeyCredential의 인터페이스 객체는 Credential의 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 구현을 상속하며, [[Create]](origin, options, sameOriginWithAncestors), [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors), 그리고 [[Store]](credential, sameOriginWithAncestors) 구현을 정의합니다.

5.1.1. `CredentialCreationOptions` 딕셔너리 확장

navigator.credentials.create() 를 통한 등록 지원을 위해, 본 문서는 CredentialCreationOptions 딕셔너리를 아래와 같이 확장합니다:

partial dictionary CredentialCreationOptions {
    PublicKeyCredentialCreationOptions      publicKey;
};

5.1.2. `CredentialRequestOptions` 딕셔너리 확장

navigator.credentials.get() 를 통한 주장 획득 지원을 위해, 본 문서는 CredentialRequestOptions 딕셔너리를 아래와 같이 확장합니다:

partial dictionary CredentialRequestOptions {
    PublicKeyCredentialRequestOptions      publicKey;
};

5.1.3. 새 자격 증명 생성 - PublicKeyCredential의 `[[Create]](origin, options, sameOriginWithAncestors)` 메서드

PublicKeyCredential 인터페이스 객체의

[[Create]](origin,
options, sameOriginWithAncestors)

내부 메서드 [CREDENTIAL-MANAGEMENT-1]은 WebAuthn 신뢰 당사자 스크립트가 navigator.credentials.create() 를 호출해 새로운 공개 키 자격 증명 소스를 인증기에 바인딩하여 생성하도록 합니다. 이 navigator.credentials.create() 작업은 AbortController를 활용해 중단(abort)할 수 있습니다. 자세한 내용은 DOM §3.3 AbortController 및 AbortSignal 객체의 API 통합를 참고하세요.

이 내부 메서드는 세 개의 인자를 받습니다:

origin

이 인자는 호출하는 create() 구현에 의해 결정된 관련 설정 객체의 오리진입니다.

options

이 인자는 CredentialCreationOptions 객체이며, options.publicKey 멤버에 PublicKeyCredentialCreationOptions 객체가 포함되어, 생성할 공개 키 자격 증명의 원하는 속성을 지정합니다.

sameOriginWithAncestors

이 인자는 Boolean 값이며, 호출자의 환경 설정 객체가 상위와 동일 오리진일 때만 true입니다. 교차 오리진인 경우 false입니다.

참고: 이 내부 메서드 호출은 권한 정책에 의해 허용된 경우를 의미하며, 이는 [CREDENTIAL-MANAGEMENT-1] 수준에서 평가됩니다. § 5.9 권한 정책 통합도 참고하세요.

참고: 이 알고리즘은 동기적입니다: Promise resolve/reject 처리는 navigator.credentials.create() 에서 처리됩니다.

참고: 본 알고리즘에서 사용되는 모든 BufferSource 객체는 알고리즘 시작 시 스냅샷(복사본)으로 처리해야 동기화 문제를 피할 수 있습니다. 구현체는 버퍼 소스의 바이트 복사본을 얻어 해당 부분에 사용해야 합니다.

이 메서드가 호출되면, 사용자 에이전트는 다음 알고리즘을 실행해야 합니다:

단언: options.publicKey가 존재함을 확인한다.
sameOriginWithAncestors가 false라면, "NotAllowedError" DOMException을 반환한다.

참고: 이 "sameOriginWithAncestors" 제한은 이슈 #1336에서 제기된 추적(tracking) 우려를 해결하기 위한 것입니다. 향후 명세 버전에서 변경될 수 있습니다.
options를 options.publicKey의 값으로 둔다.
timeout 멤버가 있을 경우, 그 값이 클라이언트가 정의한 합리적 범위 내에 있는지 검사하고, 범위를 벗어나면 가장 가까운 허용 값으로 수정한다. lifetimeTimer를 수정된 값으로 설정. timeout 멤버가 없다면, lifetimeTimer를 클라이언트별 기본값으로 설정한다.

아래는 timeout 멤버의 권장 범위 및 기본값입니다. options.authenticatorSelection.userVerification

discouraged로 설정

권장 범위: 30000ms ~ 180000ms

권장 기본값: 120000ms (2분)

required 또는 preferred로 설정

권장 범위: 30000ms ~ 600000ms

권장 기본값: 300000ms (5분)

참고: 사용자 에이전트는 특수 요구가 있는 사용자를 위한 인지적 가이드라인을 고려해야 합니다.
options.user.id 의 길이가 1~64바이트(포함) 사이가 아니면, TypeError를 반환한다.
callerOrigin을 origin으로 둔다. callerOrigin이 불투명 오리진이면, DOMException "NotAllowedError"를 반환하고 알고리즘을 종료한다.
effectiveDomain을 callerOrigin의 유효 도메인으로 둔다. 유효 도메인이 유효한 도메인이 아니면, DOMException "SecurityError"를 반환하고 알고리즘을 종료한다.

참고: 유효 도메인은 호스트로 해석될 수 있으며, 도메인, IPv4 주소, IPv6 주소, 불투명 호스트, 빈 호스트 등 여러 형태가 있습니다. 여기서는 도메인 형식만 허용합니다. 이는 단순화 및 PKI 기반 보안과 IP 주소 직접 사용의 여러 문제를 고려한 것입니다.
만약 options.rp.id

존재함

만약 options.rp.id 등록 가능한 도메인 접미사이거나 동일하지 않으면 effectiveDomain과, DOMException 이름이 "SecurityError"인 예외를 반환하고 알고리즘을 종료한다.

존재하지 않음

options.rp.id 를 effectiveDomain으로 설정한다.

참고: options.rp.id 은 호출자의 RP ID를 나타냅니다. RP ID는 기본적으로 호출자의 origin의 effective domain으로 설정되며, 호출자가 명시적으로 options. rp.id 값을 설정하지 않은 경우에 해당합니다. 만약 create()를 호출할 때 명시적으로 값을 설정했다면 그 값이 사용됩니다.
credTypesAndPubKeyAlgs를 리스트로 새로 만들고, 항목은 PublicKeyCredentialType 과 COSEAlgorithmIdentifier의 쌍으로 한다.
options.pubKeyCredParams의 크기
0인 경우
아래 쌍을 credTypesAndPubKeyAlgs에 추가한다:
- public-key 와 -7("ES256")
- public-key 와 -257("RS256")
0이 아닌 경우
각 current에 대해 options.pubKeyCredParams:
1. current.type 이 현재 구현에서 지원하는 PublicKeyCredentialType을 포함하지 않으면, continue한다.
2. alg를 current.alg로 둔다.
3. 현재 쌍 current.type 와 alg를 credTypesAndPubKeyAlgs에 추가한다.
만약 credTypesAndPubKeyAlgs가 비어 있다면, DOMException 이름이 "NotSupportedError"인 예외를 반환하고 알고리즘을 종료한다.
clientExtensions를 새 맵으로, authenticatorExtensions도 새 맵으로 둔다.
extensions 멤버가 options에 존재하면, 각 extensionId → clientExtensionInput에 대해 options.extensions:
1. extensionId가 해당 클라이언트 플랫폼에서 지원되지 않거나 등록 확장이 아니면 continue한다.
2. clientExtensions[extensionId]를 clientExtensionInput로 설정한다.
3. extensionId가 인증기 확장이 아니면 continue한다.
4. authenticatorExtensionInput을 extensionId의 클라이언트 확장 처리 알고리즘을 clientExtensionInput에 대해 실행한 결과(CBOR)로 둔다. 알고리즘이 오류를 반환하면 continue한다.
5. authenticatorExtensions[extensionId]를 base64url 인코딩한 authenticatorExtensionInput로 설정한다.
collectedClientData를 CollectedClientData 인스턴스로 새로 만들고, 필드는 다음과 같다:

type

문자열 "webauthn.create"

challenge

options.challenge의 base64url 인코딩

origin

callerOrigin의 직렬화

crossOrigin

이 내부 메서드에 전달된 sameOriginWithAncestors 인자의 반대 값

tokenBinding

callerOrigin과 클라이언트 간의 토큰 바인딩 상태와, 토큰 바인딩 ID가 있을 경우 callerOrigin에 연결된 값
clientDataJSON을 collectedClientData로부터 생성된 클라이언트 데이터의 JSON 호환 직렬화로 둔다.
clientDataHash를 clientDataJSON이 나타내는 직렬화된 클라이언트 데이터의 해시로 둔다.
options.signal 이 존재하고 aborted flag가 true일 경우, DOMException 이름이 "AbortError" 인 예외를 반환하고 알고리즘을 종료한다.
issuedRequests를 새로운 순서가 있는 집합으로 둔다.
authenticators를 특정 시점에 집합으로 표현하고, 각 항목은 해당 시점에 이 클라이언트 플랫폼에서 사용 가능한 인증기를 식별한다.

참고: 어떤 인증기가 "사용 가능"으로 간주되는지는 의도적으로 명시되지 않았으며, 이는 인증기가 USB 등으로 핫플러그되거나(NFC, 블루투스 등으로 검색), 클라이언트에 내장되는 등 다양한 방식으로 동작하기 때문임.
lifetimeTimer를 시작한다.
lifetimeTimer가 만료되지 않은 동안, lifetimeTimer 및 authenticators의 각 authenticator의 상태/응답에 따라 다음 작업을 수행한다:
만약 lifetimeTimer가 만료되면,

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 실행하고 issuedRequests에서 제거한다.

사용자가 사용자 에이전트 UI 옵션으로 프로세스를 취소한 경우,

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 실행하고 issuedRequests에서 제거한다. 그리고 DOMException 이름이 "NotAllowedError"인 예외를 반환한다.

options.signal 이 존재하고 aborted flag가 true인 경우

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 실행하고 issuedRequests에서 제거한다. 그리고 DOMException 이름이 "AbortError"인 예외를 반환하고 알고리즘을 종료한다.

클라이언트 디바이스(client device)에 authenticator가 사용 가능 상태가 된 경우,
참고: 이는 lifetimeTimer 시작 시 authenticator가 이미 사용 가능했던 경우도 포함한다.
1. 이 authenticator는 후보 인증기가 된다.
2. options.authenticatorSelection 이 존재한다면:
  1. options.authenticatorSelection.authenticatorAttachment 이 존재하고 값이 authenticator의 인증기 부착 방식과 다르면, continue한다.
  2. options.authenticatorSelection.residentKey
    
    존재하며 required로 설정된 경우
    
    만약 authenticator가 클라이언트 측 검색 가능한 공개 키 자격 증명 소스 저장을 지원하지 않으면, continue한다.
    
    존재하며 preferred 또는 discouraged로 설정된 경우
    
    영향 없음.
    
    존재하지 않는 경우
    
    options.authenticatorSelection.requireResidentKey 이 true로 설정되어 있고 authenticator가 클라이언트 측 검색 가능한 공개 키 자격 증명 소스 저장을 지원하지 않는 경우, continue한다.
  3. options.authenticatorSelection.userVerification 이 required로 설정되어 있고 authenticator가 사용자 검증을 지원하지 않으면, continue한다.
3. requireResidentKey는 자격 증명 생성의 실질적 resident key 요구사항으로, Boolean 값이며 다음과 같다:
  
  options.authenticatorSelection.residentKey
  
  존재하며 required로 설정된 경우
  
  requireResidentKey를 true로 둔다.
  
  존재하며 preferred로 설정된 경우
  
  authenticator
  
  클라이언트 측 자격 증명 저장 방식을 지원함
  
  requireResidentKey를 true로 둔다.
  
  지원하지 않거나 클라이언트가 인증기 기능을 확인할 수 없음
  
  requireResidentKey를 false로 둔다.
  
  존재하며 discouraged로 설정된 경우
  
  requireResidentKey를 false로 둔다.
  
  존재하지 않는 경우
  
  options.authenticatorSelection.requireResidentKey의 값을 requireResidentKey로 둔다.
4. userVerification는 자격 증명 생성의 실질적 사용자 검증 요구사항으로, Boolean 값이며 다음과 같다. options.authenticatorSelection.userVerification
  
  required로 설정된 경우
  
  userVerification를 true로 둔다.
  
  preferred로 설정된 경우
  
  authenticator
  
  사용자 검증을 지원함
  
  userVerification를 true로 둔다.
  
  지원하지 않음
  
  userVerification를 false로 둔다.
  
  discouraged로 설정된 경우
  
  userVerification를 false로 둔다.
5. enterpriseAttestationPossible는 Boolean 값이며, 아래와 같다. options.attestation
  
  enterprise로 설정된 경우
  
  사용자 에이전트가 해당 options.rp.id에 대해 엔터프라이즈 보증을 지원하고자 한다면 true, 아니면 false.
  
  그 외의 경우
  
  enterpriseAttestationPossible를 false로 둔다.
6. excludeCredentialDescriptorList를 새 리스트로 둔다.
7. excludeCredentials의 각 credential descriptor C에 대해:
  1. C.transports 가 비어 있지 않고, authenticator가 해당 transport에 연결되어 있지 않으면 클라이언트는 continue 할 수 있다.
    
    참고: 클라이언트가 continue를 선택할 경우, C.transports 힌트가 부정확하다면 동일 인증기에 여러 자격 증명이 등록될 수 있다. 예를 들면, 소프트웨어 업그레이드로 연결 옵션이 추가되어 힌트가 부정확해질 수 있다.
  2. 그 외의 경우 excludeCredentialDescriptorList에 C를 추가한다.
  3. authenticator에 대해 authenticatorMakeCredential 작업을 clientDataHash, options.rp, options.user, requireResidentKey, userVerification, credTypesAndPubKeyAlgs, excludeCredentialDescriptorList, enterpriseAttestationPossible, authenticatorExtensions를 인자로 호출한다.
8. issuedRequests에 authenticator를 추가한다.
클라이언트 디바이스(client device)에서 authenticator가 사용 불가 상태가 된 경우,

issuedRequests에서 authenticator를 제거한다.

어떤 authenticator가 사용자가 작업을 취소했다는 상태를 반환한 경우,
1. issuedRequests에서 authenticator를 제거한다.
2. issuedRequests의 남은 authenticator에 대해 authenticatorCancel 작업을 실행하고 issuedRequests에서 제거한다.
  
  참고: 인증기는 "사용자가 전체 작업을 취소함"을 명시적으로 반환할 수 있다. 사용자 에이전트가 사용자에게 이 상태를 어떻게 보여줄지는 명세에 포함되지 않음.
어떤 authenticator가 "InvalidStateError"와 동등한 오류 상태를 반환한 경우,
1. issuedRequests에서 authenticator를 제거한다.
2. issuedRequests의 남은 authenticator에 대해 authenticatorCancel 작업을 실행하고 issuedRequests에서 제거한다.
3. DOMException 이름이 "InvalidStateError"인 예외를 반환하고 알고리즘을 종료한다.
참고: 이 오류 상태는 별도로 처리되는데, authenticator가 excludeCredentialDescriptorList가 authenticator에 바인딩된 자격 증명을 식별하고 사용자가 작업에 동의했을 때만 반환하기 때문이다. 명시적 동의가 있으므로 이 경우는 신뢰 당사자에게 구분되어도 된다.
어떤 authenticator가 "InvalidStateError"와 동등하지 않은 오류 상태를 반환한 경우,

issuedRequests에서 authenticator를 제거한다.

참고: 이 경우 작업에 대한 사용자 동의가 없으므로, 오류 세부 정보는 신뢰 당사자에게 노출되지 않음. 자세한 내용은 § 14.5.1 등록 절차 프라이버시 참조.

어떤 authenticator가 성공을 반환한 경우,
1. issuedRequests에서 authenticator를 제거한다. 이 인증기는 선택된 인증기가 된다.
2. credentialCreationData를 구조체로 두고, 항목은 다음과 같다:
  
  attestationObjectResult
  
  값은 성공적으로 authenticatorMakeCredential 작업에서 반환된 바이트이다.
  
  참고: 이 값은 attObj로, § 6.5.4 보증 객체 생성에서 정의됨.
  
  clientDataJSONResult
  
  값은 clientDataJSON의 바이트이다.
  
  attestationConveyancePreferenceOption
  
  값은 options.attestation의 값이다.
  
  clientExtensionResults
  
  값은 AuthenticationExtensionsClientOutputs 객체이며, 확장 식별자 → 클라이언트 확장 출력 엔트리가 들어 있다. 각 확장의 클라이언트 확장 처리 알고리즘을 실행해 클라이언트 확장 출력을 만들고, 클라이언트 확장이 options.extensions에 들어 있을 때만 해당.
3. constructCredentialAlg는 global object global을 인자로 받아 다음 단계로 동작하는 알고리즘으로 둔다:
  1. credentialCreationData.attestationConveyancePreferenceOption 값이
    
    "none"
    
    잠재적으로 고유 식별 가능한 정보를 비식별 버전으로 대체한다:
    
    AAGUID가 attested credential data에 있고 값이 16바이트 0이며, credentialCreationData.attestationObjectResult.fmt 가 "packed"이고, "x5c"가 credentialCreationData.attestationObjectResult에 없으면 self attestation이며 추가 조치 없음.
    
    그 외의 경우
    
    AAGUID를 attested credential data에서 16바이트 0으로 대체한다.
    
    credentialCreationData.attestationObjectResult.fmt 를 "none"으로, credentialCreationData.attestationObjectResult.attStmt를 빈 CBOR 맵으로 설정한다. (자세한 내용은 § 8.7 none 보증 서명 형식 및 § 6.5.4 보증 객체 생성 참고)
    
    "indirect"
    
    클라이언트는 AAGUID 및 보증 서명을 더 프라이버시 친화적이거나 검증이 쉬운 버전(예시로 익명화 CA 활용)으로 대체할 수 있다.
    
    "direct" 또는 "enterprise"
    
    인증기의 AAGUID 및 보증 서명을 변경 없이 신뢰 당사자로 전달한다.
  2. attestationObject를 ArrayBuffer로 새로 만들고, global의 %ArrayBuffer% 생성자를 사용하며, credentialCreationData.attestationObjectResult의 바이트를 담는다.
  3. id를 attestationObject.authData.attestedCredentialData.credentialId로 둔다.
  4. pubKeyCred를 PublicKeyCredential 객체로 새로 만들고, global에 연결하며, 속성은 다음과 같다:
    
    [[identifier]]
    
    id
    
    response
    
    AuthenticatorAttestationResponse 객체로 새로 만들고, global에 연결하며, 속성은 다음과 같다:
    
    clientDataJSON
    
    global의 %ArrayBuffer%를 사용해 credentialCreationData.clientDataJSONResult의 바이트로 새 ArrayBuffer를 만든다.
    
    attestationObject
    
    attestationObject
    
    [[transports]]
    
    0개 이상 고유 DOMString 시퀀스(사전순)로, authenticator가 지원하는 것으로 추정됨. 값은 AuthenticatorTransport 멤버여야 하나, 클라이언트 플랫폼은 알 수 없는 값은 무시해야 함.
    
    사용자 에이전트가 이 정보를 공개하고 싶지 않으면 프라이버시 보호를 위한 임의 시퀀스를 사용할 수 있음. 시퀀스는 반드시 유효해야 하며(사전순, 중복 없음), 예로 빈 시퀀스를 사용할 수 있음. 이 경우 신뢰 당사자 동작이 최적화되지 않을 수 있음.
    
    transport 정보를 알 수 없을 경우 빈 시퀀스로 설정해야 함.
    
    참고: 사용자 에이전트가 인증기가 지원하는 transport를 어떻게 파악하는지는 명세 범위 밖이나, 보증 인증서(예: [FIDO-Transports-Ext]), 인증기 프로토콜(CTAP2 등) 메타데이터, 혹은 플랫폼 인증기에 대한 특수 지식 등이 있을 수 있음.
    
    [[clientExtensionsResults]]
    
    global의 %ArrayBuffer%를 사용해 credentialCreationData.clientExtensionResults의 바이트로 새 ArrayBuffer를 만든다.
  5. pubKeyCred를 반환한다.
4. issuedRequests의 남은 authenticator에 대해 authenticatorCancel 작업을 실행하고 issuedRequests에서 제거한다.
5. constructCredentialAlg를 반환하고 알고리즘을 종료한다.
DOMException 이름이 "NotAllowedError"인 예외를 반환한다. 사용자 동의 없이 사용자를 식별할 수 있는 정보 유출을 막기 위해, 이 단계는 반드시 lifetimeTimer 만료 전에는 실행하지 않아야 한다. 자세한 내용은 § 14.5.1 등록 절차 프라이버시 참고.

위 과정 동안, 사용자 에이전트는 인증기 선택 및 권한 부여 과정을 사용자에게 안내하는 UI를 보여주는 것이 바람직하다.

5.1.4. 기존 자격 증명을 사용해 어서션 생성 - PublicKeyCredential의 `[[Get]](options)` 메서드

WebAuthn Relying Party는 navigator.credentials.get({publicKey:..., ...}) 를 호출하여 기존 공개키 자격 증명을 발견하고 사용할 수 있으며, 이 과정에서 사용자의 동의가 필요합니다. Relying Party 스크립트는 옵션으로 자신에게 허용되는 자격 증명 소스의 기준을 지정할 수 있습니다. 클라이언트 플랫폼은 지정 기준에 맞는 자격 증명 소스를 찾아 사용자가 선택할 수 있도록 안내합니다. 사용자는 스크립트가 사용할 수 있도록 허용된 항목을 선택할 수 있지만, 예를 들어 개인 정보 보호 목적으로 자격 증명 소스가 있어도 전체 상호작용을 거부할 수도 있습니다. 사용자가 자격 증명 소스를 선택하면, 사용자 에이전트는 § 6.3.3 authenticatorGetAssertion 작업을 사용하여 Relying Party가 제공한 챌린지 및 수집된 기타 데이터를 어서션으로 서명하며, 이 어서션은 자격 증명으로 사용됩니다.

get() 구현체 [CREDENTIAL-MANAGEMENT-1]는 PublicKeyCredential.[[CollectFromCredentialStore]]() 를 호출하여 자격 증명 중 사용자 중재(user mediation) 없이(즉, 본 명세의 authorization gesture와 유사) 사용 가능한 것을 수집한다. 만약 정확히 하나만 찾지 못하면, PublicKeyCredential.[[DiscoverFromExternalSource]]() 를 호출하여 사용자가 credential source를 직접 선택하도록 한다.

본 명세는 인가 제스처를 통해서만 자격 증명을 생성할 수 있으므로, PublicKeyCredential.[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 내부 메서드는 Credential.[[CollectFromCredentialStore]]() 의 기본 동작을 상속받아 빈 집합을 반환합니다.

이 navigator.credentials.get() 작업은 AbortController 를 활용하여 중단할 수 있습니다; 자세한 내용은 DOM §3.3 AbortController 및 AbortSignal 객체의 API 통합를 참조하세요.

5.1.4.1. PublicKeyCredential의 `[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)` 메서드

이 내부 메서드는 세 개의 인자를 받습니다:

origin

이 인자는 호출 get() 구현체가 결정한 관련 설정 객체의 origin입니다. 즉, CredentialsContainer의 자격 증명 요청 추상 연산에서 결정됩니다.

options

이 인자는 CredentialRequestOptions 객체이며, options.publicKey 멤버에는 PublicKeyCredentialRequestOptions 객체가 포함되어 있으며, 발견하려는 공개키 자격 증명의 속성을 지정합니다.

sameOriginWithAncestors

이 인자는 Boolean 값이며, 호출자의 환경 설정 객체가 상위와 동일 origin일 때만 true입니다. cross-origin일 경우 false입니다.

참고: 이 내부 메서드가 호출되었다는 것은 권한 정책에 의해 허용되었음을 의미하며, 이는 [CREDENTIAL-MANAGEMENT-1] 수준에서 평가됩니다. 자세한 내용은 § 5.9 권한 정책 통합을 참조하세요.

참고: 이 알고리즘은 동기적입니다: Promise 의 resolve/reject는 navigator.credentials.get() 에서 처리됩니다.

참고: 본 알고리즘에서 사용하는 모든 BufferSource 객체는 동기화 문제를 방지하기 위해 알고리즘 시작 시 스냅샷을 떠야 합니다. 구현체는 버퍼 소스의 바이트 복사본을 가져와 알고리즘 관련 부분에서 해당 복사본을 사용해야 합니다.

이 메서드가 호출되면, 사용자 에이전트는 다음 알고리즘을 반드시 실행해야 합니다:

단언: options.publicKey 가 존재해야 한다.
options을 options.publicKey 의 값으로 할당한다.
options의 timeout 멤버가 존재한다면, 그 값이 클라이언트에서 정의한 허용 범위 내에 있는지 확인하고, 범위를 벗어나면 가장 가까운 범위 내 값으로 조정한다. lifetimeTimer를 이 조정된 값으로 설정한다. timeout 멤버가 존재하지 않으면 lifetimeTimer를 클라이언트별 기본값으로 설정한다.

timeout 멤버에 대한 권장 범위 및 기본값은 아래와 같다. 만약 options.userVerification

가 discouraged로 설정된 경우

권장 범위: 30,000밀리초 ~ 180,000밀리초.

권장 기본값: 120,000밀리초 (2분).

가 required 또는 preferred로 설정된 경우

권장 범위: 30,000밀리초 ~ 600,000밀리초.

권장 기본값: 300,000밀리초 (5분).

참고: 사용자 에이전트는 특수 요구가 있는 사용자의 timeout에 대해 인지적 가이드라인을 고려해야 한다.
callerOrigin을 origin으로 할당한다. callerOrigin이 불투명 origin이라면, 이름이 "NotAllowedError"인 DOMException을 반환하고 알고리즘을 종료한다.
effectiveDomain을 callerOrigin의 effective domain으로 할당한다. effective domain이 유효한 domain이 아니면, 이름이 "SecurityError"인 DOMException을 반환하고 알고리즘을 종료한다.

참고: effective domain은 호스트로 해석될 수 있으며, 도메인, ipv4 주소, ipv6 주소, 불투명 호스트, 빈 호스트 등 다양한 방식으로 표현될 수 있다. 여기서는 도메인 형식의 호스트만 허용된다. 이는 단순화와 PKI 기반 보안에서 직접 IP 주소 사용의 여러 문제를 인지한 결과이다.
options.rpId 가 존재하지 않으면, rpId를 effectiveDomain으로 할당한다.
그 외의 경우:
1. options.rpId 가 effectiveDomain의 등록 가능 도메인 접미사 또는 동일하지 않으면 이름이 "SecurityError"인 DOMException을 반환하고 알고리즘을 종료한다.
2. rpId를 options.rpId로 설정한다.
  
  참고: rpId는 호출자의 RP ID를 나타낸다. RP ID는 기본적으로 호출자의 origin의 effective domain이며, 호출자가 options.rpId를 명시적으로 지정한 경우 그 값이 사용된다.
clientExtensions을 새로운 맵으로, authenticatorExtensions도 새로운 맵으로 생성한다.
options의 extensions 멤버가 존재하면, 각 extensionId → clientExtensionInput에 대해 options.extensions:
1. extensionId가 해당 클라이언트 플랫폼에서 지원되지 않거나 인증 확장이 아니면, 계속한다.
2. clientExtensions[extensionId]에 clientExtensionInput을 할당한다.
3. extensionId가 인증기 확장이 아니면 계속한다.
4. authenticatorExtensionInput을 (CBOR) extensionId의 클라이언트 확장 처리 알고리즘을 clientExtensionInput에 대해 실행한 결과로 할당한다. 오류가 반환되면 계속한다.
5. Set authenticatorExtensions[extensionId]를 base64url 인코딩된 authenticatorExtensionInput으로 설정한다.
collectedClientData를 새로운 CollectedClientData 인스턴스로 생성하며, 필드는 다음과 같다:

type

문자열 "webauthn.get".

challenge

options.challenge의 base64url 인코딩 값

origin

callerOrigin의 ASCII 직렬화 값

crossOrigin

이 내부 메서드로 전달된 sameOriginWithAncestors 인자의 반대 값

tokenBinding

클라이언트와 callerOrigin 사이의 Token Binding 상태와, callerOrigin에 연결된 Token Binding ID (있다면)
clientDataJSON을 collectedClientData로 구성된 클라이언트 데이터의 JSON 호환 직렬화 값으로 할당한다.
clientDataHash를 clientDataJSON의 직렬화된 클라이언트 데이터의 해시 값으로 할당한다.
options.signal 이 존재하고, 그 aborted flag가 true로 설정되어 있으면, 이름이 "AbortError"인 DOMException을 반환하고 알고리즘을 종료한다.
issuedRequests를 새로운 순서 있는 집합으로 생성한다.
savedCredentialIds를 새로운 맵으로 생성한다.
authenticators는 임의 시점에 집합으로, 각 항목이 해당 시점에서 클라이언트 플랫폼에 존재하는 인증기를 식별하는 핸들임을 나타낸다.

참고: 인증기가 "사용 가능"하다는 조건은 명시적으로 정의되지 않는다. 이는 인증기가 USB 등으로 hot-plug되거나 NFC, Bluetooth 등으로 발견되거나, 클라이언트에 영구적으로 내장된 경우 등 다양한 메커니즘을 고려한다.
lifetimeTimer를 시작한다.
lifetimeTimer가 만료되지 않을 동안, lifetimeTimer, 상태 및 각 authenticator의 응답에 따라 다음 동작을 수행한다:
lifetimeTimer가 만료된 경우

각 authenticator에 대해 issuedRequests에 대해 authenticatorCancel을 호출하고, issuedRequests에서 제거한다.

사용자가 사용자 에이전트 UI 옵션을 통해 프로세스를 취소한 경우

각 authenticator에 대해 issuedRequests에 대해 authenticatorCancel을 호출하고, issuedRequests에서 제거한다. 그리고 이름이 "NotAllowedError"인 DOMException을 반환한다.

signal 멤버가 존재하고 aborted flag가 true인 경우

각 authenticator에 대해 issuedRequests에 대해 authenticatorCancel을 호출하고, issuedRequests에서 제거한다. 그리고 이름이 "AbortError"인 DOMException을 반환하고 알고리즘을 종료한다.

issuedRequests가 비어 있고, options.allowCredentials 가 비어 있지 않으며, 해당 공개키 자격 증명에 대해 이용 가능한 authenticator가 없는 경우

사용자에게 적합한 자격 증명을 찾을 수 없음을 알린다. 사용자가 다이얼로그를 확인하면, 이름이 "NotAllowedError"인 DOMException을 반환한다.

참고: 클라이언트 플랫폼이 이용 가능한 authenticator가 없음을 판단하는 한 가지 방법은, 현재 있는 transports 멤버를 검토하는 것이다. 예를 들어, 모든 PublicKeyCredentialDescriptor 항목이 internal만 나열하고, 모든 플랫폼 authenticator가 이미 시도되었다면, 요청을 만족시킬 가능성이 없다. 또는 모든 PublicKeyCredentialDescriptor 항목이 클라이언트 플랫폼에서 지원하지 않는 transports만 나열할 수도 있다.

어떤 authenticator가 해당 클라이언트 디바이스에서 사용 가능해진 경우
참고: 이는 lifetimeTimer 시작 시 이미 사용 가능하던 authenticator도 포함한다.
1. options.userVerification 이 required로 설정되어 있고 authenticator가 사용자 확인을 지원하지 않으면, 계속한다.
2. userVerification을 어서션을 위한 실효 사용자 확인 요구사항이라는 Boolean 값으로 할당한다. 만약 options.userVerification
  
  required로 설정된 경우
  
  userVerification을 true로 설정한다.
  
  preferred로 설정된 경우
  
  authenticator
  
  사용자 확인을 지원하는 경우
  
  userVerification을 true로 설정한다.
  
  사용자 확인을 지원하지 않는 경우
  
  userVerification을 false로 설정한다.
  
  discouraged로 설정된 경우
  
  userVerification을 false로 설정한다.
3. options.allowCredentials
  가 비어 있지 않은 경우
  
  allowCredentialDescriptorList를 새로운 리스트로 생성한다.
  
  클라이언트 플랫폼별 절차를 실행하여, options.allowCredentials 에서 기술된 공개키 자격 증명 중 authenticator에 바인딩된 것을 rpId, options.allowCredentials.id, options.allowCredentials.type 으로 필터링한다. allowCredentialDescriptorList를 이 결과로 설정한다.
  
  allowCredentialDescriptorList가 비어 있으면, 계속한다.
  
  distinctTransports를 새로운 순서 있는 집합으로 생성한다.
  
  allowCredentialDescriptorList가 정확히 하나의 값을 가지면, savedCredentialIds[authenticator] 를 allowCredentialDescriptorList[0].id의 값으로 설정한다 (자세한 내용은 여기 및 § 6.3.3 authenticatorGetAssertion 작업 참조).
  
  각 credential descriptor C에 대해, allowCredentialDescriptorList에서 각 값(있는 경우)을 C.transports 에서 distinctTransports에 추가한다.
  
  참고: 이는 순서 있는 집합 특성으로 인해, transports 의 중복 없는 값들만 distinctTransports에 집계된다.
  
  distinctTransports
  
  가 비어 있지 않은 경우
  
  클라이언트는 distinctTransports 중 하나를 선택하며, authenticator에 적합한 전송 방식을 로컬 설정에 따라 선정할 수 있다.
  
  선택한 transport를 이용해 authenticator에 대해 authenticatorGetAssertion 작업을 rpId, clientDataHash, allowCredentialDescriptorList, userVerification, authenticatorExtensions을 인자로 호출한다.
  
  가 비어 있는 경우
  
  클라이언트는 authenticator에 적합한 전송 방식을 로컬 설정에 따라 선정하여, authenticatorGetAssertion 작업을 rpId, clientDataHash, allowCredentialDescriptorList, userVerification, authenticatorExtensions을 인자로 호출한다.
  
  가 비어 있는 경우
  
  클라이언트는 authenticator에 적합한 전송 방식을 로컬 설정에 따라 선정하여, authenticatorGetAssertion 작업을 authenticator에 대해 rpId, clientDataHash, userVerification, authenticatorExtensions을 인자로 호출한다.
  
  참고: 이 경우, Relying Party가 허용되는 자격 증명 descriptor 리스트를 제공하지 않았다. 따라서 인증기는 자신이 가지고 있는 scope가 rpId로 식별되는 Relying Party에 바인딩된 자격 증명을 모두 검사하도록 요청받는다.
4. authenticator를 issuedRequests에 추가한다.
어떤 authenticator가 해당 클라이언트 디바이스에서 더 이상 사용 가능하지 않은 경우

authenticator를 issuedRequests에서 제거한다.

어떤 authenticator가 사용자가 작업을 취소했다는 상태를 반환한 경우
1. authenticator를 issuedRequests에서 제거한다.
2. 남은 authenticator에 대해 issuedRequests에서 authenticatorCancel을 호출하고, issuedRequests에서 제거한다.
  
  참고: 인증기는 "사용자가 전체 작업을 취소했다"는 신호를 반환할 수 있다. 사용자 에이전트가 이 상태를 사용자에게 어떻게 보여줄지는 정의되어 있지 않다.
어떤 authenticator가 오류 상태를 반환한 경우

authenticator를 issuedRequests에서 제거한다.

어떤 authenticator가 성공 상태를 반환한 경우
1. authenticator를 issuedRequests에서 제거한다.
2. assertionCreationData를 struct로 생성하고, 각 항목은 다음과 같다:
  
  credentialIdResult
  
  savedCredentialIds[authenticator] 가 존재하면, credentialIdResult 값을 savedCredentialIds[authenticator]의 바이트로 설정한다. 그렇지 않으면, credentialIdResult 값을 성공한 authenticatorGetAssertion 작업에서 반환된 credential ID의 바이트로 설정한다. (자세한 내용은 § 6.3.3 authenticatorGetAssertion 작업 참조)
  
  clientDataJSONResult
  
  값은 clientDataJSON의 바이트.
  
  authenticatorDataResult
  
  값은 authenticator data의 바이트로, authenticator가 반환.
  
  signatureResult
  
  값은 authenticator가 반환한 서명 값의 바이트.
  
  userHandleResult
  
  authenticator가 user handle을 반환했다면, userHandleResult 값을 반환된 user handle의 바이트로 설정한다. 그렇지 않으면 userHandleResult 값을 null로 설정한다.
  
  clientExtensionResults
  
  값은 AuthenticationExtensionsClientOutputs 객체로, extension identifier → client extension output 항목을 가진다. 각 항목은 options.extensions 에 포함된 각 클라이언트 확장에 대해 클라이언트 확장 처리 알고리즘을 실행하여 생성한다.
3. constructAssertionAlg를 글로벌 오브젝트 global을 인자로 받아 다음 절차를 수행하는 알고리즘으로 할당한다:
  1. pubKeyCred를 PublicKeyCredential 객체로 생성하며, global에 연결된 다음 필드를 가진다:
    
    [[identifier]]
    
    새로운 ArrayBuffer로, global의 %ArrayBuffer%를 사용해 assertionCreationData.credentialIdResult의 바이트를 담는다.
    
    response
    
    새로운 AuthenticatorAssertionResponse 객체로, global에 연결된 다음 필드를 가진다:
    
    clientDataJSON
    
    새로운 ArrayBuffer로, global의 %ArrayBuffer%를 사용해 assertionCreationData.clientDataJSONResult의 바이트를 담는다.
    
    authenticatorData
    
    새로운 ArrayBuffer로, global의 %ArrayBuffer%를 사용해 assertionCreationData.authenticatorDataResult의 바이트를 담는다.
    
    signature
    
    새로운 ArrayBuffer로, global의 %ArrayBuffer%를 사용해 assertionCreationData.signatureResult의 바이트를 담는다.
    
    userHandle
    
    assertionCreationData.userHandleResult 가 null이면, 이 필드는 null로 설정. 그렇지 않으면, 새로운 ArrayBuffer로, global의 %ArrayBuffer%를 사용해 assertionCreationData.userHandleResult의 바이트를 담는다.
    
    [[clientExtensionsResults]]
    
    새로운 ArrayBuffer로, global의 %ArrayBuffer%를 사용해 assertionCreationData.clientExtensionResults의 바이트를 담는다.
  2. pubKeyCred를 반환한다.
4. 남은 authenticator에 대해 issuedRequests에서 authenticatorCancel을 호출하고, issuedRequests에서 제거한다.
5. constructAssertionAlg를 반환하고 알고리즘을 종료한다.
이름이 "NotAllowedError"인 DOMException을 반환한다. 사용자의 동의 없이 사용자를 식별할 수 있는 정보 유출을 방지하기 위해, 이 단계는 lifetimeTimer가 만료되기 전에는 반드시 실행되면 안 된다. 자세한 내용은 § 14.5.2 인증 세리머니 프라이버시 참조.

위 과정 동안, 사용자 에이전트는 사용자가 인증기를 선택하고 해당 작업을 완료하도록 안내하는 UI를 표시해야 한다.

5.1.5. 기존 자격 증명 저장 - PublicKeyCredential의 `[[Store]](credential, sameOriginWithAncestors)` 메서드

[[Store]](credential, sameOriginWithAncestors) 메서드는 Web Authentication의 PublicKeyCredential 타입에서 지원되지 않으므로 항상 오류를 반환합니다.

참고: 이 알고리즘은 동기적으로 동작하며, Promise 해제/거부는 navigator.credentials.store() 에서 처리됩니다.

이 내부 메서드는 두 개의 인수를 받습니다:

credential: 이 인수는 PublicKeyCredential 객체입니다.
sameOriginWithAncestors: 이 인수는 Boolean 값이며, 호출자의 environment settings object가 조상과 동일 출처일 때만 true입니다.

이 메서드가 호출되면, 사용자 에이전트는 다음 알고리즘을 반드시 실행해야 합니다:

DOMException 이름이 "NotSupportedError"인 예외를 반환하고, 알고리즘을 종료합니다.

5.1.6. 기존 자격 증명에 대한 무언의 접근 방지 - PublicKeyCredential의 `[[preventSilentAccess]](credential, sameOriginWithAncestors)` 메서드

[[preventSilentAccess]](credential, sameOriginWithAncestors) 메서드를 호출해도 승인 제스처가 필요한 인증기에는 아무런 효과가 없지만, 해당 플래그를 설정하면 사용자의 개입 없이 동작 가능한 인증기는 제외될 수 있습니다.

이 내부 메서드는 인수를 받지 않습니다.

5.1.7. 사용자 검증 플랫폼 인증기의 사용 가능 여부 - PublicKeyCredential의 `isUserVerifyingPlatformAuthenticatorAvailable()` 메서드

WebAuthn Relying Parties는 이 메서드를 사용하여 사용자 검증 플랫폼 인증기를 사용하여 새 자격 증명을 생성할 수 있는지 확인합니다. 호출 시 클라이언트는 클라이언트 플랫폼별 절차를 사용하여 사용 가능한 사용자 검증 플랫폼 인증기를 탐색합니다. 인증기가 발견되면 promise는 true 값으로 resolve됩니다. 그렇지 않으면 promise는 false 값으로 resolve됩니다. 결과에 따라 Relying Party는 사용자가 자격 증명을 생성할 수 있도록 추가 조치를 취할 수 있습니다.

이 메서드는 인수를 받지 않으며 Boolean 값을 반환합니다.

PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable

모든 최신 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge (Legacy)18IE없음

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음

partial interface PublicKeyCredential {
    static Promise<boolean> isUserVerifyingPlatformAuthenticatorAvailable();
};

참고: 브라우징 컨텍스트에서 Web Authentication API가 allowed to use 알고리즘에 따라 "비활성화"되어 있으면—예를 들어 permissions policy에 의해—promise는 DOMException 이름이 "NotAllowedError"인 예외로 reject됩니다. § 5.9 권한 정책 통합도 참고하세요.

5.2. 인증기 응답 (interface `AuthenticatorResponse`)

AuthenticatorResponse

모든 최신 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge (Legacy)18IE없음

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음

인증기는 신뢰 당사자의 요청에 대해 AuthenticatorResponse 인터페이스에서 파생된 객체를 반환하여 응답합니다:

[SecureContext, Exposed=Window]
interface AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      clientDataJSON;
};

AuthenticatorResponse/clientDataJSON 모든 최신 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (Legacy)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음 clientDataJSON, 타입 ArrayBuffer, readonly: 이 속성은 JSON 호환 직렬화된 클라이언트 데이터를 포함하며, 직렬화된 클라이언트 데이터의 해시가 클라이언트에서 인증기로 전달될 때 create() 또는 get() 호출 시 사용됩니다(즉, 클라이언트 데이터 자체는 인증기로 전달되지 않습니다).

5.2.1. 공개 키 자격 증명 정보 (interface `AuthenticatorAttestationResponse`)

AuthenticatorAttestationResponse

모든 최신 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge (Legacy)18IE없음

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet10.0+Opera Mobile없음

AuthenticatorAttestationResponse 인터페이스는 클라이언트가 새로운 공개 키 자격 증명 생성을 요청할 때 인증기의 응답을 나타냅니다. 이 인터페이스는 이후 사용을 위해 자격 증명을 식별할 수 있는 정보와, WebAuthn 신뢰 당사자가 등록 과정에서 자격 증명의 특성을 평가할 수 있는 메타데이터를 포함합니다.

AuthenticatorAttestationResponse/getTransports

현재 엔진에서는 지원되지 않음.

Firefox없음Safari없음Chrome없음

Opera없음Edge없음

Edge (Legacy)없음IE없음

Firefox for Android없음iOS Safari없음Chrome for Android없음Android WebView없음Samsung Internet없음Opera Mobile없음

[SecureContext, Exposed=Window]
interface AuthenticatorAttestationResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      attestationObject;
    sequence<DOMString>                              getTransports();
    ArrayBuffer                                      getAuthenticatorData();
    ArrayBuffer?                                     getPublicKey();
    COSEAlgorithmIdentifier                          getPublicKeyAlgorithm();
};

clientDataJSON: 이 속성은 AuthenticatorResponse 로부터 상속된 것으로, 클라이언트 데이터의 JSON 호환 직렬화(§ 6.5 인증서 참조)를 포함하며, 이 자격 증명을 생성하기 위해 클라이언트가 인증기에 전달한 값입니다. JSON 직렬화는 반드시 그대로 유지되어야 하며, 직렬화된 클라이언트 데이터의 해시가 그 위에 계산됩니다.
AuthenticatorAttestationResponse/attestationObject 모든 최신 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (Legacy)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet10.0+Opera Mobile없음 attestationObject, 타입 ArrayBuffer, readonly: 이 속성은 attestation object를 포함하며, 클라이언트가 조작할 수 없고 암호학적으로 보호됩니다. attestation object는 authenticator data와 attestation statement를 모두 포함합니다. 앞쪽(authenticator data)에는 AAGUID, 고유한 credential ID, credential public key가 포함됩니다. attestation statement의 내용은 attestation statement format에 따라 결정되며, 인증기가 사용합니다. 또한 신뢰 당사자의 서버가 attestation statement를 검증하거나, authenticator data 및 클라이언트 데이터의 JSON 호환 직렬화를 해석 및 검증하는 데 필요한 추가 정보도 포함되어 있습니다. 자세한 내용은 § 6.5 인증서, § 6.5.4 인증 오브젝트 생성, 그림 6을 참조하세요.
getTransports(): 이 연산은 [[transports]]의 값을 반환합니다.
getAuthenticatorData(): 이 연산은 attestationObject에 포함된 authenticator data를 반환합니다. § 5.2.1.1 자격 증명 데이터 쉽게 접근하기를 참조하세요.
getPublicKey(): 이 연산은 새 자격 증명의 DER SubjectPublicKeyInfo를 반환하며, 사용 불가 시 null을 반환합니다. § 5.2.1.1 자격 증명 데이터 쉽게 접근하기를 참조하세요.
getPublicKeyAlgorithm(): 이 연산은 새 자격 증명의 COSEAlgorithmIdentifier를 반환합니다. § 5.2.1.1 자격 증명 데이터 쉽게 접근하기를 참조하세요.
[[transports]]: 이 내부 슬롯은 0개 이상의 고유한 DOMString들의 시퀀스를 사전순으로 포함합니다. 이 값들은 인증기가 지원하는 전송 방식(transport)이며, 정보가 없을 경우 빈 시퀀스입니다. 값들은 AuthenticatorTransport 멤버여야 하지만, 신뢰 당사자는 알 수 없는 값은 무시해야 합니다.

5.2.1.1. 자격 증명 데이터 쉽게 접근하기

[[Create]](origin, options, sameOriginWithAncestors) 메서드의 모든 사용자는 향후 인증 어서션을 검증하기 위해 반환된 자격 증명 공개키를 파싱하고 저장해야 합니다. 하지만 자격 증명 공개키는 [RFC8152] (COSE) 형식으로, attestedCredentialData의 credentialPublicKey 멤버 안에, authenticator data 안에, attestation object 안에 포함되어 있으며, 이는 AuthenticatorAttestationResponse.attestationObject를 통해 전달받습니다. attestation을 사용하고자 하는 신뢰 당사자는 해당 attestationObject를 파싱하고 자격 증명 공개키를 획득해야 합니다. 왜냐하면 해당 공개키가 인증기가 서명한 것이기 때문입니다. 하지만 많은 WebAuthn 유효 사용 사례는 attestation을 요구하지 않습니다. 이런 경우, 사용자 에이전트가 파싱 작업을 대신 수행하고, authenticator data를 직접 노출하며, 자격 증명 공개키를 더 편리한 형식으로 변환해 줄 수 있습니다.

getPublicKey() 연산은 자격 증명 공개키를 SubjectPublicKeyInfo 형식으로 반환합니다. 이 ArrayBuffer 는 예를 들어 Java의 java.security.spec.X509EncodedKeySpec, .NET의 System.Security.Cryptography.ECDsa.ImportSubjectPublicKeyInfo, 또는 Go의 crypto/x509.ParsePKIXPublicKey 등에 전달할 수 있습니다.

getPublicKey() 를 사용하면 몇 가지 제한이 있습니다. pubKeyCredParams 를 통해 신뢰 당사자가 인증기와 공개키 알고리즘을 협상할 수 있습니다. 이 때, 사용자 에이전트가 해당 알고리즘을 이해하지 못할 수도 있습니다. 만약 신뢰 당사자가 지원하지 않는 알고리즘을 사용하면, 사용자 에이전트가 결과 자격 증명 공개키를 SubjectPublicKeyInfo 형식으로 변환할 수 없고, getPublicKey()의 반환값은 null이 됩니다.

사용자 에이전트는 getPublicKey()가 다음 COSEAlgorithmIdentifier 값을 가진 자격 증명 공개키에 대해 null이 아닌 값을 반환할 수 있어야 합니다:

-7 (ES256), kty가 2(비압축 포인트 사용), crv가 1(P-256)일 때.
-257 (RS256).
-8 (EdDSA), crv가 6(Ed25519)일 때.

SubjectPublicKeyInfo에는 COSE 공개키에 포함된 서명 알고리즘(예: 사용할 해시 함수 등)에 대한 정보가 포함되어 있지 않습니다. 이를 제공하기 위해 getPublicKeyAlgorithm() 은 해당 자격 증명 공개키의 COSEAlgorithmIdentifier를 반환합니다.

많은 경우 CBOR 파싱이 필요 없도록 getAuthenticatorData() 는 attestationObject의 authenticator data를 반환합니다. authenticator data에는 다른 필드들도 바이너리 형식으로 인코딩되어 있습니다. 하지만 보조 함수는 제공되지 않습니다. 왜냐하면 신뢰 당사자가 어서션 획득 시 이미 해당 필드들을 추출해야 하기 때문입니다. 자격 증명 생성에서는 서명 검증이 선택적이지만, 신뢰 당사자는 어서션의 서명을 항상 검증해야 하므로 서명된 authenticator data에서 필드를 추출해야 합니다. 동일한 함수들을 자격 증명 생성 시에도 사용할 수 있습니다.

참고: getPublicKey() 와 getAuthenticatorData() 는 이 명세의 두 번째 레벨에 추가되었습니다. 신뢰 당사자는 'getPublicKey' in AuthenticatorAttestationResponse.prototype 값을 테스트하여 이러한 함수 사용 전에 기능 탐지를 해야 합니다. 해당 함수가 반드시 존재해야 하는 신뢰 당사자는 오래된 사용자 에이전트와 호환되지 않을 수 있습니다.

5.2.2. 웹 인증 어서션 (interface `AuthenticatorAssertionResponse`)

AuthenticatorAssertionResponse

모든 최신 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge (Legacy)18IE없음

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음

AuthenticatorAssertionResponse 인터페이스는 인증기가 WebAuthn 신뢰 당사자의 챌린지와 (선택적으로) 알고 있는 자격 증명 목록을 받아 클라이언트의 요청에 따라 새로운 인증 어서션을 생성한 응답을 나타냅니다. 이 응답은 자격 증명 개인키 소유를 증명하는 암호학적 서명과, (선택적으로) 특정 거래에 대한 사용자 동의의 증거를 포함합니다.

[SecureContext, Exposed=Window]
interface AuthenticatorAssertionResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      authenticatorData;
    [SameObject] readonly attribute ArrayBuffer      signature;
    [SameObject] readonly attribute ArrayBuffer?     userHandle;
};

clientDataJSON: 이 속성은 AuthenticatorResponse로부터 상속된 것으로, 클라이언트 데이터의 JSON 호환 직렬화(§ 5.8.1 WebAuthn 서명에 사용되는 클라이언트 데이터 (dictionary CollectedClientData) 참조)를 포함하며, 해당 어서션을 생성하기 위해 클라이언트가 인증기에 전달한 값입니다. JSON 직렬화는 반드시 그대로 유지되어야 하며, 직렬화된 클라이언트 데이터의 해시가 그 위에 계산됩니다.
AuthenticatorAssertionResponse/authenticatorData 모든 최신 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (Legacy)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음 authenticatorData, 타입 ArrayBuffer, readonly: 이 속성은 인증기에서 반환한 authenticator data를 포함합니다. § 6.1 인증기 데이터를 참조하세요.
AuthenticatorAssertionResponse/signature 모든 최신 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (Legacy)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음 signature, 타입 ArrayBuffer, readonly: 이 속성은 인증기에서 반환한 원시 서명 값을 포함합니다. § 6.3.3 authenticatorGetAssertion 연산을 참조하세요.
AuthenticatorAssertionResponse/userHandle 모든 최신 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (Legacy)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음 userHandle, 타입 ArrayBuffer, readonly, nullable: 이 속성은 인증기에서 반환된 user handle을 포함하거나, 인증기가 user handle을 반환하지 않은 경우 null입니다. § 6.3.3 authenticatorGetAssertion 연산을 참조하세요.

5.3. 자격 증명 생성 파라미터 (dictionary `PublicKeyCredentialParameters`)

dictionary PublicKeyCredentialParameters {
    required DOMString                    type;
    required COSEAlgorithmIdentifier      alg;
};

이 사전(dictionary)은 새로운 자격 증명을 생성할 때 추가 파라미터를 제공하는 데 사용됩니다.

type, 타입 DOMString: 이 멤버는 생성할 자격 증명의 타입을 지정합니다. 값은 PublicKeyCredentialType 멤버여야 하지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시해야 하며, 알 수 없는 PublicKeyCredentialParameters의 type은 무시해야 합니다.
alg, 타입 COSEAlgorithmIdentifier: 이 멤버는 새로 생성된 자격 증명이 사용할 암호학적 서명 알고리즘을 지정하며, 따라서 생성될 비대칭 키 쌍의 타입(예: RSA 또는 타원 곡선)도 결정합니다.

참고: 우리는 두 번째 멤버 이름을 "algorithm"을 풀어서 쓰지 않고 "alg"로 사용하는데, 이는 인증기에 메시지로 직렬화되어 저대역폭 링크로 전송될 수 있기 때문입니다.

5.4. 자격 증명 생성 옵션 (dictionary `PublicKeyCredentialCreationOptions`)

PublicKeyCredentialCreationOptions

모든 최신 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera54+Edge79+

Edge (Legacy)없음IE없음

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+

dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp;
    required PublicKeyCredentialUserEntity       user;

    required BufferSource                             challenge;
    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;

    unsigned long                                timeout;
    sequence<PublicKeyCredentialDescriptor>      excludeCredentials = [];
    AuthenticatorSelectionCriteria               authenticatorSelection;
    DOMString                                    attestation = "none";
    AuthenticationExtensionsClientInputs         extensions;
};

PublicKeyCredentialCreationOptions/rp 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ rp, 타입 PublicKeyCredentialRpEntity

이 멤버는 해당 요청을 한 신뢰 당사자에 대한 정보를 포함합니다.

값의 name 멤버는 반드시 필요합니다. 자세한 내용은 § 5.4.1 공개 키 엔터티 설명(dictionary PublicKeyCredentialEntity)를 참고하세요.

값의 id 멤버는 자격 증명이 RP ID에 스코프되어야 함을 명시합니다. 생략하면, 값은 CredentialsContainer 객체의 관련 설정 객체의 origin의 유효 도메인이 됩니다. 자세한 내용은 § 5.4.2 자격 증명 생성을 위한 신뢰 당사자 파라미터(dictionary PublicKeyCredentialRpEntity)를 참고하세요.

PublicKeyCredentialCreationOptions/user 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ user, 타입 PublicKeyCredentialUserEntity

이 멤버는 신뢰 당사자가 어테스테이션을 요청하는 사용자 계정에 대한 정보를 포함합니다.

값의 name, displayName 및 id 멤버는 반드시 필요합니다. 자세한 내용은 § 5.4.1 공개 키 엔터티 설명(dictionary PublicKeyCredentialEntity) 및 § 5.4.3 자격 증명 생성을 위한 사용자 계정 파라미터(dictionary PublicKeyCredentialUserEntity)를 참고하세요.

PublicKeyCredentialCreationOptions/challenge 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ challenge, 타입 BufferSource

이 멤버는 새로 생성된 자격 증명의 어테스테이션 오브젝트 생성을 위해 사용될 챌린지를 포함합니다. § 13.4.3 암호학적 챌린지 보안 고려사항을 참고하세요.

PublicKeyCredentialCreationOptions/pubKeyCredParams 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ pubKeyCredParams, 타입 sequence<PublicKeyCredentialParameters>

이 멤버는 생성될 자격 증명의 원하는 특성에 대한 정보를 포함합니다. 시퀀스는 가장 선호하는 것부터 가장 덜 선호하는 것 순서로 정렬됩니다. 클라이언트는 가능한 한 가장 선호하는 자격 증명을 생성하기 위해 최선을 다합니다.

PublicKeyCredentialCreationOptions/timeout 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ timeout, 타입 unsigned long

이 멤버는 호출자가 작업 완료까지 기다릴 의향이 있는 시간(밀리초 단위)을 지정합니다. 이는 힌트로 취급되며, 클라이언트에 의해 무시될 수 있습니다.

PublicKeyCredentialCreationOptions/excludeCredentials 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ excludeCredentials, 타입 sequence<PublicKeyCredentialDescriptor>, 기본값 []

이 멤버는 동일한 인증기에 대해 동일 계정에 여러 자격 증명이 생성되는 것을 제한하려는 신뢰 당사자에서 사용합니다. 클라이언트는 새 자격 증명이 이 파라미터에 나열된 자격 증명 중 하나와 동일한 인증기에 생성될 경우 오류를 반환해야 합니다.

PublicKeyCredentialCreationOptions/authenticatorSelection 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ authenticatorSelection, 타입 AuthenticatorSelectionCriteria

이 멤버는 신뢰 당사자가 create() 작업에 참여할 적합한 인증기를 선택할 때 사용합니다.

PublicKeyCredentialCreationOptions/attestation 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ attestation, 타입 DOMString, 기본값 "none"

이 멤버는 신뢰 당사자가 어테스테이션 전송에 대한 선호도를 표현할 때 사용합니다. 값은 AttestationConveyancePreference 멤버여야 하며, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하며, 알 수 없는 값은 해당 멤버가 존재하지 않는 것과 동일하게 취급해야 합니다. 기본값은 "none"입니다.

extensions, 타입 AuthenticationExtensionsClientInputs

이 멤버는 클라이언트 및 인증기에게 추가 처리를 요청하는 추가 파라미터를 포함합니다. 예를 들어, 호출자는 특정 기능을 가진 인증기만을 사용해 자격 증명을 생성하도록 요청하거나, 어테스테이션 오브젝트에 특정 정보를 반환하도록 요청할 수 있습니다. 일부 확장은 § 9 WebAuthn 확장에 정의되어 있습니다. 최신 등록된 WebAuthn 확장 목록은 [IANA-WebAuthn-Registries] 및 [RFC8809]에서 확인할 수 있습니다.

5.4.1. 공개 키 엔터티 설명 (dictionary `PublicKeyCredentialEntity`)

PublicKeyCredentialEntity 사전(dictionary)은 사용자 계정 또는 WebAuthn 신뢰 당사자를 설명하며, 각각 공개 키 자격 증명이 연결되거나 스코프됩니다.

dictionary PublicKeyCredentialEntity {
    required DOMString    name;
};

name, 타입 DOMString

엔터티를 위한 사람 친화적 이름입니다. 기능은 PublicKeyCredentialEntity 가 무엇을 나타내는지에 따라 달라집니다:

PublicKeyCredentialRpEntity 에 상속될 경우 신뢰 당사자의 사람 친화적 식별자로, 오직 표시용입니다. 예: "ACME Corporation", "Wonderful Widgets, Inc." 또는 "ОАО Примертех".
- 신뢰 당사자는 PRECIS FreeformClass의 Nickname Profile에 대해 [RFC8266] 2.3절에서 규정한 대로 name 값 설정 또는 사용자에게 표시 시 반드시 규제(enforcement)를 해야 합니다. [RFC8264] 참조.
- 이 문자열에는 언어 및 방향 메타데이터가 포함될 수 있습니다. 신뢰 당사자는 이 정보 제공을 고려해야 하며, 메타데이터 인코딩 방법은 § 6.4.2 언어 및 방향 인코딩을 참고하세요.
- 클라이언트는 name 값 표시 전 또는 authenticatorMakeCredential 연산의 파라미터로 포함하기 전, PRECIS FreeformClass의 Nickname Profile에 대해 [RFC8266] 2.3절에서 규정한 대로 반드시 규제(enforcement)를 해야 합니다. [RFC8264] 참조.
PublicKeyCredentialUserEntity 에 상속될 경우 사용자 계정의 사람 친화적 식별자로, 오직 표시용입니다. 예를 들어, "alexm", "alex.mueller@example.com" 또는 "+14255551234". displayName이 유사한 여러 계정 구분에 도움을 줍니다.
- 신뢰 당사자는 사용자가 이 값을 선택하도록 허용할 수 있으며, PRECIS IdentifierClass의 UsernameCasePreserved Profile에 대해 [RFC8265] 3.4.3절에서 규정한 대로 name 값 설정 또는 사용자에게 표시 시 반드시 규제(enforcement)를 해야 합니다. [RFC8264] 참조.
- 이 문자열에는 언어 및 방향 메타데이터가 포함될 수 있습니다. 신뢰 당사자는 이 정보 제공을 고려해야 하며, 메타데이터 인코딩 방법은 § 6.4.2 언어 및 방향 인코딩을 참고하세요.
- 클라이언트는 name 값 표시 전 또는 authenticatorMakeCredential 연산의 파라미터로 포함하기 전, PRECIS IdentifierClass의 UsernameCasePreserved Profile에 대해 [RFC8265] 3.4.3절에서 규정한 대로 반드시 규제(enforcement)를 해야 합니다. [RFC8264] 참조.

클라이언트, 클라이언트 플랫폼, 또는 인증기가 name 값을 표시할 때는 항상 UI 요소를 사용해 표시값 경계를 명확히 해야 하며, 다른 요소로 오버플로우 되지 않도록 해야 합니다 [css-overflow-3].

인증기는 값을 저장하는 경우 name 멤버 값을 64바이트 내로 잘라 저장할 수 있습니다. 문자열 잘림 및 기타 고려사항은 § 6.4.1 문자열 잘림을 참고하세요.

5.4.2. 자격 증명 생성을 위한 신뢰 당사자 파라미터 (dictionary `PublicKeyCredentialRpEntity`)

PublicKeyCredentialRpEntity 사전(dictionary)은 새로운 자격 증명 생성 시 신뢰 당사자에 대한 추가 속성을 제공하는 데 사용됩니다.

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString      id;
};

id, 타입 DOMString: 신뢰 당사자 엔터티의 고유 식별자이며, RP ID를 설정합니다.

5.4.3. 자격 증명 생성을 위한 사용자 계정 파라미터 (dictionary `PublicKeyCredentialUserEntity`)

PublicKeyCredentialUserEntity 사전(dictionary)은 새로운 자격 증명 생성 시 사용자 계정에 대한 추가 속성을 제공하는 데 사용됩니다.

dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity {
    required BufferSource   id;
    required DOMString      displayName;
};

id, 타입 BufferSource

사용자 계정 엔터티의 user handle입니다. user handle은 최대 64바이트 크기의 불투명 바이트 시퀀스이며, 사용자에게 표시되지 않습니다.

안전한 동작을 위해 인증 및 권한 결정은 반드시 id 멤버를 기반으로 이루어져야 하며, displayName 또는 name 멤버를 기반으로 하면 안 됩니다. [RFC8266] 6.1절 참고.

user handle에는 사용자 이름, 이메일 주소 등 개인정보가 포함되어서는 안 됩니다; 자세한 내용은 § 14.6.1 user handle 내용을 참고하세요. user handle은 비어 있을 수 없지만 null일 수는 있습니다.

참고: user handle은 서로 다른 계정에서 상수값이 되어서는 안 되며, 비발견 가능 자격 증명에서도 마찬가지입니다. 일부 인증기는 항상 발견 가능 자격 증명을 생성하므로, 상수 user handle은 하나의 신뢰 당사자에서 여러 계정을 사용할 수 없게 만듭니다.

displayName, 타입 DOMString

사용자 계정을 위한 사람 친화적 이름으로, 오직 표시용입니다. 예: "Alex Müller" 또는 "田中倫". 신뢰 당사자는 사용자가 직접 선택하도록 허용해야 하며, 필요 이상으로 선택을 제한해서는 안 됩니다.

신뢰 당사자는 PRECIS FreeformClass의 Nickname Profile에 대해 [RFC8266] 2.3절에서 규정한 대로 displayName 값 설정 또는 사용자에게 표시 시 반드시 규제(enforcement)를 해야 합니다. [RFC8264] 참조.
이 문자열에는 언어 및 방향 메타데이터가 포함될 수 있습니다. 신뢰 당사자는 이 정보 제공을 고려해야 하며, 메타데이터 인코딩 방법은 § 6.4.2 언어 및 방향 인코딩을 참고하세요.
클라이언트는 displayName 값 표시 전 또는 authenticatorMakeCredential 연산의 파라미터로 포함하기 전, 반드시 규제(enforcement)를 해야 합니다. 규제 방법은 PRECIS FreeformClass의 Nickname Profile에 대해 [RFC8266] 2.3절 및 [RFC8264] 참조.

클라이언트, 클라이언트 플랫폼, 또는 인증기가 displayName 값을 표시할 때는 항상 UI 요소를 사용해 표시값 경계를 명확히 해야 하며, 다른 요소로 오버플로우 되지 않도록 해야 합니다 [css-overflow-3].

인증기는 displayName 멤버 값을 64바이트 최소 길이로 수용하고 저장해야 하며, 64바이트 내로 잘라 저장할 수 있습니다. 문자열 잘림 및 기타 고려사항은 § 6.4.1 문자열 잘림을 참고하세요.

5.4.4. 인증기 선택 기준 (dictionary `AuthenticatorSelectionCriteria`)

WebAuthn 신뢰 당사자는 AuthenticatorSelectionCriteria 사전을 사용해 인증기 속성에 대한 요구사항을 지정할 수 있습니다.

dictionary AuthenticatorSelectionCriteria {
    DOMString                    authenticatorAttachment;
    DOMString                    residentKey;
    boolean                      requireResidentKey = false;
    DOMString                    userVerification = "preferred";
};

authenticatorAttachment, 타입 DOMString

이 멤버가 있으면, 해당 § 5.4.5 인증기 부착 열거형(enum AuthenticatorAttachment)에 따라 부착된 인증기만 선택됩니다. 값은 AuthenticatorAttachment 멤버여야 하지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하며, 알 수 없는 값은 해당 멤버가 없는 것으로 취급해야 합니다(member does not exist).

residentKey, 타입 DOMString

신뢰 당사자가 클라이언트 측 발견 가능 자격 증명을 얼마나 원하는지를 지정합니다. 과거 명칭 때문에 "resident" 용어가 유지됩니다. 값은 ResidentKeyRequirement 멤버여야 하지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하며, 알 수 없는 값은 해당 멤버가 없는 것으로 취급해야 합니다(member does not exist). 값이 없으면 required는 requireResidentKey가 true일 때, discouraged는 false 또는 없을 때 적용됩니다.

값과 의미에 대한 설명은 ResidentKeyRequirement를 참고하세요.

requireResidentKey, 타입 boolean, 기본값 false

이 멤버는 WebAuthn Level 1과의 하위 호환성을 위해 유지되며, 과거 명칭 때문에 "resident" 용어를 사용합니다(발견 가능 자격 증명 의미). 신뢰 당사자는 residentKey가 required로 설정된 경우에만 true로 설정해야 합니다.

userVerification, 타입 DOMString, 기본값 "preferred"

이 멤버는 신뢰 당사자가 create() 작업에서 사용자 검증에 대해 요구하는 사항을 설명합니다. 해당 요구를 만족시킬 수 있는 인증기만 선택됩니다. 값은 UserVerificationRequirement 멤버여야 하지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하며, 알 수 없는 값은 해당 멤버가 없는 것으로 취급해야 합니다(member does not exist).

5.4.5. 인증기 부착 열거형 (enum `AuthenticatorAttachment`)

이 열거형의 값은 인증기의 부착 방식을 설명합니다. 신뢰 당사자는 navigator.credentials.create() 호출 시 자격 증명 생성에 대해 선호하는 인증기 부착 방식을 표현합니다.

enum AuthenticatorAttachment {
    "platform",
    "cross-platform"
};

참고: AuthenticatorAttachment 열거형은 의도적으로 참조되지 않았습니다. 자세한 내용은 § 2.1.1 DOMString 타입의 열거형을 참고하세요.

platform: 이 값은 플랫폼 부착을 의미합니다.
cross-platform: 이 값은 크로스 플랫폼 부착을 의미합니다.

참고: 인증기 부착 방식 선택 옵션은 [[Create]](origin, options, sameOriginWithAncestors) 작업에서만 사용할 수 있습니다. 신뢰 당사자는 예를 들어 로밍 자격 증명을 확보하거나, 특정 클라이언트 디바이스에서 편리한 재인증을 위해 플랫폼 자격 증명을 등록할 수 있습니다. [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 작업에는 인증기 부착 방식 선택 옵션이 없으므로, 신뢰 당사자는 사용자의 등록된 자격 증명을 모두 허용해야 합니다. 클라이언트와 사용자는 상황에 따라 사용 가능한 것을 선택하여 사용할 수 있습니다.

5.4.6. 레지던트 키 요구사항 열거형 (enum `ResidentKeyRequirement`)

enum ResidentKeyRequirement {
    "discouraged",
    "preferred",
    "required"
};

참고: ResidentKeyRequirement 열거형은 의도적으로 참조되지 않았습니다. 자세한 내용은 § 2.1.1 DOMString 타입의 열거형을 참고하세요.

이 열거형의 값은 신뢰 당사자의 클라이언트 측 발견 가능 자격 증명(과거에는 레지던트 자격 증명 또는 레지던트 키로 불림)에 대한 요구사항을 설명합니다.

discouraged

이 값은 신뢰 당사자가 서버 측 자격 증명 생성을 선호하지만, 클라이언트 측 발견 가능 자격 증명도 허용함을 의미합니다.

참고: 신뢰 당사자는 반드시 서버 측 자격 증명이 생성되도록 요구할 수 없으며, 자격 증명 속성 확장(Credential Properties Extension)에서 rk 속성 값이 반환되지 않을 수도 있습니다. 이로 인해 해당 자격 증명이 서버 측 자격 증명인지 여부를 알 수 없으며, 동일 user handle로 두 번째 자격 증명을 생성하면 첫 번째 것이 삭제되는지 알 수 없습니다.

preferred

이 값은 신뢰 당사자가 클라이언트 측 발견 가능 자격 증명 생성을 강하게 선호하지만, 서버 측 자격 증명도 허용함을 의미합니다. 예를 들어, 사용자 에이전트는 사용자 검증이 필요하다면 이를 안내해서 클라이언트 측 발견 가능 자격 증명을 생성해야 합니다. 이 설정은 userVerification 설정보다 우선합니다.

required

이 값은 신뢰 당사자가 클라이언트 측 발견 가능 자격 증명을 반드시 요구하며, 생성할 수 없을 경우 오류를 받을 준비가 되어 있음을 의미합니다.

참고: 신뢰 당사자는 인증기가 클라이언트 측 발견 가능 자격 증명을 생성했는지 여부를 자격 증명 속성 확장의 반환 값을 통해 확인할 수 있습니다. 이 값은 options.authenticatorSelection.residentKey에 따라 달라집니다. discouraged 또는 preferred 값 사용 시에는 인증기가 클라이언트 측 발견 가능 자격 증명 또는 서버 측 자격 증명 중 어떤 것을 생성할 수 있습니다.

5.4.7. 어테스테이션 전달 선호 열거형(enum `AttestationConveyancePreference`)

WebAuthn 신뢰 당사자는 AttestationConveyancePreference을 사용하여 자격 증명 생성 중 어테스테이션 전달에 대한 선호를 지정할 수 있습니다.

enum AttestationConveyancePreference {
    "none",
    "indirect",
    "direct",
    "enterprise"
};

참고: AttestationConveyancePreference 열거형은 의도적으로 참조되지 않았습니다. 자세한 내용은 § 2.1.1 DOMString 타입의 열거형을 참고하세요.

none

이 값은 신뢰 당사자가 인증기 어테스테이션에 관심이 없음을 나타냅니다. 예를 들어, 신뢰 당사자에게 식별 정보를 전달하기 위해 사용자 동의를 받지 않아도 되거나, 어테스테이션 CA 또는 익명화 CA와의 왕복(roundtrip)을 줄이기 위해 사용할 수 있습니다.

이 값이 기본값입니다.

indirect

이 값은 신뢰 당사자가 검증 가능한 어테스테이션 문을 포함하는 어테스테이션 전달을 선호하지만, 해당 문 얻는 방법은 클라이언트에 맡긴다는 의미입니다. 클라이언트는 인증기에서 생성된 어테스테이션 문을 익명화 CA에서 생성한 것으로 바꿀 수 있으며, 이는 사용자의 프라이버시를 보호하거나 다양한 환경에서 신뢰 당사자의 어테스테이션 검증을 돕기 위한 목적입니다.

참고: 이 경우 신뢰 당사자가 반드시 검증 가능한 어테스테이션 문을 받을 수 있다는 보장은 없습니다. 예를 들어, 인증기가 자체 어테스테이션을 사용하는 경우 등입니다.

direct

이 값은 신뢰 당사자가 인증기가 생성한 어테스테이션 문을 그대로 받기를 원하는 경우입니다.

enterprise

이 값은 신뢰 당사자가 고유 식별 정보를 포함할 수 있는 어테스테이션 문을 받기를 원하는 경우입니다. 이는 엔터프라이즈 내부에서 특정 인증기에 등록을 연결하려는 통제된 배포 환경에 사용됩니다. 사용자 에이전트는 해당 RP ID에 대해 사용자 에이전트 또는 인증기 설정이 허용하지 않는 한 반드시 이런 어테스테이션을 제공해서는 안 됩니다.

허용되는 경우, 사용자 에이전트는 인증기에(초기화 시점에) 엔터프라이즈 어테스테이션이 요청되었다고 신호를 주고, 생성된 AAGUID와 어테스테이션 문을 변경 없이 신뢰 당사자에게 전달해야 합니다.

5.5. 어서션 생성 옵션 (dictionary `PublicKeyCredentialRequestOptions`)

PublicKeyCredentialRequestOptions

모든 현행 표준 엔진에서 지원됨.

Firefox60+Safari13+Chrome67+

Opera54+Edge79+

Edge (Legacy)없음IE없음

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+

PublicKeyCredentialRequestOptions 사전(dictionary)은 get() 에서 어서션을 생성하는 데 필요한 데이터를 제공합니다. challenge 멤버는 반드시 있어야 하며, 다른 멤버들은 선택적입니다.

dictionary PublicKeyCredentialRequestOptions {
    required BufferSource                challenge;
    unsigned long                        timeout;
    USVString                            rpId;
    sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
    DOMString                            userVerification = "preferred";
    AuthenticationExtensionsClientInputs extensions;
};

PublicKeyCredentialRequestOptions/challenge 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ challenge, 타입 BufferSource: 이 멤버는 선택된 인증기가 인증 어서션을 생성할 때 다른 데이터와 함께 서명하는 챌린지를 나타냅니다. § 13.4.3 암호학적 챌린지 보안 고려사항을 참고하세요.
PublicKeyCredentialRequestOptions/timeout 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ timeout, 타입 unsigned long: 이 선택적 멤버는 호출자가 작업 완료까지 기다릴 의향이 있는 시간(밀리초 단위)을 지정합니다. 값은 힌트로 취급되며, 클라이언트에 의해 무시될 수 있습니다.
PublicKeyCredentialRequestOptions/rpId 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ rpId, 타입 USVString: 이 선택적 멤버는 호출자가 주장하는 신뢰 당사자 식별자를 지정합니다. 생략 시 값은 CredentialsContainer 객체의 관련 설정 객체의 origin의 유효 도메인이 됩니다.
PublicKeyCredentialRequestOptions/allowCredentials 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ allowCredentials, 타입 sequence<PublicKeyCredentialDescriptor>, 기본값 []: 이 선택적 멤버는 호출자가 허용하는 PublicKeyCredentialDescriptor 객체 목록을 포함하며, 우선순위에 따라 내림차순으로 정렬(첫 번째가 가장 선호함)됩니다.
PublicKeyCredentialRequestOptions/userVerification 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ userVerification, 타입 DOMString, 기본값 "preferred": 이 선택적 멤버는 get() 작업에서 신뢰 당사자가 사용자 검증에 대해 요구하는 사항을 설명합니다. 값은 UserVerificationRequirement 멤버여야 하지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하며, 알 수 없는 값은 해당 멤버가 없는 것으로 취급해야 합니다(member does not exist). 요구사항을 만족시킬 수 있는 인증기만 선택됩니다.
PublicKeyCredentialCreationOptions/extensions 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ PublicKeyCredentialRequestOptions/extensions 모든 현행 표준 엔진에서 지원됨. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (Legacy)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ extensions, 타입 AuthenticationExtensionsClientInputs: 이 선택적 멤버는 클라이언트와 인증기에 추가 처리를 요청하는 추가 파라미터를 포함합니다. 예를 들어, 트랜잭션 확인을 사용자에게 요청하려면 프롬프트 문자열을 확장(extension)으로 포함할 수 있습니다.

5.6. `AbortSignal`로 작업 중단

개발자는 AbortController 를 활용하여 [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 작업을 관리하는 것이 권장됩니다. 자세한 지침은 DOM §3.3 AbortController 및 AbortSignal 객체를 API에서 사용하기 섹션을 참고하세요.

참고: DOM §3.3 AbortController 및 AbortSignal 객체를 API에서 사용하기 섹션에서는 AbortController 와 통합하는 웹 플랫폼 API들은 aborted flag가 설정된 즉시 promise를 즉시 거부해야 한다고 명시합니다. [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 메서드의 복잡한 상속 및 병렬 구조를 고려하여, 두 API의 알고리즘은 aborted flag를 세 곳에서 확인함으로써 이 요구사항을 충족합니다. [[Create]](origin, options, sameOriginWithAncestors)의 경우, Credential Management 1 §2.5.4 자격 증명 생성에서 [[Create]](origin, options, sameOriginWithAncestors) 호출 직전에, § 5.1.3 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 메서드에서 인증기 세션 시작 직전에, 마지막으로 authenticator session 중에 확인합니다. [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)도 동일하게 동작합니다.

visibility 및 focus 상태는 Window 객체에서 [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 작업이 계속되어야 하는지 결정합니다. [Document]와 연결된 Window 객체가 포커스를 잃으면, [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 작업은 중단되어야 합니다.

WHATWG HTML WG에서는 브라우징 컨텍스트가 포커스를 얻거나 잃을 때 후크(hook)를 제공할지 논의 중입니다. 만약 후크가 제공된다면, 위 문단은 해당 후크를 포함하도록 업데이트될 예정입니다. 자세한 내용은 WHATWG HTML WG Issue #2711을 참고하세요.

5.7. WebAuthn 확장 입력과 출력

아래 하위 섹션에서는 WebAuthn 확장 입력과 출력을 전달하는 데 사용되는 데이터 타입을 정의합니다.

참고: 인증기 확장 출력은 authenticator data의 일부로 전달됩니다(표 1 참고).

참고: 아래 정의된 타입 — AuthenticationExtensionsClientInputs 와 AuthenticationExtensionsClientOutputs — 는 등록 확장과 인증 확장 모두에 적용됩니다. 이름의 "Authentication..." 부분은 "WebAuthentication..."을 의미하는 것으로 간주해야 합니다.

5.7.1. 인증 확장 클라이언트 입력(dictionary `AuthenticationExtensionsClientInputs`)

dictionary AuthenticationExtensionsClientInputs {
};

이 사전(dictionary)은 0개 이상의 WebAuthn 확장에 대해 클라이언트 확장 입력 값을 담고 있습니다.

5.7.2. 인증 확장 클라이언트 출력(dictionary `AuthenticationExtensionsClientOutputs`)

dictionary AuthenticationExtensionsClientOutputs {
};

이 사전(dictionary)은 0개 이상의 WebAuthn 확장에 대해 클라이언트 확장 출력 값을 담고 있습니다.

5.7.3. 인증 확장 인증기 입력(CDDL 타입 `AuthenticationExtensionsAuthenticatorInputs`)

AuthenticationExtensionsAuthenticatorInputs = {
  * $$extensionInput .within ( tstr => any )
}

CDDL 타입 AuthenticationExtensionsAuthenticatorInputs는 0개 이상의 WebAuthn 확장에 대한 인증기 확장 입력 값을 담고 있는 CBOR 맵을 정의합니다. 확장은 § 9.3 요청 파라미터 확장에 설명된 대로 멤버를 추가할 수 있습니다.

이 타입은 신뢰 당사자에게는 공개되지 않으며, 클라이언트와 인증기가 사용합니다.

5.7.4. 인증 확장 인증기 출력(CDDL 타입 `AuthenticationExtensionsAuthenticatorOutputs`)

AuthenticationExtensionsAuthenticatorOutputs = {
  * $$extensionOutput .within ( tstr => any )
}

CDDL 타입 AuthenticationExtensionsAuthenticatorOutputs는 0개 이상의 WebAuthn 확장에 대한 인증기 확장 출력 값을 담고 있는 CBOR 맵을 정의합니다. 확장은 § 9.3 요청 파라미터 확장에 설명된 대로 멤버를 추가할 수 있습니다.

5.8. 지원 데이터 구조

공개 키 자격 증명 타입은 지원 명세에 정의된 몇 가지 데이터 구조를 사용합니다. 다음과 같습니다.

5.8.1. WebAuthn 서명에 사용되는 클라이언트 데이터 (dictionary `CollectedClientData`)

클라이언트 데이터는 WebAuthn 신뢰 당사자와 클라이언트의 컨텍스트 바인딩을 나타냅니다. 이는 키가 문자열인 키-값 매핑입니다. 값은 JSON에서 유효하게 인코딩될 수 있는 모든 타입이 될 수 있습니다. 구조는 아래 Web IDL로 정의됩니다.

참고: CollectedClientData 는 향후 확장될 수 있습니다. 따라서 파싱 시 미지의 키와 키의 순서 변경에 대해 관대하게 처리하는 것이 중요합니다. § 5.8.1.2 제한적 검증 알고리즘도 참고하세요.

dictionary CollectedClientData {
    required DOMString           type;
    required DOMString           challenge;
    required DOMString           origin;
    boolean                      crossOrigin;
    TokenBinding                 tokenBinding;
};

dictionary TokenBinding {
    required DOMString status;
    DOMString id;
};

enum TokenBindingStatus { "present", "supported" };

type, 타입 DOMString

새 자격 증명 생성 시 "webauthn.create", 기존 자격 증명에서 어서션을 얻을 때 "webauthn.get" 문자열이 포함됩니다. 이 멤버는 특정 유형의 서명 혼동 공격(공격자가 한 합법적 서명을 다른 것으로 대체하는 상황)을 방지하기 위한 목적입니다.

challenge, 타입 DOMString

이 멤버는 신뢰 당사자가 제공한 챌린지의 base64url 인코딩 값을 담고 있습니다. § 13.4.3 암호학적 챌린지 보안 고려사항을 참고하세요.

origin, 타입 DOMString

이 멤버는 요청자의 완전한 origin을 포함하며, 클라이언트가 인증기에 제공한 값입니다. [RFC6454]에서 정의된 구문을 따릅니다.

crossOrigin, 타입 boolean

이 멤버는 내부 메서드에 전달된 sameOriginWithAncestors 인자의 반대 값을 포함합니다.

tokenBinding, 타입 TokenBinding

이 선택적 멤버는 Token Binding 프로토콜 [TokenBinding]의 상태 정보를 담고 있습니다. 값이 없으면 클라이언트가 토큰 바인딩을 지원하지 않음을 의미합니다.

status, 타입 DOMString

이 멤버는 TokenBindingStatus 멤버여야 하지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하며, 알 수 없는 값은 tokenBinding 멤버가 없는 것으로 취급해야 합니다(member does not exist). 알 수 있는 경우 다음 중 하나입니다:

supported: 클라이언트가 토큰 바인딩을 지원하지만, 신뢰 당사자와 통신할 때 협상되지 않은 경우입니다.
present: 신뢰 당사자와 통신할 때 토큰 바인딩이 사용된 경우입니다. 이 경우 id 멤버가 반드시 존재해야 합니다.

참고: TokenBindingStatus 열거형은 의도적으로 참조되지 않았습니다. 자세한 내용은 § 2.1.1 DOMString 타입의 열거형 참고.

id, 타입 DOMString

status가 present일 때 반드시 있어야 하며, 신뢰 당사자와 통신할 때 사용된 base64url 인코딩의 Token Binding ID여야 합니다.

참고: Token Binding ID를 얻는 것은 클라이언트 플랫폼별 동작입니다.

CollectedClientData 구조는 클라이언트가 다음 값을 계산하는 데 사용됩니다:

클라이언트 데이터의 JSON 호환 직렬화: 이는 CollectedClientData 사전에 대해 JSON 호환 직렬화 알고리즘을 수행한 결과입니다.
직렬화된 클라이언트 데이터의 해시: 이는 클라이언트가 생성한 클라이언트 데이터의 JSON 호환 직렬화에 대해 SHA-256을 이용해 계산한 해시입니다.

5.8.1.1. 직렬화

CollectedClientData 의 직렬화는 바이트로 JSON 직렬화 알고리즘의 부분집합입니다. 즉, CollectedClientData 의 유효한 JSON 인코딩을 생성하지만, 검증자가 전체 JSON 파서를 통합하지 않아도 되는 추가 구조를 제공합니다. 검증자는 표준 JSON 파싱을 수행하는 것이 권장되지만, 전체 JSON 파서가 너무 클 경우 아래 더 제한적인 알고리즘을 사용할 수 있습니다. 이 검증 알고리즘은 base64url 인코딩, 바이트 문자열 덧붙이기(고정 템플릿에 기록하는 것으로 구현 가능), 그리고 세 가지 조건 검사를 요구합니다(입력이 이스케이프가 필요하지 않다는 것이 보장된 경우).

직렬화 알고리즘은 최초에는 비어있는 부분 결과에 연속적으로 바이트 문자열을 덧붙여 완전한 결과가 나올 때까지 작동합니다.

result를 빈 바이트 문자열로 둡니다.
0x7b2274797065223a ({"type":)를 result에 덧붙입니다.
CCDToString(type) 을 result에 덧붙입니다.
0x2c226368616c6c656e6765223a (,"challenge":)를 result에 덧붙입니다.
CCDToString(challenge) 을 result에 덧붙입니다.
0x2c226f726967696e223a (,"origin":)를 result에 덧붙입니다.
CCDToString(origin) 을 result에 덧붙입니다.
0x2c2263726f73734f726967696e223a (,"crossOrigin":)를 result에 덧붙입니다.
crossOrigin 이 없거나 false라면:
1. 0x66616c7365 (false)를 result에 덧붙입니다.
그 외의 경우:
1. 0x74727565 (true)를 result에 덧붙입니다.
CollectedClientData 의 임시 복사본을 만들고, type, challenge, origin, 그리고 crossOrigin (있다면) 필드를 제거합니다.
임시 복사본에 남은 필드가 없다면:
1. 0x7d (})를 result에 덧붙입니다.
그 외의 경우:
1. 임시 복사본에 serialize JSON to bytes를 수행하여 바이트 문자열 remainder를 만듭니다.
2. 0x2c (,)를 result에 덧붙입니다.
3. remainder의 첫 바이트를 제거합니다.
4. remainder를 result에 덧붙입니다.
직렬화 결과는 result의 값입니다.

위 알고리즘에서 사용하는 CCDToString 함수는 다음과 같이 정의됩니다:

encoded를 빈 바이트 문자열로 둡니다.
0x22 (")를 encoded에 덧붙입니다.
주어진 객체에 ToString을 호출해 문자열로 변환합니다.
결과 문자열의 각 코드 포인트에 대해, 코드 포인트가:

{U+0020, U+0021, U+0023–U+005B, U+005D–U+10FFFF}에 포함될 때

해당 코드 포인트의 UTF-8 인코딩을 encoded에 덧붙입니다.

U+0022일 때

0x5c22 (\")를 encoded에 덧붙입니다.

U+005C일 때

0x5c5c (\\)를 encoded에 덧붙입니다.

그 외의 경우

0x5c75 (\u)를 encoded에 덧붙이고, 코드 포인트를 16진수로 변환한 4자리 소문자 헥스값을 이어 붙입니다.
0x22 (")를 encoded에 덧붙입니다.
함수의 결과는 encoded의 값입니다.

5.8.1.2. 제한적 검증 알고리즘

검증자는 전체 JSON 파서를 지원할 수 없는 경우, 인코딩된 CollectedClientData 를 아래 알고리즘으로 검증할 수 있습니다:

알고리즘의 입력은 다음과 같습니다:
1. clientDataJSON: clientDataJSON — 검증할 직렬화된 CollectedClientData의 바이트 문자열.
2. type: 기대되는 type이 들어있는 문자열.
3. challenge: PublicKeyCredentialRequestOptions 또는 PublicKeyCredentialCreationOptions에 전달된 챌린지의 바이트 문자열.
4. origin: 사용자 에이전트에 요청을 보낸 기대되는 origin 문자열.
5. crossOrigin: 요청이 cross-origin iframe에서 수행된 경우에만 true인 불리언 값.
expected를 빈 바이트 문자열로 둡니다.
0x7b2274797065223a ({"type":)를 expected에 덧붙입니다.
CCDToString(type)을 expected에 덧붙입니다.
0x2c226368616c6c656e6765223a (,"challenge":)를 expected에 덧붙입니다.
challenge에 base64url 인코딩을 수행해 challengeBase64 문자열을 만듭니다.
CCDToString(challengeBase64)를 expected에 덧붙입니다.
0x2c226f726967696e223a (,"origin":)를 expected에 덧붙입니다.
CCDToString(origin)을 expected에 덧붙입니다.
0x2c2263726f73734f726967696e223a (,"crossOrigin":)를 expected에 덧붙입니다.
crossOrigin이 true이면:
1. 0x74727565 (true)를 expected에 덧붙입니다.
그 외, 즉 crossOrigin이 false이면:
1. 0x66616c7365 (false)를 expected에 덧붙입니다.
expected가 clientDataJSON의 접두사가 아니면 검증 실패입니다.
clientDataJSON이 expected보다 최소 1바이트 더 길지 않으면 검증 실패입니다.
clientDataJSON에서 expected 길이 위치의 바이트가:

0x7d인 경우

검증 성공입니다.

0x2c인 경우

검증 성공입니다.

그 외의 경우

검증 실패입니다.

5.8.1.3. 향후 개발

제한적 검증 알고리즘과 호환을 유지하기 위해, 이 명세의 향후 버전에서는 type, challenge, origin, crossOrigin 필드를 CollectedClientData 에서 제거해서는 안 됩니다. 또한 이 필드들의 직렬화 순서가 바뀌는 방식으로 직렬화 알고리즘을 변경해서도 안 됩니다.

CollectedClientData 에 추가 필드가 포함된다면, 제한적 검증 알고리즘을 사용하는 검증자들은 두 알고리즘이 추가 필드를 포함하도록 업데이트되기 전까지는 그것들을 고려할 수 없습니다. 업데이트가 이루어지면 추가된 필드는 이전 문단에서 설명한 동일한 제한을 상속받습니다. 이런 알고리즘 업데이트는 이전 버전에서 생성된 직렬화도 처리할 수 있어야 합니다. 즉, 검증 알고리즘은 다섯 번째 키-값 쌍이 이전 버전 사용자 에이전트에 의해 생성된 경우 다섯 번째에 나타나지 않거나 아예 없을 수도 있음을 처리해야 합니다.

5.8.2. 자격 증명 타입 열거형(enum `PublicKeyCredentialType`)

enum PublicKeyCredentialType {
    "public-key"
};

참고: PublicKeyCredentialType 열거형은 의도적으로 참조되지 않았습니다. 자세한 내용은 § 2.1.1 DOMString 타입의 열거형을 참고하세요.

이 열거형은 유효한 자격 증명 타입을 정의합니다. 확장 포인트로, 앞으로 더 많은 자격 증명 타입이 정의되면 값이 추가될 수 있습니다. 이 열거형의 값들은 인증기의 타입에 따라 인증 어서션과 어테스테이션 구조의 버전 관리를 위해 사용됩니다.

현재 하나의 자격 증명 타입만 정의되어 있으며, "public-key" 입니다.

5.8.3. 자격 증명 디스크립터(dictionary `PublicKeyCredentialDescriptor`)

dictionary PublicKeyCredentialDescriptor {
    required DOMString                    type;
    required BufferSource                 id;
    sequence<DOMString>                   transports;
};

이 사전(dictionary)은 create() 또는 get() 메서드의 입력 파라미터로서, 호출자가 공개 키 자격 증명을 참조할 때 지정하는 속성들을 담고 있습니다. 이는 해당 메서드에서 반환되는 PublicKeyCredential 객체의 필드와 동일합니다.

type, 타입 DOMString

이 멤버는 호출자가 참조하는 공개 키 자격 증명의 타입을 포함합니다. 값은 PublicKeyCredentialType 멤버여야 하지만, 클라이언트 플랫폼은 알 수 없는 PublicKeyCredentialDescriptor의 type을 반드시 무시해야 합니다.

id, 타입 BufferSource

이 멤버는 호출자가 참조하는 공개 키 자격 증명의 자격 증명 ID를 포함합니다.

transports, 타입 sequence<DOMString>

이 선택적 멤버는 호출자가 참조하는 공개 키 자격 증명의 관리 인증기와 클라이언트가 어떻게 통신할 수 있는지에 대한 힌트를 포함합니다. 값은 AuthenticatorTransport 멤버여야 하지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시해야 합니다.

getTransports() 연산으로 해당 멤버에 적합한 값을 얻을 수 있습니다. 새 자격 증명 등록 시, 신뢰 당사자는 getTransports()에서 반환되는 값을 저장해야 합니다. 이후 해당 자격 증명에 대해 PublicKeyCredentialDescriptor를 생성할 때, 신뢰 당사자는 저장한 값을 가져와 transports 멤버에 설정해야 합니다.

5.8.4. 인증기 전송 방식 열거형(enum `AuthenticatorTransport`)

enum AuthenticatorTransport {
    "usb",
    "nfc",
    "ble",
    "internal"
};

참고: AuthenticatorTransport 열거형은 의도적으로 참조되지 않았습니다. 자세한 내용은 § 2.1.1 DOMString 타입의 열거형을 참고하세요.

인증기는 전송 방식(transports)을 다양하게 구현할 수 있습니다. 이 열거형은 클라이언트가 특정 인증기와 통신하여 특정 자격 증명에 대한 어서션을 얻을 때 사용할 수 있는 힌트를 정의합니다. 이 힌트는 WebAuthn 신뢰 당사자가 인증기에 어떻게 접근할 수 있을지에 대한 최선의 추정값입니다. 신뢰 당사자는 일반적으로 getTransports()를 통해 공개 키 자격 증명의 지원 전송 방식을 확인할 수 있습니다.

usb: 해당 인증기가 분리형 USB를 통해 접속될 수 있음을 나타냅니다.
nfc: 해당 인증기가 근거리 무선통신(NFC)을 통해 접속될 수 있음을 나타냅니다.
ble: 해당 인증기가 블루투스 스마트(저전력 블루투스 / BLE)를 통해 접속될 수 있음을 나타냅니다.
internal: 해당 인증기가 클라이언트 디바이스별 전송 방식을 통해 접속되며, 즉 플랫폼 인증기임을 의미합니다. 이러한 인증기는 클라이언트 디바이스에서 분리할 수 없습니다.

5.8.5. 암호 알고리즘 식별자(typedef `COSEAlgorithmIdentifier`)

typedef long COSEAlgorithmIdentifier;

COSEAlgorithmIdentifier 값은 암호 알고리즘을 식별하는 숫자입니다. 알고리즘 식별자는 IANA COSE 알고리즘 레지스트리 [IANA-COSE-ALGS-REG]에 등록된 값을 사용하는 것이 좋으며, 예를 들어 "ES256"에는 -7, "RS256"에는 -257을 사용합니다.

COSE 알고리즘 레지스트리는 COSE key에서 다른 파라미터로 지정할 수 있는 자유도를 남겨둡니다. 상호운용성을 높이기 위해, 이 명세는 자격 증명 공개키에 대해 다음을 추가로 보장합니다:

ES256(-7) 알고리즘 키는 crv 파라미터로 반드시 P-256(1)을 지정해야 하며, 압축 포인트 형식을 사용하면 안 됩니다.
ES384(-35) 알고리즘 키는 crv 파라미터로 반드시 P-384(2)를 지정해야 하며, 압축 포인트 형식을 사용하면 안 됩니다.
ES512(-36) 알고리즘 키는 crv 파라미터로 반드시 P-521(3)을 지정해야 하며, 압축 포인트 형식을 사용하면 안 됩니다.
EdDSA(-8) 알고리즘 키는 crv 파라미터로 반드시 Ed25519(6)를 지정해야 합니다. (COSE에서는 항상 압축 형식 사용.)

참고: 이 알고리즘들로 서명 검증을 올바르게 구현하기 위해서는 많은 검사가 필요합니다. 그 중 하나는 압축되지 않은 타원 곡선 포인트를 처리할 때, 해당 포인트가 실제로 곡선 위에 있는지 확인하는 것입니다. 이 검사는 암호 라이브러리와 다른 코드 사이에서 누락될 위험이 높기 때문에 강조됩니다.

5.8.6. 사용자 검증 요구 열거형(enum `UserVerificationRequirement`)

enum UserVerificationRequirement {
    "required",
    "preferred",
    "discouraged"
};

WebAuthn 신뢰 당사자는 일부 작업에 대해 사용자 검증을 요구할 수 있고, 다른 작업에는 요구하지 않을 수도 있습니다. 이 타입을 사용해 필요를 표현할 수 있습니다.

참고: UserVerificationRequirement 열거형은 의도적으로 참조되지 않았습니다. 자세한 내용은 § 2.1.1 DOMString 타입의 열거형을 참고하세요.

required: 이 값은 신뢰 당사자가 해당 작업에 사용자 검증을 반드시 요구하며, 응답에 UV 플래그가 설정되어 있지 않으면 작업이 실패함을 의미합니다.
preferred: 이 값은 신뢰 당사자가 가능하다면 해당 작업에 사용자 검증을 선호하지만, 응답에 UV 플래그가 설정되어 있지 않아도 작업이 실패하지 않음을 의미합니다.
discouraged: 이 값은 신뢰 당사자가 해당 작업에 사용자 검증이 사용되지 않기를 원함을 나타냅니다(예: 사용자 인터랙션 흐름의 방해를 최소화하기 위해).

5.9. Permissions Policy 통합

Headers/Feature-Policy/publickey-credentials-get

현행 표준 엔진 중 한 개에서만 지원됨.

Firefox없음Safari없음Chrome84+

Opera없음Edge84+

Edge (Legacy)없음IE없음

Firefox for Android없음iOS Safari없음Chrome for Android84+Android WebView84+Samsung Internet없음Opera Mobile없음

이 명세는 "publickey-credentials-get"라는 feature-identifier 토큰으로 식별되는 하나의 정책 제어 기능을 정의합니다. 기본 허용 목록(default allowlist)은 'self'입니다. [Permissions-Policy]

Document의 permissions policy는 해당 문서의 모든 콘텐츠가 Web Authentication API를 성공적으로 호출할 수 있는지 결정합니다. 즉, navigator.credentials.get({publicKey:..., ...})를 사용할 수 있는지 여부입니다. 비활성화된 문서에서는 해당 메서드들을 사용할 수 없으며, 시도하면 오류가 반환됩니다.

참고: [CREDENTIAL-MANAGEMENT-1]에서 정의된 알고리즘이 실제 permissions policy 평가를 수행합니다. 이러한 정책 평가는 current settings object에 접근해야 할 때 이루어져야 하기 때문입니다. [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드는 해당 접근 권한이 없으며, [CREDENTIAL-MANAGEMENT-1]에서 정의된 알고리즘에 의해 병렬로 호출됩니다.

5.10. `iframe` 요소 내에서 Web Authentication 사용

Web Authentication API는 cross-origin iframe에서는 기본적으로 비활성화됩니다. 이 기본 정책을 재정의하고 cross-origin iframe이 Web Authentication API의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 메서드를 호출할 수 있도록 하려면, allow 속성을 iframe 요소에 지정하고, publickey-credentials-get feature-identifier 토큰을 allow 속성 값에 포함시켜야 합니다.

신뢰 당사자가 임베디드 컨텍스트에서 WebAuthn API를 활용할 경우, § 13.4.2 임베디드 사용의 가시성 고려사항에서 UI redressing 및 가능한 완화책을 검토해야 합니다.

6. WebAuthn 인증기 모델

Web Authentication API는 WebAuthn 인증기의 특정 추상 기능 모델을 내포합니다. 이 섹션에서는 인증기 모델을 설명합니다.

클라이언트 플랫폼은 이 추상 모델을 원하는 방식으로 구현하고 노출할 수 있습니다. 하지만 해당 클라이언트 플랫폼이 지원하는 인증기에서 클라이언트의 Web Authentication API 구현 동작은 반드시 § 5 Web Authentication API에 명시된 동작과 구별할 수 없어야 합니다.

참고: [FIDO-CTAP]는 이 모델의 구체적인 구현 예시이지만, 반환되는 데이터와 WebAuthn API 알고리즘에서 기대하는 데이터 간 차이가 있습니다. CTAP2 응답 메시지는 이 명세에서 동일 객체에 대해 정의된 문자열 키 대신 정수 키로 구성된 CBOR 맵입니다. 클라이언트가 이러한 데이터의 필요한 변환을 수행해야 합니다. [FIDO-CTAP] 명세는 6.2절 §6.2. Responses에서 CTAP2 정수 키와 WebAuthn 문자열 키 간 매핑을 자세히 설명합니다.

인증기 측에서는 지원해야 할 논리적 동작과 클라이언트 및 WebAuthn 신뢰 당사자에게 노출되는 데이터 형식을 정의합니다. 단, 클라이언트 디바이스와 인증기 간의 통신 방법은 상호운용성에 필요한 경우가 아니면 정의하지 않습니다. 예를 들어, USB나 NFC 같은 전송 방식에 대한 프로토콜은 정의하지 않습니다. 또한, 구체적인 오류 코드나 반환 방식도 정의하지 않으며, 클라이언트의 요구에 맞는 오류 동작만 정의합니다. 따라서 특정 오류 코드는 어떤 오류 조건이 서로 구별되어야(또는 구별되지 않아야) 하는지 보여주기 위한 수단으로 언급됩니다. 이는 준수적이고 안전한 클라이언트 구현을 가능하게 합니다.

신뢰 당사자는 필요 시 인증기 선택에 영향을 줄 수 있으며, 자격 증명 생성 또는 어서션 생성 시 각각 자격 증명 생성 옵션이나 어서션 생성 옵션을 활용해 다양한 인증기 특성을 지정할 수 있습니다. WebAuthn API의 알고리즘은 이러한 옵션을 수집해 아래 정의된 해당 인증기 동작에 전달합니다.

이 추상 모델에서 인증기는 키 관리 및 암호 서명 기능을 제공합니다. 인증기는 WebAuthn 클라이언트에 내장되거나 별도의 장치로 존재할 수 있습니다. 인증기 자체에 더 높은 보안 수준의 암호 모듈이 포함될 수 있습니다. 이는 인증기가 WebAuthn 클라이언트에 내장된 경우 특히 중요하며, 이러한 암호 모듈(TPM 등)은 인증기의 나머지 부분보다 더 신뢰할 수 있다고 간주될 수 있습니다.

각 인증기는 자격 증명 맵을 저장하는데, 이는 (rpId, [userHandle])에서 공개 키 자격 증명 소스로의 맵입니다.

또한 각 인증기는 AAGUID를 가지며, 이는 인증기 유형(예: 제조사 및 모델)을 나타내는 128비트 식별자입니다. AAGUID는 제조사가 제조한 실질적으로 동일한 인증기 모두에 대해 동일해야 하며, 다른 유형의 인증기와는 높은 확률로 달라야 합니다. 인증기 유형의 AAGUID는 무작위로 생성하는 것이 바람직합니다. 신뢰 당사자는 AAGUID를 활용해 인증기의 인증 수준, 키 보호 강도 등 특성을 다른 출처의 정보를 통해 추론할 수 있습니다.

인증기의 주요 기능은 다양한 컨텍스트 데이터에 바인딩된 WebAuthn 서명을 제공하는 것입니다. 이 데이터들은 서명 요청이 서버에서 인증기로 전달되는 과정에서 스택의 여러 단계에서 관찰되고 추가됩니다. 서버는 서명을 검증할 때 이러한 바인딩 값을 기대 값과 비교합니다. 이런 컨텍스트 바인딩은 두 가지로 나뉩니다: 신뢰 당사자 또는 클라이언트가 추가한 클라이언트 데이터, 그리고 인증기가 추가한 인증기 데이터입니다. 인증기는 클라이언트 데이터에 대해 서명을 하지만, 그 내용 자체에는 관심이 없습니다. 인증기의 대역폭과 처리 요구를 줄이기 위해, 클라이언트는 클라이언트 데이터를 해싱한 값을 인증기에 전달하고, 인증기는 직렬화된 클라이언트 데이터의 해시와 자신의 인증기 데이터를 조합해 서명합니다.

이 설계의 목표는 다음과 같이 요약할 수 있습니다.

서명 생성 방식은 클라이언트 디바이스와 인증기 간 연결이 대역폭/지연 측면에서 매우 제한된 경우도 지원해야 합니다. 예: 블루투스 저전력, NFC 등.
인증기가 처리하는 데이터는 작고 저수준 코드에서 해석하기 쉬워야 하며, 인증기가 JSON 등 고수준 인코딩을 파싱할 필요가 없어야 합니다.
클라이언트와 인증기 모두 필요에 따라 컨텍스트 바인딩을 자유롭게 추가할 수 있어야 합니다.
설계는 도입과 구현을 돕기 위해 기존 인코딩 포맷을 최대한 재사용하는 것을 목표로 합니다.

인증기는 두 가지 목적으로 암호 서명을 생성합니다:

어테스테이션 서명은 authenticatorMakeCredential 연산을 통해 새로운 공개 키 자격 증명이 생성될 때 만들어집니다. 어테스테이션 서명은 인증기 및 자격 증명의 특정 특성에 대한 암호학적 증거를 제공합니다. 예를 들어, 어테스테이션 서명은 인증기 유형(AAGUID로 표시됨)과 자격 증명 공개키를 증명합니다. 어테스테이션 서명은 원하는 어테스테이션의 유형에 따라 선택된 어테스테이션 개인키로 서명됩니다. 어테스테이션에 대한 자세한 내용은 § 6.5 어테스테이션을 참고하세요.
어서션 서명은 authenticatorGetAssertion 메서드가 호출될 때 생성됩니다. 이는 인증기가 사용자가 특정 트랜잭션(로그인, 구매 등)에 동의했다는 주장을 나타냅니다. 즉, 어서션 서명은 특정 자격 증명 개인키를 가진 인증기가 해당 자격 증명 생성을 동의한 사용자와 동일한 사용자임을 최대한 확인했다는 것을 증명합니다. 또한 클라이언트 데이터라 불리는 추가 정보를 주장하며, 예를 들어 사용자 동의가 어떻게 제공되었는지, 인증기가 사용자에게 보여준 프롬프트 등입니다. 어서션 서명 형식은 아래 그림 4에 예시가 있습니다.

WebAuthn 서명은 어테스테이션 서명과 어서션 서명 모두를 의미합니다. 이 서명들의 형식과 생성 절차는 아래에서 정의되어 있습니다.

6.1. 인증기 데이터

인증기 데이터 구조는 인증기가 수행하는 컨텍스트 바인딩을 인코딩합니다. 이 바인딩은 인증기가 직접 제어하며, WebAuthn 신뢰 당사자가 인증기의 보안 특성을 평가한 신뢰에 기반합니다. 극단적으로 인증기가 클라이언트에 내장되어 있다면, 그 바인딩은 클라이언트 데이터만큼이나 신뢰할 수 없을 수 있습니다. 반대로 인증기가 높은 보안 하드웨어와 소프트웨어를 갖춘 독립적인 장치라면 클라이언트와 보안 채널로 연결될 수 있습니다. 두 경우 모두 신뢰 당사자는 동일한 형식의 인증기 데이터를 받고 인증기에 대한 지식을 바탕으로 신뢰 결정을 내립니다.

인증기 데이터는 간결하면서도 확장 가능한 인코딩을 가지고 있습니다. 이는 인증기가 제한된 기능과 저전력 요구, 클라이언트 플랫폼보다 훨씬 단순한 소프트웨어 스택을 가진 장치일 수 있기 때문입니다.

인증기 데이터 구조는 최소 37바이트 이상의 바이트 배열이며, 표 와 같이 배치됩니다.

이름	길이(바이트)	설명
rpIdHash	32	자격 증명이 스코프되는 RP ID의 SHA-256 해시값.
flags	1	플래그(비트 0이 최하위 비트): 비트 0: 사용자 존재(UP) 결과. `1`은 사용자가 존재함을 의미. `0`은 사용자가 존재하지 않음을 의미. 비트 1: 미래를 위한 예약(`RFU1`). 비트 2: 사용자 검증됨(UV) 결과. `1`은 사용자가 검증됨을 의미. `0`은 사용자가 검증되지 않음을 의미. 비트 3-5: 미래를 위한 예약(`RFU2`). 비트 6: 어테스트된 자격 증명 데이터 포함됨(`AT`). 인증기가 어테스트된 자격 증명 데이터를 추가했는지 나타냄. 비트 7: 확장 데이터 포함됨(`ED`). 인증기 데이터에 확장이 포함되어 있는지 표시.
signCount	4	서명 카운터, 32비트 부호 없는 빅엔디언 정수.
attestedCredentialData	가변(존재하는 경우)	어테스트된 자격 증명 데이터(존재 시). 자세한 내용은 § 6.5.1 어테스트된 자격 증명 데이터 참고. 길이는 자격 증명 ID 및 자격 증명 공개키의 길이에 따라 달라짐.
extensions	가변(존재하는 경우)	확장 정의 인증기 데이터. 이는 CBOR [RFC8949] 맵이며 확장 식별자를 키로, 인증기 확장 출력을 값으로 가집니다. 자세한 내용은 § 9 WebAuthn 확장 참고.

인증기 데이터 레이아웃. 이름 열에 있는 이름들은 본 문서 내 참고용이며, 실제 인증기 데이터 표현에는 포함되지 않습니다.

RP ID는 자격 증명 생성 시 클라이언트에서 처음 받아오며, 어서션 생성 시에도 다시 받아옵니다. 그러나 다른 클라이언트 데이터와는 몇 가지 중요한 차이가 있습니다. 첫째, 클라이언트 데이터와 달리 자격 증명의 RP ID는 작업 간에 바뀌지 않고 해당 자격 증명 생애 동안 동일하게 유지됩니다. 둘째, authenticatorGetAssertion 작업 중, 인증기가 요청받은 자격 증명이 스코프되는 RP ID가 클라이언트가 전달한 RP ID와 정확히 일치하는지 확인하여 검증합니다.

인증기는 다음 절차로 인증기 데이터 구조를 생성합니다:

RP ID를 SHA-256으로 해싱하여 rpIdHash를 생성합니다.
UP 플래그는 인증기가 사용자 존재 테스트를 수행한 경우에만 설정됩니다. UV 플래그는 인증기가 사용자 검증을 수행한 경우에만 설정됩니다. RFU 비트는 0으로 설정해야 합니다.

참고: 인증기가 사용자 존재 테스트와 사용자 검증을 모두 수행한 경우(둘이 하나의 승인 제스처로 합쳐진 경우 포함), 인증기는 UP 플래그와 UV 플래그를 모두 설정합니다.
어테스테이션 서명의 경우 인증기는 AT 플래그를 설정하고 attestedCredentialData를 포함시켜야 합니다. 어서션 서명의 경우 AT 플래그는 설정하지 않으며 attestedCredentialData도 포함시키지 않아야 합니다.
인증기가 확장 데이터를 포함하지 않으면 ED 플래그를 0으로, 포함하면 1로 설정해야 합니다.

그림 은 인증기 데이터 구조의 시각적 예시입니다.

참고: 인증기 데이터는 자신의 길이를 기술합니다. AT, ED 플래그가 모두 설정되지 않으면 항상 37바이트입니다. 어테스트된 자격 증명 데이터(AT 플래그가 설정된 경우에만 존재)는 자체 길이를 기술합니다. ED 플래그가 설정되어 있다면 전체 길이는 37바이트 + 어테스트된 자격 증명 데이터 길이(AT 플래그가 설정된 경우), 그리고 그 뒤를 따르는 확장 출력(CBOR 맵)의 길이입니다.

어테스트된 자격 증명 데이터의 길이 결정에는 자격 증명 ID(credentialId)의 길이를 이용해 credentialPublicKey의 시작 위치를 결정하고, 이어서 credentialPublicKey의 길이를 결정합니다(자세한 내용은 RFC8152 7절 참고).

6.1.1. 서명 카운터 고려사항

인증기는 서명 카운터 기능을 구현하는 것이 좋습니다. 이 카운터는 개념적으로 인증기가 각 자격 증명별로 또는 인증기 전체에 대해 전역적으로 저장할 수 있습니다. 자격 증명의 초기 서명 카운터 값은 authenticatorMakeCredential에서 반환된 인증기 데이터의 signCount 값으로 지정됩니다. 서명 카운터는 authenticatorGetAssertion이 성공할 때마다 양의 값으로 증가하며, 이후 값이 WebAuthn 신뢰 당사자에게 인증기 데이터 내에 다시 반환됩니다. 서명 카운터의 목적은 신뢰 당사자가 복제된 인증기를 탐지할 수 있도록 돕는 것입니다. 복제 탐지는 보호 수단이 제한된 인증기에 더 중요합니다.

신뢰 당사자는 가장 최근의 authenticatorGetAssertion 작업의 서명 카운터를 저장합니다. (또는 자격 증명에 대해 authenticatorGetAssertion이 한 번도 수행되지 않았다면 authenticatorMakeCredential의 카운터를 저장합니다.) 이후 authenticatorGetAssertion 작업에서는 저장된 서명 카운터 값과 어서션의 인증기 데이터에 반환된 새로운 signCount 값을 비교합니다. 둘 중 하나라도 0이 아니고, 새로운 signCount 값이 저장된 값보다 작거나 같으면 복제된 인증기가 존재하거나 인증기가 오작동 중일 수 있습니다.

서명 카운터 불일치가 감지되어도 현재 작업이 복제된 인증기에서 수행된 것인지 원본 인증기에서 수행된 것인지는 알 수 없습니다. 신뢰 당사자는 각자의 상황과 위험 허용도에 따라 적절히 대응해야 합니다.

인증기:

각 자격 증명별 서명 카운터를 구현하는 것이 좋습니다. 이를 통해 서명 카운터 값이 신뢰 당사자간에 공유되어 사용자의 상관 핸들로 쓰이는 것을 방지할 수 있습니다. 인증기는 전역 서명 카운터(인증기 단위)도 구현 가능하지만, 이는 사용자 프라이버시 측면에서 덜 우호적입니다.
서명 카운터 값이 하드웨어 오류 등으로 인해 실수로 감소하지 않게 해야 합니다.

6.1.2. FIDO U2F 서명 형식 호환성

어떤 어서션 서명이 인증기 데이터 구조와 직렬화된 클라이언트 데이터의 해시를 연결해서 서명한다면, 이는 FIDO U2F 인증 서명 형식과 호환됩니다(섹션 5.4, [FIDO-U2F-Message-Formats] 참고).

이는 FIDO U2F 인증 응답 메시지에서 서명된 데이터의 처음 37바이트가 유효한 인증기 데이터 구조이고, 나머지 32바이트가 직렬화된 클라이언트 데이터의 해시이기 때문입니다. 이 인증기 데이터 구조에서 rpIdHash는 FIDO U2F application parameter이고, flags의 UP 이외는 항상 0이며, attestedCredentialData와 extensions는 존재하지 않습니다. 따라서 FIDO U2F 인증 서명은 authenticatorMakeCredential 작업에서 생성된 다른 어서션 서명과 동일한 절차로 검증할 수 있습니다.

6.2. 인증기 분류

많은 사용 사례는 사용된 인증기의 역량에 의존합니다. 이 섹션은 그러한 역량, 가장 중요한 조합, 그리고 어떤 사용 사례가 그런 조합을 가능하게 하는지에 대해 용어를 정의합니다.

예시:

특정 클라이언트 디바이스에서 처음 인증할 때는 사용자가 해당 디바이스에 플랫폼 자격 증명을 아직 갖고 있지 않으므로 로밍 인증기가 필요합니다.
동일 클라이언트 디바이스에서 재인증할 때는 내장된 플랫폼 인증기가 가장 편리합니다. 별도 장치를 찾을 필요 없이 바로 사용 가능하기 때문입니다.
기존 사용자명/비밀번호에 추가로 2차 인증을 할 때는 어떤 인증기든 사용할 수 있습니다.
비밀번호 없는 다중 인증은 사용자 검증이 가능한 인증기가 필요하며, 경우에 따라 발견가능 자격 증명 지원도 요구됩니다.
노트북은 USB와 블루투스를 통해 로밍 인증기 연결을 지원할 수 있지만, 모바일 폰은 NFC만 지원할 수 있습니다.

위 예시들은 주요 인증기 타입 특성을 보여줍니다:

인증기가 로밍인지 플랫폼 인증기인지 — 인증기 부착 방식. 로밍 인증기는 클라이언트와 통신을 위해 하나 이상의 전송 방식을 지원할 수 있습니다.
인증기가 사용자 검증을 지원하는지 — 인증 요소 역량.
인증기가 발견가능 자격 증명 지원인지 — 자격 증명 저장 방식.

이러한 특성은 서로 독립적이며 이론상 어떤 조합도 가능하지만, 표 는 특별히 관심을 가질 만한 인증기 타입들의 목록과 이름을 제공합니다.

인증기 타입	인증기 부착 방식	자격 증명 저장 방식	인증 요소 역량
2차 인증 플랫폼 인증기	platform	둘 다 가능	단일 요소 지원
사용자 검증 플랫폼 인증기	platform	둘 다 가능	다중 요소 지원
2차 인증 로밍 인증기	cross-platform	서버 저장	단일 요소 지원
1차 인증 로밍 인증기	cross-platform	클라이언트 저장	다중 요소 지원

주요 인증기 타입의 이름 정의.

2차 인증 플랫폼 인증기는 동일 클라이언트 디바이스에서 재인증하기에 편리하며, 신규 세션 시작이나 기존 세션 재개 시 모두 추가 보안 계층을 제공할 수 있습니다. 2차 인증 로밍 인증기는 특정 클라이언트 디바이스에서 처음 인증할 때나 여러 사용자가 공유하는 클라이언트 디바이스에서 사용될 가능성이 높습니다.

사용자 검증 플랫폼 인증기와 1차 인증 로밍 인증기는 비밀번호 없는 다중 인증을 가능하게 합니다. 자격 증명 개인키 소유 증명 외에도, 이 인증기들은 사용자 검증(예: PIN, 생체 인식)을 두번째 인증 요소로 지원합니다. 인증기는 두 종류의 인증 요소 역할을 할 수 있으므로 다중 인증을 구현하면서 신뢰 당사자와 비밀번호를 공유할 필요가 없어집니다.

표 에 이름이 없는 네 가지 조합은 구별되는 사용 사례가 적습니다:

플랫폼 인증기에서는 자격 증명 저장 방식이 로밍 인증기만큼 중요하지 않습니다. 플랫폼 인증기 사용자는 일반적으로 세션 쿠키 등(즉, 주변 자격 증명)으로 구별 가능합니다.
로밍 인증기가 발견가능 자격 증명 지원이지만 다중 요소 지원이 아닌 경우는, 사용자 이름 없이 단일 요소 인증에 사용할 수 있습니다. 이때 사용자는 user handle과 자격 증명 개인키 소유만으로 인증됩니다. 이는 특정 상황에서 유용하지만, 인증기 도난에 매우 취약할 수 있습니다.
로밍 인증기가 다중 요소 지원이지만 발견가능 자격 증명 지원이 아닌 경우, 다중 인증에 사용될 수 있으나, 사용자를 먼저 식별해야 하므로 개인정보 유출 위험이 있습니다(자세한 내용은 § 14.6.3 Credential ID를 통한 프라이버시 유출 참고).

아래 하위 섹션에서는 인증기 부착 방식, 자격 증명 저장 방식, 인증 요소 역량을 더 자세히 정의합니다.

6.2.1. 인증기 부착 방식

클라이언트는 인증자와 다양한 방식으로 통신할 수 있습니다. 예를 들어, 클라이언트는 클라이언트 기기별 API를 사용하여 인증자와 통신할 수 있으며, 이 인증자는 클라이언트 기기에 물리적으로 연결되어 있습니다. 반면, 클라이언트는 Bluetooth와 같은 다양한 표준화된 크로스 플랫폼 전송 프로토콜(자세한 내용은 § 5.8.4 인증자 전송 열거(enum AuthenticatorTransport) 참고)을 사용하여 크로스 플랫폼 부착된 인증자를 발견하고 통신할 수 있습니다. 인증자 중에서 클라이언트 기기의 일부인 경우를 플랫폼 인증자라고 하며, 크로스 플랫폼 전송 프로토콜을 통해 접근 가능한 경우를 로밍 인증자라고 합니다.

플랫폼 인증기는 클라이언트 디바이스별 전송 방식(플랫폼 부착)으로 연결되며, 일반적으로 클라이언트 디바이스에서 분리할 수 없습니다. 플랫폼 인증기에 바인딩된 공개 키 자격 증명을 플랫폼 자격 증명이라고 합니다.
로밍 인증기는 크로스 플랫폼 전송 방식(크로스 플랫폼 부착)으로 연결됩니다. 이 타입의 인증기는 클라이언트 디바이스에서 분리 가능하며 "로밍"할 수 있습니다. 로밍 인증기에 바인딩된 공개 키 자격 증명을 로밍 자격 증명이라고 합니다.

일부 플랫폼 인증기는 상황에 따라 로밍 인증기 역할도 할 수 있습니다. 예를 들어, 모바일 기기에 내장된 플랫폼 인증기가 Bluetooth를 통해 로밍 인증기로 동작할 수 있습니다. 이 경우 모바일 기기에서 동작하는 클라이언트는 해당 인증기를 플랫폼 인증기로 인식하지만, 다른 클라이언트 디바이스에서 Bluetooth로 통신하는 클라이언트는 동일 인증기를 로밍 인증기로 인식합니다.

플랫폼 인증기의 주요 사용 사례는 특정 클라이언트 디바이스를 "신뢰 디바이스"로 등록하는 것입니다. 이렇게 하면 클라이언트 디바이스 자체가 미래 소유물 인증 요소(authentication factor)로 동작하게 됩니다. 이를 통해 사용자는 이후 인증 절차에서 로밍 인증기를 찾을 필요 없이 편리하게 인증할 수 있습니다.

로밍 인증기의 사용 사례로는: 새로운 클라이언트 디바이스에서 최초 인증, 사용 빈도가 낮은 클라이언트 디바이스, 여러 사용자가 공유하는 클라이언트 디바이스, 플랫폼 인증기가 없는 클라이언트 디바이스에서 인증하는 경우, 또는 정책/선호에 따라 인증기를 사용하는 클라이언트 디바이스와 분리해야 할 경우 등이 있습니다. 또한 로밍 인증기는 다른 인증기 분실 시 백업 자격 증명 저장 용도로 사용할 수도 있습니다.

6.2.2. 자격 증명 저장 방식

인증기는 공개 키 자격 증명 소스를 두 가지 방식 중 하나로 저장할 수 있습니다:

인증기, 클라이언트 또는 클라이언트 디바이스에 내장된 영구 저장소에 저장(예: 안전한 보안 모듈). 이는 클라이언트 측 발견가능 공개 키 자격 증명 소스의 기술적 요구사항입니다.
자격 증명 개인키를 암호화(랩핑)하여 해당 인증기만 복호화(언랩)할 수 있도록 하고, 만들어진 암호문을 자격 증명 ID로 사용합니다. 자격 증명 ID는 신뢰 당사자가 저장하며, allowCredentials 옵션을 통해 인증기에 다시 전달되어 인증기가 개인키를 복호화하여 사용할 수 있게 됩니다.

이 방식은 인증기가 자격 증명 개인키를 무제한 저장할 수 있게 해줍니다. 암호화된 자격 증명 개인키는 신뢰 당사자가 저장하므로 인증기가 직접 저장하지 않아도 되지만, 이 방식으로 저장된 자격 증명은 인증기가 사용하기 전에 신뢰 당사자로부터 먼저 가져와야 합니다.

인증기가 어느 저장 방식을 지원하는지가 아래와 같이 자격 증명 저장 방식을 정의합니다:

인증기가 클라이언트 측 발견가능 공개 키 자격 증명 소스를 지원하면 클라이언트 측 자격 증명 저장 방식을 가진다고 합니다. 클라이언트 측 자격 증명 저장 방식 인증기는 발견가능 자격 증명 지원이라고도 합니다.
인증기가 클라이언트 측 자격 증명 저장 방식을 지원하지 않는 경우, 즉 암호문 형태로 자격 증명 개인키만 저장하는 경우 서버 측 자격 증명 저장 방식을 가진다고 합니다.

발견가능 자격 증명 지원 인증기는 두 저장 전략을 모두 지원할 수도 있습니다. 이 경우 인증기는 자격 증명마다 다른 저장 전략을 사용할 수 있지만, residentKey 또는 requireResidentKey 옵션에 따라야 합니다(create() 참조).

6.2.3. 인증 요소 역량

신원을 증명하는 인증 요소의 범주는 세 가지가 있습니다: 소유물, 지식, 특성. 예를 들어 물리적 키, 비밀번호, 지문 등이 해당합니다.

모든 WebAuthn 인증기는 소유물 범주에 속하지만, 사용자 검증을 지원하는 인증기는 추가로 1~2개의 인증 요소 역할도 할 수 있습니다. 예를 들어 인증기가 PIN 검증 가능하면 해당 PIN은 지식 요소이고, 생체 인증기가 특성 요소를 검증할 수 있습니다. 따라서 사용자 검증을 지원하는 인증기는 다중 요소 지원입니다. 반대로 다중 요소 지원이 아닌 인증기는 단일 요소 지원입니다. 단일 다중 요소 지원 인증기가 여러 종류 사용자 검증 방식을 지원할 수도 있어 인증 요소 세 가지 모두 역할을 할 수 있습니다.

사용자 검증은 인증기에서 로컬로 수행되며 신뢰 당사자가 직접 수행하는 것이 아닙니다. 인증기는 사용자 검증 여부를 서명된 응답의 UV 플래그로 표시해 신뢰 당사자에게 반환합니다. 신뢰 당사자는 UV 플래그를 통해 추가 인증 요소가 등록 또는 인증 절차에서 사용됐음을 검증할 수 있습니다. UV 플래그의 진위성은 인증기의 어테스테이션 문을 검사하여 평가할 수 있습니다.

6.3. 인증기 동작

WebAuthn 클라이언트는 인증기 동작을 호출하기 위해 반드시 인증기에 연결해야 합니다. 이 연결은 인증기 세션을 정의합니다. 인증기는 세션 간 격리를 유지해야 하며, 한 번에 하나의 세션만 허용하거나 더 복잡한 세션 관리로 격리를 구현할 수 있습니다.

다음 동작들은 인증기 세션에서 클라이언트가 호출할 수 있습니다.

6.3.1. 자격 증명 ID로 자격 증명 소스 조회 알고리즘

credential id credentialId를 authenticator authenticator에서 조회한 결과는 다음 알고리즘으로 결정됩니다:

authenticator가 credentialId를 복호화해 공개 키 자격 증명 소스 credSource로 만들 수 있다면:
1. credSource.id를 credentialId로 설정합니다.
2. credSource를 반환합니다.
각 공개 키 자격 증명 소스 credSource에 대해 authenticator의 자격 증명 맵에서:
1. credSource.id가 credentialId와 같으면 credSource를 반환합니다.
null을 반환합니다.

6.3.2. authenticatorMakeCredential 동작

다음 입력 파라미터를 받습니다:

hash: 클라이언트가 제공한 직렬화된 클라이언트 데이터의 해시.
rpEntity: 신뢰 당사자의 PublicKeyCredentialRpEntity.
userEntity: 사용자 계정의 PublicKeyCredentialUserEntity로, 신뢰 당사자가 제공한 user handle을 포함합니다.
requireResidentKey: 자격 증명 생성에 대한 실효적 resident key 요구사항으로, 클라이언트가 결정한 불리언 값입니다.
requireUserPresence: 상수 불리언 값 true. WebAuthn에서는 사용자 존재 테스트를 선택적으로 하지 않지만, 이 추상 인증기 모델을 구현에 적용하기 쉽게 하기 위해 의사 파라미터로 포함되어 있습니다.
requireUserVerification: 자격 증명 생성에 대한 실효적 사용자 검증 요구사항으로, 클라이언트가 결정한 불리언 값입니다.
credTypesAndPubKeyAlgs: 신뢰 당사자가 요청한 PublicKeyCredentialType와 공개키 알고리즘(COSEAlgorithmIdentifier) 쌍의 시퀀스입니다. 이 시퀀스는 우선순위가 높은 순서대로 정렬됩니다. 인증기는 가능한 한 가장 선호하는 자격 증명을 생성하려고 시도합니다.
excludeCredentialDescriptorList: 선택적 PublicKeyCredentialDescriptor 객체 리스트로, 신뢰 당사자가 제공하며, 인증기가 이들 중 하나를 알고 있다면 새 자격 증명을 생성하지 않아야 합니다. excludeCredentialDescriptorList에는 이미 알려진 자격 증명 목록이 포함됩니다.
enterpriseAttestationPossible: 인증기가 개별 식별 어테스테이션을 반환할 수 있음을 나타내는 불리언 값입니다.
extensions: 신뢰 당사자가 요청한 확장(있을 경우)을 바탕으로 클라이언트가 생성한, 확장 식별자에서 인증기 확장 입력으로의 CBOR 맵.

참고: 이 동작을 실행하기 전에, 해당 인증기 세션에서 진행 중인 모든 다른 동작을 authenticatorCancel 동작을 실행하여 중단해야 합니다.

이 동작이 호출되면, 인증기는 다음 절차를 수행해야 합니다:

모든 입력 파라미터가 문법적으로 올바른지, 길이가 맞는지 확인합니다. 그렇지 않으면 "UnknownError" 오류 코드를 반환하고 작업을 종료합니다.
credTypesAndPubKeyAlgs에 지정된 PublicKeyCredentialType 및 암호 파라미터 조합 중 하나라도 지원되는지 확인합니다. 지원되지 않으면 "NotSupportedError" 오류 코드를 반환하고 작업을 종료합니다.
각 descriptor에 대해 excludeCredentialDescriptorList에서:
1. 이 인증기에서 descriptor.id를 조회한 결과가 null이 아니고, 반환된 항목의 RP ID와 type이 각각 rpEntity.id와 excludeCredentialDescriptorList.type에 일치한다면, 새로운 자격 증명 생성을 위한 승인 제스처로 사용자 동의를 수집합니다. 이 승인 제스처에는 반드시 사용자 존재 테스트가 포함되어야 합니다. 사용자가
  
  새 자격 증명 생성에 동의한 경우
  
  "InvalidStateError" 오류 코드를 반환하고 작업을 종료합니다.
  
  동의하지 않은 경우
  
  "NotAllowedError" 오류 코드를 반환하고 작업을 종료합니다.
  
  참고: 이 승인 제스처의 목적은 자격 증명 생성을 진행하는 것이 아니라, 프라이버시 보호를 위해 descriptor.id가 이 인증기에 바인딩되어 있음을 공개하는 것에 대해 승인받는 것입니다. 사용자가 동의하면 클라이언트와 신뢰 당사자가 이를 감지하고 사용자를 다른 인증기로 안내할 수 있습니다. 동의하지 않으면 인증기는 해당 descriptor.id가 자신에게 바인딩되어 있음을 공개하지 않고, 사용자가 단순히 자격 증명 생성에 동의하지 않은 것처럼 응답합니다.
requireResidentKey가 true이고 인증기가 클라이언트 측 발견가능 공개 키 자격 증명 소스를 저장할 수 없다면, "ConstraintError" 오류 코드를 반환하고 작업을 종료합니다.
requireUserVerification이 true이고 인증기가 사용자 검증을 수행할 수 없다면, "ConstraintError" 오류 코드를 반환하고 작업을 종료합니다.
새로운 자격 증명 생성에 대한 사용자 동의를 확인하는 승인 제스처를 수집합니다. 인증기에 자체 출력 기능이 있으면 인증기가 프롬프트를 표시하고, 그렇지 않으면 사용자 에이전트가 표시합니다. 프롬프트에는 가능하다면 rpEntity.id, rpEntity.name, userEntity.name 그리고 userEntity.displayName 을 표시해야 합니다.
requireUserVerification이 true이면 승인 제스처에 사용자 검증이 포함되어야 합니다.

requireUserPresence가 true이면 승인 제스처에 사용자 존재 테스트가 포함되어야 합니다.

사용자가 동의하지 않거나 사용자 검증에 실패하면 "NotAllowedError" 오류 코드를 반환하고 작업을 종료합니다.
승인 제스처가 완료되어 사용자 동의를 얻으면, 새 자격 증명 객체를 생성합니다:
1. 지원하는 첫 항목의 PublicKeyCredentialType 및 암호 파라미터 조합으로 새 암호키 쌍(publicKey, privateKey)을 생성합니다.
2. userHandle을 userEntity.id로 지정합니다.
3. credentialSource를 아래 필드를 가진 새 공개 키 자격 증명 소스로 만듭니다:
  
  type
  
  public-key
  
  privateKey
  
  privateKey
  
  rpId
  
  rpEntity.id
  
  userHandle
  
  userHandle
  
  otherUI
  
  인증기가 포함하기로 한 기타 정보.
4. requireResidentKey가 true이거나 인증기가 클라이언트 측 발견가능 공개 키 자격 증명 소스를 생성하기로 선택한 경우:
  1. 새 credential id를 credentialId로 지정합니다.
  2. credentialSource.id를 credentialId로 설정합니다.
  3. credentials를 이 인증기의 자격 증명 맵으로 지정합니다.
  4. Set credentials[rpEntity.id, userHandle] = credentialSource로 설정합니다.
5. 그 외의 경우:
  1. credentialId를 credentialSource를 직렬화·암호화하여 이 인증기만 복호화할 수 있도록 만든 결과로 지정합니다.
새 자격 증명 객체 생성 도중 오류가 발생하면 "UnknownError" 오류 코드를 반환하고 작업을 종료합니다.
processedExtensions를 인증기 확장 처리의 결과로 지정합니다(각 지원 확장 식별자 → 인증기 확장 입력에 대해 extensions에서).
인증기가 다음 중 어느 것인지에 따라:

U2F 디바이스인 경우

새 자격 증명의 서명 카운터 값을 0으로 지정합니다. (U2F 디바이스는 서명 카운터를 지원할 수 있지만 자격 증명 생성 시 카운터를 반환하지 않습니다. [FIDO-U2F-Message-Formats] 참고)

전역 서명 카운터를 지원하는 경우

새 인증기 데이터 생성 시 실제 전역 서명 카운터 값을 사용합니다.

자격 증명별 서명 카운터를 지원하는 경우

카운터를 할당하고 새 자격 증명에 연결하며, 카운터 값을 0으로 초기화합니다.

서명 카운터를 지원하지 않는 경우

새 자격 증명의 서명 카운터 값을 항상 0으로 지정합니다.
attestedCredentialData를 어테스트된 자격 증명 데이터 바이트 배열로 지정하며, credentialId와 publicKey를 포함합니다.
authenticatorData를 § 6.1 인증기 데이터에서 지정한 바이트 배열로 만들며, attestedCredentialData를 attestedCredentialData, processedExtensions(있다면)을 extensions로 포함합니다.
새 자격 증명에 대해 어테스테이션 객체를 생성합니다. § 6.5.4 어테스테이션 객체 생성의 절차에 따라, 인증기 선택 어테스테이션 문 형식, authenticatorData, hash와 enterpriseAttestationPossible 값을 반영합니다. 어테스테이션에 대한 자세한 내용은 § 6.5 어테스테이션 참고.

이 동작이 성공적으로 완료되면, 인증기는 어테스테이션 객체를 클라이언트에 반환합니다.

6.3.3. authenticatorGetAssertion 작업

다음 입력 매개변수를 받습니다:

rpId: 호출자의 RP ID로, 사용자 에이전트와 클라이언트에 의해 결정됩니다.
hash: 클라이언트가 제공한 직렬화된 클라이언트 데이터의 해시입니다.
allowCredentialDescriptorList: 목록에 해당하는 PublicKeyCredentialDescriptor 객체들의 OPTIONAL 목록으로, Relying Party가 허용하는 자격증명(클라이언트에 의해 필터링될 수 있음)을 설명합니다. (있다면)
requireUserPresence: 상수 불리언 값 true입니다. 이는 WebAuthn에서는 선택 사항이 아니지만, 일부 구현에서 사용자 존재 테스트를 선택적으로 적용할 수 있도록 이 추상 인증자 모델에 가상 매개변수로 포함됩니다.
requireUserVerification: 클라이언트가 제공한 불리언 값으로, 인증을 위한 실질적인 사용자 검증 요구사항입니다.
extensions: 클라이언트가 Relying Party가 요청한 확장에 따라 생성한 CBOR 맵으로, 확장 식별자에서 인증자 확장 입력으로 매핑됩니다. (있다면)

참고: 이 작업을 수행하기 전에, 인증자 세션에서 진행 중인 다른 모든 작업은 authenticatorCancel 작업을 실행하여 반드시 중단해야 합니다.

이 메서드가 호출되면, 인증자는 다음 절차를 반드시 수행해야 합니다:

모든 전달된 매개변수가 구문적으로 올바르며 길이가 맞는지 확인합니다. 아니라면, "UnknownError" 오류 코드를 반환하고 작업을 종료합니다.
credentialOptions를 새로운 빈 집합(set)으로 생성합니다. 이 집합은 공개키 자격증명 소스를 담습니다.
allowCredentialDescriptorList가 제공된 경우, 각 allowCredentialDescriptorList의 descriptor에 대해:
1. credSource를, 이 인증자에서 조회한 결과로 설정합니다. descriptor.id
2. credSource가 null이 아니면 추가합니다. credSource를 credentialOptions에 추가합니다.
그렇지 않으면 (allowCredentialDescriptorList가 제공되지 않은 경우), 각 이 인증자의 credentials map에서 key → credSource에 대해 추가합니다. credSource를 credentialOptions에 추가합니다.
제거합니다. rpId가 rpId와 같지 않은 credentialOptions의 항목들을 제거합니다.
credentialOptions가 비어 있으면, "NotAllowedError" 오류 코드를 반환하고 작업을 종료합니다.
사용자에게 공개키 자격증명 소스 중에서 selectedCredential을 선택하도록 프롬프트합니다. authorization gesture를 수집해, 사용자 동의를 확인합니다. authorization gesture를 인증자가 자체적으로 출력할 수 있으면 직접 보여주고, 아니면 사용자 에이전트가 보여줄 수 있습니다.

requireUserVerification이 true면, authorization gesture에 사용자 검증이 반드시 포함되어야 합니다.

requireUserPresence가 true면, authorization gesture에 사용자 존재 테스트가 반드시 포함되어야 합니다.

만약 사용자가 동의하지 않으면, "NotAllowedError" 오류 코드를 반환하고 작업을 종료합니다.
processedExtensions를, 인증자 확장 처리의 결과로 설정합니다. 각 지원되는 확장 식별자 → 인증자 확장 입력에 대해 extensions에서 처리합니다.
인증자에서 사용하는 방식에 따라, 자격증명별 서명 카운터 또는 글로벌 서명 카운터 값을 양의 값만큼 증가시킵니다. 인증자가 서명 카운터를 구현하지 않으면, 서명 카운터 값은 0으로 유지됩니다.
authenticatorData를 바이트 배열로 설정합니다. § 6.1 인증자 데이터에 명시된 대로, processedExtensions이 있다면 extensions에 포함시키고, attestedCredentialData는 제외합니다.
signature를 assertion signature로 설정합니다. authenticatorData || hash를 selectedCredential의 privateKey로 서명합니다. 아래 그림 참고. 단순한, 구분자 없는 연결 방식이 안전하게 사용되며, authenticator data는 자체 길이를 설명하고, 직렬화된 클라이언트 데이터의 해시는 항상 마지막 요소입니다.

assertion signature 생성.
assertion signature 생성 중 오류가 발생하면, "UnknownError" 오류 코드를 반환하고 작업을 종료합니다.
사용자 에이전트에 반환:
- selectedCredential.id (클라이언트가 2개 이상의 자격증명(allowCredentialDescriptorList)을 제공했거나, 아예 제공하지 않은 경우)
  
  참고: allowCredentialDescriptorList 내에 클라이언트가 정확히 하나의 자격증명을 제공하고 성공적으로 사용된 경우, credential ID는 반환되지 않습니다. 이는 클라이언트가 이미 알고 있으므로, 제한된 연결에서 전송할 바이트를 절약할 수 있습니다.
- authenticatorData
- signature
- selectedCredential.userHandle
  
  참고: 반환된 userHandle 값은 null일 수 있습니다. 자세한 내용은: userHandleResult 참고.

인증자가 지정된 Relying Party에 해당하는 자격증명을 찾지 못하면, 작업을 종료하고 오류를 반환합니다.

6.3.4. authenticatorCancel 작업

이 작업은 입력 매개변수를 받지 않으며 결과도 반환하지 않습니다.

클라이언트가 인증자 세션에서 이 작업을 호출하면, 해당 인증자 세션에서 현재 진행 중인 authenticatorMakeCredential 또는 authenticatorGetAssertion 작업을 종료시키는 효과가 있습니다. 인증자는 취소된 작업과 관련된 사용자 입력을 더 이상 요청하거나 받아들이지 않습니다. 클라이언트는 취소된 작업에 대해 인증자로부터 오는 추가 응답을 무시합니다.

이 작업이 인증자 세션에서 호출되었으나, 해당 세션에 authenticatorMakeCredential 또는 authenticatorGetAssertion 작업이 진행 중이지 않은 경우, 이 작업은 무시됩니다.

6.4. 문자열 처리

인증자는 Relying Party가 선택한 임의의 문자열을 저장해야 할 수도 있습니다. 예를 들어 name 및 displayName 등 PublicKeyCredentialUserEntity 객체 내에 저장될 수 있습니다. 본 절에서는 사람에게 제공될 수 있는 임의 문자열 처리에 관한 실질적인 결과를 논의합니다.

6.4.1. 문자열 절단

API에서의 각 임의 문자열은 인증자가 사용할 수 있는 자원이 제한될 수 있음을 감안해 처리됩니다. 만약 문자열 값의 절단(truncation)이 선택된 처리 방식이라면, 인증자는 지정된 최소 지원 길이 이상으로 문자열을 맞추기 위해 절단할 수 있습니다. 이러한 절단은 UTF-8 시퀀스 경계 또는 그래프 클러스터 경계를 존중해야 하며 [UTR29] 참조. 이는 허용되는 최대 절단 범위를 정의하며, 인증자는 그 이상으로 절단해서는 안 됩니다.

예를 들어, 그림 에서 문자열 길이는 65바이트입니다. 만약 64바이트로 절단해야 하면, 마지막 0x88 바이트는 공간 문제로 제거해야 합니다. 남은 값이 부분적인 UTF-8 시퀀스라면 그 시퀀스의 나머지도 제거할 수 있습니다. 만약 부분적인 그래프 클러스터가 남는다면, 인증자는 그 클러스터 전체의 나머지를 제거할 수 있습니다.

현행 표준 사용자 에이전트는, Relying Party가 관찰하는 인증자 동작이 본 명세를 준수하도록 문자열 처리에 책임을 집니다. 예를 들어 인증자가 긴 문자열을 저장할 때 올바르게 동작하지 않는 것으로 알려진 경우, 사용자 에이전트는 Relying Party 관점에서 모델을 유지하기 위해 대신 절단을 수행해야 합니다. 이때 사용자 에이전트는 그래프 클러스터 경계에서 절단하는 것이 바람직합니다.

UTF-8 시퀀스 경계만 기준으로 절단하면 그래프 클러스터가 잘려, 클러스터가 다른 글리프로 렌더링되어 문자열 의미가 바뀌거나 글리프 자체가 사라질 수 있습니다.

이와 더불어, 바이트 경계만 기준으로 절단하면 사용자 에이전트가 주의해야 할 문제가 있습니다: 인증자가 [FIDO-CTAP]를 사용하는 경우, 인증자에서 이후 메시지에 CBOR 타입이 CBOR 문자열로 선언되었으므로 반드시 유효한 UTF-8이어야 합니다. 사용자 에이전트는 문자 인코딩과 유니코드 특성을 인증자에 부담시키지 않도록 처리해야 하며, 인증자를 대상으로 할 때 사용자 에이전트는 다음을 권장합니다:

인증자에 전송되는 모든 문자열이 올바르게 인코딩되어 있는지 확인합니다.
문자열이 절단되어 인코딩이 잘못된 경우를 처리합니다. 예를 들어, 끝에 부분 코드 포인트가 있으면 이를 삭제하거나 U+FFFD로 대체합니다.

6.4.2. 언어 및 방향 정보 인코딩

문자열이 문맥에서 올바르게 표시되기 위해서는, 언어 및 기본 방향 정보가 필요할 수 있습니다. 본 API의 문자열은 고정 기능 인증자에 기록되고, 이후 다른 플랫폼에서 다시 읽어 표시될 수 있습니다. 따라서 언어 및 방향 메타데이터는 문자열 자체에 인코딩되어 원자적으로 전달될 수 있도록 해야 합니다.

문서상 허용되는 문자열에 언어 및 방향 메타데이터를 인코딩하려면, 문자열의 코드 포인트 뒤에 두 개의 코드 포인트 시퀀스를 덧붙입니다:

첫 번째 시퀀스는 언어 태그를 인코딩하며, U+E0001 코드 포인트 뒤에 언어 태그의 ASCII 값 각각에 U+E0000을 더한 값이 이어집니다. 예를 들어, 언어 태그 “en-US”는 U+E0001, U+E0065, U+E006E, U+E002D, U+E0055, U+E0053 코드 포인트로 변환됩니다.

두 번째 시퀀스는 단일 코드 포인트로, U+200E(“LEFT-TO-RIGHT MARK”), U+200F(“RIGHT-TO-LEFT MARK”), U+E007F(“CANCEL TAG”) 중 하나입니다. 처음 두 값은 방향성을 표시할 때 사용할 수 있으며, 올바른 결과를 내기 위해 필요할 때만 사용해야 합니다. (예: LTR 강한 문자로 시작하는 RTL 문자열 등) U+E007F는 방향성에 관계없이 언어 태그 끝을 나타냅니다.

따라서 문자열 “حبیب الرحمان”은 언어가 인코딩되었는지 여부에 따라 두 가지 DOMString 값을 가질 수 있습니다. (방향성이 명확하므로 방향 표시자는 필요 없음)

언어 태그 없는 문자열: U+FEA2, U+FE92, U+FBFF, U+FE91, U+20, U+FE8E, U+FEDF, U+FEAE, U+FEA4, U+FEE3, U+FE8E, U+FEE7
“ar-SA” 언어가 인코딩된 경우: U+FEA2, U+FE92, U+FBFF, U+FE91, U+20, U+FE8E, U+FEDF, U+FEAE, U+FEA4, U+FEE3, U+FE8E, U+FEE7, U+E0001, U+E0061, U+E0072, U+E002D, U+E0053, U+E0041, U+E007F

언어 및 방향 정보가 인코딩된 문자열을 소비하는 측에서는, 절단 시 언어 태그가 다른 유효한 언어로 잘릴 수 있음을 유의해야 합니다. 마지막 방향 표시자나 CANCEL TAG 코드 포인트가 절단 여부를 명확하게 나타냅니다.

6.5. 인증 증명

인증자는 가능하다면 인증 증명을 제공해야 합니다. 인증자가 이를 제공하는 경우, 기본 요구 사항은 인증자가 각 자격증명 공개키에 대해 인증 증명문을 생성할 수 있어야 하며, 이는 WebAuthn Relying Party에서 검증할 수 있어야 합니다. 일반적으로 인증 증명문에는 인증 증명 개인키로 서명된 자격증명 공개키와 챌린지, 그리고 인증 증명 공개키에 대한 출처 정보를 제공하는 인증서 또는 유사 데이터가 포함되어, Relying Party가 신뢰 결정을 내릴 수 있도록 합니다. 그러나 인증 증명 키 쌍이 없는 경우, 인증자는 해당 자격증명 공개키에 대해 자체 인증 증명을 자격증명 개인키로 수행하거나, 아예 인증 증명하지 않을 수 있습니다. 이러한 정보는 인증자가 새로운 공개키 자격증명을 생성할 때마다 반환되며, 전체적으로 인증 증명 객체 형태를 가집니다. 인증 증명 객체와 인증자 데이터(인증된 자격증명 데이터 포함), 인증 증명문과의 관계는 아래 그림에서 보여집니다.

인증자가 자체 인증 증명 또는 인증 증명 없음을 사용하는 경우, Relying Party가 신뢰 결정을 내릴 수 있는 출처 정보가 제공되지 않습니다. 이런 경우 인증자는 Relying Party에 자신의 동작에 대해 아무런 보증을 하지 않습니다.

인증 증명 객체 레이아웃으로, 인증자 데이터(인증된 자격증명 데이터 포함)와 인증 증명문을 포함합니다.

이 그림은 packed 인증 증명문 형식만을 예시합니다. 여러 추가적인 인증 증명문 형식은 § 8 정의된 인증 증명문 형식에서 정의되어 있습니다.

인증 증명 객체의 중요한 구성 요소는 인증 증명문입니다. 이는 특정 타입의 서명된 데이터 객체로, 공개키 자격증명 자체 및 이를 생성한 인증자에 관한 진술을 포함합니다. 인증 증명 서명이 포함되어 있으며, 이는 증명 기관의 키로 생성됩니다(단, 자체 인증 증명의 경우 자격증명 개인키로 생성됨). 인증 증명문을 올바르게 해석하기 위해, Relying Party는 인증 증명의 두 측면을 이해해야 합니다:

인증 증명문 형식은 서명이 어떻게 표현되는지와 여러 컨텍스트 바인딩이 인증자에 의해 증명문에 어떻게 통합되는지 정의합니다. 즉, 증명문의 구문을 의미합니다. 다양한 기존 컴포넌트 및 OS 플랫폼(예: TPM, Android OS)이 인증 증명문 형식을 정의한 바 있습니다. 본 명세는 § 6.5.2 인증 증명문 형식에서 다양한 형식을 확장 가능하게 지원합니다. 형식 식별자는 § 8.1 인증 증명문 형식 식별자에서 설명합니다.
인증 증명 타입은 인증 증명문의 의미와 그 기반 신뢰 모델을 정의합니다. 구체적으로, Relying Party가 특정 인증 증명문에 대해 신뢰를 어떻게 구축하는지(암호학적으로 유효함을 확인한 후)를 정의합니다. 본 명세는 § 6.5.3 인증 증명 타입에서 여러 인증 증명 타입을 지원합니다.

일반적으로 인증 증명문 형식과 인증 증명 타입 간에는 간단한 매핑이 없습니다. 예를 들어 packed 인증 증명문 형식은 § 8.2 packed 인증 증명문 형식에서 정의되며, 모든 인증 증명 타입과 함께 사용할 수 있습니다. 반면, 다른 형식과 타입은 적용 범위가 더 제한적입니다.

인증 증명의 개인정보 보호, 보안 및 운영 특성은 다음에 따라 달라집니다:

신뢰 모델을 결정하는 인증 증명 타입,
인증 증명문 형식으로, 인증 증명의 강도를 제한할 수 있으며, 인증 증명문에 표현할 수 있는 내용을 제한할 수 있습니다.
개별 인증자의 특성(구조, 안전한 실행 환경 여부 등)

대부분의 인증자는 소수의 인증 증명 타입과 인증 증명문 형식만 지원할 것으로 예상되며, Relying Party는 정책에 따라 허용할 인증 증명 타입을 결정합니다. 또한 Relying Party는 신뢰하는 인증자의 특성을 알고 있어야 하며, 예를 들어 FIDO Metadata Service [FIDOMetadataService]는 이러한 정보를 확인하는 한 방법입니다.

6.5.1. 인증된 자격증명 데이터

인증된 자격증명 데이터는 특정 자격증명에 대해 인증 증명 객체를 생성할 때 인증자 데이터에 추가되는 가변 길이 바이트 배열입니다. 그 형식은 아래 표에 나타나 있습니다.

Name	Length (in bytes)	Description
aaguid	16	인증자의 AAGUID.
credentialIdLength	2	자격증명 ID의 바이트 길이 L, 16비트 부호 없는 빅엔디언 정수.
credentialId	L	자격증명 ID
credentialPublicKey	variable	자격증명 공개키를 COSE_Key 형식으로 인코딩, RFC8152 Section 7 및 CTAP2 표준 CBOR 인코딩 형태 사용. COSE_Key로 인코딩된 자격증명 공개키에는 "alg" 파라미터가 반드시 포함되어야 하며, 다른 OPTIONAL 파라미터는 포함되면 안 됨. "alg" 파라미터에는 `COSEAlgorithmIdentifier` 값이 들어가야 함. 또한 인코딩된 자격증명 공개키에는 해당 키 타입 규격에서 요구하는 추가 필수(REQUIRED) 파라미터가 반드시 들어가야 하며, (즉 "kty"와 "alg"에 대해 REQUIRED, RFC8152 Section 8 참조)

인증된 자격증명 데이터 레이아웃. Name 열의 명칭은 본 문서 내 참조용으로만 사용되며, 실제 인증된 자격증명 데이터 표현에는 존재하지 않습니다.

6.5.1.1. COSE_Key 형식으로 인코딩된 `credentialPublicKey` 값 예시

본 절에서는 ES256, PS256, RS256 서명 알고리즘을 위한 COSE_Key로 인코딩된 타원 곡선(Elliptic Curve) 및 RSA 공개키 예시를 제공합니다. 이 예시는 위에서 정한 credentialPublicKey 규칙을 따르며, 명확성을 위해 CDDL [RFC8610]로 제시합니다.

[RFC8152] Section 7은 모든 COSE_Key 인코딩 키에 대한 일반 프레임워크를 정의합니다. 특정 알고리즘의 키 타입은 [RFC8152] 내 다른 절이나 기타 규격에서 정의되어 있습니다.

아래는 P-256 곡선에서 ES256 서명 알고리즘(ECDSA w/ SHA-256, [RFC8152] Section 8.1 참조)에 사용할 EC2 형식 COSE_Key로 인코딩된 타원 곡선 공개키 예시입니다([RFC8152] Section 13.1 참조).

{
  1:   2,  ; kty: EC2 key type
  3:  -7,  ; alg: ES256 signature algorithm
 -1:   1,  ; crv: P-256 curve
 -2:   x,  ; x-coordinate as byte string 32 bytes in length
           ; e.g., in hex: 65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d
 -3:   y   ; y-coordinate as byte string 32 bytes in length
           ; e.g., in hex: 1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
}

아래는 위의 타원 곡선 공개키를 CTAP2 표준 CBOR 인코딩 형태로 표현한 예시입니다. 공백 및 줄 바꿈은 명확성을 위해 포함되어 있으며 위 CDDL [RFC8610] 제시와 일치시켰습니다:

A5
   01  02

   03  26

   20  01

   21  58 20   65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d

   22  58 20   1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c

아래는 PS256 서명 알고리즘(RSASSA-PSS with SHA-256, [RFC8230] Section 4 참조)에 사용할 2048비트 RSA 공개키 COSE_Key 인코딩 예시입니다. ([RFC8230] Section 2 참조)

{
  1:   3,  ; kty: RSA key type
  3: -37,  ; alg: PS256
 -1:   n,  ; n:   RSA modulus n byte string 256 bytes in length
           ;      e.g., in hex (middle bytes elided for brevity): DB5F651550...6DC6548ACC3
 -2:   e   ; e:   RSA public exponent e byte string 3 bytes in length
           ;      e.g., in hex: 010001
}

아래는 위 RSA 공개키를 RS256 서명 알고리즘(RSASSA-PKCS1-v1_5 with SHA-256)에 사용할 때의 COSE_Key 인코딩 예시입니다:

{
  1:   3,  ; kty: RSA key type
  3:-257,  ; alg: RS256
 -1:   n,  ; n:   RSA modulus n byte string 256 bytes in length
           ;      e.g., in hex (middle bytes elided for brevity): DB5F651550...6DC6548ACC3
 -2:   e   ; e:   RSA public exponent e byte string 3 bytes in length
           ;      e.g., in hex: 010001
}

6.5.2. 인증 증명문 형식

위에서 설명한 대로, 인증 증명문 형식은 인증자가 컨텍스트 바인딩 집합에 대해 암호학적 서명을 표현하는 데이터 형식입니다. 각 인증 증명문 형식은 반드시 다음 템플릿을 사용해 정의되어야 합니다:

인증 증명문 형식 식별자:
지원되는 인증 증명 타입:
구문: 이 형식으로 생성된 인증 증명문의 구문을, [RFC8610]의 CDDL로 정의합니다. 이는 § 6.5.4 인증 증명 객체 생성에서 정의된 확장 포인트 $attStmtFormat에 해당합니다.
서명 절차: 주어진 공개키 자격증명, 인증자 데이터 구조(인증 증명용 인증자 데이터 포함), 그리고 직렬화된 클라이언트 데이터의 해시를 기반으로 이 형식의 인증 증명문을 계산하는 서명 절차입니다.
검증 절차: 인증 증명문을 검증하는 절차로, 다음 검증 절차 입력값을 받습니다:
- attStmt: 인증 증명문 구조
- authenticatorData: 인증 증명에 사용되었다고 주장하는 인증자 데이터
- clientDataHash: 직렬화된 클라이언트 데이터의 해시
이 절차는 다음 중 하나를 반환합니다:
- 인증 증명이 유효하지 않음을 나타내는 오류, 또는
- 구현별 값으로, 인증 증명 타입 및 신뢰 경로를 나타냅니다. 이 인증 증명 신뢰 경로는 자체 인증 증명의 경우 비어 있고, 아니면 X.509 인증서 집합입니다.

지정된 인증 증명문 형식의 초기 목록은 § 8 정의된 인증 증명문 형식에 있습니다.

6.5.3. 인증 증명 타입

WebAuthn은 여러 인증 증명 타입을 지원하며, 인증 증명문의 의미와 그 기반 신뢰 모델을 정의합니다:

참고: 본 명세는 인증자가 사용하는 인증 증명 타입을 명시적으로 표현하는 데이터 구조를 정의하지 않습니다. Relying Party가 인증 증명문 검증을 수행할 때(즉, navigator.credentials.create() 호출 시) 인증 증명 전달 옵션으로 none 외의 값을 선택하고, 받은 인증 증명문을 검증하면, 검증 과정에서 사용된 인증 증명 타입을 결정하게 됩니다. § 8 정의된 인증 증명문 형식의 "검증 절차" 절을 참고하세요. 또한 § 14.4.1 인증 증명 개인정보 보호도 참고. 본 절에서 정의된 모든 인증 증명 타입 중 자체(Self)와 없음(None)을 제외한 경우, Relying Party는 검증 후 신뢰 경로를 허용 가능한 루트 인증서와 매칭해야 합니다(§ 7.1 신규 자격증명 등록 21단계 참고). 이 인증 증명 타입 구분은 Relying Party 정책에 따라 인증 증명의 허용 여부를 결정하는 데 주로 유용합니다.

기본 인증 증명 (Basic)

기본 인증 증명 [UAFProtocol]의 경우, 인증자의 인증 증명 키 쌍은 인증자 "모델", 즉 "배치(batch)" 단위로 고유합니다. 따라서 동일하거나 유사한 모델의 인증자는 같은 인증 증명 키 쌍을 공유하는 경우가 많습니다. 자세한 정보는 § 14.4.1 인증 증명 개인정보 보호 참고.

기본 인증 증명은 배치 인증 증명(batch attestation)이라고도 불립니다.

자체 인증 증명 (Self)

자체 인증 증명(surrogate 기본 인증 증명 [UAFProtocol]이라고도 함)에서는 인증자가 특정 인증 증명 키 쌍을 갖고 있지 않습니다. 대신 자격증명 개인키로 인증 증명 서명을 생성합니다. 인증 증명 개인키에 의미 있는 보호수단이 없는 인증자는 대개 이 타입을 사용합니다.

인증 증명 CA (AttCA)

이 경우, 인증자는 Trusted Platform Module(TPM)을 기반으로 하며, 인증자 고유의 "인증키(endorsement key, EK)"를 보유합니다. 이 키는 신뢰할 수 있는 제3자인 인증 증명 CA(Attestation CA) [TCG-CMCProfile-AIKCertEnroll](이전 이름: Privacy CA)와 안전하게 통신하는 데 사용됩니다. 인증자는 여러 인증 신원 키 쌍(AIK)을 생성할 수 있으며, 각각에 대해 인증 증명 CA에 AIK 인증서 발급을 요청합니다. 이 방법을 통해 인증자는 EK(글로벌 상관 핸들)의 노출을 Attestation CA에 제한할 수 있습니다. 각 인증자가 생성한 공개키 자격증명마다 AIK를 요청 및 Relying Party에 인증 증명서로 전달할 수 있습니다.

참고: 이 개념은 일반적으로 여러 인증 증명서를 초래합니다. 가장 최근에 요청된 인증 증명서를 "활성(active)"이라고 합니다.

익명화 CA (AnonCA)

이 경우, 인증자는 익명화 CA(Anonymization CA)를 사용해 자격증명별 인증 증명서를 동적으로 생성합니다. 이렇게 생성된 인증 증명문은 Relying Party에 고유 식별 정보(예: 추적에 쓰일 수 있는 정보)를 제공하지 않습니다.

참고: 익명화 CA(AnonCA) 또는 AttCA 타입의 인증 증명문은 Basic 타입과 동일한 데이터 구조를 사용하므로, 외부적으로 전달된 인증 증명서의 내용에 대한 지식이 있어야만 세 가지 타입을 구분할 수 있습니다.

인증 증명문 없음 (None)

이 경우, 인증 증명 정보가 제공되지 않습니다. § 8.7 인증 증명문 없음 형식도 참고하세요.

6.5.4. 인증 증명 객체 생성

인증 증명 객체(Figure 6 참고)를 생성하기 위해 다음이 주어졌을 때:

attestationFormat: 인증 증명문 형식
authData: 인증자 데이터가 들어있는 바이트 배열
hash: 직렬화된 클라이언트 데이터의 해시

인증자는 반드시 다음을 수행해야 합니다:

attStmt를 authData와 hash를 입력값으로 attestationFormat의 서명 절차를 실행한 결과로 설정합니다.
fmt를 attestationFormat의 인증 증명문 형식 식별자로 설정합니다.

다음 구문으로 CBOR 맵 형태의 인증 증명 객체를 반환합니다. 변수들은 이 알고리즘에서 초기화된 값으로 채워집니다:

    attObj = {
                authData: bytes,
                $$attStmtType
             }

    attStmtTemplate = (
                          fmt: text,
                          attStmt: { * tstr => any } ; Map은 각 구체적 attStmtType별로 채워짐
                      )

    ; 모든 인증 증명문 형식은 위 필드를 포함해야 함
    attStmtTemplate .within $$attStmtType

6.5.5. Packed 인증 증명, FIDO U2F 인증 증명, Assertion 서명용 서명 형식

COSEAlgorithmIdentifier -7(ES256) 및 기타 ECDSA 기반 알고리즘의 경우, sig 값은 반드시 ASN.1 DER Ecdsa-Sig-Value로 인코딩되어야 하며, 이는 [RFC3279] 2.2.3절에서 정의됩니다.

        예시:
        30 44                                ; SEQUENCE (68 Bytes)
            02 20                            ; INTEGER (32 Bytes)
            |  3d 46 28 7b 8c 6e 8c 8c  26 1c 1b 88 f2 73 b0 9a
            |  32 a6 cf 28 09 fd 6e 30  d5 a7 9f 26 37 00 8f 54
            02 20                            ; INTEGER (32 Bytes)
            |  4e 72 23 6e a3 90 a9 a1  7b cf 5f 7a 09 d6 3a b2
            |  17 6c 92 bb 8e 36 c0 41  98 a2 7b 90 9b 6e 8f 13

참고: CTAP1/U2F 인증자는 이미 이 형식으로 서명값을 생성하므로, CTAP2 인증자도 일관성 유지를 위해 같은 형식으로 서명값을 생성합니다.

새로 정의되는 인증 증명 형식에서는 ASN.1 인코딩을 사용하지 않고, 내부 구조 없이 동일한 길이의 바이트 배열로 서명을 표현하는 것이 권장됩니다. COSE 서명에서 사용되는 표현과 동일하게 [RFC8152] 및 [RFC8230]에 정의된 방식 사용.

아래 서명 형식 정의는 이러한 요구사항을 충족하며, 여기서 명시적으로 언급하지 않은 다른 서명 알고리즘의 예시로도 활용할 수 있습니다:

COSEAlgorithmIdentifier -257(RS256)의 경우, sig에는 [RFC8017] 8.2.1절에 정의된 RSASSA-PKCS1-v1_5 서명 방식으로 생성된 서명이 포함되어야 하며, 해시 함수는 SHA-256입니다. 서명은 ASN.1 래핑되지 않습니다.
COSEAlgorithmIdentifier -37(PS256)의 경우, sig에는 [RFC8017] 8.1.1절에 정의된 RSASSA-PSS 서명 방식으로 생성된 서명이 포함되어야 하며, 해시 함수는 SHA-256입니다. 서명은 ASN.1 래핑되지 않습니다.

7. WebAuthn Relying Party 작업

등록 또는 인증 절차는 WebAuthn Relying Party가 PublicKeyCredentialCreationOptions 또는 PublicKeyCredentialRequestOptions 객체를 각각 생성하는 것으로 시작되며, 이 객체는 절차의 매개변수를 인코딩합니다. Relying Party는 이 단계에서 민감한 정보가 유출되지 않도록 주의해야 하며, 자세한 내용은 § 14.6.2 사용자명 열거를 참고하세요.

create() 또는 get() 실행이 성공적으로 완료되면, Relying Party의 스크립트는 클라이언트로부터 PublicKeyCredential 객체를 받으며, 이 객체에는 각각 AuthenticatorAttestationResponse 또는 AuthenticatorAssertionResponse 구조가 포함됩니다. 이후 이 구조의 내용을 Relying Party 서버로 전달해야 하며, 이 전달 방식은 본 명세의 범위에 포함되지 않습니다. 본 절에서는 Relying Party가 이러한 구조를 수신한 후 수행해야 할 작업을 설명합니다.

7.1. 신규 자격증명 등록

등록 절차를 수행하기 위해 Relying Party는 다음과 같이 진행해야 합니다:

options를 Relying Party의 절차 요구에 맞게 설정된 새로운 PublicKeyCredentialCreationOptions 구조체로 둔다.
navigator.credentials.create() 를 호출하고 options를 publicKey 옵션으로 전달합니다. 성공적으로 Promise가 resolve되면 credential로 결과를 설정합니다. Promise가 reject되면, 사용자에게 보이는 오류로 절차를 중단하거나, reject된 Promise의 context에 따라 사용자 경험을 안내해야 합니다. 예를 들어 Promise가 "InvalidStateError"와 같은 오류 코드로 reject되면, 사용자는 다른 인증자를 사용하라고 안내할 수 있습니다. 다양한 오류 context와 그 발생 상황에 대한 정보는 § 6.3.2 authenticatorMakeCredential 작업 참고.
response를 credential.response 로 설정합니다. response가 AuthenticatorAttestationResponse의 인스턴스가 아니면, 사용자에게 보이는 오류로 절차를 중단합니다.
clientExtensionResults를 credential.getClientExtensionResults() 호출 결과로 설정합니다.
JSONtext를 response.clientDataJSON 값에 UTF-8 디코드를 적용한 결과로 설정합니다.

참고: 어떤 UTF-8 디코드 구현을 사용해도 UTF-8 디코드 알고리즘과 동일한 결과를 얻는다면 사용 가능합니다. 특히, 선행 바이트 오더 마크(BOM)는 반드시 제거해야 합니다.
C를, 자격증명 생성 시 수집된 것으로 주장된 클라이언트 데이터로서, JSONtext에 구현별 JSON 파서를 적용한 결과로 설정합니다.

참고: C는 구현별 임의 데이터 구조 표현일 수 있으며, C의 구성 요소가 본 알고리즘에서 참조 가능하면 됩니다.
C.type 값이 webauthn.create인지 확인합니다.
C.challenge 값이 options.challenge 를 base64url 인코딩한 값과 같은지 확인합니다.
C.origin 값이 Relying Party의 origin과 일치하는지 확인합니다.
C.tokenBinding.status 값이 Token Binding의 TLS 연결 상태와 일치하는지 확인합니다. 만약 해당 TLS 연결에 Token Binding이 사용됐다면, C.tokenBinding.id 값이 해당 연결의 base64url 인코딩 Token Binding ID와 일치하는지도 확인합니다.
hash를 response.clientDataJSON 값에 SHA-256 해시를 적용한 결과로 설정합니다.
attestationObject 필드에 CBOR 디코딩을 수행하여 AuthenticatorAttestationResponse 구조에서 인증 증명문 형식 fmt, 인증자 데이터 authData, 인증 증명문 attStmt를 얻습니다.
rpIdHash 가 authData 내에서 Relying Party가 기대하는 RP ID의 SHA-256 해시인지 확인합니다.
flags 의 User Present 비트가 authData에서 set되어 있는지 확인합니다.
등록에 사용자 검증이 필요하다면, flags의 User Verified 비트가 authData에서 set되어 있는지 확인합니다.
authData 내 credential public key의 "alg" 파라미터가 alg 속성이 options.pubKeyCredParams 에 포함된 항목 중 하나와 일치하는지 확인합니다.
clientExtensionResults에 있는 클라이언트 확장 출력과 authData 내 extensions에 있는 인증자 확장 출력 값이 기대한 대로인지 확인합니다. 여기서 기대값은 options.extensions에 제공된 클라이언트 확장 입력 값과, Relying Party의 미지정 확장 정책에 따라 달라집니다. 일반적으로 "기대한 대로"의 의미는 Relying Party와 사용 중인 확장에 따라 다릅니다.

참고: 클라이언트 플랫폼은 추가 인증자 확장 또는 클라이언트 확장을 설정하는 로컬 정책을 적용할 수 있으며, 이로 인해 인증자 확장 출력이나 클라이언트 확장 출력에 원래 지정하지 않은 값이 나타날 수 있습니다. Relying Party는 이러한 상황(예: 미지정 확장 무시 또는 인증 증명 거부)을 처리할 수 있어야 하며, 결정은 로컬 정책과 사용 중인 확장에 따라 내릴 수 있습니다.

참고: 모든 확장은 클라이언트와 인증자 모두에 대해 OPTIONAL이므로, Relying Party는 요청한 확장이 아예 적용되지 않거나 일부만 적용된 경우도 처리할 수 있어야 합니다.
인증 증명문 형식을 결정하기 위해 fmt 값을 지원되는 WebAuthn 인증 증명문 형식 식별자 집합과 USASCII 대소문자 구분 일치(match)를 수행합니다. 등록된 WebAuthn 인증 증명문 형식 식별자 값의 최신 목록은 [IANA-WebAuthn-Registries]에서 확인할 수 있으며, 이는 [RFC8809]에 의해 설정되었습니다.
attStmt가 올바른 인증 증명문이고, 유효한 인증 증명 서명을 전달하는지, fmt의 인증 증명문 형식의 검증 절차에 attStmt, authData, hash를 입력해 확인합니다.

참고: 각 인증 증명문 형식은 고유의 검증 절차를 지정합니다. 초기 정의된 형식은 § 8 정의된 인증 증명문 형식을, 최신 목록은 [IANA-WebAuthn-Registries]를 참고하세요.
검증이 성공하면, 해당 인증 증명 타입 및 인증 증명문 형식 fmt에 대해 허용 가능한 신뢰 앵커(즉, 인증 증명 루트 인증서)의 목록을 신뢰할 수 있는 소스 또는 정책에서 획득합니다. 예를 들어 FIDO Metadata Service [FIDOMetadataService]는 aaguid 정보(attestedCredentialData 내 포함)를 이용해 이런 정보를 획득하는 방법을 제공합니다.
19단계의 검증 절차 결과를 이용해 인증 증명의 신뢰성을 평가합니다:
- 인증 증명 없음이 제공되었다면, None 인증 증명이 Relying Party 정책에 허용되는지 확인합니다.
- 자체 인증 증명이 사용되었다면, 자체 인증 증명이 Relying Party 정책에 허용되는지 확인합니다.
- 그 외의 경우, 검증 절차의 결과로 반환된 X.509 인증서(인증 증명 신뢰 경로)를 이용해 인증 증명 공개키가 허용 가능한 루트 인증서까지 올바르게 체인되는지, 또는 그 자체가 허용 가능한 인증서인지(즉, 20단계에서 얻은 루트 인증서와 동일할 수 있음) 확인합니다.
credentialId 가 아직 다른 사용자에게 등록되지 않았는지 확인합니다. 이미 등록된 자격증명으로 등록을 요청한 경우, Relying Party는 해당 등록 절차를 실패 처리하거나, 기존 등록을 삭제하는 등 등록을 허용할 수도 있습니다.
인증 증명문 attStmt가 성공적으로 검증되고 신뢰할 수 있다면, options.user에 명시된 계정으로 신규 자격증명을 등록합니다:
- 사용자 계정을 credentialId와 credentialPublicKey (authData.attestedCredentialData 내 포함)와 연관시킵니다. 이는 Relying Party 시스템에 맞게 처리합니다.
- credentialId 를 새로운 저장된 서명 카운터 값과 연관시키고, 해당 값은 authData.signCount로 초기화합니다.
다음도 권장됩니다:
- credentialId 를 credential.response.getTransports() 호출로 반환된 transport 힌트와 연관시킵니다. 이 값은 저장 전후로 수정하지 않아야 하며, 이후 transports에 활용하거나, 향후 allowCredentials 옵션의 값으로 get() 호출 시 사용하여 클라이언트가 적합한 인증자를 찾는 데 도움을 줄 수 있습니다.
인증 증명문 attStmt가 성공적으로 검증됐지만 21단계에서 신뢰할 수 없는 것으로 판명된 경우, Relying Party는 등록 절차를 실패 처리해야 합니다.

참고: 단, 정책상 허용된다면 Relying Party는 credential ID와 공개키 자격증명을 등록하되, 해당 자격증명을 자체 인증 증명으로 처리할 수 있습니다(§ 6.5.3 인증 증명 타입 참고). 이 경우 Relying Party는 공개키 자격증명이 특정 인증자 모델에서 생성됐다는 암호학적 증거가 없다는 점을 명시적으로 인정하는 것입니다. 자세한 논의는 [FIDOSecRef] 및 [UAFProtocol] 참고.

인증 증명 객체 검증을 위해서는, 위 20단계에서 Relying Party가 허용 가능한 신뢰 앵커를 결정할 수 있는 신뢰할 수 있는 방법을 가져야 합니다. 또한 인증서가 사용되는 경우, Relying Party는 중간 CA 인증서의 상태 정보에 접근할 수 있어야 하며, Relying Party는 클라이언트가 인증 정보에 인증서 체인을 제공하지 않은 경우, 인증 증명서 체인도 직접 구축할 수 있어야 합니다.

7.2. 인증 어서션 검증

인증 절차를 수행하기 위해, Relying Party는 다음과 같이 진행해야 합니다:

options를 PublicKeyCredentialRequestOptions 구조로 새로 생성하고, Relying Party의 절차 요구에 맞게 설정합니다.

options.allowCredentials 값이 있으면, 각 항목의 transports 멤버는 해당 자격증명이 등록될 때 credential.response.getTransports() 호출로 반환된 값으로 설정해야 합니다.
navigator.credentials.get() 호출 시 options를 publicKey 옵션으로 전달합니다. 성공적으로 Promise가 resolve되면 credential에 결과를 저장합니다. Promise가 reject되면, 사용자에게 보이는 오류로 절차를 중단하거나, reject된 Promise의 context에 따라 사용자 경험을 안내해야 합니다. 다양한 오류 context 및 발생 상황에 대한 정보는 § 6.3.3 authenticatorGetAssertion 작업 참고.
response를 credential.response 로 설정합니다. response가 AuthenticatorAssertionResponse의 인스턴스가 아니면, 사용자에게 보이는 오류로 절차를 중단합니다.
clientExtensionResults를 credential.getClientExtensionResults() 호출 결과로 설정합니다.
options.allowCredentials 가 비어있지 않으면, credential.id 값이 options.allowCredentials에 포함된 공개키 자격증명 중 하나임을 확인합니다.
인증 중인 사용자를 식별하고, 해당 사용자가 공개키 자격증명 소스 credentialSource의 소유자임을 확인합니다. credential.id로 credentialSource를 식별합니다:

사용자가 인증 절차 시작 전에(예: 사용자명, 쿠키 등) 식별된 경우,

식별된 사용자가 credentialSource의 소유자인지 확인합니다. response.userHandle 값이 있으면, userHandle로 저장하고, 이 값이 동일 사용자임도 확인합니다.

사용자가 인증 절차 시작 전에 식별되지 않은 경우,

response.userHandle 값이 반드시 존재하며, 이 값으로 식별되는 사용자가 credentialSource의 소유자인지도 확인합니다.
credential.id (혹은 credential.rawId - base64url 인코딩이 적합하지 않은 경우)로 해당 자격증명 공개키를 조회하고, credentialPublicKey에 저장합니다.
cData, authData, sig를 각각 response의 clientDataJSON, authenticatorData, signature 값으로 설정합니다.
JSONtext를 cData 값에 UTF-8 디코드를 적용한 결과로 설정합니다.

참고: 어떤 UTF-8 디코드 구현을 사용해도 UTF-8 디코드 알고리즘과 동일한 결과를 얻으면 사용 가능합니다. 특히, 선행 바이트 오더 마크(BOM)는 반드시 제거해야 합니다.
C를, 서명에 사용된 것으로 주장된 클라이언트 데이터로서, JSONtext에 구현별 JSON 파서를 적용한 결과로 설정합니다.

참고: C는 구현별 임의 데이터 구조 표현일 수 있으며, C의 구성 요소가 본 알고리즘에서 참조 가능하면 됩니다.
C.type 값이 webauthn.get 문자열인지 확인합니다.
C.challenge 값이 options.challenge 를 base64url 인코딩한 값과 같은지 확인합니다.
C.origin 값이 Relying Party의 origin과 일치하는지 확인합니다.
C.tokenBinding.status 값이 attestation이 얻어진 TLS 연결의 Token Binding 상태와 일치하는지 확인합니다. 해당 TLS 연결에 Token Binding이 사용됐다면, C.tokenBinding.id 값이 해당 연결의 base64url 인코딩 Token Binding ID와 일치하는지도 확인합니다.
rpIdHash가 authData에 포함되어 있으며, Relying Party가 기대하는 RP ID의 SHA-256 해시인지 확인합니다.
참고: appid 확장을 사용하는 경우, 이 단계에 특별한 로직이 필요합니다. 자세한 내용은 § 10.1 FIDO AppID 확장(appid) 참고.
flags 의 User Present 비트가 authData에서 set되어 있는지 확인합니다.
이 어서션에 사용자 검증이 필요하다면, flags의 User Verified 비트가 authData에서 set되어 있는지 확인합니다.
clientExtensionResults에 있는 클라이언트 확장 출력과 authData 내 extensions에 있는 인증자 확장 출력 값이 기대한 대로인지 확인합니다. 여기서 기대값은 options.extensions에 제공된 클라이언트 확장 입력 값과, Relying Party의 미지정 확장 정책에 따라 달라집니다. 일반적으로 "기대한 대로"의 의미는 Relying Party와 사용 중인 확장에 따라 다릅니다.

참고: 클라이언트 플랫폼은 추가 인증자 확장 또는 클라이언트 확장을 설정하는 로컬 정책을 적용할 수 있으며, 이로 인해 인증자 확장 출력이나 클라이언트 확장 출력에 원래 지정하지 않은 값이 나타날 수 있습니다. Relying Party는 이러한 상황(예: 미지정 확장 무시 또는 어서션 거부)을 처리할 수 있어야 하며, 결정은 로컬 정책과 사용 중인 확장에 따라 내릴 수 있습니다.

참고: 모든 확장은 클라이언트와 인증자 모두에 대해 OPTIONAL이므로, Relying Party는 요청한 확장이 아예 적용되지 않거나 일부만 적용된 경우도 처리할 수 있어야 합니다.
hash를 cData에 SHA-256 해시를 적용한 결과로 설정합니다.
credentialPublicKey를 사용해 sig가 authData와 hash의 바이너리 연결에 대해 올바른 서명인지 검증합니다.

참고: 이 검증 단계는 FIDO U2F 인증자가 생성한 서명과도 호환됩니다. 자세한 내용은 § 6.1.2 FIDO U2F 서명 형식 호환성 참고.
storedSignCount를 credential.id에 연관된 저장된 서명 카운터 값으로 설정합니다. authData.signCount가 0이 아니거나 storedSignCount가 0이 아니면, 다음 하위 단계를 수행합니다:
- authData.signCount 값이
  
  저장된 storedSignCount보다 큰 경우:
  storedSignCount 값을 authData.signCount 값으로 갱신합니다.
  저장된 storedSignCount보다 작거나 같은 경우:
  이는 인증자가 복제(clone)되었을 가능성을 신호합니다. 즉, 자격증명 개인키가 두 개 이상 존재하며 병렬로 사용 중일 수 있습니다. Relying Party는 이를 위험 점수에 반영해야 합니다. Relying Party가 이 경우 storedSignCount 값을 갱신할지, 인증 절차를 실패 처리할지는 Relying Party별로 결정합니다.
위 모든 단계가 성공하면, 인증 절차를 계속 진행합니다. 그렇지 않으면 인증 절차를 실패 처리합니다.

8. 정의된 인증 증명문 형식

WebAuthn은 플러그형 인증 증명문 형식을 지원합니다. 본 절에서는 이러한 형식의 초기 집합을 정의합니다.

8.1. 인증 증명문 형식 식별자

인증 증명문 형식은 인증 증명문 형식 식별자라 불리는 문자열로 식별되며, 인증 증명문 형식의 작성자가 지정합니다.

인증 증명문 형식 식별자는 IANA "WebAuthn Attestation Statement Format Identifiers" 레지스트리 [IANA-WebAuthn-Registries]에 등록되어야 하며, 이는 [RFC8809]에서 제정되었습니다. 등록된 모든 인증 증명문 형식 식별자는 고유합니다.

등록되지 않은 인증 증명문 형식 식별자는 고유성을 위해 개발자가 등록한 도메인명의 소문자 역순 도메인-이름 네이밍을 사용해야 합니다. 모든 인증 증명문 형식 식별자는 최대 32 옥텟 길이여야 하며, USASCII 인쇄 문자만을 포함해야 하며 백슬래시 및 쌍따옴표는 포함하지 않아야 합니다. 즉, [RFC5234]의 VCHAR에서 %x22, %x5c만 제외한 집합입니다.

참고: 도메인 기반 인증 증명문 형식 식별자는 LDH 라벨만을 포함해야 합니다 [RFC5890].

구현체는 WebAuthn 인증 증명문 형식 식별자 매칭 시 대소문자 구분(case-sensitive)으로 해야 합니다.

여러 버전이 존재할 수 있는 인증 증명문 형식은 식별자에 버전을 포함해야 하며, 즉 다른 버전은 다른 형식으로 취급됩니다(예: packed2는 § 8.2 Packed Attestation Statement Format의 새 버전).

아래 절에서는 현재 정의 및 등록된 인증 증명문 형식과 그 식별자를 제시합니다. 최신 WebAuthn 확장 목록은 IANA "WebAuthn Attestation Statement Format Identifiers" 레지스트리 [IANA-WebAuthn-Registries]에서 관리됩니다.

8.2. Packed 인증 증명문 형식

이 형식은 WebAuthn 최적화 인증 증명문 형식입니다. 매우 컴팩트하면서도 확장 가능한 인코딩 방식을 사용합니다. 자원 제한이 있는 인증자(예: 시큐어 엘리먼트)에서 구현 가능합니다.

인증 증명문 형식 식별자

packed

지원되는 인증 증명 타입

Basic, Self, AttCA

구문

Packed 인증 증명문 형식의 구문은 아래 CDDL로 정의됩니다:

    $$attStmtType //= (
                          fmt: "packed",
                          attStmt: packedStmtFormat
                      )

    packedStmtFormat = {
                           alg: COSEAlgorithmIdentifier,
                           sig: bytes,
                           x5c: [ attestnCert: bytes, * (caCert: bytes) ]
                       } //
                       {
                           alg: COSEAlgorithmIdentifier
                           sig: bytes,
                       }

각 필드의 의미는 다음과 같습니다:

alg: COSEAlgorithmIdentifier로, 인증 증명 서명에 사용된 알고리즘 식별자를 담습니다.
sig: 바이트 문자열로 인증 증명 서명이 담겨 있습니다.
x5c: 이 배열의 각 요소는 attestnCert와(있다면) 연결된 인증서 체인을 X.509 형식으로 인코딩합니다. 인증 증명서 attestnCert는 반드시 배열의 첫 번째 요소여야 합니다.
attestnCert: X.509 형식으로 인코딩된 인증 증명서입니다.

서명 절차

본 인증 증명문 형식의 서명 절차는 어서션 서명 생성 절차와 유사합니다.

authenticatorData를 인증 증명용 인증자 데이터로, clientDataHash를 직렬화된 클라이언트 데이터의 해시로 둡니다.
Basic 또는 AttCA 인증 증명이 사용된다면, 인증자는 authenticatorData와 clientDataHash를 연결(concatenate)한 후, 인증자-특정 메커니즘으로 선택된 인증 증명 개인키로 서명하여 sig를 생성합니다. x5c에는 attestnCert와 연결된 인증서 체인을(있다면) 넣고, alg에는 인증 증명 개인키의 알고리즘을 설정합니다.
자체 인증 증명이 사용된다면, 인증자는 authenticatorData와 clientDataHash를 연결(concatenate)한 후 자격증명 개인키로 서명하여 sig를 생성합니다. alg에는 자격증명 개인키의 알고리즘을 설정하고, 나머지 필드는 생략합니다.

검증 절차

검증 절차 입력값 attStmt, authenticatorData, clientDataHash가 주어지면, 검증 절차는 다음과 같습니다:

attStmt가 위 정의된 구문에 맞는 유효한 CBOR인지 확인하고, CBOR 디코딩으로 필드를 추출합니다.
x5c가 있으면:
- sig가 authenticatorData와 clientDataHash의 연결에 대해 alg에 지정된 알고리즘으로 attestnCert의 인증 증명 공개키로 올바르게 서명됐는지 검증합니다.
- attestnCert가 § 8.2.1 Packed 인증 증명문 인증서 요구사항을 만족하는지 확인합니다.
- attestnCert에 OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) 확장이 있으면, 해당 확장 값이 authenticatorData의 aaguid와 일치하는지 확인합니다.
- 선택적으로 x5c를 검사하고 외부 지식과 대조하여 attStmt가 Basic 또는 AttCA 인증 증명을 전달하는지 판단합니다.
- 검증 성공 시, 인증 증명 타입 Basic, AttCA 또는 불확실성, 그리고 인증 증명 신뢰 경로 x5c를 구현별 값으로 반환합니다.
x5c가 없으면 자체 인증 증명이 사용된 경우입니다.
- alg가 authenticatorData 내 credentialPublicKey의 알고리즘과 일치하는지 확인합니다.
- sig가 authenticatorData와 clientDataHash의 연결에 대해 alg로 자격증명 공개키로 올바르게 서명됐는지 확인합니다.
- 검증 성공 시, 인증 증명 타입 Self와 빈 인증 증명 신뢰 경로를 구현별 값으로 반환합니다.

8.2.1. Packed 인증 증명문 인증서 요구사항

인증 증명서는 다음 필드/확장을 반드시 포함해야 합니다:

Version 값은 반드시 3이어야 하며(ASN.1 INTEGER 값 2로 표시됨).
Subject 필드는 반드시 다음과 같아야 합니다:

Subject-C

인증자 벤더가 설립된 국가의 ISO 3166 코드(PrintableString)

Subject-O

인증자 벤더의 법적 명칭(UTF8String)

Subject-OU

문자열 “Authenticator Attestation”(UTF8String)

Subject-CN

벤더가 선택한 UTF8String
관련 인증 증명 루트 인증서가 여러 인증자 모델에 사용된다면, Extension OID 1.3.6.1.4.1.45724.1.1.4(id-fido-gen-ce-aaguid)가 반드시 존재하며, AAGUID를 16바이트 OCTET STRING으로 포함해야 합니다. 이 확장은 critical로 표시돼서는 안 됩니다.

X.509 Extension은 값의 DER 인코딩을 OCTET STRING에 담으므로, AAGUID는 두 번 OCTET STRING으로 감싸야 유효합니다. 샘플 인코딩 확장 구조는 아래와 같습니다:
```
30 21                                     -- SEQUENCE
  06 0b 2b 06 01 04 01 82 e5 1c 01 01 04  -- 1.3.6.1.4.1.45724.1.1.4
  04 12                                   -- OCTET STRING
    04 10                                 -- OCTET STRING
      cd 8c 39 5c 26 ed ee de             -- AAGUID
      65 3b 00 79 7d 03 ca 3c
```
Basic Constraints 확장에서 CA 구성요소는 반드시 false로 설정해야 합니다.
Authority Information Access(AIA) 확장에 id-ad-ocsp 항목과 CRL Distribution Point 확장 [RFC5280]은 모두 OPTIONAL이며, 많은 인증 증명서의 상태는 인증자 메타데이터 서비스에서 확인 가능합니다. 예: FIDO Metadata Service [FIDOMetadataService].

8.3. TPM 인증 증명문 형식

이 인증 증명문 형식은 일반적으로 암호 엔진으로 Trusted Platform Module(TPM)을 사용하는 인증자에서 사용됩니다.

인증 증명문 형식 식별자

tpm

지원되는 인증 증명 타입

AttCA

구문

TPM 인증 증명문 형식의 구문은 아래와 같습니다:

    $$attStmtType // = (
                           fmt: "tpm",
                           attStmt: tpmStmtFormat
                       )

    tpmStmtFormat = {
                        ver: "2.0",
                        (
                            alg: COSEAlgorithmIdentifier,
                            x5c: [ aikCert: bytes, * (caCert: bytes) ]
                        )
                        sig: bytes,
                        certInfo: bytes,
                        pubArea: bytes
                    }

위 필드의 의미는 다음과 같습니다:

ver: 서명이 준수하는 TPM 명세의 버전입니다.
alg: COSEAlgorithmIdentifier로, 인증 증명 서명에 사용된 알고리즘 식별자를 담습니다.
x5c: X.509 인코딩된 aikCert와 그 인증서 체인(있다면).
aikCert: 인증 증명에 사용되는 AIK 인증서(X.509 인코딩).
sig: 인증 증명 서명으로, [TPMv2-Part2] 11.3.4절에서 정의된 TPMT_SIGNATURE 구조입니다.
certInfo: 위 서명이 계산된 TPMS_ATTEST 구조([TPMv2-Part2] 10.12.8절 참고).
pubArea: TPM에서 자격증명 공개키를 표현하는 TPMT_PUBLIC 구조([TPMv2-Part2] 12.2.4절 참고).

서명 절차

authenticatorData를 인증 증명용 인증자 데이터로, clientDataHash를 직렬화된 클라이언트 데이터의 해시로 둡니다.

authenticatorData와 clientDataHash를 연결하여 attToBeSigned를 만듭니다.

[TPMv2-Part3] 18.2절에서 정의된 절차에 따라 인증 증명 개인키로 서명을 생성하며, extraData 파라미터는 attToBeSigned에 대해 "alg" 서명 알고리즘에 대응하는 해시 알고리즘을 사용해 생성한 다이제스트로 설정합니다. (예를 들어 "RS256" 알고리즘은 SHA-256 다이제스트 사용)

pubArea 필드는 자격증명 공개키의 public area로, certInfo 필드는 동명 출력 파라미터로, sig 필드는 위 절차에서 얻은 서명으로 설정합니다.

검증 절차

검증 절차 입력값 attStmt, authenticatorData, clientDataHash가 주어지면, 검증 절차는 다음과 같습니다:

attStmt가 위 정의된 구문에 맞는 유효한 CBOR인지 확인하고, CBOR 디코딩으로 필드를 추출합니다.

pubArea의 parameters 및 unique 필드로 지정된 공개키가 authenticatorData 내 attestedCredentialData의 credentialPublicKey와 동일한지 확인합니다.

authenticatorData와 clientDataHash를 연결하여 attToBeSigned를 만듭니다.

certInfo가 유효한지 검증합니다:

magic 값이 TPM_GENERATED_VALUE로 설정되어 있는지 확인합니다.
type 값이 TPM_ST_ATTEST_CERTIFY로 설정되어 있는지 확인합니다.
extraData 값이 attToBeSigned에 "alg"에 사용된 해시 알고리즘을 적용한 해시와 일치하는지 확인합니다.
attested가 [TPMv2-Part2] 10.12.3절에 정의된 TPMS_CERTIFY_INFO 구조를 포함하며, 그 name 필드가 pubArea의 유효한 Name을 포함하는지(nameAlg 필드의 알고리즘 사용, [TPMv2-Part1] 16절 참고) 확인합니다.
x5c가 존재하는지 확인합니다.
"Standard Attestation Structure"([TPMv2-Part1] 31.2절)의 qualifiedSigner, clockInfo, firmwareVersion 등 나머지 필드는 무시합니다. 이 필드는 위험 평가 엔진의 입력값으로 사용될 수 있습니다.
sig가 certInfo에 대해 aikCert의 인증 증명 공개키로, alg에 지정된 알고리즘을 사용해 올바르게 서명됐는지 검증합니다.
aikCert가 § 8.3.1 TPM 인증 증명문 인증서 요구사항을 만족하는지 확인합니다.
aikCert에 OID 1.3.6.1.4.1.45724.1.1.4(id-fido-gen-ce-aaguid) 확장이 있으면, 해당 확장 값이 authenticatorData의 aaguid와 일치하는지 확인합니다.
검증 성공 시, 인증 증명 타입 AttCA와 인증 증명 신뢰 경로 x5c를 구현별 값으로 반환합니다.

8.3.1. TPM 인증 증명문 인증서 요구사항

TPM 인증 증명서에는 다음 필드/확장이 반드시 포함되어야 합니다:

Version 값은 반드시 3이어야 합니다.
Subject 필드는 반드시 비어 있어야 합니다.
Subject Alternative Name 확장은 [TPMv2-EK-Profile] 3.2.9절에서 정의된 대로 설정되어야 합니다.
Extended Key Usage 확장은 반드시 OID 2.23.133.8.3 ("joint-iso-itu-t(2) internationalorganizations(23) 133 tcg-kp(8) tcg-kp-AIKCertificate(3)")를 포함해야 합니다.
Basic Constraints 확장에서 CA 구성요소는 반드시 false로 설정해야 합니다.
Authority Information Access(AIA) 확장에 id-ad-ocsp 항목과 CRL Distribution Point 확장 [RFC5280]은 모두 OPTIONAL이며, 많은 인증 증명서의 상태는 메타데이터 서비스에서 확인 가능합니다. 예: FIDO Metadata Service [FIDOMetadataService].

8.4. Android Key 인증 증명문 형식

해당 인증자가 Android "N" 이상 플랫폼의 플랫폼 인증자일 때, 인증 증명문은 Android 키 인증 증명을 기반으로 합니다. 이 경우 인증 증명문은 보안 운영 환경에서 실행되는 컴포넌트에 의해 생성되지만, 인증 증명용 인증자 데이터는 해당 환경 외부에서 생성됩니다. WebAuthn Relying Party는 인증 증명에 사용된 것으로 주장되는 인증자 데이터가 인증 증명서의 확장 데이터 필드와 일치하는지 확인해야 합니다.

인증 증명문 형식 식별자

android-key

지원되는 인증 증명 타입

Basic

구문

Android Key 인증 증명문은 Android 인증 증명문 자체로, 일련의 DER 인코딩된 X.509 인증서입니다. Android 개발자 문서 참고. 구문은 다음과 같이 정의됩니다:

    $$attStmtType //= (
                          fmt: "android-key",
                          attStmt: androidStmtFormat
                      )

    androidStmtFormat = {
                          alg: COSEAlgorithmIdentifier,
                          sig: bytes,
                          x5c: [ credCert: bytes, * (caCert: bytes) ]
                        }

서명 절차

authenticatorData를 인증 증명용 인증자 데이터로, clientDataHash를 직렬화된 클라이언트 데이터의 해시로 둡니다.

Android Key 인증 증명을 요청하려면 keyStore.getCertificateChain(myKeyUUID)을 호출하면서 clientDataHash를 챌린지 값으로 제공합니다(예: setAttestationChallenge 사용). x5c 필드는 반환값으로 설정합니다.

인증자는 authenticatorData와 clientDataHash를 연결한 후 자격증명 개인키로 서명하여 sig를 생성합니다. alg는 서명 형식의 알고리즘으로 설정합니다.

검증 절차

검증 절차 입력값 attStmt, authenticatorData, clientDataHash가 주어지면, 검증 절차는 다음과 같습니다:

attStmt가 위 구문에 맞는 유효한 CBOR인지 확인하고, CBOR 디코딩으로 필드를 추출합니다.
sig가 authenticatorData와 clientDataHash 연결에 대해 x5c의 첫 인증서의 공개키로, alg에 지정된 알고리즘으로 올바르게 서명됐는지 검증합니다.
x5c의 첫 인증서의 공개키가 authenticatorData 내 attestedCredentialData의 credentialPublicKey와 일치하는지 확인합니다.
인증 증명서 확장 데이터의 attestationChallenge 필드가 clientDataHash와 동일한지 확인합니다.
인증 증명서 확장 데이터의 적절한 authorization list에서 다음을 검증합니다:
- AuthorizationList.allApplications 필드는 softwareEnforced와 teeEnforced 어느 인증 목록에도 포함되지 않습니다. PublicKeyCredential은 반드시 스코프가 RP ID로 한정되어야 하기 때문입니다.
- 다음 항목은 RP가 신뢰된 실행 환경에서만 키를 허용하려면 teeEnforced authorization list만 사용하고, 그렇지 않으면 teeEnforced와 softwareEnforced의 합집합을 사용합니다.
  - AuthorizationList.origin 값이 KM_ORIGIN_GENERATED와 같은지 확인합니다.
  - AuthorizationList.purpose 값이 KM_PURPOSE_SIGN와 같은지 확인합니다.
검증 성공 시, 인증 증명 타입 Basic과 인증 증명 신뢰 경로 x5c를 구현별 값으로 반환합니다.

8.4.1. Android Key 인증 증명문 인증서 요구사항

Android Key 인증 증명 인증 증명서의 Android Key 인증 증명서 확장 데이터는 OID 1.3.6.1.4.1.11129.2.1.17로 식별되며, 스키마는 Android 개발자 문서에 정의되어 있습니다.

8.5. Android SafetyNet 인증 증명문 형식

인증자가 특정 Android 플랫폼의 플랫폼 인증자일 때, 인증 증명문은 SafetyNet API를 기반으로 할 수 있습니다. 이 경우 인증자 데이터는 SafetyNet API를 호출하는 주체(주로 Android 플랫폼에서 실행되는 앱)가 완전히 제어하며, 인증 증명문은 플랫폼의 상태와 호출 앱의 신원을 기술합니다 (SafetyNet 문서 참고).

인증 증명문 형식 식별자

android-safetynet

지원되는 인증 증명 타입

Basic

구문

Android 인증 증명문의 구문은 다음과 같이 정의됩니다:

    $$attStmtType //= (
                          fmt: "android-safetynet",
                          attStmt: safetynetStmtFormat
                      )

    safetynetStmtFormat = {
                              ver: text,
                              response: bytes
                          }

각 필드의 의미는 다음과 같습니다:

ver: SafetyNet API를 제공하는 Google Play Services의 버전 번호입니다.
response: SafetyNet API의 getJwsResult() 호출 결과 UTF-8 인코딩 값입니다. 이 값은 Compact Serialization 방식의 JWS [RFC7515] 객체입니다(SafetyNet 온라인 문서 참고).

서명 절차

authenticatorData를 인증 증명용 인증자 데이터로, clientDataHash를 직렬화된 클라이언트 데이터의 해시로 둡니다.

authenticatorData와 clientDataHash를 연결한 후 SHA-256 해시를 적용하여 attToBeSigned를 만듭니다.

SafetyNet 인증 증명을 요청하면서 attToBeSigned를 nonce 값으로 제공합니다. response에는 결과값을, ver에는 인증자에서 실행 중인 Google Play Services의 버전을 설정합니다.

검증 절차

검증 절차 입력값 attStmt, authenticatorData, clientDataHash가 주어지면, 검증 절차는 다음과 같습니다:

attStmt가 위 정의된 구문에 맞는 유효한 CBOR인지 확인하고, CBOR 디코딩으로 필드를 추출합니다.
response가 ver 버전의 유효한 SafetyNet 응답인지 SafetyNet 온라인 문서 절차로 검증합니다. 현재는 SafetyNet 응답 형식이 하나뿐이며 ver은 향후 확장용입니다.
response 페이로드의 nonce 속성이 authenticatorData와 clientDataHash를 연결한 후 SHA-256 해시의 Base64 인코딩과 동일한지 확인합니다.
SafetyNet 응답이 실제로 SafetyNet 서비스에서 온 것인지 SafetyNet 문서 절차로 검증합니다.
검증 성공 시, 인증 증명 타입 Basic과 인증 증명 신뢰 경로 x5c를 구현별 값으로 반환합니다.

8.6. FIDO U2F 인증 증명문 형식

이 인증 증명문 형식은 [FIDO-U2F-Message-Formats]에 정의된 형식을 사용하는 FIDO U2F 인증자에서 사용됩니다.

인증 증명문 형식 식별자

fido-u2f

지원되는 인증 증명 타입

Basic, AttCA

구문

FIDO U2F 인증 증명문의 구문은 다음과 같이 정의됩니다:

    $$attStmtType //= (
                          fmt: "fido-u2f",
                          attStmt: u2fStmtFormat
                      )

    u2fStmtFormat = {
                        x5c: [ attestnCert: bytes ],
                        sig: bytes
                    }

각 필드의 의미는 다음과 같습니다:

x5c: X.509 형식의 인증 증명서가 담긴 단일 요소 배열입니다.
sig: 인증 증명 서명입니다. 이 서명은 인증자가 클라이언트로 반환한(수신한) U2F 등록 응답 메시지([FIDO-U2F-Message-Formats])의 원본(raw)에 대해 계산됩니다.

서명 절차

인증된 자격증명의 자격증명 공개키가 알고리즘 -7("ES256")이 아니면 오류 반환. 그렇지 않으면 authenticatorData를 인증 증명용 인증자 데이터로, clientDataHash를 직렬화된 클라이언트 데이터의 해시로 둡니다.(SHA-256을 사용하므로 clientDataHash는 32바이트)

[FIDO-U2F-Message-Formats] 4.3절 절차대로 등록 응답 메시지를 생성하되, application parameter는 RP ID의 SHA-256 해시, challenge parameter는 clientDataHash, key handle parameter는 해당 자격증명의 자격증명 ID로 설정. Registration Response Message의 원본 서명 부분(즉, 사용자 공개키, key handle, 인증 증명서는 제외)은 sig로, 인증 증명 공개키의 인증 증명서는 x5c로 설정.

검증 절차

검증 절차 입력값 attStmt, authenticatorData, clientDataHash가 주어지면, 검증 절차는 다음과 같습니다:

attStmt가 위 정의된 구문에 맞는 유효한 CBOR인지 확인하고, CBOR 디코딩으로 필드를 추출합니다.
x5c의 요소가 정확히 하나인지 확인하고, attCert를 해당 요소로 설정합니다. certificate public key를 attCert가 담는 공개키로 설정. 공개키가 P-256 곡선의 타원 곡선(EC) 공개키가 아니면 오류 반환.
authenticatorData에서 rpIdHash와 credentialId, credentialPublicKey를 추출합니다 (authenticatorData.attestedCredentialData에서).
COSE_KEY 형식의 credentialPublicKey(RFC8152 7절 참고)를 Raw ANSI X9.62 공개키 형식으로 변환(3.6.2절 참고).
- x: credentialPublicKey에서 "-2" 키(x 좌표)의 값(32바이트). 없거나 크기 불일치시 오류 반환.
- y: credentialPublicKey에서 "-3" 키(y 좌표)의 값(32바이트). 없거나 크기 불일치시 오류 반환.
- publicKeyU2F: 0x04 || x || y 연결.
  
  참고: 이는 비압축 ECC 키 형식임을 의미.
verificationData를 0x00 || rpIdHash || clientDataHash || credentialId || publicKeyU2F 연결로 생성(4.3절 참고).
sig가 verificationData에 대해 certificate public key로 [SEC1] 4.1.4절에 따라, 2단계에서는 SHA-256 해시로 올바르게 서명됐는지 검증합니다.
선택적으로 x5c를 검사하고 외부 지식과 대조하여 attStmt가 Basic 또는 AttCA 인증 증명을 전달하는지 판단합니다.
검증 성공 시, 인증 증명 타입 Basic, AttCA 또는 불확실성, 그리고 인증 증명 신뢰 경로 x5c를 구현별 값으로 반환합니다.

8.7. None 인증 증명문 형식

None 인증 증명문 형식은 WebAuthn Relying Party가 인증 정보 수신을 원하지 않는다고 표시할 때, 인증자가 제공하는 인증 증명문을 대체하는 데 사용됩니다. 자세한 내용은 § 5.4.7 인증 증명 전달 선호 열거(enum AttestationConveyancePreference) 참고.

인증자가 인증 증명을 지원하지 않는 경우, 이 형식의 인증 증명문을 직접 생성할 수도 있습니다.

인증 증명문 형식 식별자

none

지원되는 인증 증명 타입

None

구문

None 인증 증명문 형식의 구문은 다음과 같이 정의됩니다:

    $$attStmtType //= (
                          fmt: "none",
                          attStmt: emptyMap
                      )

    emptyMap = {}

서명 절차

위에서 정의한 고정 인증 증명문을 반환합니다.

검증 절차

인증 증명 타입 None과 빈 인증 증명 신뢰 경로를 나타내는 구현별 값을 반환합니다.

8.8. Apple 익명 인증 증명문 형식

이 인증 증명문 형식은 특정 WebAuthn을 지원하는 Apple 기기에서 Apple이 독점적으로 사용합니다.

인증 증명문 형식 식별자

apple

지원되는 인증 증명 타입

Anonymization CA

구문

Apple 인증 증명문 형식의 구문은 다음과 같이 정의됩니다:

    $$attStmtType //= (
                          fmt: "apple",
                          attStmt: appleStmtFormat
                      )

    appleStmtFormat = {
                          x5c: [ credCert: bytes, * (caCert: bytes) ]
                      }

각 필드의 의미는 다음과 같습니다:

x5c: credCert와 그 인증서 체인(X.509 형식) 순서대로.
credCert: 인증 증명에 사용되는 자격증명 공개키 인증서(X.509 형식 인코딩).

서명 절차

authenticatorData를 인증 증명용 인증자 데이터로, clientDataHash를 직렬화된 클라이언트 데이터의 해시로 설정합니다.
authenticatorData와 clientDataHash를 연결하여 nonceToHash를 생성합니다.
nonceToHash에 SHA-256 해시를 적용하여 nonce를 생성합니다.
Apple 익명 인증 증명 CA가 해당 자격증명 공개키에 대해 X.509 인증서를 생성하며, nonce를 OID 1.2.840.113635.100.8.2가 있는 인증서 확장에 포함시킵니다. credCert가 그 인증서입니다. credCert는 인증 증명의 증거 역할을 하며, 포함된 nonce는 인증 증명이 실시간으로 생성됐음을 입증합니다. 또한 nonce는 authenticatorData와 클라이언트 데이터의 무결성도 보호합니다.
x5c를 credCert와 그 인증서 체인으로 설정합니다.

검증 절차

검증 절차 입력값 attStmt, authenticatorData, clientDataHash가 주어지면 검증 절차는 다음과 같습니다:

attStmt가 위 정의된 구문에 맞는 유효한 CBOR인지 확인하고, CBOR 디코딩으로 필드를 추출합니다.
authenticatorData와 clientDataHash를 연결하여 nonceToHash를 생성합니다.
nonceToHash에 SHA-256 해시를 적용하여 nonce를 생성합니다.
nonce가 credCert 내 OID 1.2.840.113635.100.8.2 확장 값과 동일한지 확인합니다.
자격증명 공개키가 credCert의 Subject Public Key와 동일한지 확인합니다.
검증 성공 시, 인증 증명 타입 Anonymization CA와 인증 증명 신뢰 경로 x5c를 구현별 값으로 반환합니다.

9. WebAuthn 확장

공개키 자격증명 생성, 인증 어서션 요청 및 생성 메커니즘은 § 5 Web Authentication API에 정의되어 있으며, 특정 사용 사례에 맞게 확장할 수 있습니다. 각 경우는 등록 확장 및/또는 인증 확장을 정의하여 다룹니다.

모든 확장은 클라이언트 확장이며, 즉 확장은 클라이언트와의 통신 및 처리에 관여합니다. 클라이언트 확장은 다음 단계와 데이터를 정의합니다:

navigator.credentials.create() 확장 요청 매개변수 및 등록 확장의 응답 값.
navigator.credentials.get() 확장 요청 매개변수 및 인증 확장의 응답 값.
클라이언트 확장 처리 단계 및 등록 확장, 인증 확장 처리.

공개키 자격증명을 생성하거나 인증 어서션을 요청할 때, WebAuthn Relying Party는 확장 세트를 요청할 수 있습니다. 이 확장들은 클라이언트 및/또는 WebAuthn 인증자가 지원하면, 요청된 작업 중에 호출됩니다. Relying Party는 각 확장에 대해 get() 호출(인증 확장) 또는 create() 호출(등록 확장)에서 클라이언트 확장 입력을 전송합니다. 클라이언트는 지원하는 각 확장에 대해 클라이언트 확장 처리를 수행하고, 각 확장에 지정된 대로 클라이언트 데이터를 확장하며, 확장 식별자와 클라이언트 확장 출력 값을 포함합니다.

확장은 인증자 확장일 수도 있습니다. 즉, 확장에 인증자와의 통신 및 처리가 수반됩니다. 인증자 확장은 다음 단계와 데이터를 정의합니다:

authenticatorMakeCredential 확장 요청 매개변수 및 등록 확장의 응답 값.
authenticatorGetAssertion 확장 요청 매개변수 및 인증 확장의 응답 값.
인증자 확장 처리 단계 및 등록 확장, 인증 확장 처리.

인증자 확장의 경우, 클라이언트 확장 처리의 일환으로 클라이언트는 각 확장에 대해 CBOR 인증자 확장 입력 값을 생성하여(종종 해당 클라이언트 확장 입력 값을 기반으로) 인증자에 전달합니다. 이 값은 create() 호출(등록 확장) 또는 get() 호출(인증 확장)에서 인증자에 CBOR 네임-값 쌍으로 전달됩니다(이름은 확장 식별자, 값은 해당 인증자 확장 입력). 인증자는 지원하는 확장에 대해 추가 처리를 수행하고, 각 확장에 대해 지정된 CBOR 인증자 확장 출력 값을 반환합니다. 클라이언트 확장 처리의 일부로, 인증자 확장 출력 값은 클라이언트 확장 출력 생성에 입력값으로 활용됩니다.

모든 WebAuthn 확장은 클라이언트와 인증자 모두에 대해 OPTIONAL입니다. 따라서 Relying Party가 요청한 확장은 클라이언트 브라우저나 OS에서 무시되어 인증자에 전달되지 않을 수도 있고, 인증자에서 무시될 수도 있습니다. 확장 무시는 WebAuthn API 처리에서 실패로 간주되지 않으므로, Relying Party가 API 호출 시 확장을 포함할 경우 일부 또는 모든 확장이 무시되는 상황을 반드시 처리할 수 있어야 합니다.

최대한 다양한 확장 지원을 원하는 클라이언트는 인식하지 못하는 확장을 인증자에 그대로 패스스루할 수 있습니다. 이 경우 인증자 확장 입력은 클라이언트 확장 입력을 CBOR로 인코딩하여 생성합니다. 모든 WebAuthn 확장은 이러한 구현 방식이 사용자의 보안이나 프라이버시를 해치지 않게 정의되어야 합니다. 예를 들어 확장에 클라이언트 처리 요구가 있다면, 단순 패스스루 시 의미적으로 잘못된 인증자 확장 입력 값이 생성되어 인증자에서 해당 확장을 무시하게 해야 합니다. 모든 확장이 OPTIONAL이므로, 이는 API 동작 실패를 초래하지 않습니다. 마찬가지로, 클라이언트는 인식하지 못하는 확장에 대해 인증자 확장 출력 값을 JSON에 인코딩하여 클라이언트 확장 출력 값으로 생성할 수 있습니다. 단, CBOR 출력값에 JSON에 존재하는 타입만 사용해야 합니다.

클라이언트가 인식하지 못하는 확장을 패스스루할 때, 클라이언트 확장 입력의 JavaScript 값은 CBOR 값으로 인증자 확장 입력에 변환됩니다. JavaScript 값이 %ArrayBuffer%라면 CBOR 바이트 배열로 변환합니다. JavaScript 값이 정수가 아닌 숫자라면 64비트 CBOR 부동소수점 숫자로 변환합니다. 그 외 JavaScript 타입이 JSON 타입에 대응하면 [RFC8949] 6.2절(JSON→CBOR 변환) 규칙대로 변환하되, 입력값은 JSON 타입이 아니라 JavaScript 타입입니다. 변환 후에는 CBOR의 CTAP2 표준 CBOR 인코딩 형태로 정규화해야 합니다.

JavaScript 숫자 변환 규칙 때문에, 클라이언트가 인식하지 못하는 확장을 패스스루할 때 확장에서 부동소수점 값을 사용할 경우 인증자는 해당 값을 CBOR 정수로 수신할 수 있으므로, 인증자가 실제 클라이언트 지원 없이 항상 확장이 동작하길 원한다면 이 점을 고려해야 합니다. 이는 부동소수점 값이 정수인 경우 발생합니다.

마찬가지로, 클라이언트가 인식하지 못하는 확장에서 받은 출력값 처리 시 인증자 확장 출력의 CBOR 값은 클라이언트 확장 출력의 JavaScript 값으로 변환됩니다. CBOR 값이 바이트 문자열일 경우 JavaScript %ArrayBuffer%로 변환합니다(base64url 인코딩 문자열 아님). 그 외 CBOR 타입이 JSON 타입에 대응하면 [RFC8949] 6.1절(CBOR→JSON 변환) 규칙대로 변환하되, 결과 값은 JSON 타입이 아니라 JavaScript 타입입니다.

일부 클라이언트는 이러한 패스스루 기능을 기능 플래그로 구현할 수 있습니다. 이 기능 지원은 혁신을 촉진하여, 인증자가 클라이언트의 명시적 지원 전에 새로운 확장을 실험하고 Relying Party가 활용할 수 있게 합니다.

IANA "WebAuthn Extension Identifiers" 레지스트리 [IANA-WebAuthn-Registries]([RFC8809] 제정)에서 등록된 WebAuthn 확장의 최신 목록을 확인할 수 있습니다.

9.1. 확장 식별자

확장은 확장 작성자가 지정한 문자열(확장 식별자)로 식별됩니다.

확장 식별자는 IANA "WebAuthn Extension Identifiers" 레지스트리 [IANA-WebAuthn-Registries]([RFC8809] 제정)에 등록되어야 하며, 등록된 모든 확장 식별자는 고유합니다.

등록되지 않은 확장 식별자는 전역적으로 고유하도록, 정의 주체(예: myCompany_extension)를 포함하는 식별자를 사용해야 합니다.

모든 확장 식별자는 최대 32 옥텟 길이, USASCII 인쇄 문자만 포함(백슬래시, 쌍따옴표 제외, [RFC5234]의 VCHAR에서 %x22, %x5c 제외)해야 하고, 구현체는 대소문자 구분으로 매칭해야 합니다.

여러 버전이 존재할 수 있는 확장은 식별자에 버전을 포함해야 하며, 즉 다른 버전은 서로 다른 확장으로 취급됩니다(예: myCompany_extension_01).

§ 10 정의된 확장에서 추가 확장 및 식별자를 정의합니다. 최신 WebAuthn Extension Identifier 목록은 IANA "WebAuthn Extension Identifiers" 레지스트리([IANA-WebAuthn-Registries], [RFC8809] 제정) 참고.

9.2. 확장 정의

확장 정의에는 반드시 확장 식별자, get() 또는 create() 호출 시 전송되는 클라이언트 확장 입력 인자, 클라이언트 확장 처리 규칙, 클라이언트 확장 출력 값을 명시해야 합니다. 확장이 인증자와 통신(즉 인증자 확장)한다면, CBOR 인증자 확장 입력 인자(authenticatorGetAssertion 또는 authenticatorMakeCredential 호출 시 전송), 인증자 확장 처리 규칙, CBOR 인증자 확장 출력 값도 명시해야 합니다.

클라이언트가 처리하는 클라이언트 확장은 반드시 클라이언트 확장 출력 값을 반환해야 하며, WebAuthn Relying Party가 클라이언트가 확장을 처리했음을 알 수 있어야 합니다. 마찬가지로 인증자 처리가 필요한 확장은 반드시 인증자 확장 출력 값을 반환해 Relying Party가 인증자가 확장을 처리했음을 알 수 있게 해야 합니다. 별도의 결과 값이 필요 없는 확장은 true로 설정된 JSON Boolean 클라이언트 확장 출력 결과를 반환하도록 정의하는 것이 좋습니다. 마찬가지로 별도의 결과 값이 필요 없는 인증자 확장은 반드시 값을 반환해야 하며, true로 설정된 CBOR Boolean 인증자 확장 출력 결과를 반환하는 것이 좋습니다.

9.3. 요청 파라미터 확장

확장은 하나 또는 두 개의 요청 인자를 정의합니다. 클라이언트 확장 입력은 JSON으로 인코딩 가능한 값으로, WebAuthn Relying Party에서 클라이언트로 get() 또는 create() 호출 시 전달됩니다. CBOR 인증자 확장 입력은 인증자 확장 처리 시 클라이언트에서 인증자로 전달됩니다.

Relying Party는 확장을 요청하면서 해당 클라이언트 확장 입력을 extensions 옵션의 엔트리로 create() 또는 get() 호출 시 설정합니다. 엔트리 key는 확장 식별자이며 값은 클라이언트 확장 입력입니다.

참고: 다른 문서에서는 확장 입력이 항상 확장 식별자를 엔트리 key로 사용하지 않는 확장을 명세한 바 있습니다. 새 확장은 위 규약을 따르는 것이 좋습니다.

var assertionPromise = navigator.credentials.get({
    publicKey: {
        // Other members omitted for brevity
        extensions: {
            // "webauthnExample_foobar" 확장 식별자 key, 
            // 값은 두 개의 입력 파라미터를 가진 맵:
            "webauthnExample_foobar": {
              foo: 42,
              bar: "barfoo"
            }
        }
    }
});

확장 정의는 반드시 클라이언트 확장 입력의 유효 값(valid values)을 명시해야 합니다. 클라이언트는 유효하지 않은 클라이언트 확장 입력의 확장은 무시해야 합니다. 확장이 Relying Party로부터 파라미터를 필요로 하지 않으면, Boolean 클라이언트 인자를 받아 true로 확장 요청 사실을 표시하는 것이 좋습니다.

클라이언트 처리에만 영향을 주는 확장은 인증자 확장 입력을 명시하지 않아도 됩니다. 인증자 처리가 필요한 확장은 반드시 클라이언트 확장 입력에서 인증자 확장 입력을 계산하는 방법을 명시해야 하며, CDDL 타입 AuthenticationExtensionsAuthenticatorInputs 및 AuthenticationExtensionsAuthenticatorOutputs 확장에 대해 group sockets의 $$extensionInput, $$extensionOutput에 확장 식별자를 key로 추가하는 방법도 정의해야 합니다. 입력 파라미터가 필요 없는 확장은 Boolean 클라이언트 확장 입력 값 true를 받아야 하며, 인증자 확장 입력도 반드시 CBOR Boolean true(major type 7, value 21)로 정의해야 합니다.

아래 예시는 식별자 webauthnExample_foobar 확장이 인증자 확장 입력으로 부호 없는 정수(uint)를 받고, 인증자 확장 출력으로 하나 이상의 바이트 문자열 배열을 반환함을 정의합니다:

$$extensionInput //= (
  webauthnExample_foobar: uint
)
$$extensionOutput //= (
  webauthnExample_foobar: [+ bytes]
)

참고: 확장은 인증자 인자를 최대한 작게 정의하는 것이 좋습니다. 일부 인증자는 Bluetooth LE, NFC 등 저대역폭 링크로 통신합니다.

9.4. 클라이언트 확장 처리

확장은 자격증명 생성 또는 어서션 생성 시 클라이언트에 추가 처리 요구 사항을 정의할 수 있습니다. 확장에 대한 클라이언트 확장 입력이 클라이언트 처리의 입력값으로 사용됩니다. 지원되는 각 클라이언트 확장에 대해 클라이언트는 clientExtensions 맵에 확장 식별자를 key, 해당 클라이언트 확장 입력을 value로 추가합니다.

마찬가지로 클라이언트 확장 출력은 getClientExtensionResults() 결과의 딕셔너리로 표현되며, key는 확장 식별자, value는 각 확장의 클라이언트 확장 출력 값입니다. 클라이언트 확장 입력과 마찬가지로, 클라이언트 확장 출력은 JSON으로 인코딩 가능한 값입니다. 무시된 확장에 대한 값은 반환되어서는 안 됩니다.

인증자 처리가 필요한 확장은 클라이언트 확장 입력에서 CBOR 인증자 확장 입력을 결정하는 과정, CBOR 인증자 확장 출력에서 클라이언트 확장 출력을 결정하는 과정을 반드시 정의해야 합니다.

9.5. 인증자 확장 처리

처리된 각 인증자 확장의 CBOR 인증자 확장 입력 값은 authenticatorMakeCredential, authenticatorGetAssertion 작업의 extensions 파라미터에 포함됩니다. extensions 파라미터는 CBOR 맵으로, key는 확장 식별자, 값은 해당 인증자 확장 입력입니다.

마찬가지로, 확장 출력은 extensions 부분에 표현되며, 이는 인증자 데이터의 일부입니다. extensions는 CBOR 맵으로, key는 확장 식별자, 값은 해당 확장의 인증자 확장 출력 값입니다.

각 지원하는 확장에 대해, 해당 확장의 인증자 확장 처리 규칙을 사용하여 인증자 확장 입력 및 필요시 기타 입력값으로부터 인증자 확장 출력을 생성합니다. 무시된 확장에 대한 값은 반환되어서는 안 됩니다.

10. 정의된 확장

이 절에서는 IANA "WebAuthn Extension Identifiers" 레지스트리 [IANA-WebAuthn-Registries]([RFC8809] 제정)에 등록될 추가 확장 집합을 정의합니다. 이 확장들은 광범위한 상호운용성을 목표로 하는 사용자 에이전트가 구현할 수 있습니다.

10.1. FIDO AppID 확장(appid)

이 확장은 WebAuthn Relying Party가 기존 FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI]를 사용해 자격증명을 등록한 경우, assertion 요청을 할 수 있도록 지원합니다. FIDO API는 Relying Party에 대해 AppID라 불리는 대체 식별자를 사용하며 [FIDO-APPID], 이 API로 생성된 자격증명은 해당 식별자에 스코프됩니다. 이 확장이 없다면, RP ID에 스코프되도록 재등록해야 합니다.

이 확장 사용 시 appid 확장 입력 설정 외에도, 등록된 U2F 자격증명으로 인증을 허용하기 위해 Relying Party가 추가 처리를 해야 합니다:

원하는 U2F 자격증명을 allowCredentials 옵션에 나열합니다(get() 호출 시):
- type 멤버를 public-key로 설정합니다.
- id 멤버를 원하는 자격증명의 U2F key handle로 설정합니다. U2F key handle은 흔히 base64url 인코딩을 사용하지만, id로 사용할 때는 바이너리 형태로 디코딩해야 합니다.
allowCredentials 에는 WebAuthn credential ID와 U2F key handle을 혼합해 포함할 수 있습니다. 이 확장(appid) 사용이 RP ID에 스코프된 WebAuthn 자격증명 사용을 막지는 않습니다.
assertion 검증 시, rpIdHash가 AppID의 해시일 수 있음을 기대해야 합니다.

이 확장으로 FIDO 호환 자격증명을 새로 생성할 수는 없습니다. 즉, WebAuthn으로 생성된 자격증명은 FIDO JavaScript API와 역호환되지 않습니다.

참고: appid 값은 Relying Party가 과거 FIDO API에서 사용한 AppID로 설정해야 하며, 이는 현재 WebAuthn RP ID를 AppID 형식으로 변환한 결과와 다를 수 있습니다. 예를 들어 과거 AppID가 "https://accounts.example.com"이고, 현재 RP ID는 "example.com"일 수 있습니다.

확장 식별자

appid

적용 작업

인증

클라이언트 확장 입력

FIDO AppID를 지정하는 단일 USVString 값.

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appid;
};

클라이언트 확장 처리

facetId를 호출자의 origin을 FIDO 알고리즘(호출 응용의 FacetID 결정)에 전달한 결과로 설정합니다.
appId를 확장 입력값으로 설정합니다.
facetId와 appId를 FIDO 알고리즘(호출 응용의 FacetID가 AppID에 권한이 있는지 결정)에 전달합니다. 알고리즘이 appId를 거부하면 "SecurityError" DOMException을 반환합니다.
allowCredentialDescriptorList 생성 시, U2F 인증자가 자격증명이 적용 불가(예: SW_WRONG_DATA 반환)임을 나타내면, 클라이언트는 U2F application parameter를 appId의 SHA-256 해시로 재시도해야 하며, 적용 가능한 자격증명이 나오면 해당 자격증명을 allowCredentialDescriptorList에 포함해야 합니다. 이 경우 appId 값이 authenticatorGetAssertion의 rpId 파라미터를 대체합니다.
output을 Boolean 값 false로 설정합니다.
assertionCreationData 생성 시, assertion이 U2F 인증자가 appId의 SHA-256 해시(U2F application parameter)로 생성한 경우 output을 true로 설정합니다.

참고: 실제로는 여러 구현체가 위 알고리즘의 4단계 이후를 구현하지 않고, 3단계에서 호스트 비교를 동일 사이트로 완화합니다.

클라이언트 확장 출력

output 값을 반환합니다. true이면 AppID가 사용된 것이며, assertion 검증 시 Relying Party는 rpIdHash가 AppID 해시임을 기대해야 합니다.

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appid;
};

인증자 확장 입력

없음.

인증자 확장 처리

없음.

인증자 확장 출력

없음.

10.2. FIDO AppID 제외 확장(appidExclude)

이 등록 확장은 WebAuthn Relying Party가 FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI]로 생성된 자격증명을 가진 인증자를 제외할 수 있게 합니다.

FIDO U2F JavaScript API에서 WebAuthn으로 전환 중인 경우, Relying Party가 기존 자격증명 등록 사용자를 보유할 수 있습니다. appid 확장은 로그인 흐름을 원활하게 전환할 수 있지만, 등록 흐름 전환 시 excludeCredentials 필드는 내용을 WebAuthn 자격증명으로만 처리하므로, 기존 자격증명 가진 인증자를 제외하는 데 효과적이지 않습니다. 이 확장은 클라이언트 플랫폼이 excludeCredentials 내용을 WebAuthn 및 기존 FIDO 자격증명 모두로 간주하도록 지시합니다. U2F key handle 역시 base64url 인코딩이 흔히 사용되지만, excludeCredentials에서 사용 시 바이너리로 디코딩해야 합니다.

확장 식별자

appidExclude

적용 작업

등록

클라이언트 확장 입력

FIDO AppID를 지정하는 단일 USVString 값.

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appidExclude;
};

클라이언트 확장 처리

새 자격증명 생성 시:

RP ID 결정 직후 다음을 수행:
1. facetId를 호출자의 origin을 FIDO 알고리즘(호출 응용의 FacetID 결정)에 전달한 결과로 설정합니다.
2. appId를 확장 입력 appidExclude 값으로 설정합니다.
3. facetId와 appId를 FIDO 알고리즘(호출 응용의 FacetID가 AppID에 권한이 있는지 결정)에 전달합니다. 알고리즘이 appId를 거부하면 "SecurityError" DOMException을 반환하며, 새 자격증명 생성 알고리즘과 이 단계들을 종료합니다.
  
  참고: 실제로는 여러 구현체가 위 알고리즘의 4단계 이후를 구현하지 않고, 3단계에서 호스트 비교를 동일 사이트로 완화합니다.
4. 그 외에는 정상 처리 계속.
authenticatorMakeCredential 호출 직전 다음을 수행:
1. authenticator가 U2F 프로토콜을 지원하면([FIDO-U2F-Message-Formats]), excludeCredentialDescriptorList 내 각 자격증명 디스크립터 C에 대해:
  1. authenticator에 U2F_AUTHENTICATE 메시지를 전송하여 C가 U2F로 생성된 자격증명인지 확인(메시지의 "다섯 부분" 값은 아래와 같음):
    
    control byte
    
    0x07 ("check-only")
    
    challenge parameter
    
    32 랜덤 바이트
    
    application parameter
    
    appId의 SHA-256 해시
    
    key handle length
    
    C.id의 바이트 길이
    
    key handle
    
    C.id 값, 즉 자격증명 ID
  2. authenticator가 message:error:test-of-user-presence-required(성공)로 응답하면, 해당 authenticator의 정상 처리를 중단하고, 인증자가 적용 불가함을 플랫폼 특화 방식으로 표시해야 합니다(UI, 사용자 동의 요청 등).
    
    사용자 동의 요청은 U2F_AUTHENTICATE 메시지를 control byte만 0x03("enforce-user-presence-and-sign")으로 바꿔 재전송, 응답은 무시.
2. 그 외에는 정상 처리 계속.

클라이언트 확장 출력

확장이 처리됐음을 Relying Party에 알리기 위해 true 반환.

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appidExclude;
};

인증자 확장 입력

없음.

인증자 확장 처리

없음.

인증자 확장 출력

없음.

10.3. 사용자 검증 방식 확장(uvm)

이 확장은 사용자 검증 방식을 사용할 수 있게 해줍니다.

확장 식별자

uvm

적용 작업

등록 및 인증

클라이언트 확장 입력

이 확장을 Relying Party가 요청했다는 의미로 Boolean 값 true를 사용합니다.

partial dictionary AuthenticationExtensionsClientInputs {
  boolean uvm;
};

클라이언트 확장 처리

클라이언트 확장 입력으로부터 인증자 확장 입력을 생성하는 것 외에는 없습니다.

클라이언트 확장 출력

인증자 확장 출력에 포함된 요소를 부호화한 3-요소 숫자 배열의 JSON 배열을 반환합니다.

typedef sequence<unsigned long> UvmEntry;
typedef sequence<UvmEntry> UvmEntries;

partial dictionary AuthenticationExtensionsClientOutputs {
  UvmEntries uvm;
};

인증자 확장 입력

CBOR로 인코딩된 Boolean 값 true(major type 7, value 21).

    $$extensionInput //= (
      uvm: true,
    )

인증자 확장 처리

인증자는 인증자 확장 출력을 사용자가 동작을 승인할 때 사용한 방식(요소) 하나 이상으로 설정합니다. 이 확장은 attestation 객체와 assertion에 추가될 수 있습니다.

인증자 확장 출력

인증자는 단일 인증 인스턴스에서 최대 3개의 사용자 검증 방식(요소)을 CBOR 구문으로 보고할 수 있습니다:

    $$extensionOutput //= (
      uvm: [ 1*3 uvmEntry ],
    )

    uvmEntry = [
                   userVerificationMethod: uint .size 4,
                   keyProtectionType: uint .size 2,
                   matcherProtectionType: uint .size 2
               ]

각 uvmEntry 필드의 의미는 다음과 같습니다:

userVerificationMethod: 인증자가 사용자를 검증하는 데 사용한 인증 방식/요소입니다. 사용 가능한 값은 FIDO-Registry 3.1 사용자 검증 방식에 정의되어 있습니다.
keyProtectionType: 인증자가 FIDO 등록 개인키를 보호하는 데 사용한 방식입니다. 사용 가능한 값은 FIDO-Registry 3.2 키 보호 방식에 정의되어 있습니다.
matcherProtectionType: 인증자가 사용자 검증을 수행하는 matcher를 보호하는 데 사용한 방식입니다. 사용 가능한 값은 FIDO-Registry 3.3 matcher 보호 방식에 정의되어 있습니다.

하나의 인증 인스턴스에서 3개 초과 요소를 사용할 수 있다면, 인증자 벤더는 서버에 가장 관련성이 높다고 판단하는 3개를 선택해 UVM에 포함해야 합니다.

예시: 다요소 인증 인스턴스에서 두 요소를 사용한 UVM 확장이 포함된 authenticator data:

...                    -- RP ID 해시 (32바이트)
81                     -- UP 및 ED 설정됨
00 00 00 01            -- (초기) 서명 카운터
...                    -- 공개키 알고리즘 등
A1                     -- 확장: CBOR 맵(요소 1개)
    63                 -- 키 1: CBOR 텍스트 문자열(3바이트)
        75 76 6d       -- "uvm" [UTF-8 인코딩] 문자열
    82                 -- 값 1: 길이 2의 CBOR 배열(두 요소 사용)
        83              -- 1번 요소: 길이 3의 CBOR 배열
            02           -- 서브요소 1: 사용자 검증 방식(지문)
            04           -- 서브요소 2: 키 보호 방식(TEE)
            02           -- 서브요소 3: matcher 보호 방식(TEE)
        83              -- 2번 요소: 길이 3의 CBOR 배열
            04           -- 서브요소 1: 사용자 검증 방식(비밀번호)
            01           -- 서브요소 2: 키 보호 방식(소프트웨어)
            01           -- 서브요소 3: matcher 보호 방식(소프트웨어)

10.4. 자격증명 속성 확장(credProps)

이 클라이언트 등록 확장은 클라이언트가 알고 있는 특정 자격증명 속성을 WebAuthn Relying Party에 공개키 자격증명 소스가 등록 절차 결과로 생성될 때 보고할 수 있도록 지원합니다.

현재 하나의 자격증명 속성만 정의되어 있습니다: 상주키 자격증명 속성(즉, 클라이언트 측 발견 가능한 자격증명 속성).

확장 식별자

credProps

적용 작업

등록

클라이언트 확장 입력

이 확장을 Relying Party가 요청했다는 의미로 Boolean 값 true를 사용합니다.

partial dictionary AuthenticationExtensionsClientInputs {
    boolean credProps;
};

클라이언트 확장 처리

출력에서 자격증명 속성을 보고하는 것 외에는 없습니다.

클라이언트 확장 출력

Set clientExtensionResults["credProps"]["rk"] 값을 authenticatorMakeCredential 작업 호출 시 사용된 requireResidentKey 파라미터 값으로 설정합니다.

dictionary CredentialPropertiesOutput {
    boolean rk;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    CredentialPropertiesOutput credProps;
};

rk, 타입 boolean

이 OPTIONAL 속성은 추상적으로 상주키 자격증명 속성(즉, 클라이언트 측 발견 가능한 자격증명 속성)이라고 하며, PublicKeyCredential 이 등록 절차 결과로 반환된 클라이언트 측 발견 가능한 자격증명인지 Boolean 값으로 나타냅니다. rk 값이 true이면 해당 자격증명은 발견 가능한 자격증명입니다. rk 값이 false이면 해당 자격증명은 서버 측 자격증명입니다. rk 값이 없으면 해당 자격증명이 발견 가능한 자격증명인지 서버 측 자격증명인지 알 수 없습니다.

참고: 일부 인증자는 클라이언트 플랫폼이 요청하지 않아도 발견 가능한 자격증명을 생성합니다. 이 때문에 클라이언트 플랫폼은 rk 속성을 false로 확실히 지정할 수 없을 때 이 속성을 생략할 수 있습니다. Relying Party는 credProps 확장을 지원한다면 클라이언트 플랫폼이 rk 속성 값을 채우려고 노력할 것으로 간주해야 하며, rk 값이 없으면 생성된 자격증명이 대부분 비발견 자격증명임을 나타냅니다.

인증자 확장 입력

없음.

인증자 확장 처리

없음.

인증자 확장 출력

없음.

10.5. 대용량 blob 저장 확장(largeBlob)

이 클라이언트 등록 확장 및 인증 확장은 Relying Party가 자격증명에 연관된 불투명 데이터(opaque data)를 저장할 수 있게 합니다. 인증자는 소량의 데이터만 저장할 수 있고, 대부분의 Relying Party는 사용자를 위한 임의의 상태를 저장할 수 있는 온라인 서비스이므로, 이 확장은 특정 경우에만 유용합니다. 예를 들어 Relying Party가 중앙 집중식 인증 서비스 대신 인증서를 발급하고 싶을 수 있습니다.

참고: Relying Party는 불투명 데이터가 용량 제한 장치에 기록될 때 압축 처리됨을 가정할 수 있으므로 직접 압축하지 않아도 됩니다.

인증서 시스템은 자격증명의 공개키에 서명해야 하며, 해당 공개키는 생성 후에만 이용 가능하므로, 이 확장은 등록 컨텍스트에서 blob 쓰기 기능을 추가하지 않습니다. 하지만 Relying Party가 이후 인증 확장 사용을 원한다면 자격증명 생성 시 등록 확장을 사용해야 합니다.

인증서는 일반 인증자 저장 능력에 비해 크기가 크므로, 사용자 에이전트는 사용자가 이 제한된 자원을 할당할 때 적절한 안내 및 확인을 하여 오용을 방지할 방안을 고려해야 합니다.

참고: 상호운용을 위해, [FIDO-CTAP]를 사용하는 인증자에 대용량 blob을 저장하는 사용자 에이전트는 해당 명세의 대용량 자격증명별 blob 저장 조항을 따라야 합니다.

확장 식별자

largeBlob

적용 작업

등록 및 인증

클라이언트 확장 입력

partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsLargeBlobInputs largeBlob;
};

enum LargeBlobSupport {
  "required",
  "preferred",
};

dictionary AuthenticationExtensionsLargeBlobInputs {
    DOMString support;
    boolean read;
    BufferSource write;
};

support, 타입 DOMString: LargeBlobSupport 값 중 하나를 가지는 DOMString입니다. (§ 2.1.1 DOMString 타입의 열거형 참고.) 등록 시에만 유효합니다.
read, 타입 boolean: Boolean으로, Relying Party가 해당 자격증명에 연관된 이전에 기록된 blob을 가져오고 싶음을 나타냅니다. 인증 시에만 유효합니다.
write, 타입 BufferSource: 기존 자격증명에 저장하고자 하는 불투명 바이트 문자열입니다. 인증 시에만 유효합니다.

클라이언트 확장 처리(등록)

read 또는 write 값이 있으면:
1. 이름이 “NotSupportedError”인 DOMException 반환.
support 값이 required이면:
1. supported 값을 true로 설정.
  
  참고: 대용량 blob 저장 가능한 인증자가 나올 것을 예상하며, [[Create]]()의 Step 11에서 확장 처리 중 발생합니다. AuthenticationExtensionsLargeBlobOutputs는 적합한 인증자가 없으면 폐기됩니다.
2. 후보 인증자가 등장하면([[Create]]()의 Step 19), 후보 인증자가 대용량 blob 저장 불가하면, continue(즉, 후보 인증자 무시).
그 외(support가 없거나 preferred이면):
1. 선택된 인증자가 대용량 blob 지원하면 supported 값을 true로, 그렇지 않으면 false로 설정.

클라이언트 확장 처리(인증)

support 값이 있으면:
1. 이름이 “NotSupportedError”인 DOMException 반환.
read 와 write 모두 있으면:
1. 이름이 “NotSupportedError”인 DOMException 반환.
read 값이 true이면:
1. 클라이언트 확장 출력 largeBlob을 초기화.
2. 어떤 인증자든 성공([[DiscoverFromExternalSource]]())을 표시하면, 해당 자격증명에 연관된 largeBlob 데이터를 읽기 시도.
3. 성공하면 blob 값으로 결과값 설정.
  
  참고: 읽기가 실패하면 largeBlob이 AuthenticationExtensionsClientOutputs에는 존재하지만 blob 멤버는 없음.
write 값이 있으면:
1. allowCredentials가 요소 하나만 포함하지 않으면:
  1. 이름이 “NotSupportedError”인 DOMException 반환.
2. assertion 작업이 성공하면, write 내용을 인증자에 해당 자격증명과 연관해 기록 시도.
3. 성공하면 written 값을 true로, 실패하면 false로 설정.

클라이언트 확장 출력

partial dictionary AuthenticationExtensionsClientOutputs {
    AuthenticationExtensionsLargeBlobOutputs largeBlob;
};

dictionary AuthenticationExtensionsLargeBlobOutputs {
    boolean supported;
    ArrayBuffer blob;
    boolean written;
};

supported, 타입 boolean: 생성된 자격증명이 대용량 blob 저장을 지원할 때만 true. 등록 출력에만 포함.
blob, 타입 ArrayBuffer: rawId로 식별되는 자격증명에 연관된 불투명 바이트 문자열. read 값이 true일 때만 유효.
written, 타입 boolean: write 내용이 인증자에 해당 자격증명과 연관되어 성공적으로 저장됐으면 true, 아니면 false.

인증자 확장 처리

이 확장은 사용자 에이전트가 대용량 blob을 인증자에 저장 또는 조회하도록 지시합니다. Relying Party에 대한 직접적인 인증자 상호작용은 명시하지 않습니다.

11. 유저 에이전트 자동화

유저 에이전트 자동화 및 웹 애플리케이션 테스트를 위해, 본 문서는 여러 [WebDriver] 확장 명령어를 정의합니다.

11.1. WebAuthn WebDriver 확장 기능

아래에 정의된 확장 명령어들의 사용 가능성을 광고하기 위해 새로운 확장 기능(capability)이 정의됩니다.

기능	키	값 타입	설명
가상 인증자 지원	`"webauthn:virtualAuthenticators"`	boolean	엔드포인트 노드가 모든 가상 인증자 명령을 지원하는지 여부.

기능 검증 시, "webauthn:virtualAuthenticators"를 value로 검증하는 확장 전용 하위 단계는 다음과 같습니다:

value가 boolean이 아니면, WebDriver 오류와 WebDriver 오류 코드 invalid argument를 반환합니다.
그 외에는 deserialized를 value로 설정합니다.

기능 매칭 시, "webauthn:virtualAuthenticators"를 value로 매칭하는 확장 전용 단계는 다음과 같습니다:

value가 true이고 엔드포인트 노드가 가상 인증자 명령을 하나도 지원하지 않으면, 매칭은 실패입니다.
그 외에는 매칭 성공입니다.

11.1.1. 인증자 확장 기능

추가적으로, 본 명세에서 정의된 모든 인증자 확장(즉, 인증자 확장 처리를 정의한 것)에 대해 확장 기능(capability)도 정의됩니다:

기능	키	값 타입	설명
사용자 검증 방식 확장 지원	`"webauthn:extension:uvm"`	boolean	엔드포인트 노드의 WebAuthn WebDriver 구현이 사용자 검증 방식 확장을 지원하는지 여부.
대용량 blob 저장 확장 지원	`"webauthn:extension:largeBlob"`	boolean	엔드포인트 노드의 WebAuthn WebDriver 구현이 largeBlob 확장을 지원하는지 여부.

기능 검증 시, 인증자 확장 기능(authenticator extension capability) key와 value를 검증하는 확장 전용 하위 단계는 다음과 같습니다:

value가 boolean이 아니면, WebDriver 오류와 WebDriver 오류 코드 invalid argument를 반환합니다.
그 외에는 deserialized를 value로 설정합니다.

기능 매칭 시, 인증자 확장 기능(authenticator extension capability) key와 value를 매칭하는 확장 전용 단계는 다음과 같습니다:

value가 true이고 엔드포인트 노드의 WebAuthn WebDriver 구현이 key로 식별되는 인증자 확장을 지원하지 않으면, 매칭은 실패입니다.
그 외에는 매칭 성공입니다.

정의된 인증자 확장을 구현하는 유저 에이전트는 대응하는 인증자 확장 기능을 구현해야 합니다.

11.2. 가상 인증자

이 WebDriver 확장 명령어는 가상 인증자를 생성·조작합니다. 가상 인증자는 인증자 모델의 소프트웨어 구현체입니다. 가상 인증자들은 가상 인증자 데이터베이스에 저장됩니다. 저장된 각 가상 인증자는 다음 속성을 갖습니다:

authenticatorId

Appendix A [RFC3986]의 unreserved 생성 규칙에 따른 최대 48글자의 널이 아닌 문자열로, 가상 인증자를 고유하게 식별합니다.

protocol

가상 인증자가 사용하는 프로토콜: "ctap1/u2f", "ctap2", "ctap2_1" 중 하나([FIDO-CTAP] 참고).

transport

시뮬레이션하는 AuthenticatorTransport 값. transport가 internal이면 인증자는 플랫폼 연결을 시뮬레이션합니다. 그 외에는 크로스 플랫폼 연결을 시뮬레이션합니다.

hasResidentKey

true로 설정하면 인증자가 클라이언트 측 발견 가능한 자격증명을 지원합니다.

hasUserVerification

true로 설정하면 인증자가 사용자 검증을 지원합니다.

isUserConsenting

모든 사용자 동의 인가 제스처 및 사용자 존재 확인 결과를 결정합니다. true면 사용자 동의가 항상 허용됩니다. false면 허용되지 않습니다.

isUserVerified

가상 인증자에서 사용자 검증 결과를 결정합니다. true면 검증이 항상 성공, false면 실패합니다.

참고: hasUserVerification이 false면 이 속성은 아무 효과가 없습니다.

extensions

가상 인증자가 지원하는 확장 식별자 문자열 배열.

가상 인증자는 extensions 배열에 포함된 모든 인증자 확장을 반드시 지원해야 합니다. 배열에 없는 인증자 확장은 지원해서는 안 됩니다.

uvm

UvmEntries 배열로, 사용자 검증 방식 확장 처리 시 인증자 확장 출력으로 설정됩니다.

참고: 해당 가상 인증자가 사용자 검증 방식 확장을 지원하지 않으면 본 속성은 아무 효과가 없습니다.

11.3. 가상 인증자 추가

가상 인증자 추가 WebDriver 확장 명령어는 소프트웨어 가상 인증자를 생성합니다. 정의는 다음과 같습니다:

HTTP 메서드	URI 템플릿
POST	`/session/{session id}/webauthn/authenticator`

인증자 구성은 JSON 객체로, 원격 엔드 단계에 parameters로 전달됩니다. 다음 key와 value 쌍을 포함합니다:

키	값 타입	유효 값	기본값
`protocol`	string	`"ctap1/u2f"`, `"ctap2"`, `"ctap2_1"`	없음
`transport`	string	`AuthenticatorTransport` 값	없음
`hasResidentKey`	boolean	`true`, `false`	`false`
`hasUserVerification`	boolean	`true`, `false`	`false`
`isUserConsenting`	boolean	`true`, `false`	`true`
`isUserVerified`	boolean	`true`, `false`	`false`
`extensions`	string 배열	확장 식별자를 포함하는 배열	빈 배열
`uvm`	`UvmEntries`	최대 3개의 사용자 검증 방식 엔트리	빈 배열

원격 엔드 단계는 다음과 같습니다:

parameters가 JSON 객체가 아니면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.

참고: parameters는 인증자 구성 객체입니다.
authenticator를 새 가상 인증자로 설정합니다.
parameters의 각 enumerable 자체 속성에 대해:
1. key를 속성명으로 설정합니다.
2. value를 속성 획득의 결과로 설정합니다.
3. parameters에 key에 해당하는 key가 없으면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
4. value가 해당 key의 valid values 중 하나가 아니면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
5. 속성 설정을 통해 key를 value로 authenticator에 설정합니다.
인증자 구성의 각 기본값 정의 속성에 대해:
1. key가 authenticator의 정의된 속성이 아니면, 속성 설정을 통해 key를 default로 authenticator에 설정.
인증자 구성의 각 속성에 대해:
1. key가 authenticator의 정의된 속성이 아니면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticator.extensions의 각 extension에 대해:
1. extension이 확장 식별자 중 해당 엔드포인트 노드 WebAuthn WebDriver 구현이 지원하지 않는 값이면, WebDriver 오류와 WebDriver 오류 코드 unsupported operation 반환.
유효한 고유 authenticatorId를 생성합니다.
속성 설정을 통해 authenticatorId를 authenticatorId로 authenticator에 설정.
authenticator를 가상 인증자 데이터베이스에 저장합니다.
성공을 authenticatorId 데이터와 함께 반환합니다.

11.4. 가상 인증자 제거

가상 인증자 제거 WebDriver 확장 명령어는 기존에 생성된 가상 인증자를 제거합니다. 정의는 다음과 같습니다:

HTTP 메서드	URI 템플릿
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}`

원격 엔드 단계는 다음과 같습니다:

authenticatorId가 가상 인증자 중 가상 인증자 데이터베이스에 저장된 값과 일치하지 않으면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticatorId로 식별되는 가상 인증자를 가상 인증자 데이터베이스에서 제거합니다.
성공을 반환합니다.

11.5. 자격증명 추가

자격증명 추가 WebDriver 확장 명령어는 공개키 자격증명 소스를 기존 가상 인증자에 주입합니다. 정의는 다음과 같습니다:

HTTP 메서드	URI 템플릿
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credential`

자격증명 파라미터는 JSON 객체로, 원격 엔드 단계에 parameters로 전달됩니다. 다음 key와 value 쌍을 포함합니다:

키	설명	값 타입
`credentialId`	Credential ID를 Base64url 인코딩으로 인코딩한 값.	string
`isResidentCredential`	`true`면 클라이언트 측 발견 가능한 자격증명을 생성. `false`면 서버 측 자격증명을 생성.	boolean
`rpId`	자격증명이 스코프되는 Relying Party ID.	string
`privateKey`	개인키 하나가 들어있는 비대칭 키 패키지 ([RFC5958]), Base64url 인코딩 적용.	string
`userHandle`	자격증명과 연관된 userHandle을 Base64url 인코딩으로 인코딩. 생략 가능.	string
`signCount`	자격증명에 연관된 서명 카운터의 초기값.	number
`largeBlob`	대용량 자격증명별 blob (공개키 자격증명 소스에 연관), Base64url 인코딩 적용. 생략 가능.	string

원격 엔드 단계는 다음과 같습니다:

parameters가 JSON 객체가 아니면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.

참고: parameters는 자격증명 파라미터 객체입니다.
credentialId를 parameters의 credentialId 속성을 Base64url 디코딩한 결과로 설정.
credentialId가 실패면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
isResidentCredential를 parameters의 isResidentCredential 속성으로 설정.
isResidentCredential가 정의되지 않으면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
rpId를 parameters의 rpId 속성으로 설정.
rpId가 유효한 RP ID가 아니면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
privateKey를 parameters의 privateKey 속성을 Base64url 디코딩한 결과로 설정.
privateKey가 실패면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
privateKey가 RFC5958에 따른 P-256 곡선의 ECDSA 개인키 단일 값으로 올바르게 인코딩되지 않으면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
parameters의 userHandle 속성이 정의되어 있으면:
1. userHandle를 parameters의 userHandle 속성을 Base64url 디코딩한 결과로 설정.
2. userHandle가 실패면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
그 외에는:
1. isResidentCredential가 true면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
2. userHandle를 null로 설정.
authenticatorId가 가상 인증자 중 가상 인증자 데이터베이스에 저장된 값과 일치하지 않으면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticator를 authenticatorId와 일치하는 가상 인증자로 설정.
isResidentCredential가 true이고 authenticator의 hasResidentKey 속성이 false면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticator가 largeBlob 확장을 지원하고 parameters의 largeBlob이 정의되어 있으면:
1. largeBlob를 parameters의 largeBlob 속성을 Base64url 디코딩한 결과로 설정.
2. largeBlob가 실패면 WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
그 외에는:
1. largeBlob를 null로 설정.
credential을 다음 값으로 새로 생성: 클라이언트 측 발견 가능한 공개키 자격증명 소스 (isResidentCredential가 true일 때) 또는 서버 측 공개키 자격증명 소스 (그 외)로, 각 항목은 다음과 같음:

type

public-key

id

credentialId

privateKey

privateKey

rpId

rpId

userHandle

userHandle
credential에 서명 카운터 counter를 연결하며, 초기값은 parameters의 signCount 혹은 0(signCount가 null일 때).
largeBlob가 null이 아니면, 해당 대용량 자격증명별 blob을 credential에 설정.
credential 및 counter를 authenticator의 데이터베이스에 저장.
성공 반환.

11.6. 자격증명 가져오기

자격증명 가져오기 WebDriver 확장 명령어는 해당 가상 인증자에 저장된 모든 공개키 자격증명 소스에 대해 각각 자격증명 파라미터 객체를 반환합니다. 이 객체들은 자격증명 추가나 navigator.credentials.create()로 저장된 것 모두 포함합니다. 정의는 아래와 같습니다:

HTTP 메서드	URI 템플릿
GET	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

원격 엔드 단계는 다음과 같습니다:

authenticatorId가 가상 인증자 중 가상 인증자 데이터베이스에 저장된 값과 일치하지 않으면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
credentialsArray를 빈 배열로 생성합니다.
authenticatorId로 식별되는 인증자가 관리하는 각 공개키 자격증명 소스 credential에 대해, 해당 자격증명 파라미터 객체를 생성해 credentialsArray에 추가합니다.
성공을 credentialsArray 데이터를 포함해 반환합니다.

11.7. 자격증명 제거

자격증명 제거 WebDriver 확장 명령어는 가상 인증자에 저장된 공개키 자격증명 소스 하나를 제거합니다. 정의는 아래와 같습니다:

HTTP 메서드	URI 템플릿
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials/{credentialId}`

원격 엔드 단계는 다음과 같습니다:

authenticatorId가 가상 인증자 중 가상 인증자 데이터베이스에 저장된 값과 일치하지 않으면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticator를 authenticatorId로 식별되는 가상 인증자로 설정합니다.
credentialId가 authenticator가 관리하는 공개키 자격증명 소스 중 어느 것과도 일치하지 않으면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticator가 관리하는 credentialId로 식별되는 공개키 자격증명 소스를 제거합니다.
성공 반환.

11.8. 모든 자격증명 제거

모든 자격증명 제거 WebDriver 확장 명령어는 해당 가상 인증자에 저장된 모든 공개키 자격증명 소스를 제거합니다. 정의는 아래와 같습니다:

HTTP 메서드	URI 템플릿
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

원격 엔드 단계는 다음과 같습니다:

authenticatorId가 가상 인증자 중 가상 인증자 데이터베이스에 저장된 값과 일치하지 않으면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticatorId로 식별되는 가상 인증자가 관리하는 모든 공개키 자격증명 소스를 제거합니다.
성공 반환.

11.9. 사용자 검증 상태 설정

사용자 검증 상태 설정 확장 명령어는 해당 가상 인증자의 isUserVerified 속성을 설정합니다. 정의는 아래와 같습니다:

HTTP 메서드	URI 템플릿
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/uv`

원격 엔드 단계는 다음과 같습니다:

parameters가 JSON 객체가 아니면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticatorId가 가상 인증자 중 가상 인증자 데이터베이스에 저장된 값과 일치하지 않으면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
isUserVerified가 parameters에 정의된 속성이 아니면, WebDriver 오류와 WebDriver 오류 코드 invalid argument 반환.
authenticator를 authenticatorId로 식별되는 가상 인증자로 설정.
authenticator의 isUserVerified 속성을 parameters의 isUserVerified 값으로 설정합니다.
성공 반환.

12. IANA 관련 사항

12.1. WebAuthn 인증 증명문 형식 식별자 등록 업데이트

이 절은 IANA "WebAuthn Attestation Statement Format Identifiers" 레지스트리 [IANA-WebAuthn-Registries]([RFC8809] 제정, [WebAuthn-1]에서 최초 등록)에 등록된 아래 인증 증명문 형식을 현행 표준의 § 8 정의된 인증 증명문 형식에 따라 업데이트합니다.

WebAuthn 인증 증명문 형식 식별자: packed
설명: "packed" 인증 증명문 형식은 WebAuthn에 최적화된 인증 증명 형식이며, 매우 간결하면서도 확장 가능한 인코딩 방식을 사용합니다. 이 형식은 자원이 제한된 인증자(예: 보안 요소)에서도 구현 가능합니다.
명세 문서: 현행 표준 § 8.2 Packed 인증 증명문 형식
WebAuthn 인증 증명문 형식 식별자: tpm
설명: TPM 인증 증명문 형식은 packed 인증 증명문 형식과 동일한 형식을 반환하지만, rawData 및 signature 필드 계산 방식이 다릅니다.
명세 문서: 현행 표준 § 8.3 TPM 인증 증명문 형식
WebAuthn 인증 증명문 형식 식별자: android-key
설명: 버전 "N" 이상 플랫폼 인증자가 이 독점적 "하드웨어 인증" 증명문을 제공할 수 있습니다.
명세 문서: 현행 표준 § 8.4 Android Key 인증 증명문 형식
WebAuthn 인증 증명문 형식 식별자: android-safetynet
설명: Android 기반 플랫폼 인증자는 Android SafetyNet API 기반 인증 증명문을 생성할 수 있습니다.
명세 문서: 현행 표준 § 8.5 Android SafetyNet 인증 증명문 형식
WebAuthn 인증 증명문 형식 식별자: fido-u2f
설명: FIDO U2F 인증자에서 사용
명세 문서: 현행 표준 § 8.6 FIDO U2F 인증 증명문 형식

12.2. WebAuthn 인증 증명문 형식 식별자 신규 등록

이 절은 IANA "WebAuthn Attestation Statement Format Identifiers" 레지스트리 [IANA-WebAuthn-Registries]([RFC8809] 제정)에 § 8 정의된 인증 증명문 형식에서 새롭게 정의된 아래 인증 증명문 형식을 등록합니다.

WebAuthn 인증 증명문 형식 식별자: apple
설명: Apple 기기의 플랫폼 인증자에서 사용
명세 문서: 현행 표준 § 8.8 Apple 익명 인증 증명문 형식
WebAuthn 인증 증명문 형식 식별자: none
설명: WebAuthn Relying Party가 인증 정보를 받지 않겠다고 표시할 때, 인증자가 제공하는 모든 인증 증명문을 대체하는 용도.
명세 문서: 현행 표준 § 8.7 None 인증 증명문 형식

12.3. WebAuthn 확장 식별자 등록 업데이트

이 절은 IANA "WebAuthn Extension Identifiers" 레지스트리 [IANA-WebAuthn-Registries]([RFC8809] 제정, [WebAuthn-1]에서 최초 등록)에 등록된 아래 확장 식별자 값을 현행 표준의 § 10 정의된 확장에 따라 업데이트합니다.

WebAuthn 확장 식별자: appid
설명: 이 인증 확장은 WebAuthn Relying Party가 FIDO JavaScript API로 등록한 자격증명을 assertion 요청에 사용할 수 있게 합니다.
명세 문서: 현행 표준 § 10.1 FIDO AppID 확장(appid)
WebAuthn 확장 식별자: uvm
설명: 이 등록 확장 및 인증 확장은 사용자 검증 방식을 사용할 수 있게 합니다. 사용자 검증 방식 확장은 WebAuthn 동작에 사용된 사용자 검증 방식(요소)을 WebAuthn Relying Party에 반환합니다.
명세 문서: 현행 표준 § 10.3 사용자 검증 방식 확장(uvm)

12.4. WebAuthn 확장 식별자 신규 등록

이 절은 IANA "WebAuthn Extension Identifiers" 레지스트리 [IANA-WebAuthn-Registries]([RFC8809] 제정)에 § 10 정의된 확장에서 새로 정의한 아래 확장 식별자 값을 등록합니다.

WebAuthn 확장 식별자: appidExclude
설명: 이 등록 확장은 WebAuthn Relying Party가 FIDO U2F JavaScript API로 생성한 특정 자격증명을 가진 인증자를 제외할 수 있게 합니다.[FIDOU2FJavaScriptAPI]
명세 문서: 현행 표준 § 10.2 FIDO AppID 제외 확장(appidExclude)
WebAuthn 확장 식별자: credProps
설명: 이 클라이언트 등록 확장은 새로 생성된 자격증명의 속성을 클라이언트에서 판단하여 호출한 WebAuthn Relying Party의 웹 애플리케이션에 보고할 수 있게 합니다.
명세 문서: 현행 표준 § 10.4 자격증명 속성 확장(credProps)
WebAuthn 확장 식별자: largeBlob
설명: 이 클라이언트 등록 확장 및 인증 확장은 Relying Party가 자격증명에 연관된 불투명 데이터를 저장할 수 있게 합니다.
명세 문서: 현행 표준 § 10.5 대용량 blob 저장 확장(largeBlob)

13. 보안 고려사항

본 명세는 웹 API 및 암호학적 피어 엔티티 인증 프로토콜을 정의합니다. Web Authentication API는 웹 개발자("작성자")가 등록 및 인증 절차에서 Web Authentication 프로토콜을 활용할 수 있게 합니다. Web Authentication 프로토콜의 엔드포인트는 사용자가 제어하는 WebAuthn 인증자와 WebAuthn Relying Party의 컴퓨팅 환경(해당 Relying Party의 웹 애플리케이션을 호스팅)입니다. 이 모델에서, 유저 에이전트와 WebAuthn 클라이언트는 인증자와 Relying Party 사이의 중개자 역할을 합니다. 또한, 인증자는 인증 증명을 통해 Relying Party에 자신이 어디서 왔는지 입증할 수 있습니다.

현 시점에서 본 명세는 상세한 보안 고려사항을 제공하지 않습니다. 하지만 [FIDOSecRef] 문서는 본 명세에 전반적으로 적용 가능한 보안 분석을 제공합니다. 또한 [FIDOAuthnrSecReqs] 문서군은 인증자 보안 특성에 대한 유용한 정보를 제공합니다.

아래 하위 절들은 Web Authentication 관련 보안 고려사항을 담고 있습니다. 대상별로 나누어져 있으며, 일반 보안 고려사항은 이 절의 직접 하위 절로, 인증자, 클라이언트, Relying Party 구현자 대상은 각각 별도 하위 절에 정리됩니다.

13.1. 자격증명 ID 미서명

자격증명 ID는 서명되지 않습니다. 이는 문제되지 않습니다. 인증자가 잘못된 자격증명 ID를 반환하거나 공격자가 자격증명 ID를 가로채 조작하더라도 WebAuthn Relying Party는 올바른 자격증명 공개키를 찾아 authenticator data(즉, assertion)의 서명을 검증할 수 없으므로, 상호작용은 오류로 종료됩니다.

13.2. 클라이언트와 인증자의 물리적 근접성

WebAuthn 인증자 모델에서는 일반적으로 로밍 인증자가 클라이언트와 물리적으로 가깝고 직접 통신한다고 가정합니다. 이 구성은 중요한 장점이 있습니다.

클라이언트와 인증자의 물리적 근접성은 보유기반(something you have) 인증 요소의 핵심 강점입니다. 예를 들어 로밍 인증자가 USB 또는 블루투스만 지원할 경우, 해당 트랜스포트의 제한된 범위 내에 악의적 행위자가 실제로 존재해야만 인증자와 상호작용이 가능합니다. 원격 호출 가능한 인증자는 이러한 제한이 없으므로, 인증자가 사용자 존재를 검증하더라도, 사용자가 원격에서 시작된 악의적 요청을 승인하도록 속일 수 있습니다.

클라이언트와 인증자의 직접 통신은 클라이언트가 스코프 제한을 직접 적용할 수 있게 해줍니다. 반대로, 클라이언트와 인증자 간 통신이 제3자에 의해 중개되면 클라이언트는 해당 제3자가 스코프 제한 및 인증자 접근 제어를 올바르게 수행한다고 신뢰해야 합니다. 이를 제대로 하지 않을 경우, 악의적 Relying Party가 다른 Relying Party에 유효한 인증 어서션을 받거나, 악의적 사용자가 다른 사용자의 인증 어서션에 접근할 수 있습니다.

만약 인증자가 클라이언트와 물리적으로 근접할 필요가 없거나, 클라이언트와 인증자가 직접 통신하지 않아도 되는 솔루션을 설계한다면, 설계자는 스코프 제한 적용 및 인증자가 보유기반 인증 요소로서의 강도에 미치는 영향을 반드시 고려해야 합니다.

13.3. 인증자 보안 고려사항

13.3.1. 인증 증명서 계층 구조

인증 증명서에는 3계층 구조(즉, 증명서 루트, 증명서 발급 CA, 증명서) 사용을 권장합니다. 각 WebAuthn 인증자 모델(라인)별로 별도의 발급 CA를 사용하는 것이 바람직하며, 이는 특정 버전의 인증자 모델에 문제가 발생했을 때 격리하기 용이하게 해줍니다.

증명서 루트가 단일 WebAuthn 인증자 모델(AAGUID)에 한정되지 않을 경우, AAGUID를 인증 증명서 자체에 포함해 인증자 데이터와 대조할 수 있도록 해야 합니다.

13.3.2. 인증 증명서 및 인증 증명서 CA 해킹/유출

인증 증명서 발급에 사용된 중간 CA 또는 루트 CA가 해킹 또는 유출된 경우, WebAuthn 인증자 인증 키 쌍 자체는 안전하지만 해당 증명서는 더 이상 신뢰할 수 없습니다. WebAuthn 인증자 제조사가 해당 모델의 인증 공개키를 기록해 두었다면, 새 중간 CA 또는 루트 CA로부터 해당 키에 대한 새 인증 증명서를 발급할 수 있습니다. 루트 CA가 변경될 경우, WebAuthn Relying Parties는 신뢰하는 루트 인증서를 반드시 갱신해야 합니다.

WebAuthn 인증자 인증 증명서의 개인키가 유출된 경우, 발급 CA는 반드시 해당 증명서를 폐기(revoke)해야 합니다. WebAuthn 인증자 제조사는 펌웨어 업데이트를 통해 이미 제조된 인증자에 새 개인키 및 증명서를 주입할 수 있어야 하며, (주입 과정은 본 명세 범위에 포함되지 않음) 만약 제조사가 이에 대한 능력이 없다면, 해당 인증자에서 발급된 인증 증명문을 더 이상 신뢰할 수 없습니다.

Relying Party의 관련 보안 고려사항은 § 13.4.5 폐기된 인증 증명서를 참조하세요.

13.4. Relying Party 보안 고려사항

13.4.1. WebAuthn Relying Party를 위한 보안 이점

본 명세가 WebAuthn Relying Party에 제공하는 주요 이점은 다음과 같습니다:

사용자 및 계정을 광범위하게 호환되며 사용이 쉬운 다요소 인증으로 보호할 수 있습니다.
Relying Party는 사용자에게 인증자 하드웨어를 별도로 제공할 필요가 없습니다. 대신 각 사용자가 원하는 인증자를 따로 구입해, 동일 인증자를 여러 Relying Party에서 사용할 수 있습니다. Relying Party는 선택적으로 인증자의 보안 특성에 대한 요구사항을, 인증자에서 반환하는 인증 증명문을 검사하여 적용할 수 있습니다.
인증 절차는 중간자 공격(man-in-the-middle attack)에 강합니다. 등록 절차 관련 사항은 아래 § 13.4.4 인증 증명 제한 참고.
Relying Party는 여러 사용자 검증 방식(예: PIN, 생체인식, 그리고 미래 방식 등)을 거의 코드 변경 없이 자동으로 지원할 수 있으며, 각 사용자가 인증자 선택을 통해 선호하는 검증 방식을 자유롭게 사용할 수 있습니다.
Relying Party는 위의 혜택을 얻기 위해 별도의 비밀을 저장할 필요가 없습니다.

적합성 절에서 언급했듯, Relying Party는 위 이점을 모두 얻으려면 § 7 WebAuthn Relying Party 동작에 따라 행동해야 합니다. 다만, 아래 § 13.4.4 인증 증명 제한에 약간 벗어난 사례가 있습니다.

13.4.2. 임베디드 사용 시 가시성 고려사항

WebAuthn을 임베디드 환경(예: § 5.10 iframe 요소 내 Web Authentication 사용 참고)에서 단순하게 사용하면, iframe 등에서 UI 변조 공격(Clickjacking)에 취약해질 수 있습니다. 공격자는 자신의 UI를 Relying Party가 의도한 UI 위에 오버레이 해, 사용자가 Relying Party에서 의도하지 않은 행동을 하도록 속일 수 있습니다. 예를 들어, 이런 기법으로 사용자를 속여 상품 구매, 송금 등의 행위를 하게 할 수 있습니다.

WebAuthn 관련 UI는 일반적으로 클라이언트 플랫폼에서 처리하므로 UI 변조에 취약하지 않지만, WebAuthn을 임베디드로 사용하는 Relying Party는 자신의 UI가 사용자에게 명확히 보이도록 주의해야 합니다. 최근에는 실험적 Intersection Observer v2의 isVisible 속성 상태를 활용하는 방법이 등장하고 있습니다. 예를 들어, 임베디드 환경 내 Relying Party 스크립트는 isVisble가 false가 되면, 선제적으로 팝업 창에서 자신을 로드해 콘텐츠가 가려지는 상황을 피할 수 있습니다.

13.4.3. 암호학적 챌린지

암호학적 프로토콜로서 Web Authentication은 리플레이 공격을 방지하기 위해 무작위 챌린지에 의존합니다. 따라서 PublicKeyCredentialCreationOptions.challenge 및 PublicKeyCredentialRequestOptions.challenge 값은 반드시 Relying Party가 신뢰하는 환경(예: 서버)에서 무작위로 생성해야 하며, 클라이언트가 반환하는 challenge 값은 반드시 생성한 값과 일치해야 합니다. 이 작업은 클라이언트 동작에 의존하지 않게, 예를 들면 Relying Party가 작업 완료 시까지 챌린지를 임시로 저장하는 방식으로 처리해야 합니다. 챌린지 불일치 허용 시 프로토콜의 보안이 손상됩니다.

리플레이 공격 방지를 위해 챌린지는 충분한 엔트로피를 가져야 하며, 16바이트 이상 길이가 바람직합니다.

13.4.4. 인증 증명 한계

이 절은 규범적(normative)이지 않습니다.

새 자격증명 등록 시, 인증 증명문이 있으면 WebAuthn Relying Party가 다양한 인증자 특성에 대해 보증을 얻을 수 있습니다. 예를 들어 인증자 모델, 또는 자격증명 개인키 저장 및 보호 방식 등입니다. 그러나 인증 증명문만으로는 Relying Party가 인증 증명 객체가 사용자가 의도한 인증자에서 생성된 것인지, 또는 중간자 공격자(man-in-the-middle attacker)에 의해 생성된 것인지 확인할 방법은 없습니다. 예를 들어 공격자가 악의적 코드를 Relying Party 스크립트에 주입할 수 있습니다. 따라서 Relying Party는 TLS 등 관련 기술을 활용해 인증 증명 객체를 중간자 공격으로부터 보호해야 합니다.

등록 절차가 안전하게 완료되고, 인증자가 자격증명 개인키의 기밀성을 유지한다면, 해당 공개키 자격증명을 사용하는 이후 인증 절차는 중간자 공격에 강합니다.

상기 논의는 모든 인증 증명 유형에 해당합니다. 모든 경우 중간자 공격자가 PublicKeyCredential 객체(인증 증명문 및 등록될 자격증명 공개키 포함)를 바꾼 뒤 해당 Relying Party에 스코프된 이후의 인증 어서션도 조작할 수 있습니다.

이런 공격은 탐지 가능할 수 있습니다. Relying Party가 사용자의 것이 아닌 공격자의 자격증명 공개키를 등록했으므로, 공격자는 해당 Relying Party에 대한 모든 이후 인증 절차를 반드시 조작해야 하며, 정상적인 절차는 실패하여 공격 사실이 드러날 수 있습니다.

인증 유형 중 자체 인증 및 없음 이외의 유형은 이러한 공격의 난이도를 높일 수 있습니다. 이는 신뢰 당사자가 사용자에게 인증기 정보(예: 모델 명칭)를 표시할 수 있기 때문입니다. 따라서 공격자는 사용자의 인증기와 동일한 모델의 진짜 인증기를 사용해야 할 수도 있으며, 또는 사용자가 신뢰 당사자가 보고하는 인증기 모델이 예상과 다르다는 것을 알아챌 수 있습니다.

참고: 위에서 설명한 모든 중간자 공격은 기존 비밀번호 인증에 대한 중간자 공격에 비해 공격자가 실행하기 훨씬 어렵습니다.

13.4.5. 폐기된 인증 증명서

인증 증명서 검증이 중간 인증 CA 증명서 폐기 때문에 실패하고, Relying Party 정책이 이 경우 등록/인증 요청을 거부하도록 요구한다면, Relying Party는 해당 중간 CA가 해킹된 이후 발급된, 같은 CA 체인에 속한 공개키 자격증명도 등록 해제하거나 "자기 인증"과 동등한 신뢰 수준으로 표시하는 것이 좋습니다. 이를 위해 Relying Party는 등록 시 중간 인증 CA 증명서를 기억해두고, 이후 해당 증명서가 폐기된 뒤에 등록된 관련 공개키 자격증명을 등록 해제할 수 있어야 합니다.

관련 인증자 보안 고려사항은 § 13.3.2 인증 증명서 및 인증 증명서 CA 해킹/유출 참고.

13.4.6. 자격증명 분실 및 키 이동성

본 명세는 자격증명 개인키 백업이나 여러 인증자 간 공유 프로토콜을 정의하지 않습니다. 일반적으로 자격증명 개인키는 생성한 인증자를 떠나지 않습니다. 인증자를 분실하면, 해당 인증자에 바인딩된 모든 자격증명도 함께 분실하게 되므로, 한 개의 자격증명만 등록되어 있으면 계정 접근이 불가능해질 수 있습니다. 개인키 백업·공유 대신 Web Authentication API는 동일 사용자에 대해 여러 자격증명을 등록할 수 있도록 지원합니다. 예를 들어 사용자는 자주 사용하는 클라이언트 기기에는 플랫폼 자격증명을, 백업·새 기기·드물게 쓰는 클라이언트 기기에는 로밍 자격증명을 등록할 수 있습니다.

Relying Party는 사용자가 동일 계정에 여러 자격증명을 등록할 수 있게 허용·권장해야 하며, excludeCredentials 및 user.id 옵션을 활용해 각 자격증명이 서로 다른 인증자에 바인딩되도록 해야 합니다.

13.4.7. 보호되지 않은 계정 탐지

이 절은 규범적(normative)이지 않습니다.

이 보안 고려사항은 인증 절차의 첫 단계에서 비-빈 allowCredentials 인자를 사용하는 Relying Party에 적용됩니다. 예를 들어, 첫 인증 단계로 서버 측 자격증명 인증을 사용하는 경우입니다.

이 경우 allowCredentials 인자는 어떤 사용자 계정에 WebAuthn 자격증명이 등록되어 있는지, 없는지에 대한 정보를 누설할 위험이 있습니다. 이는 계정 보호 강도에 대한 신호가 될 수 있습니다. 예를 들어 공격자가 단지 사용자 이름만으로 인증 절차를 시작할 수 있고, Relying Party가 일부 사용자에게는 비어있지 않은 allowCredentials을, 다른 사용자에게는 실패 또는 비밀번호 챌린지를 반환하면, 공격자는 후자의 계정이 WebAuthn assertion이 없어도 인증 가능하다고 추정하고, 더 취약한 계정에 공격을 집중할 수 있습니다.

이 문제는 § 14.6.2 사용자명 열거 및 § 14.6.3 자격증명 ID를 통한 개인정보 누출에서 설명한 것과 유사하며, 유사한 방식으로 완화할 수 있습니다.

14. 프라이버시 고려사항

[FIDO-Privacy-Principles]의 프라이버시 원칙은 이 명세에도 적용됩니다.

이 절은 대상별로 나뉘어 있습니다; 일반 프라이버시 고려사항은 이 절의 직접 하위 절로, 인증자, 클라이언트, Relying Party 구현자 대상은 각각 별도 하위 절에 정리됩니다.

14.1. 비식별화 방지 조치

이 절은 규범적(normative)이지 않습니다.

Web Authentication API 설계의 많은 부분은 프라이버시 우려에서 비롯되었습니다. 본 명세에서 고려한 주요 우려는 사용자의 개인적 신원, 즉 인간 개인의 식별 또는 별도 신원들의 동일인 연관입니다. Web Authentication API는 어떠한 형태의 글로벌 신원을 사용하거나 제공하지 않지만, 다음과 같은 잠재적으로 상호 연관 가능한 식별자가 사용됩니다:

사용자의 자격증명 ID 및 자격증명 공개키.

이 값들은 WebAuthn Relying Party에 등록되고, 이후 사용자가 해당 자격증명 개인키 소유를 증명하는 데 사용합니다. 또한 클라이언트와 인증자 간 통신에서도 보입니다.
각 Relying Party별 사용자의 신원, 예: 사용자명 및 user handle.

각 Relying Party가 자기 시스템 내에서 사용자 식별에 사용합니다. 또한 클라이언트와 인증자 통신에도 보입니다.
사용자의 생체 정보, 예: 지문, 얼굴 인식 데이터 [ISOBiometricVocabulary].

이는 인증자가 사용자 검증에 선택적으로 사용합니다. Relying Party에는 공개되지 않지만, 플랫폼 인증자의 경우 구현에 따라 클라이언트에 보일 수 있습니다.
사용자 인증자의 모델(예: 제품명).

이는 Relying Party에 인증 증명문으로 노출됩니다. 또한 클라이언트와 인증자 통신에도 보입니다.
사용자 인증자의 식별 정보(예: 일련번호).

이는 클라이언트가 인증자와 통신할 때 사용될 수 있으나, Relying Party에는 노출되지 않습니다.

상기 정보 중 일부는 Relying Party와 반드시 공유됩니다. 다음 절에서는 악의적 Relying Party가 사용자의 개인 신원을 알아내지 못하도록 하는 방안을 설명합니다.

14.2. 익명·스코프·비연관화 공개키 자격증명

이 절은 규범적(normative)이지 않습니다.

자격증명 ID 및 자격증명 공개키는 강력한 인증을 위해 WebAuthn Relying Party와 반드시 공유되지만, 최소한의 식별만 가능하도록 설계되었으며 Relying Party 간에는 공유되지 않습니다.

자격증명 ID와 자격증명 공개키는 각각 자격증명 키 쌍만 식별할 뿐, 사용자를 직접 식별하지는 않습니다.
각 공개키 자격증명은 특정 Relying Party에만 스코프되며, 클라이언트가 해당 존재를 다른 Relying Party에 노출하지 않게 보장합니다. 악의적 Relying Party는 클라이언트에 사용자의 다른 신원을 요청해 알아낼 수 없습니다.
클라이언트는 또한 공개키 자격증명의 존재를 Relying Party에게 사용자 동의 없이 노출하지 않도록 합니다. 이는 § 14.5.1 등록 절차 프라이버시 및 § 14.5.2 인증 절차 프라이버시에서 더 자세히 다룹니다. 악의적 Relying Party는 사용자가 공개키 자격증명을 등록·보유하더라도 이를 몰래 식별할 수 없습니다.
인증자는 서로 다른 공개키 자격증명의 자격증명 ID와 자격증명 공개키가 동일 사용자에게 속하지 않도록 상호 연관 불가하게 합니다. 악의적 Relying Party들이 추가 정보(예: 반복 사용하는 사용자명, 이메일 주소) 없이 사용자를 연결할 수 없습니다.
인증자는 인증 증명서가 단일 인증자 또는 소수의 인증자를 식별하지 못하도록 충분히 비식별적으로 만듭니다. 이는 § 14.4.1 인증 증명 프라이버시에서 더 자세히 다룹니다. 악의적 Relying Party들은 개별 인증자 추적으로 사용자를 연관지을 수 없습니다.

또한, 클라이언트 측 발견 가능한 공개키 자격증명 소스에는 user handle을 옵션으로 포함할 수 있으며, 이는 Relying Party가 지정합니다. 자격증명으로 사용자를 식별·인증할 수 있습니다. 즉, 프라이버시를 중시하는 Relying Party는 전통적 사용자명 없이도 계정 생성이 가능해져, Relying Party 간 비연관성이 더욱 향상됩니다.

14.3. 인증자 로컬 생체 인식

생체 인증자는 생체 인식을 내부적으로 인증자 내에서 처리합니다(단, 플랫폼 인증자의 경우 구현에 따라 생체 데이터가 클라이언트에 보일 수 있음). 생체 데이터는 WebAuthn Relying Party에 공개되지 않으며, 로컬에서 사용자 검증을 통해 등록 및 인증 시에만 사용됩니다. 악의적 Relying Party는 생체 데이터를 통해 사용자의 신원을 알아낼 수 없고, Relying Party의 보안 침해 시에도 생체 데이터가 공격자에게 노출되어 다른 Relying Party 로그인 위조에 사용될 수 없습니다.

Relying Party가 생체 인식을 요구하는 경우, 이는 생체 인증자가 로컬에서 사용자 검증을 수행한 뒤, UV 플래그를 서명된 assertion 응답에 설정해 결과만 전달하며, 생체 데이터 자체는 Relying Party에 공개하지 않습니다.

14.4. 인증자 프라이버시 고려사항

14.4.1. 인증 증명 프라이버시

인증 증명서와 인증 키 쌍은 사용자를 추적하거나 동일 사용자의 여러 온라인 신원을 연결하는 데 사용될 수 있습니다. 여러 방법으로 완화할 수 있습니다:

WebAuthn 인증자 제조사는 인증자 여러 개가 동일 인증 증명서를 공유하는 배치(batches, 기본 인증 또는 배치 인증)로 출고할 수 있습니다. 이는 사용자를 익명화하지만, 인증 개인키가 유출될 경우 해당 증명서 폐기가 불가능하다는 위험이 있습니다. 제조사는 익명화 효과가 충분히 의미 있도록 배치 크기를 크게 하면서, 유출 시 영향받는 사용자 수를 줄이기 위해 배치 크기를 최소화해야 합니다.

[UAFProtocol]은 최소 100,000개의 인증자가 동일 인증 증명서를 공유해야 충분히 큰 그룹이 된다고 규정합니다. 이는 적절한 배치 크기 결정에 참고될 수 있습니다.
WebAuthn 인증자는 익명화 CA 방식을 사용해 각 자격증명마다 동적으로 다른 인증 키 쌍(및 연관 증명서)을 생성할 수 있습니다. 예를 들어, 인증자는 마스터 인증 개인키(및 증명서)와 클라우드 기반 익명화 CA를 조합해 각 자격증명마다 동적으로 인증 키 쌍 및 인증 증명서를 생성할 수 있습니다.

참고: 본 명세 외 다양한 맥락에서 "Privacy CA"라는 용어가 여기서 말하는 익명화 CA와 같은 의미로 쓰입니다. Trusted Computing Group(TCG)은 "Privacy CA"를 현재 "Attestation CA"(ACA) [TCG-CMCProfile-AIKCertEnroll]로 부르므로, 혼란을 줄이기 위해 본 명세에서는 "익명화 CA" 용어를 사용합니다.

14.4.2. 인증자에 저장된 개인정보 프라이버시

인증자는 명세 외의 추가 정보를 클라이언트에 제공할 수 있습니다(예: 사용자가 어떤 자격증명을 사용할지 고르는 UI 제공). 이 경우, 사용자 검증에 성공하지 않은 한 개인정보를 노출하지 않아야 합니다. 여러 사용자가 동시 등록된 인증자는 검증된 사용자를 제외한 개인정보를 노출하지 않아야 하며, 사용자 검증이 불가능한 인증자는 개인정보를 저장하지 않아야 합니다.

이 논의에서 user handle은 id 멤버로 전달되지만, PublicKeyCredentialUserEntity 기준으로는 개인정보로 간주하지 않습니다. § 14.6.1 User Handle 내용 참고.

이 권고는 물리적으로 인증자에 접근할 수 있는 공격자가 인증자에 등록된 사용자의 개인정보를 추출하는 것을 방지하려는 목적입니다.

14.5. 클라이언트 프라이버시 고려사항

14.5.1. 등록 절차 프라이버시

사용자가 동의 없이 식별되지 않도록, [[Create]](origin, options, sameOriginWithAncestors) 구현체는 악의적 WebAuthn Relying Party가 아래와 같은 경우를 구분하지 못하도록 정보 누출을 주의해야 합니다("제외됨"은 Relying Party가 excludeCredentials에 나열한 자격증명 중 하나 이상이 해당 인증자에 바인딩된 상태임을 의미):

인증자가 없음.
인증자가 하나 이상 있음, 그리고 그 중 하나 이상이 제외됨.

위 경우가 구분 가능하면, 악의적 Relying Party가 어떤 자격증명이 사용 가능한지 탐색하면서 사용자를 식별할 수 있습니다. 예를 들어, 클라이언트가 제외된 인증자가 사용 가능해지자마자 실패 응답을 반환하면, (특히 해당 인증자가 플랫폼 인증자라면) Relying Party가 타임아웃이나 사용자의 수동 취소 이전에 절차가 취소됐음을 감지하고, excludeCredentials에 나열된 자격증명 중 하나 이상이 실제로 사용 가능하다고 추론할 수 있습니다.

그러나 사용자가 명확히 동의한 뒤 구분 가능한 오류가 반환되는 경우에는, 이미 사용자가 해당 정보 공유 의사를 확인하였으므로 이 문제는 해당되지 않습니다.

14.5.2. 인증 절차 프라이버시

사용자가 동의 없이 식별되지 않도록, [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 구현체는 악의적 WebAuthn Relying Party가 아래와 같은 경우를 구분하지 못하도록 정보 누출을 주의해야 합니다("named"는 자격증명이 Relying Party가 allowCredentials에 나열한 것임을 의미):

named 자격증명이 사용 불가.
named 자격증명이 사용 가능하나 사용자가 동의하지 않음.

위 경우가 구분 가능하면, 악의적 Relying Party가 어떤 자격증명이 사용 가능한지 탐색하면서 사용자를 식별할 수 있습니다. 예를 들어, 사용자가 인증 절차 진행에 동의하지 않자마자 클라이언트가 실패 응답을 반환하면, Relying Party가 타임아웃이 아니라 사용자의 취소로 절차가 중단됐음을 감지하고, allowCredentials에 나열된 자격증명 중 하나 이상이 실제로 사용 가능하다고 추론할 수 있습니다.

14.5.3. 운영체제 계정 간 프라이버시

플랫폼 인증자가 다중 사용자 운영체제를 가진 클라이언트 기기에 포함된 경우, 플랫폼 인증자와 클라이언트 기기는 해당 플랫폼 자격증명의 존재가 오직 해당 자격증명을 생성한 운영체제 사용자에게만 노출되도록 협력해야 합니다.

14.6. Relying Party 프라이버시 고려사항

14.6.1. User Handle 내용

user handle은 § 14.4.2 인증자에 저장된 개인정보 프라이버시에서 개인정보로 간주되지 않으므로, Relying Party는 user handle에 이메일 주소, 사용자명 등 개인정보를 포함해서는 안 됩니다. 해시값 역시 salt가 Relying Party만 아는 값으로 섞이지 않았다면 포함할 수 없습니다. 해싱만으로 추측 가능한 입력값에 대한 탐색을 막을 수 없기 때문입니다. user handle은 64바이트 난수로 생성해 사용자의 계정에 저장하는 것이 좋습니다.

14.6.2. 사용자명 열거

등록 또는 인증 절차를 시작할 때 WebAuthn Relying Party가 등록된 사용자에 대한 민감한 정보를 누출할 위험이 있습니다. 예를 들어, Relying Party가 이메일 주소를 사용자명으로 쓰고, 공격자가 "alex.mueller@example.com"으로 인증 절차를 시도할 때 실패하고, "j.doe@example.com"은 성공하면, 공격자는 "j.doe@example.com"이 해당 Relying Party에 계정이 있음을 알 수 있습니다.

다음은 Relying Party가 이런 정보 누출을 완화·방지하기 위해 구현할 수 있는 비규범적·비완전 조치 목록입니다:

등록 절차에 대해:
- Relying Party가 자체 사용자명으로 사용자 식별을 한다면:
  - 등록 절차 시작 시, 문법적으로 유효한 이메일 주소는 사용자명으로 등록을 허용하지 않습니다.
    
    참고: 이 권고의 취지는, 이미 등록된 사용자명으로 추가 등록을 시도할 때 Relying Party가 실패 처리를 할 수밖에 없고, 정보 누출을 피하기 어렵기 때문입니다. 이메일 주소를 사용자명으로 금지하면, 동일 이메일 주소로 여러 Relying Party에 동일 사용자명이 존재할 가능성을 줄여 누출 영향이 완화됩니다.
- Relying Party가 이메일 주소로 사용자 식별을 한다면:
  - 등록 절차 시작 시, 이메일을 입력받은 뒤 사용자 상호작용을 중단하고, 해당 주소로 예측 불가 일회성 코드와 절차 진행 방법을 안내하는 메시지를 발송합니다. 웹 인터페이스에는 발송 여부·내용과 무관하게 동일 메시지를 표시합니다.
    
    참고: 이 권고는 이메일 외 다른 외부 유의미 식별자(예: 주민등록번호, 신용카드번호)에 대해서도, 해당 식별자에 대한 외부 연락수단(예: 우편주소 등)이 있을 때 유사하게 적용 가능합니다.
인증 절차에 대해:
- 인증 절차 시작 시, 입력한 사용자명과 일치하는 계정이 없으면, 그럴듯한 임의값을 채운 유효한 navigator.credentials.get() 및 PublicKeyCredentialRequestOptions 객체로 절차를 계속 진행합니다.
  
  이 방식은 allowCredentials 정보 누출도 완화할 수 있습니다. § 13.4.7 보호되지 않은 계정 탐지 및 § 14.6.3 자격증명 ID를 통한 개인정보 누출 참고.
  
  참고: 사용자명은 각 Relying Party별 방식(로그인 폼, 세션 쿠키 등)으로 "제공"될 수 있습니다.
  
  참고: 반환된 임의값이 실제값과 눈에 띄게 다르면, 공격자가 실제 계정 존재 여부를 구분할 수 있습니다. 예를 들어, 모든 입력에 항상 동일값을 반환하거나 같은 입력에 반복 시 값이 달라지면 구분이 쉬워집니다. allowCredentials 값은 사용자명에서 결정적으로 파생된 의사난수값을 채워 넣는 식으로 처리할 수 있습니다.
- AuthenticatorAssertionResponse 응답 검증 시, 서명 검증 실패, 등록된 사용자/자격증명 없음 등 실패 원인을 구분 불가하게 처리합니다.
- 다단계 인증 절차(예: 사용자명+비밀번호/세션 쿠키 입력 후 WebAuthn 절차)를 사용하여 사용자명 열거 문제를 WebAuthn 이전 단계로 옮깁니다. 일반 인증 절차에서 해결이 더 쉬울 수 있습니다.

14.6.3. 자격증명 ID를 통한 개인정보 누출

이 절은 규범적(normative)이지 않습니다.

이 프라이버시 고려사항은 첫 인증 단계에서 비-빈 allowCredentials 인자를 사용하는 인증 절차를 지원하는 Relying Party에 적용됩니다. 예를 들어, 첫 인증 단계로 서버측 자격증명 인증을 사용하는 경우입니다.

이 경우 allowCredentials 인자는 사용자의 자격증명 ID를 인증되지 않은 호출자에게 노출하여 개인정보를 누출할 위험이 있습니다. 자격증명 ID는 Relying Party 간 연관 불가하도록 설계되었지만, 자격증명 ID의 길이가 어떤 인증자에서 생성된 것인지 힌트가 될 수 있습니다. 사용자는 여러 Relying Party에서 동일 사용자명과 동일 인증자 세트를 사용할 가능성이 높으므로, allowCredentials 내 자격증명 ID 개수와 길이가 사용자를 비식별화할 수 있는 글로벌 연관 핸들로 작용할 수 있습니다. 사용자의 자격증명 ID를 알면, 공격자가 해당 사용자의 인증자에 잠시 물리적 접근만 해도 신원 추정이 가능합니다.

이런 정보 누출을 막기 위해 Relying Party는 다음과 같은 조치를 취할 수 있습니다:

WebAuthn 인증 절차 및 사용자 자격증명 ID 노출 전에 사용자명+비밀번호 인증 또는 세션 쿠키 인증 등 별도의 인증 단계를 수행합니다.
클라이언트 측 발견 가능한 자격증명을 사용하여 allowCredentials 인자 사용을 피합니다.

위 예방 조치가 불가능한 경우, 즉 allowCredentials 인자를 사용자명만으로 노출해야 할 경우, Relying Party는 § 14.6.2 사용자명 열거에서 논의한 것처럼 임의의 자격증명 ID를 반환하는 방식으로 프라이버시 누출을 완화할 수 있습니다.

15. 접근성 고려사항

사용자 검증 지원 인증자는 로밍이든 플랫폼이든 사용자에게 두 가지 이상의 사용자 검증 방식을 제공해야 합니다. 예를 들어, 지문 센서와 PIN 입력을 모두 제공하는 것입니다. 이렇게 하면 선택한 검증 방식에 문제가 있을 때 다른 검증 수단으로 대체할 수 있습니다. 로밍 인증자의 경우, 인증자와 플랫폼이 함께 PIN 입력 등 사용자 검증 수단을 제공할 수 있습니다 [FIDO-CTAP].

Relying Party는 등록 시, 사용자가 향후 인가 제스처를 올바르게 수행할 수 있도록 배려 기능을 제공해야 합니다. 예를 들어, 인증자 이름 지정, 기기와 연결할 이미지를 선택, 자유 입력 텍스트 지시(예: 스스로에 대한 알림) 등이 있습니다.

절차가 타이밍에 의존하는 경우, 예를 들어 등록 절차(timeout 참조) 또는 인증 절차(timeout 참조), [WCAG21]의 Guideline 2.2 충분한 시간을 따라야 합니다. 클라이언트 플랫폼이 Relying Party가 제공한 타임아웃이 WCAG21 가이드라인을 적절히 준수하지 않는다고 판단하면, 클라이언트 플랫폼이 해당 타임아웃을 조정할 수 있습니다.

16. 감사의 글

저희는 본 명세의 검토 및 기여를 해주신 다음 분들께 감사드립니다: Yuriy Ackermann, James Barclay, Richard Barnes, Dominic Battré, Julien Cayzac, Domenic Denicola, Rahul Ghosh, Brad Hill, Jing Jin, Wally Jones, Ian Kilpatrick, Axel Nennker, Yoshikazu Nojima, Kimberly Paulhamus, Adam Powers, Yaron Sheffer, Ki-Eun Shin, Anne van Kesteren, Johan Verrept, 그리고 Boris Zbarsky.

전체 등록 및 인증 흐름 다이어그램(Figure 1 및 Figure 2)을 제작해주신 Adam Powers께 감사드립니다.

Anthony Nadalin, John Fontana, 그리고 Richard Barnes 에게 Web Authentication Working Group 공동 의장으로서의 기여에 감사드립니다.

Wendy Seltzer, Samuel Weiler, 그리고 Harry Halpin 에게 W3C 팀 연락 담당으로서의 기여에 감사드립니다.

요약

이 문서의 상태

1. 소개

1.1. 명세 로드맵

1.2. 사용 사례

1.2.1. 등록

1.2.2. 인증

1.2.3. 새 디바이스 등록

1.2.4. 기타 사용 사례와 구성

1.3. API 사용 예시 시나리오

1.3.1. 등록

1.3.2. 사용자 검증 플랫폼 인증기로 등록

1.3.3. 인증

1.3.4. 인증 작업 중단

1.3.5. 폐기

1.4. 플랫폼별 구현 지침

2. 준수

2.1. 사용자 에이전트

2.1.1. DOMString 타입으로서의 열거형

2.2. 인증기

2.2.1. FIDO U2F와의 하위 호환성

2.3. WebAuthn 신뢰당사자

2.4. 모든 준수 클래스

3. 의존성

4. 용어

5. 웹 인증 API

5.1. PublicKeyCredential 인터페이스

5.1.1. CredentialCreationOptions 딕셔너리 확장

5.1.2. CredentialRequestOptions 딕셔너리 확장

5.1.3. 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 메서드

5.1.4. 기존 자격 증명을 사용해 어서션 생성 - PublicKeyCredential의 [[Get]](options) 메서드

5.1.4.1. PublicKeyCredential의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 메서드

5.1.5. 기존 자격 증명 저장 - PublicKeyCredential의 [[Store]](credential, sameOriginWithAncestors) 메서드

5.1.6. 기존 자격 증명에 대한 무언의 접근 방지 - PublicKeyCredential의 [[preventSilentAccess]](credential, sameOriginWithAncestors) 메서드

5.1.7. 사용자 검증 플랫폼 인증기의 사용 가능 여부 - PublicKeyCredential의 isUserVerifyingPlatformAuthenticatorAvailable() 메서드

5.2. 인증기 응답 (interface AuthenticatorResponse)

5.2.1. 공개 키 자격 증명 정보 (interface AuthenticatorAttestationResponse)

5.2.1.1. 자격 증명 데이터 쉽게 접근하기

5.2.2. 웹 인증 어서션 (interface AuthenticatorAssertionResponse)

5.3. 자격 증명 생성 파라미터 (dictionary PublicKeyCredentialParameters)

5.4. 자격 증명 생성 옵션 (dictionary PublicKeyCredentialCreationOptions)

5.4.1. 공개 키 엔터티 설명 (dictionary PublicKeyCredentialEntity)

5.4.2. 자격 증명 생성을 위한 신뢰 당사자 파라미터 (dictionary PublicKeyCredentialRpEntity)

5.4.3. 자격 증명 생성을 위한 사용자 계정 파라미터 (dictionary PublicKeyCredentialUserEntity)

5.4.4. 인증기 선택 기준 (dictionary AuthenticatorSelectionCriteria)

5.4.5. 인증기 부착 열거형 (enum AuthenticatorAttachment)

5.4.6. 레지던트 키 요구사항 열거형 (enum ResidentKeyRequirement)

5.4.7. 어테스테이션 전달 선호 열거형(enum AttestationConveyancePreference)

5.5. 어서션 생성 옵션 (dictionary PublicKeyCredentialRequestOptions)

5.6. AbortSignal로 작업 중단

5.7. WebAuthn 확장 입력과 출력

5.7.1. 인증 확장 클라이언트 입력(dictionary AuthenticationExtensionsClientInputs)

5.7.2. 인증 확장 클라이언트 출력(dictionary AuthenticationExtensionsClientOutputs)

5.7.3. 인증 확장 인증기 입력(CDDL 타입 AuthenticationExtensionsAuthenticatorInputs)

5.7.4. 인증 확장 인증기 출력(CDDL 타입 AuthenticationExtensionsAuthenticatorOutputs)

5.8. 지원 데이터 구조

5.8.1. WebAuthn 서명에 사용되는 클라이언트 데이터 (dictionary CollectedClientData)

5.8.1.1. 직렬화

5.8.1.2. 제한적 검증 알고리즘

5.8.1.3. 향후 개발

5.8.2. 자격 증명 타입 열거형(enum PublicKeyCredentialType)

5.8.3. 자격 증명 디스크립터(dictionary PublicKeyCredentialDescriptor)

5.8.4. 인증기 전송 방식 열거형(enum AuthenticatorTransport)

5.8.5. 암호 알고리즘 식별자(typedef COSEAlgorithmIdentifier)

5.8.6. 사용자 검증 요구 열거형(enum UserVerificationRequirement)

5.9. Permissions Policy 통합

5.10. iframe 요소 내에서 Web Authentication 사용

6. WebAuthn 인증기 모델

6.1. 인증기 데이터

6.1.1. 서명 카운터 고려사항

6.1.2. FIDO U2F 서명 형식 호환성

6.2. 인증기 분류

6.2.1. 인증기 부착 방식

6.2.2. 자격 증명 저장 방식

6.2.3. 인증 요소 역량

6.3. 인증기 동작

6.3.1. 자격 증명 ID로 자격 증명 소스 조회 알고리즘

6.3.2. authenticatorMakeCredential 동작

6.3.3. authenticatorGetAssertion 작업

6.3.4. authenticatorCancel 작업

5.1. `PublicKeyCredential` 인터페이스

5.1.1. `CredentialCreationOptions` 딕셔너리 확장

5.1.2. `CredentialRequestOptions` 딕셔너리 확장

5.1.3. 새 자격 증명 생성 - PublicKeyCredential의 `[[Create]](origin, options, sameOriginWithAncestors)` 메서드

5.1.4. 기존 자격 증명을 사용해 어서션 생성 - PublicKeyCredential의 `[[Get]](options)` 메서드

5.1.4.1. PublicKeyCredential의 `[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)` 메서드

5.1.5. 기존 자격 증명 저장 - PublicKeyCredential의 `[[Store]](credential, sameOriginWithAncestors)` 메서드

5.1.6. 기존 자격 증명에 대한 무언의 접근 방지 - PublicKeyCredential의 `[[preventSilentAccess]](credential, sameOriginWithAncestors)` 메서드

5.1.7. 사용자 검증 플랫폼 인증기의 사용 가능 여부 - PublicKeyCredential의 `isUserVerifyingPlatformAuthenticatorAvailable()` 메서드

5.2. 인증기 응답 (interface `AuthenticatorResponse`)

5.2.1. 공개 키 자격 증명 정보 (interface `AuthenticatorAttestationResponse`)

5.2.2. 웹 인증 어서션 (interface `AuthenticatorAssertionResponse`)

5.3. 자격 증명 생성 파라미터 (dictionary `PublicKeyCredentialParameters`)

5.4. 자격 증명 생성 옵션 (dictionary `PublicKeyCredentialCreationOptions`)

5.4.1. 공개 키 엔터티 설명 (dictionary `PublicKeyCredentialEntity`)

5.4.2. 자격 증명 생성을 위한 신뢰 당사자 파라미터 (dictionary `PublicKeyCredentialRpEntity`)

5.4.3. 자격 증명 생성을 위한 사용자 계정 파라미터 (dictionary `PublicKeyCredentialUserEntity`)

5.4.4. 인증기 선택 기준 (dictionary `AuthenticatorSelectionCriteria`)

5.4.5. 인증기 부착 열거형 (enum `AuthenticatorAttachment`)

5.4.6. 레지던트 키 요구사항 열거형 (enum `ResidentKeyRequirement`)

5.4.7. 어테스테이션 전달 선호 열거형(enum `AttestationConveyancePreference`)

5.5. 어서션 생성 옵션 (dictionary `PublicKeyCredentialRequestOptions`)

5.6. `AbortSignal`로 작업 중단

5.7.1. 인증 확장 클라이언트 입력(dictionary `AuthenticationExtensionsClientInputs`)

5.7.2. 인증 확장 클라이언트 출력(dictionary `AuthenticationExtensionsClientOutputs`)

5.7.3. 인증 확장 인증기 입력(CDDL 타입 `AuthenticationExtensionsAuthenticatorInputs`)

5.7.4. 인증 확장 인증기 출력(CDDL 타입 `AuthenticationExtensionsAuthenticatorOutputs`)

5.8.1. WebAuthn 서명에 사용되는 클라이언트 데이터 (dictionary `CollectedClientData`)

5.8.2. 자격 증명 타입 열거형(enum `PublicKeyCredentialType`)

5.8.3. 자격 증명 디스크립터(dictionary `PublicKeyCredentialDescriptor`)

5.8.4. 인증기 전송 방식 열거형(enum `AuthenticatorTransport`)

5.8.5. 암호 알고리즘 식별자(typedef `COSEAlgorithmIdentifier`)

5.8.6. 사용자 검증 요구 열거형(enum `UserVerificationRequirement`)

5.10. `iframe` 요소 내에서 Web Authentication 사용

6.5.1.1. COSE_Key 형식으로 인코딩된 `credentialPublicKey` 값 예시