웹 인증: 공개 키 자격 증명에 접근하기 위한 API

1. 소개

이 절은 규범적이지 않습니다.

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

신뢰 당사자는 사용자와 관련된 서로 구별되지만 연관된 두 가지 절차에서 웹 인증 API를 사용합니다. 첫 번째는 등록으로, 공개 키 자격 증명이 인증자에 생성되고 현재 사용자의 계정과 함께 신뢰 당사자에 범위가 지정됩니다 (계정은 이미 존재할 수도 있고 이때 생성될 수도 있습니다). 두 번째는 인증으로, 신뢰 당사자에 공개 키 자격 증명을 등록한 사용자의 존재와 동의를 증명하는 인증 어설션이 제공됩니다. 기능적으로 웹 인증 API는 Credential Management API [CREDENTIAL-MANAGEMENT-1]을 확장하는 PublicKeyCredential과 이러한 자격 증명을 navigator.credentials.create() 및 navigator.credentials.get()과 함께 사용할 수 있게 하는 인프라로 구성됩니다. 전자는 등록 중에 사용되고, 후자는 인증 중에 사용됩니다.

대체로, 적합한 인증자는 공개 키 자격 증명을 보호하고 사용자 에이전트와 상호 작용하여 웹 인증 API를 구현합니다. 적합한 인증자는 다음에서 실행되는 소프트웨어로 구현할 수 있습니다. (a) 범용 컴퓨팅 장치, (b) 장치 내 보안 실행 환경, 신뢰할 수 있는 플랫폼 모듈(TPM) 또는 보안 요소(SE), 또는 (c) 장치 외부. 장치에 구현된 인증자를 플랫폼 인증자라고 합니다. 장치 외부에 구현된 인증자(로밍 인증자)에는 USB(Universal Serial Bus), BLE(Bluetooth Low Energy) 또는 NFC(Near Field Communications)와 같은 전송 방식을 통해 접근할 수 있습니다.

1.1. 명세 로드맵

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

모든 독자는 § 1.2 사용 사례, § 1.3 API 사용 예시 시나리오 및 § 4 용어부터 읽는 것이 좋으며, 전체적인 자습서는 [WebAuthnAPIGuide]도 참조하는 것이 좋습니다. 그 외에 이 문서가 대상으로 하는 주요 독자 그룹은 다음과 같습니다.

신뢰 당사자 웹 애플리케이션 개발자, 특히 신뢰 당사자 웹 애플리케이션 로그인 흐름, 계정 복구 흐름, 사용자 계정 데이터베이스 내용 등을 담당하는 개발자.
웹 프레임워크 개발자
- 위의 두 독자는 특히 § 7 WebAuthn 신뢰 당사자 작업을 참조해야 합니다. § 5 웹 인증 API의 소개도 유용할 수 있지만, 독자는 § 5 웹 인증 API 절이 웹 애플리케이션 개발자가 아니라 사용자 에이전트 개발자를 특별히 대상으로 한다는 점을 이해해야 합니다. 또한 인증자 증명을 검증하려는 경우, § 6.5 증명 및 § 8 정의된 증명문 형식도 관련이 있습니다. 확장을 사용하려는 경우 § 9 WebAuthn 확장 및 § 10 정의된 확장에도 관심을 가져야 합니다. 마지막으로 § 13.5 신뢰 당사자에 대한 보안 고려사항 및 § 14.6 신뢰 당사자에 대한 개인정보 보호 고려사항을 읽고 어떤 과제가 자신의 애플리케이션과 사용자에게 적용되는지 고려해야 합니다.
사용자 에이전트 개발자
플랫폼별 인증자 API, 플랫폼 WebAuthn 클라이언트 인스턴스화 등과 관련된 OS 플랫폼 API 설계 및 구현을 담당하는 OS 플랫폼 개발자.
- 위의 두 독자는 확장 지원을 계획하는 경우 § 9 WebAuthn 확장과 함께 § 5 웹 인증 API를 매우 주의 깊게 읽어야 합니다. 또한 § 14.5 클라이언트에 대한 개인정보 보호 고려사항도 주의 깊게 읽어야 합니다.
인증자 개발자. 이러한 독자는 § 6 WebAuthn 인증자 모델, § 8 정의된 증명문 형식, § 9 WebAuthn 확장 및 § 10 정의된 확장에 특별히 주의를 기울여야 합니다. 또한 § 13.3 인증자에 대한 보안 고려사항 및 § 14.4 인증자에 대한 개인정보 보호 고려사항도 주의 깊게 읽어야 합니다.

참고: 이 명세는 웹 인증 API 자체와 함께 WebAuthn 신뢰 당사자 서버와 인증자 사이의 요청-응답 암호화 프로토콜인 WebAuthn/FIDO2 프로토콜도 정의합니다. 여기서 신뢰 당사자의 요청은 챌린지와 신뢰 당사자가 제공하고 인증자에 전송하는 기타 입력 데이터로 구성됩니다. 요청은 HTTPS, 신뢰 당사자 웹 애플리케이션, WebAuthn API 및 사용자 에이전트와 인증자 사이의 플랫폼별 통신 채널을 조합하여 전달됩니다. 인증자는 디지털 서명된 인증자 데이터 메시지와 기타 출력 데이터로 응답하며, 이는 동일한 경로를 역순으로 거쳐 신뢰 당사자 서버로 전달됩니다. 프로토콜의 세부 사항은 인증 작업 또는 등록 작업 중 어느 것이 신뢰 당사자에 의해 호출되는지에 따라 달라집니다. 그림 1 및 그림 2도 참조하십시오.

웹 인증 배포의 종단 간 보안을 위해서는 각 구성 요소, 즉 신뢰 당사자 서버, 클라이언트 및 인증자의 역할뿐만 아니라 § 13 보안 고려사항 및 § 14 개인정보 보호 고려사항을 모든 독자가 이해하는 것이 중요합니다.

1.2. 사용 사례

아래 사용 사례 시나리오는 두 가지 일반적인 배포 유형에서 서로 매우 다른 두 유형의 인증자 및 자격 증명을 사용하는 방법을 보여주고 추가 시나리오도 개략적으로 설명합니다. 샘플 코드를 포함한 추가 시나리오는 뒤의 § 1.3 API 사용 예시 시나리오에 제시되어 있습니다. 이러한 예는 설명을 위한 것일 뿐이며, 기능의 사용 가능 여부는 클라이언트 및 인증자 구현에 따라 다를 수 있습니다.

1.2.1. 다중 기기 자격 증명을 사용하는 소비자

이 사용 사례는 소비자 중심의 신뢰 당사자가 사용자 기기에 내장된 인증자를 활용하여 다중 기기 자격 증명(일반적으로 동기화된 패스키라고 함)을 사용한 피싱 방지 로그인을 제공할 수 있는 방법을 보여줍니다.

1.2.1.1. 등록

휴대전화에서:
- 사용자가 브라우저에서 example.com으로 이동하여 지금까지 사용해 온 방식 (암호와 같은 기존 방식일 수도 있음)을 사용해 기존 계정에 로그인하거나 새 계정을 생성합니다.
- 휴대전화에 "example.com용 패스키를 생성하시겠습니까?"라는 메시지가 표시됩니다.
- 사용자가 동의합니다.
- 휴대전화에서 이전에 구성된 인증 제스처(PIN, 생체 인식 등)를 사용자에게 요청하고, 사용자가 이를 제공합니다.
- 웹사이트에 "등록이 완료되었습니다."라는 메시지가 표시됩니다.

1.2.1.2. 인증

노트북 또는 데스크톱에서:
- 사용자가 브라우저에서 example.com으로 이동하여 로그인을 시작합니다.
- 다중 기기 자격 증명(일반적으로 동기화된 패스키라고 함)을 해당 기기에서 사용할 수 있는 경우:
  - 브라우저 또는 운영 체제가 이전에 구성된 인증 제스처(PIN, 생체 인식 등)를 사용자에게 요청하고, 사용자가 이를 제공합니다.
  - 웹 페이지는 선택한 사용자가 로그인했음을 표시하고 로그인된 페이지로 이동합니다.
- 동기화된 패스키를 해당 기기에서 사용할 수 없는 경우:
  - 브라우저 또는 운영 체제가 휴대전화나 보안 키와 같은 외부 인증자를 사용자에게 요청합니다.
  - 사용자가 이전에 연결한 휴대전화를 선택합니다.
다음으로 휴대전화에서:
- 사용자에게 "example.com에 로그인"이라는 별도의 프롬프트 또는 알림이 표시됩니다.
- 사용자가 이 프롬프트/알림을 선택합니다.
- 사용자에게 example.com의 사용자 ID 목록이 표시됩니다. 예: "Mohamed로 로그인 / 张三으로 로그인".
- 사용자가 사용자 ID를 선택하면 인증 제스처(PIN, 생체 인식 등)를 요청받고 이를 제공합니다.
이제 다시 노트북에서:
- 웹 페이지는 선택한 사용자가 로그인했음을 표시하고 로그인된 페이지로 이동합니다.

1.2.2. 단일 기기 자격 증명을 사용하는 조직 구성원

이 사용 사례는 조직 구성원 중심의 신뢰 당사자가 로밍 인증자(예: USB 보안 키)와 플랫폼 인증자(예: 내장 지문 센서)를 함께 활용하여 사용자가 다음을 이용할 수 있도록 하는 방법을 보여줍니다.

사용자가 처음 사용하는 클라이언트 기기(예: 노트북, 데스크톱) 또는 플랫폼 인증자가 없는 해당 클라이언트 기기에서 인증하는 데 사용하는 "기본" 로밍 인증자, 그리고
플랫폼 인증자가 있는 클라이언트 기기에서 마찰을 최소화하면서 강력하게 재인증하는 수단, 또는
단일 기기 자격 증명 (일반적으로 기기 바인딩 패스키라고 함)을 지원하지 않는 패스키 플랫폼 인증자가 있는 클라이언트 기기에서 강력하게 재인증하는 수단.

1.2.2.1. 등록

이 예에서는 사용자의 고용주가 기기 바인딩 패스키가 사전 구성된 보안 키를 우편으로 보냅니다.

임시 PIN은 별도의 경로(예: RCS 메시지)를 통해 사용자에게 전송되었습니다.

1.2.2.2. 인증

노트북 또는 데스크톱에서:
- 사용자가 브라우저에서 corp.example.com으로 이동하여 로그인을 시작합니다.
- 브라우저 또는 운영 체제가 사용자에게 보안 키를 요청합니다.
- 사용자가 USB 보안 키를 연결합니다.
- USB 보안 키가 깜박여 사용자가 버튼을 눌러야 함을 알리고, 사용자가 버튼을 누릅니다.
- 브라우저 또는 운영 체제가 사용자에게 PIN을 입력하도록 요청합니다.
- 사용자가 제공받은 임시 PIN을 입력하고 계속합니다.
- 브라우저 또는 운영 체제가 PIN을 변경해야 한다고 알리고 새 PIN을 입력하도록 요청합니다.
- 사용자가 새 PIN을 입력하고 계속합니다.
- 브라우저 또는 운영 체제가 인증 흐름을 다시 시작하고 사용자에게 PIN을 입력하도록 요청합니다.
- 사용자가 새 PIN을 입력하고 보안 키를 누릅니다.
- 웹 페이지는 선택한 사용자가 로그인했음을 표시하고 로그인된 페이지로 이동합니다.

1.2.3. 기타 사용 사례 및 구성

다음을 포함하되 이에 국한되지 않는 다양한 추가 사용 사례 및 구성도 가능합니다.

사용자가 노트북에서 example.com으로 이동한 다음 휴대전화에 자격 증명을 생성하고 등록하는 흐름을 안내받습니다.
사용자가 USB 및/또는 NFC 연결 옵션이 있는 보안 키와 같은 별도의 로밍 인증자를 구한 다음, 노트북이나 휴대전화의 브라우저에서 example.com을 로드하고 보안 키에 자격 증명을 생성하고 등록하는 흐름을 안내받습니다.
신뢰 당사자가 결제 또는 기타 금융 거래와 같은 단일 거래를 승인하기 위해 사용자에게 인증 제스처를 요청합니다.

1.3. API 사용 예시 시나리오

이 절은 규범적이지 않습니다.

이 절에서는 공개 키 자격 증명의 수명 주기에서 발생하는 몇 가지 이벤트와 함께 이 API를 사용하는 해당 샘플 코드를 살펴봅니다. 이는 예시 흐름이며 API의 사용 범위를 제한하지 않는다는 점에 유의하십시오.

앞 절과 마찬가지로 이 흐름은 자체 디스플레이가 있는 패스키 로밍 인증자를 사용하는 사례에 초점을 맞춥니다. 이러한 인증자의 한 예는 스마트폰입니다. 다른 인증자 유형도 클라이언트 플랫폼의 구현에 따라 이 API에서 지원됩니다. 예를 들어 이 흐름은 클라이언트 기기에 내장된 인증자의 경우에도 수정 없이 작동합니다. 또한 특정 구현 고려사항을 전제로, 자체 디스플레이가 없는 인증자(스마트 카드와 유사한 경우)에도 이 흐름이 작동합니다. 구체적으로 클라이언트 플랫폼은 원래 인증자가 표시했을 모든 프롬프트를 표시해야 하며, 인증자는 클라이언트가 적절한 프롬프트를 표시할 정보를 가질 수 있도록 클라이언트 플랫폼이 인증자의 모든 자격 증명을 열거할 수 있게 해야 합니다.

1.3.1. 등록

이는 새 자격 증명을 생성하고 서버에 등록하는 최초 흐름입니다. 이 흐름에서 WebAuthn 신뢰 당사자는 플랫폼 인증자 또는 로밍 인증자 중 어느 쪽도 선호하지 않습니다.

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

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

if (!window.PublicKeyCredential) { /* 클라이언트가 지원하지 않습니다. 오류를 처리합니다. */ }

var publicKey = {
  // 챌린지는 서버에서 생성합니다. 보안 고려사항을 참조하십시오.
  challenge: new Uint8Array([21,31,105 /* 서버에서 생성한 임의의 바이트 29개 추가 */]),

  // 신뢰 당사자:
  rp: {
    name: "ACME Corporation"
  },

  // 사용자:
  user: {
    id: Uint8Array.from(window.atob("MIIBkzCCATigAwIBAjCCAZMwggE4oAMCAQIwggGTMII="), c=>c.charCodeAt(0)),
    name: "alex.mueller@example.com",
    displayName: "Alex Müller",
  },

  // 이 신뢰 당사자는 EdDSA, ES256 또는 RS256 자격 증명을 모두 허용하지만
  // EdDSA 자격 증명을 선호합니다.
  pubKeyCredParams: [
    {
      type: "public-key",
      alg: -8 // IANA COSE 알고리즘 레지스트리에 등록된 "EdDSA"
    },
    {
      type: "public-key",
      alg: -7 // IANA COSE 알고리즘 레지스트리에 등록된 "ES256"
    },
    {
      type: "public-key",
      alg: -257 // 이 명세에서 "RS256"에 대해 등록한 값
    }
  ],

  authenticatorSelection: {
    // 가능하면 UV를 사용합니다. 이것이 기본값이기도 합니다.
    userVerification: "preferred"
  },

  timeout: 300000,  // 5분
  excludeCredentials: [
    // 이러한 자격 증명 중 하나를 가진 인증자는 다시 등록하지 않습니다
    {"id": Uint8Array.from(window.atob("ufJWp8YGlibm1Kd9XQBWN1WAw2jy5In2Xhon9HAqcXE="), c=>c.charCodeAt(0)), "type": "public-key"},
    {"id": Uint8Array.from(window.atob("E/e1dhZc++mIsz4f9hb6NifAzJpF1V4mEtRlIPBiWdY="), c=>c.charCodeAt(0)), "type": "public-key"}
  ],

  // U2F로 등록된 자격 증명과 excludeCredentials 검사의 하위 호환성을 유지합니다
  extensions: {"appidExclude": "https://acme.example.com"}
};

// 참고: 다음 호출로 인해 인증자가 UI를 표시합니다.
navigator.credentials.create({ publicKey })
  .then(function (newCredentialInfo) {
    // 새 자격 증명 정보를 검증 및 등록을 위해 서버로 전송합니다.
  }).catch(function (err) {
    // 허용 가능한 인증자가 없거나 사용자가 동의를 거부했습니다. 적절하게 처리합니다.
  });

1.3.2. 사용자 검증 플랫폼 인증자를 사용한 등록

이는 WebAuthn 신뢰 당사자가 특별히 사용자 검증 플랫폼 인증자를 사용하여 공개 키 자격 증명을 생성하려는 경우의 예시 흐름입니다.

사용자가 example.com을 방문하여 로그인 버튼을 클릭하면 login.example.com으로 리디렉션됩니다.
사용자가 사용자 이름과 암호를 입력하여 로그인합니다. 로그인에 성공하면 다시 example.com으로 리디렉션됩니다.
신뢰 당사자 스크립트가 아래 코드 조각을 실행합니다.
1. 사용자 에이전트가 사용자 검증 플랫폼 인증자를 사용할 수 있는지 확인합니다. 사용할 수 없으면 이 흐름을 종료합니다.
2. 신뢰 당사자가 사용자에게 이를 사용하여 자격 증명을 생성할지 묻습니다. 원하지 않으면 이 흐름을 종료합니다.
3. 사용자 에이전트 및/또는 운영 체제가 적절한 UI를 표시하고 사용 가능한 플랫폼 인증자 중 하나를 사용하여 자격 증명을 생성하도록 사용자를 안내합니다.
4. 자격 증명 생성에 성공하면 신뢰 당사자 스크립트가 새 자격 증명을 서버로 전달합니다.

if (!window.PublicKeyCredential) { /* 클라이언트가 API를 지원하지 않습니다. 오류를 처리합니다. */ }

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
    .then(function (uvpaAvailable) {
        // 사용자 검증 플랫폼 인증자가 있는 경우
        if (uvpaAvailable) {
            // RP별 UI를 렌더링하고 Boolean 값에 대한 Promise를 가져옵니다
            return askIfUserWantsToCreateCredential();
        }
    }).then(function (userSaidYes) {
        // 사용자 검증 플랫폼 인증자가 있고
        // 사용자가 자격 증명을 생성하려는 경우
        if (userSaidYes) {
            var publicKeyOptions = { /* 공개 키 자격 증명 생성 옵션. */};
            return navigator.credentials.create({ "publicKey": publicKeyOptions });
        }
    }).then(function (newCredentialInfo) {
        if (newCredentialInfo) {
            // 새 자격 증명 정보를 검증 및 등록을 위해 서버로 전송합니다.
        }
    }).catch(function (err) {
        // 문제가 발생했습니다. 적절하게 처리합니다.
    });

1.3.3. 인증

이는 이미 등록된 자격 증명이 있는 사용자가 웹사이트를 방문하여 해당 자격 증명을 사용해 인증하려는 경우의 흐름입니다.

사용자가 example.com을 방문하면 스크립트가 제공됩니다.
스크립트는 사용자에게 허용 가능한 자격 증명의 선택 범위를 좁힐 수 있도록 가능한 한 많은 정보를 제공하면서 클라이언트에 인증 어설션을 요청합니다. 이 정보는 등록 후 로컬에 저장된 데이터에서 얻거나 사용자에게 사용자 이름을 입력하도록 요청하는 등의 다른 방법으로 얻을 수 있습니다.
신뢰 당사자 스크립트가 아래 코드 조각 중 하나를 실행합니다.
클라이언트 플랫폼이 인증자를 검색하고 찾습니다.
클라이언트가 인증자에 연결하고 필요한 경우 페어링 작업을 수행합니다.
인증자는 사용자에게 주의가 필요하다는 알림을 표시합니다. 사용자가 알림을 열면 자격 증명을 생성할 때 제공한 계정 정보와 이 키를 요청하는 오리진에 관한 일부 정보를 사용하여 허용 가능한 자격 증명의 친숙한 선택 메뉴가 표시됩니다.
인증자는 사용자로부터 생체 인식 또는 다른 인증 제스처를 받습니다.
인증자는 클라이언트에 응답을 반환하고, 클라이언트는 다시 신뢰 당사자 스크립트에 응답을 반환합니다. 사용자가 자격 증명을 선택하거나 승인을 제공하는 것을 거부한 경우 적절한 오류가 반환됩니다.
어설션이 성공적으로 생성되고 반환된 경우,
- 스크립트가 어설션을 서버로 전송합니다.
- 서버는 어설션을 검사하고 자격 증명 ID를 추출한 다음 데이터베이스에서 등록된 자격 증명 공개 키를 찾아 어설션 서명을 검증합니다. 유효하면 어설션의 자격 증명 ID와 연결된 사용자 ID를 조회하며, 이제 해당 사용자 ID가 인증됩니다. 자격 증명 ID를 서버가 인식하지 못하는 경우(예: 비활성으로 인해 등록이 해제된 경우) 인증이 실패합니다. 각 신뢰 당사자는 이를 자체 방식으로 처리합니다.
- 이제 서버는 인증 성공 시 일반적으로 수행하는 작업을 수행합니다. 즉, 성공 페이지를 반환하고 인증 쿠키를 설정하는 등의 작업입니다.

신뢰 당사자 스크립트에 자격 증명 목록을 좁히는 데 도움이 되는 힌트(예: 로컬에 저장된 데이터)가 없는 경우, 이러한 인증을 수행하는 샘플 코드는 다음과 같을 수 있습니다.

if (!window.PublicKeyCredential) { /* 클라이언트가 지원하지 않습니다. 오류를 처리합니다. */ }

// credentialId는 인증자가 생성하며 불투명한 임의의 바이트 배열입니다
var credentialId = new Uint8Array([183, 148, 245 /* 인증자가 이전에 생성한 임의의 바이트 추가 */]);
var options = {
  // 챌린지는 서버에서 생성합니다. 보안 고려사항을 참조하십시오.
  challenge: new Uint8Array([4,101,15 /* 서버에서 생성한 임의의 바이트 29개 추가 */]),
  timeout: 300000,  // 5분
  allowCredentials: [{ type: "public-key", id: credentialId }]
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // 검증을 위해 어설션을 서버로 전송합니다
}).catch(function (err) {
    // 허용 가능한 자격 증명이 없거나 사용자가 동의를 거부했습니다. 적절하게 처리합니다.
});

반면 신뢰 당사자 스크립트에 자격 증명 목록을 좁히는 데 도움이 되는 힌트가 있는 경우, 이러한 인증을 수행하는 샘플 코드는 다음과 같을 수 있습니다. 이 샘플은 자격 증명 속성 확장을 사용하는 방법도 보여준다는 점에 유의하십시오.

if (!window.PublicKeyCredential) { /* 클라이언트가 지원하지 않습니다. 오류를 처리합니다. */ }

var encoder = new TextEncoder();
var acceptableCredential1 = {
    type: "public-key",
    id: encoder.encode("BA44712732CE")
};
var acceptableCredential2 = {
    type: "public-key",
    id: encoder.encode("BG35122345NF")
};

var options = {
  // 챌린지는 서버에서 생성합니다. 보안 고려사항을 참조하십시오.
  challenge: new Uint8Array([8,18,33 /* 서버에서 생성한 임의의 바이트 29개 추가 */]),
  timeout: 300000,  // 5분
  allowCredentials: [acceptableCredential1, acceptableCredential2],
  extensions: { 'credProps': true }
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // 검증을 위해 어설션을 서버로 전송합니다
}).catch(function (err) {
    // 허용 가능한 자격 증명이 없거나 사용자가 동의를 거부했습니다. 적절하게 처리합니다.
});

1.3.4. 인증 작업 중단

아래 예는 개발자가 AbortSignal 매개변수를 사용하여 자격 증명 등록 작업을 중단하는 방법을 보여줍니다. 인증 작업에도 유사한 절차가 적용됩니다.

const authAbortController = new AbortController();
const authAbortSignal = authAbortController.signal;

authAbortSignal.onabort = function () {
    // 페이지가 중단이 시작되었음을 알게 되면 사용자에게 중단을 시도 중임을 알립니다.
}

var options = {
    // 옵션 목록.
}

navigator.credentials.create({
    publicKey: options,
    signal: authAbortSignal})
    .then(function (attestation) {
        // 사용자를 등록합니다.
    }).catch(function (error) {
        if (error.name === "AbortError") {
            // 자격 증명이 생성되지 않았음을 사용자에게 알립니다.
            // 키가 생성되지 않았음을 서버에 알립니다.
        }
    });

// 인증이 발생할 때마다 위젯이 표시된다고 가정합니다.
if (widget == "disappear") {
    authAbortController.abort();
}

1.3.5. 사용 중단

다음은 자격 증명의 사용을 중단하고자 할 수 있는 가능한 상황입니다. 이러한 상황은 모두 서버 측에서 처리되며 여기에 명시된 API의 지원이 필요하지 않다는 점에 유의하십시오.

가능성 #1 -- 사용자가 자격 증명 분실을 신고합니다.
- 사용자가 server.example.net으로 이동하여 인증한 다음 분실/도난된 인증자를 신고하는 링크를 따릅니다.
- 서버는 등록 중 구성한 친숙한 이름과 함께 등록된 자격 증명 목록을 보여주는 페이지를 반환합니다.
- 사용자가 자격 증명을 선택하면 서버가 이를 데이터베이스에서 삭제합니다.
- 이후 신뢰 당사자 스크립트는 허용 가능한 자격 증명 목록에 이 자격 증명을 지정하지 않으며, 이 자격 증명으로 서명된 어설션은 거부됩니다.
가능성 #2 -- 서버가 비활성으로 인해 자격 증명 등록을 해제합니다.
- 서버가 유지보수 작업 중 데이터베이스에서 자격 증명을 삭제합니다.
- 이후 신뢰 당사자 스크립트는 허용 가능한 자격 증명 목록에 이 자격 증명을 지정하지 않으며, 이 자격 증명으로 서명된 어설션은 거부됩니다.
가능성 #3 -- 사용자가 인증자에서 자격 증명을 삭제합니다.
- 사용자가 인증자별 방법(예: 기기 설정 UI)을 사용하여 자신의 인증자에서 자격 증명을 삭제합니다.
- 이 시점부터 이 자격 증명은 어떤 선택 프롬프트에도 나타나지 않으며, 이를 사용하여 어설션을 생성할 수 없습니다.
- 얼마 후 서버가 비활성으로 인해 이 자격 증명의 등록을 해제합니다.

1.4. 플랫폼별 구현 지침

이 명세는 일반적인 경우 웹 인증을 사용하는 방법을 정의합니다. 특정 플랫폼 지원(예: 앱)과 함께 웹 인증을 사용하는 경우 추가 지침과 제한 사항은 플랫폼별 문서와 가이드를 참조하는 것이 좋습니다.

2. 적합성

이 명세는 세 가지 적합성 클래스를 정의합니다. 각 클래스는 적합한 클래스 구성원이 다른 클래스의 부적합하거나 적대적인 구성원에 대해 안전하도록 명시됩니다.

2.1. 사용자 에이전트

사용자 에이전트가 적합한 것으로 간주되려면 § 5 웹 인증 API에 설명된 대로 동작해야 합니다(MUST). 적합한 사용자 에이전트는 최종 결과가 이 명세의 알고리즘으로 얻을 수 있는 결과와 구별되지 않는 한, 이 명세에 제시된 알고리즘을 원하는 방식으로 구현할 수 있습니다(MAY).

적합한 사용자 에이전트는 “Web IDL” 명세에 설명된 대로 이 명세의 IDL 조각에 대한 적합한 구현이기도 해야 합니다(MUST). [WebIDL]

2.1.1. DOMString 유형으로서의 열거형

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

2.2. 인증자

WebAuthn 인증자는 § 6 WebAuthn 인증자 모델에 정의된 작업을 제공해야 하며(MUST), 이러한 작업은 거기에 설명된 대로 동작해야 합니다(MUST). 이는 인증자가 적합한 사용자 에이전트에 의해 사용되기 위한 기능 및 보안 요구사항 집합입니다.

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

2.2.1. FIDO U2F와의 하위 호환성

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

2.3. WebAuthn 신뢰 당사자

WebAuthn 신뢰 당사자는 이 명세가 제공하는 모든 보안 이점을 얻기 위해 § 7 WebAuthn 신뢰 당사자 작업에 설명된 대로 동작해야 합니다(MUST). 이에 대한 추가 논의는 § 13.5.1 WebAuthn 신뢰 당사자를 위한 보안 이점을 참조하십시오.

2.4. 모든 적합성 클래스

위 적합성 클래스의 구성원이 수행하는 모든 CBOR 인코딩은 CTAP2 정규 CBOR 인코딩 형식을 사용하여 수행해야 합니다(MUST). 위 적합성 클래스의 모든 디코더는 CTAP2 정규 CBOR 인코딩 형식으로 유효하게 인코딩되지 않은 CBOR을 거부해야 하며(SHOULD), 중복 맵 키가 있는 메시지도 거부해야 합니다(SHOULD).

3. 종속성

이 명세는 아래 및 참조에 의해 정의된 용어에 나열된 여러 기반 명세에 의존합니다.

Base64url 인코딩: Base64url 인코딩이라는 용어는 [RFC4648] 제5절에 정의된 URL 및 파일 이름에 안전한 문자 집합을 사용하는 base64 인코딩을 의미하며, 끝의 모든 '=' 문자를 생략하고(제3.2절에서 허용됨) 줄 바꿈, 공백 또는 기타 추가 문자를 포함하지 않습니다.
CBOR: 증명문과 확장을 포함하여 이 명세의 여러 구조는 [FIDO-CTAP]에 정의된 Compact Binary Object Representation(CBOR) [RFC8949]의 CTAP2 정규 CBOR 인코딩 형식을 사용하여 인코딩됩니다.
CDDL: 이 명세는 CBOR Data Definition Language(CDDL) [RFC8610]를 사용하여 모든 CBOR 인코딩 데이터의 구문을 설명합니다.
COSE: CBOR Object Signing and Encryption(COSE) [RFC9052] [RFC9053]. 원래 [RFC8152]에 의해 설정되고 이들 명세에 의해 업데이트된 IANA COSE 알고리즘 레지스트리 [IANA-COSE-ALGS-REG]도 사용됩니다.
자격 증명 관리: 이 문서에 설명된 API는 [CREDENTIAL-MANAGEMENT-1]에 정의된 Credential 개념의 확장입니다.
DOM: DOMException과 이 명세에서 사용하는 DOMException 값은 [DOM4]에 정의되어 있습니다.
ECMAScript: %ArrayBuffer%는 [ECMAScript]에 정의되어 있습니다.
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", "NOT RECOMMENDED", "MAY" 및 "OPTIONAL"이라는 핵심 단어는 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 합니다.

4. 용어

증명

일반적으로 증명은 어떤 사실을 증언하거나 확인하거나 인증하는 역할을 하는 진술입니다. WebAuthn 맥락에서 증명은 인증자의 출처와 해당 인증자가 내보내는 데이터에 대한 검증 가능한 증거를 제공하는 데 사용됩니다. 여기에는 자격 증명 ID, 자격 증명 키 쌍, 서명 카운터 등이 포함됩니다.

등록 절차 중에는 증명 객체 내부에 증명문이 제공됩니다. § 6.5 증명 및 그림 6도 참조하십시오. 클라이언트가 증명 객체의 증명문 및 aaguid 부분을 신뢰 당사자에게 전달하는지 여부와 방법은 증명 전달에 설명되어 있습니다.

증명 인증서

인증자가 자신의 제조 정보와 기능을 증명하는 데 사용하는 증명 키 쌍에 대한 X.509 인증서입니다. 등록 시 인증자는 증명 개인 키를 사용하여 authenticatorMakeCredential 작업을 통해 생성하고 반환하는 신뢰 당사자별 자격 증명 공개 키(및 추가 데이터)에 서명합니다. 신뢰 당사자는 증명 인증서에 전달된 증명 공개 키를 사용하여 증명 서명을 검증합니다. 자체 증명의 경우에는 인증자에 별도의 증명 키 쌍이나 증명 인증서가 없다는 점에 유의하십시오. 자세한 내용은 자체 증명을 참조하십시오.

인증

인증 절차

사용자와 사용자의 클라이언트 플랫폼(하나 이상의 인증자를 포함하거나 이에 연결됨)이 협력하여, 사용자가 이전에 등록된 공개 키 자격 증명의 자격 증명 개인 키를 제어하고 있음을 신뢰 당사자에게 암호학적으로 증명하는 절차입니다(등록 참조). 여기에는 사용자 존재 여부 테스트 또는 사용자 검증이 포함됩니다.

WebAuthn 인증 절차는 § 7.2 인증 어설션 검증에 정의되어 있으며, 신뢰 당사자가 publicKey 인수와 함께 navigator.credentials.get() 작업을 호출함으로써 시작됩니다. 소개 개요는 § 5 웹 인증 API를, 구현 예시는 § 1.3.3 인증을 참조하십시오.

인증 어설션

어설션

authenticatorGetAssertion 작업의 결과로 인증자가 반환하는 암호학적으로 서명된 AuthenticatorAssertionResponse 객체입니다.

이는 [CREDENTIAL-MANAGEMENT-1] 명세의 일회용 자격 증명에 해당합니다.

인증자

WebAuthn 인증자

하드웨어 또는 소프트웨어에 존재하는 암호학적 엔터티로서, 지정된 신뢰 당사자에 사용자를 등록하고 나중에 등록된 공개 키 자격 증명의 소유를 어설션할 수 있으며, 선택적으로 사용자를 신뢰 당사자에 대해 검증할 수 있습니다. 인증자는 등록 및 어설션 중 증명을 통해 자신의 유형과 보안 특성에 관한 정보를 보고할 수 있습니다.

WebAuthn 인증자는 로밍 인증자, 클라이언트 기기에 통합된 전용 하드웨어 서브시스템, 또는 클라이언트나 클라이언트 기기의 소프트웨어 구성 요소일 수 있습니다. WebAuthn 인증자가 반드시 로컬 컨텍스트에서만 작동하도록 제한되는 것은 아니며, 클라이언트 측 하드웨어 외부의 서버에서 자격 증명 키 쌍을 생성하거나 저장할 수 있습니다.

일반적으로 인증자에는 사용자가 한 명뿐이라고 가정합니다. 여러 자연인이 하나의 인증자에 대한 접근 권한을 공유하는 경우, 해당 인증자의 맥락에서는 동일한 사용자를 나타내는 것으로 간주됩니다. 인증자 구현이 서로 분리된 구획에서 여러 사용자를 지원하는 경우, 각 구획은 다른 사용자의 자격 증명에 접근할 수 없는 단일 사용자를 가진 별도의 인증자로 간주됩니다.

승인 제스처

승인 제스처는 사용자가 등록 또는 인증과 같은 절차의 일부로 인증자와 수행하는 물리적 상호 작용입니다. 이러한 승인 제스처를 수행함으로써 사용자는 절차가 진행되도록 동의(즉, 승인)합니다. 사용된 인증자가 이를 지원하는 경우 사용자 검증이 포함될 수 있으며(MAY), 또는 단순한 사용자 존재 여부 테스트가 포함될 수 있습니다(MAY).

백업됨

공개 키 자격 증명 소스는 해당 소스를 생성한 인증자 이외의 인증자에도 존재할 수 있도록 어떤 방식으로든 백업될 수 있습니다. 백업은 P2P 동기화, 클라우드 동기화, 로컬 네트워크 동기화 및 수동 가져오기/내보내기를 포함하되 이에 국한되지 않는 메커니즘을 통해 이루어질 수 있습니다. § 6.1.3 자격 증명 백업 상태도 참조하십시오.

백업 가능 여부

백업 가능

공개 키 자격 증명 소스의 생성 인증자는 공개 키 자격 증명 소스가 백업될 수 있는지를 생성 시점에 결정합니다. 백업 가능 여부는 현재 백업 상태와 함께 인증자 데이터의 플래그에 표시됩니다. 백업 가능 여부는 자격 증명 속성이며 지정된 공개 키 자격 증명 소스에 대해 영구적입니다. 백업 가능한 공개 키 자격 증명 소스는 다중 기기 자격 증명이라고 하며, 백업 가능하지 않은 것은 단일 기기 자격 증명이라고 합니다. § 6.1.3 자격 증명 백업 상태도 참조하십시오.

백업 상태

현재 관리 인증자가 결정하는 다중 기기 자격 증명의 현재 백업 상태입니다. 백업 상태는 인증자 데이터의 플래그에 표시되며 시간이 지남에 따라 변경될 수 있습니다. 백업 가능 여부 및 § 6.1.3 자격 증명 백업 상태도 참조하십시오.

생체 인증자

생체 인식을 구현하는 모든 인증자입니다.

생체 인식

개인의 생물학적 및 행동적 특성을 기반으로 개인을 자동으로 인식하는 것입니다 [ISOBiometricVocabulary].

바인딩된 자격 증명

"인증자가 자격 증명을 포함합니다"

"인증자에서 생성된 자격 증명"

공개 키 자격 증명 소스 또는 공개 키 자격 증명은 해당 관리 인증자에 바인딩되어 있다고 합니다. 이는 관리 인증자만 자신에게 바인딩된 공개 키 자격 증명 소스에 대한 어설션을 생성할 수 있음을 의미합니다.

이는 또한 "관리 인증자가 바인딩된 자격 증명을 포함합니다", 또는 "바인딩된 자격 증명이 해당 관리 인증자에서 생성되었습니다"라고 표현할 수도 있습니다. 다만 서버 측 자격 증명은 인증자 내부의 영구 메모리에 물리적으로 저장되지 않을 수 있으므로 "바인딩됨"이 기본 용어입니다. § 6.2.2 자격 증명 저장 방식을 참조하십시오.

절차

절차라는 개념 [Ceremony]은 네트워크 프로토콜 개념을 확장한 것으로, 컴퓨터 노드뿐 아니라 인간 노드도 포함하며 통신 링크에는 사용자 인터페이스, 사람 간 통신 및 데이터를 운반하는 물리적 객체의 전달이 포함됩니다. 프로토콜에서 대역 외인 것은 절차에서는 대역 내입니다. 이 명세에서는 등록과 인증이 절차이며, 승인 제스처는 흔히 이러한 절차의 구성 요소입니다.

클라이언트

WebAuthn 클라이언트

이 문서에서는 단순히 클라이언트라고도 합니다. 적합한 사용자 에이전트도 참조하십시오. WebAuthn 클라이언트는 일반적으로 사용자 에이전트에서 전체 또는 일부가 구현되는 중개 엔터티입니다. 개념적으로 웹 인증 API의 기반이 되며 [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드의 구현을 포함합니다. 이는 기반 인증자 작업의 입력을 마샬링하고, 후자의 작업 결과를 웹 인증 API 호출자에게 반환하는 작업 모두를 담당합니다.

WebAuthn 클라이언트는 WebAuthn 클라이언트 기기에서 실행되며, 그 기기와는 별개의 개체입니다.

클라이언트 기기

WebAuthn 클라이언트 기기

WebAuthn 클라이언트가 실행되는 하드웨어 기기(예: 스마트폰, 노트북 컴퓨터 또는 데스크톱 컴퓨터)와 해당 하드웨어에서 실행되는 운영 체제입니다.

WebAuthn 클라이언트 기기와 클라이언트의 차이점은 다음과 같습니다.

하나의 클라이언트 기기는 여러 클라이언트, 즉 브라우저 구현을 실행할 수 있으며(MAY), 이들 모두는 해당 클라이언트 기기에서 사용할 수 있는 동일한 인증자에 접근할 수 있습니다. 그리고
플랫폼 인증자는 WebAuthn 클라이언트가 아니라 클라이언트 기기에 바인딩됩니다.

클라이언트 기기와 클라이언트는 함께 클라이언트 플랫폼을 구성합니다.

클라이언트 플랫폼

클라이언트 기기와 클라이언트는 함께 클라이언트 플랫폼을 구성합니다. 하나의 하드웨어 기기는 서로 다른 운영 체제 및/또는 클라이언트를 실행함으로써 서로 다른 시점에 여러 별개의 클라이언트 플랫폼의 일부가 될 수 있습니다(MAY).

클라이언트 측

일반적으로 사용자의 클라이언트 플랫폼, 인증자 및 이 모든 것을 서로 연결하는 모든 요소의 조합을 의미합니다.

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

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

검색 가능한 자격 증명

패스키

[사용 중단됨] 상주 자격 증명

[사용 중단됨] 상주 키

참고: 역사적으로 클라이언트 측에서 검색 가능한 자격 증명은 상주 자격 증명 또는 상주 키라고 알려져 왔습니다. ResidentKey 및 residentKey라는 표현은 WebAuthn API와 인증자 모델 모두에서 널리 사용되므로(예: 딕셔너리 멤버 이름, 알고리즘 변수 이름 및 작업 매개변수) 하위 호환성을 위해 해당 이름 내 resident의 사용은 변경되지 않았습니다. 또한 상주 키라는 용어는 클라이언트 측에서 검색 가능한 자격 증명과 동등한 것으로 여기에서 정의됩니다.

클라이언트 측에서 검색 가능한 공개 키 자격 증명 소스, 줄여서 검색 가능한 자격 증명은 신뢰 당사자가 어떤 자격 증명 ID도 제공하지 않는 인증 절차에서 검색 가능하고 사용할 수 있는 공개 키 자격 증명 소스입니다. 즉, 신뢰 당사자는 빈 allowCredentials 인수와 함께 navigator.credentials.get()을 호출합니다. 이는 신뢰 당사자가 반드시 사용자를 먼저 식별할 필요는 없음을 의미합니다.

따라서 검색 가능한 자격 증명을 지원하는 인증자는 RP ID만 주어져도 검색 가능한 자격 증명에 대한 어설션 서명을 생성할 수 있으며, 이로 인해 공개 키 자격 증명 소스는 인증자 또는 클라이언트 플랫폼에 저장되어야 합니다. 이는 서버 측 공개 키 자격 증명 소스와 대조됩니다. 서버 측 공개 키 자격 증명 소스는 인증자에 RP ID와 자격 증명 ID가 모두 제공되어야 하지만, 공개 키 자격 증명 소스를 클라이언트 측에 저장할 필요는 없습니다.

다음도 참조하십시오. 클라이언트 측 자격 증명 저장 방식 및 검색 불가능한 자격 증명.

참고: 클라이언트 측에서 검색 가능한 자격 증명은 자격 증명 ID가 제공되는 인증 절차에서도 사용할 수 있습니다. 즉, 비어 있지 않은 allowCredentials 인수와 함께 navigator.credentials.get()을 호출하는 경우입니다. 여기서 비어 있지 않은 상태를 의미합니다.

적합한 사용자 에이전트

기반 클라이언트 기기와 협력하여 웹 인증 API와 이 명세에 제시된 알고리즘을 구현하고, 인증자와 신뢰 당사자 간의 통신을 처리하는 사용자 에이전트입니다.

자격 증명 ID

공개 키 자격 증명 소스와 그 인증 어설션을 식별하는 확률적으로 고유한 바이트 시퀀스입니다. 최대 길이는 1023바이트입니다.

자격 증명 ID는 인증자가 다음 두 가지 형태로 생성합니다.

최소 100비트의 엔트로피를 포함하는 최소 16바이트, 또는
공개 키 자격 증명 소스에서 해당 자격 증명 ID 및 변경 가능한 항목을 제외한 뒤, 해당 관리 인증자만 복호화할 수 있도록 암호화한 형태입니다. 이 형태를 사용하면 신뢰 당사자가 필요한 모든 상태를 저장하도록 함으로써 인증자가 거의 무상태로 동작할 수 있습니다.

참고: [FIDO-UAF-AUTHNR-CMDS]에는 "보안 지침" 아래에 암호화 기법에 대한 지침이 포함되어 있습니다.

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

자격 증명 키 쌍

자격 증명 개인 키

자격 증명 공개 키

사용자 공개 키

자격 증명 키 쌍은 인증자가 생성하고 특정 WebAuthn 신뢰 당사자의 범위로 지정된 비대칭 암호화 키의 쌍입니다. 이는 공개 키 자격 증명의 핵심 부분입니다.

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

자격 증명 개인 키는 자격 증명 키 쌍의 개인 키 부분입니다. 자격 증명 개인 키는 특정 인증자, 즉 해당 관리 인증자에 바인딩되며, 인증자의 소유자에게조차 다른 어떤 당사자에게도 절대로 노출되지 않을 것으로 기대됩니다.

자체 증명의 경우 자격 증명 키 쌍이 증명 키 쌍으로도 사용된다는 점에 유의하십시오. 자세한 내용은 자체 증명을 참조하십시오.

참고: 자격 증명 공개 키는 FIDO UAF [UAFProtocol] 및 FIDO U2F [FIDO-U2F-Message-Formats], 그리고 이와 관련된 이 명세의 일부에서 사용자 공개 키라고 합니다.

자격 증명 속성

자격 증명 속성은 공개 키 자격 증명 소스의 어떤 특성으로, 예를 들어 해당 소스가 클라이언트 측에서 검색 가능한 자격 증명인지 또는 서버 측 자격 증명인지와 같은 속성입니다.

자격 증명 레코드

§ 7 WebAuthn 신뢰 당사자 작업에 정의된 알고리즘을 구현하려면, 신뢰 당사자는 등록된 공개 키 자격 증명 소스의 일부 속성을 저장해야 합니다(MUST). 자격 증명 레코드 구조체는 사용자 계정에 저장된 이러한 속성을 추상화한 것입니다. 자격 증명 레코드는 등록 절차 중 생성되고 이후의 인증 절차에서 사용됩니다. 신뢰 당사자는 필요하거나 사용자가 요청한 경우 자격 증명 레코드를 삭제할 수 있습니다(MAY).

정의된 대로 § 7.1 새 자격 증명 등록 및 § 7.2 인증 어설션 검증의 모든 단계를 구현하려면 다음 항목을 사용하는 것이 권장됩니다(RECOMMENDED).

type

공개 키 자격 증명 소스의 유형입니다.

id

공개 키 자격 증명 소스의 자격 증명 ID입니다.

publicKey

공개 키 자격 증명 소스의 자격 증명 공개 키입니다.

signCount

공개 키 자격 증명 소스를 사용하는 모든 절차의 인증자 데이터에서 가장 최근의 서명 카운터 값입니다.

transports

공개 키 자격 증명 소스가 등록되었을 때 getTransports()에서 반환된 값입니다.

참고: getTransports()에서 반환된 값의 항목을 수정하거나 제거하면 사용자 경험에 부정적인 영향을 미치거나, 해당 자격 증명을 사용할 수 없게 될 수도 있습니다.

uvInitialized

이 공개 키 자격 증명 소스의 어떤 자격 증명에서든 UV 플래그가 설정된 적이 있는지를 나타내는 Boolean 값입니다.

이 값이 true이면 신뢰 당사자는 인증 절차에서 UV 플래그를 인증 요소로 간주할 수 있습니다(MAY). 예를 들어 uvInitialized가 true이고 UV 플래그가 설정되어 있으면, 사용자 검증이 요구되지 않았더라도 신뢰 당사자는 암호 프롬프트를 생략할 수 있습니다.

이 값이 false인 경우에는, 이 값이 true로 업데이트되는 인증 절차를 포함하여, UV 플래그를 인증 요소로 신뢰해서는 안 됩니다(MUST NOT). 이는 공개 키 자격 증명 소스가 처음으로 UV 플래그를 1로 설정할 때, 아직 신뢰 당사자와 인증자의 사용자 검증 간에 신뢰 관계가 수립되지 않았기 때문입니다. 따라서 uvInitialized를 false에서 true로 업데이트하려면 WebAuthn 사용자 검증과 동등한 추가 인증 요소에 의한 승인이 필요합니다(SHOULD).

backupEligible

공개 키 자격 증명 소스가 생성되었을 때 BE 플래그의 값입니다.

backupState

공개 키 자격 증명 소스를 사용하는 모든 절차의 인증자 데이터에 있는 BS 플래그의 가장 최근 값입니다.

다음 항목은 선택 사항입니다(OPTIONAL).

attestationObject: 공개 키 자격 증명 소스가 등록되었을 때의 attestationObject 속성 값입니다. 이를 저장하면 신뢰 당사자가 나중에 자격 증명의 증명문을 참조할 수 있습니다.
attestationClientDataJSON: 공개 키 자격 증명 소스가 등록되었을 때의 clientDataJSON 속성 값입니다. 위의 attestationObject 항목과 함께 이를 저장하면 신뢰 당사자가 나중에 증명 서명을 다시 검증할 수 있습니다.
rpId: 자격 증명 등록 중 create() 작업에서 지정된 rp.id 매개변수의 값입니다. 이 값은 자격 증명을 어디에서 사용할 수 있는지를 결정하는 자격 증명의 핵심 속성입니다. 등록 시 이 값을 저장하면 향후 사용 내역을 감사하거나, 이 자격 증명으로 인증할 때 발생하는 문제를 해결하거나, 나중에 관련 오리진을 통해 서로 다른 도메인에서 사용하는 등의 작업에 도움이 될 수 있습니다.

WebAuthn 확장은 확장 처리에 필요한 추가 항목을 정의할 수 있습니다(MAY). 신뢰 당사자는 필요에 따라 추가 항목을 포함할 수도 있으며(MAY), 구현에 필요하지 않은 항목은 생략할 수도 있습니다(MAY).

자격 증명 레코드의 자격 증명 설명자는 다음 내용을 가진 PublicKeyCredentialDescriptor 값입니다.

type: 자격 증명 레코드의 type입니다.
id: 자격 증명 레코드의 id입니다.
transports: 자격 증명 레코드의 transports입니다.

생성 인증자

생성 인증자는 지정된 공개 키 자격 증명 소스를 생성한 authenticatorMakeCredential 작업에 관여한 인증자입니다. 생성 인증자는 단일 기기 자격 증명의 경우 관리 인증자와 동일합니다. 다중 기기 자격 증명의 경우 생성 인증자는 지정된 인증 작업에 참여하는 현재 관리 인증자와 같을 수도 있고 다를 수도 있습니다.

사람 친화성

사람에게 친숙한 식별자는, 예를 들어 무작위로 생성된 비트 시퀀스와 같은 식별자와 달리 일반적인 사용자가 기억하고 재현할 수 있도록 의도된 식별자입니다 [EduPersonObjectClassSpec].

검색 불가능한 자격 증명

이는 클라이언트 측에서 검색 가능하지 않기 때문에 navigator.credentials.get()을 호출할 때 해당 자격 증명 ID를 allowCredentials에 제공해야 하는 자격 증명입니다. 서버 측 자격 증명도 참조하십시오.

등록 가능한 오리진 레이블

도메인의 등록 가능한 도메인에서 첫 번째 도메인 레이블이며, 등록 가능한 도메인이 null이면 null입니다. 예를 들어 co.uk와 de가 모두 공개 접미사인 경우, example.co.uk와 www.example.de의 등록 가능한 오리진 레이블은 모두 example입니다.

공개 키 자격 증명

일반적으로 자격 증명은 한 엔터티가 자신을 다른 엔터티에 인증하기 위해 제시하는 데이터입니다 [RFC4949]. 공개 키 자격 증명이라는 용어는 다음 중 하나를 가리킵니다. 공개 키 자격 증명 소스, 공개 키 자격 증명 소스에 대응하며 선택적으로 증명된 자격 증명 공개 키, 또는 인증 어설션입니다. 일반적으로 어떤 것을 의미하는지는 문맥에 따라 결정됩니다.

참고: 이는 [RFC4949]에 대한 의도적인 위반입니다. 영어에서 "credential"은 a) 어떤 진술을 증명하기 위해 제시되는 것인 동시에 b) 여러 번 사용되도록 의도된 것을 의미합니다. 공개 키 시스템에서 단일 데이터 조각으로 이 두 기준을 모두 안전하게 충족하는 것은 불가능합니다. [RFC4949]는 자격 증명을 여러 번 사용할 수 있는 것(공개 키)으로 정의하는 반면, 이 명세에서는 "credential"에 영어 용어가 가진 유연성을 부여합니다. 이 명세는 [RFC4949] 자격 증명과 관련된 데이터를 식별하기 위해 더 구체적인 용어를 사용합니다.

"인증 정보"(개인 키를 포함할 수 있음): 공개 키 자격 증명 소스
"서명된 값": 인증 어설션
[RFC4949] "자격 증명": 자격 증명 공개 키 또는 증명 객체

등록 시, 인증자는 비대칭 키 쌍을 생성하고, 그 개인 키 부분과 신뢰 당사자의 정보를 공개 키 자격 증명 소스에 저장합니다. 공개 키 부분은 신뢰 당사자에게 반환되며, 신뢰 당사자는 이를 활성 사용자 계정에 저장합니다. 그 후에는 RP ID로 식별되는 해당 신뢰 당사자만이 get() 메서드를 통해 인증 절차에서 공개 키 자격 증명을 사용할 수 있습니다. 신뢰 당사자는 저장된 자격 증명 공개 키 사본을 사용하여 결과 인증 어설션을 검증합니다.

공개 키 자격 증명 소스

인증자가 인증 어설션을 생성하는 데 사용하는 자격 증명 소스([CREDENTIAL-MANAGEMENT-1])입니다. 공개 키 자격 증명 소스는 다음 항목을 가진 구조체로 구성됩니다.

type: 값의 유형은 PublicKeyCredentialType이며, 기본값은 public-key입니다.
id: 자격 증명 ID입니다.
privateKey: 자격 증명 개인 키입니다.
rpId: 이 공개 키 자격 증명 소스의 범위가 지정된 신뢰 당사자에 대한 신뢰 당사자 식별자입니다. 이는 create() 작업의 rp.id 매개변수에 의해 결정됩니다.
userHandle: 이 공개 키 자격 증명 소스가 생성될 때 연결된 사용자 핸들입니다. 이 항목에는 null을 사용할 수 있지만, 검색 가능한 자격 증명의 경우에는 사용자 핸들이 항상 채워져 있어야 합니다(MUST).
otherUI: 인증자가 자신의 UI에 정보를 제공하는 데 사용하는 선택적(OPTIONAL) 기타 정보입니다. 예를 들어 사용자의 displayName을 포함할 수 있습니다. otherUI는 변경 가능한 항목이며, otherUI가 업데이트되지 못하게 하는 방식으로 공개 키 자격 증명 소스에 바인딩해서는 안 됩니다(SHOULD NOT).

authenticatorMakeCredential 작업은 관리 인증자에 바인딩된 공개 키 자격 증명 소스를 생성하고, 해당 자격 증명 개인 키와 연결된 자격 증명 공개 키를 반환합니다. 신뢰 당사자는 이 자격 증명 공개 키를 사용하여 이 공개 키 자격 증명 소스가 생성한 인증 어설션을 검증할 수 있습니다.

요청 제한

지정된 시간 동안 연속된 인증 실패 시도 횟수를 제한하여 인증자가 무차별 대입 공격에 대한 제어를 구현하는 프로세스(스로틀링이라고도 함)입니다. 제한에 도달하면 인증자는 연속된 시도마다 지수적으로 증가하는 지연을 적용하거나, 현재 인증 방식을 비활성화하고 사용 가능한 경우 다른 인증 요소를 제공해야 합니다. 요청 제한은 흔히 사용자 검증의 한 측면으로 구현됩니다.

등록

등록 절차

사용자, 신뢰 당사자, 그리고 사용자의 클라이언트 플랫폼(하나 이상의 인증자를 포함하거나 이에 연결됨)이 함께 협력하여 공개 키 자격 증명을 생성하고 이를 사용자 계정과 연결하는 절차입니다. 여기에는 사용자 존재 여부 테스트 또는 사용자 검증의 사용이 포함됩니다. 등록 절차가 성공한 후에는 사용자를 인증 절차를 통해 인증할 수 있습니다.

WebAuthn 등록 절차는 § 7.1 새 자격 증명 등록에 정의되어 있으며, 신뢰 당사자가 publicKey 인수와 함께 navigator.credentials.create() 작업을 호출함으로써 시작됩니다. 소개 개요는 § 5 웹 인증 API를, 구현 예시는 § 1.3.1 등록을 참조하십시오.

신뢰 당사자

WebAuthn 신뢰 당사자

자신의 웹 애플리케이션이 웹 인증 API를 사용하여 사용자를 등록하고 인증하는 엔터티입니다.

신뢰 당사자 구현은 일반적으로 클라이언트에서 웹 인증 API를 호출하는 클라이언트 측 스크립트와, 신뢰 당사자 작업 및 기타 애플리케이션 로직을 실행하는 서버 측 구성 요소로 이루어집니다. 두 구성 요소 간 통신은 HTTPS 또는 동등한 전송 보안을 사용해야 하지만(MUST), 그 외의 사항은 이 명세의 범위를 벗어납니다.

참고: 신뢰 당사자라는 용어는 다른 맥락(예: X.509 및 OAuth)에서도 자주 사용되지만, 한 맥락에서 신뢰 당사자로 작동하는 엔터티가 다른 맥락에서도 반드시 신뢰 당사자인 것은 아닙니다. 이 명세에서는 WebAuthn 신뢰 당사자라는 용어를 흔히 단순히 신뢰 당사자로 줄여 사용하며, WebAuthn 맥락의 신뢰 당사자를 명시적으로 가리킵니다. 구체적인 구현에서는 WebAuthn 맥락이 더 넓은 전체 맥락, 예를 들어 OAuth 기반 맥락에 포함될 수 있다는 점에 유의하십시오.

신뢰 당사자 식별자

RP ID

WebAuthn API의 맥락에서 신뢰 당사자 식별자는 지정된 등록 또는 인증 절차가 대신 수행되는 WebAuthn 신뢰 당사자를 식별하는 유효한 도메인 문자열입니다. 공개 키 자격 증명은 등록 당시와 동일한 엔터티(RP ID로 식별됨)에 대한 인증에만 사용할 수 있습니다.

기본적으로 WebAuthn 작업의 RP ID는 호출자의 오리진의 유효 도메인으로 설정됩니다. 호출자가 지정한 RP ID 값이 호출자의 오리진의 유효 도메인과 같거나 등록 가능한 도메인 접미사인 한, 호출자는 이 기본값을 재정의할 수 있습니다(MAY). § 5.1.3 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드 및 § 5.1.4 기존 자격 증명을 사용하여 어설션 생성도 참조하십시오.

RP ID는 호스트의 도메인 이름을 기반으로 합니다. 오리진과 달리 그 자체에는 스킴이나 포트가 포함되지 않습니다. 공개 키 자격 증명의 RP ID는 해당 자격 증명의 범위를 결정합니다. 즉, 다음과 같이 공개 키 자격 증명을 사용할 수 있는 오리진의 집합을 결정합니다.

RP ID는 오리진의 유효 도메인과 같거나, 오리진의 유효 도메인의 등록 가능한 도메인 접미사여야 합니다.
다음 중 하나가 참이어야 합니다.
- 오리진의 스킴이 https입니다.
- 오리진의 호스트가 localhost이고 그 스킴이 http입니다.
오리진의 포트는 제한되지 않습니다.

예를 들어 오리진이 https://login.example.com:1337인 신뢰 당사자가 주어졌다면 다음 RP ID는 유효합니다. login.example.com(기본값) 및 example.com. 그러나 m.login.example.com과 com은 유효하지 않습니다. 또 다른 유효한 오리진의 예는 http://localhost:8000이며, 이는 오리진이 localhost이기 때문입니다.

이는 광범위하게 배포된 주변 자격 증명(예: 쿠키, [RFC6265])의 동작과 일치시키기 위한 것입니다. 이는 document.domain의 설정자가 제공하는 것보다 "동일 오리진" 제한을 더 크게 완화한다는 점에 유의하십시오.

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

Web이 아닌 플랫폼(예: 네이티브 모바일 애플리케이션)에서 WebAuthn 공개 키 자격 증명을 사용하도록 WebAuthn API를 모방하는 다른 명세는 호출자를 신뢰 당사자 식별자에 바인딩하는 서로 다른 규칙을 정의할 수 있습니다(MAY). 다만 RP ID 구문은 유효한 도메인 문자열 또는 URI [RFC3986] [URL] 중 하나를 준수해야 합니다(MUST).

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

서버 측 자격 증명

[사용 중단됨] 비상주 자격 증명

참고: 역사적으로 서버 측 자격 증명은 비상주 자격 증명이라고 알려져 왔습니다. 하위 호환성을 위해, 이름에 다양한 형태의 resident가 포함된 여러 WebAuthn API 및 인증자 모델 구성 요소는 변경되지 않았습니다.

서버 측 공개 키 자격 증명 소스, 줄여서 서버 측 자격 증명은 신뢰 당사자가 navigator.credentials.get()의 allowCredentials 인수에 해당 자격 증명 ID를 제공하는 경우에만 인증 절차에서 사용할 수 있는 공개 키 자격 증명 소스입니다. 이는 신뢰 당사자가 자격 증명의 저장 및 검색을 관리해야 하며, navigator.credentials.get() 호출에 제공할 자격 증명 ID를 찾기 위해 먼저 사용자를 식별할 수 있어야 함을 의미합니다.

서버 측 자격 증명에서는 공개 키 자격 증명 소스를 클라이언트 측에 저장할 필요가 없습니다. 이는 클라이언트 측에서 검색 가능한 자격 증명과 대조됩니다. 후자의 경우에는 사용자의 자격 증명 ID를 navigator.credentials.get() 호출에 제공하기 위해 사용자를 먼저 식별할 필요가 없습니다.

다음도 참조하십시오. 서버 측 자격 증명 저장 방식 및 검색 불가능한 자격 증명.

사용자 존재 여부 테스트

사용자 존재 여부 테스트는 사용자가 인증자를 일반적으로 단순히 터치하여(다른 방식도 존재할 수 있음) 상호 작용하고 Boolean 결과를 얻는 단순한 형태의 승인 제스처이자 기술적 프로세스입니다. 이는 사용자 검증에 해당하지 않는다는 점에 유의하십시오. 정의상 사용자 존재 여부 테스트는 생체 인식을 수행할 수 없으며, 암호나 PIN과 같은 공유 비밀의 제시도 포함하지 않기 때문입니다.

사용자 계정

이 명세의 맥락에서 사용자 계정은 신뢰 당사자가 유지하고 승인하는, 자격 증명 집합 [CREDENTIAL-MANAGEMENT-1]과 신뢰 당사자 리소스의 (부분) 집합 간 매핑을 나타냅니다. 신뢰 당사자는 지정된 공개 키 자격 증명의 사용자 핸들에 사용자 계정별 값을 할당하고, 해당 자격 증명에 대한 자격 증명 레코드를 사용자 계정에 저장함으로써 해당 자격 증명을 사용자 계정에 매핑합니다. 이 매핑, 자격 증명 집합 및 해당 권한은 시간이 지남에 따라 변경될 수 있습니다. 지정된 사용자 계정에는 한 명 이상의 자연인("사용자"라고도 함)이 접근할 수 있으며, 한 자연인은 사용자와 신뢰 당사자의 동작에 따라 하나 이상의 사용자 계정에 접근할 수 있습니다.

사용자 동의

사용자 동의란 사용자가 요청받은 내용에 동의한다는 의미이며, 즉 프롬프트를 읽고 이해하는 것을 포함합니다. 승인 제스처는 사용자 동의를 나타내기 위해 흔히 사용되는 절차의 구성 요소입니다.

사용자 핸들

사용자 핸들은 사용자 계정의 식별자로, 신뢰 당사자가 등록 중 user.id로 지정합니다. 검색 가능한 자격 증명은 이 식별자를 저장하고, 빈 allowCredentials 인수로 시작된 인증 절차에서는 이를 response.userHandle로 반환해야 합니다(MUST).

사용자 핸들의 주된 용도는 이러한 인증 절차에서 사용자 계정을 식별하는 것이지만, 대신 자격 증명 ID를 사용할 수도 있습니다. 주요 차이점은 자격 증명 ID는 인증자가 선택하고 각 자격 증명마다 고유하지만, 사용자 핸들은 신뢰 당사자가 선택하며 동일한 사용자 계정에 등록된 모든 자격 증명에서 동일한 것이 바람직합니다.

인증자는 RP ID와 사용자 핸들의 쌍을 공개 키 자격 증명 소스에 매핑합니다. 따라서 인증자는 신뢰 당사자별, 사용자 핸들별로 최대 하나의 검색 가능한 자격 증명만 저장합니다. 따라서 사용자 핸들의 두 번째 용도는 인증자가 등록 절차 중 기존 검색 가능한 자격 증명을 새 것으로 교체해야 하는 시점을 알 수 있도록 하는 것입니다.

사용자 핸들은 최대 64바이트 크기의 불투명한 바이트 시퀀스이며 사용자에게 표시하기 위한 것이 아닙니다. 개인 식별 정보를 포함해서는 안 됩니다(MUST NOT). § 14.6.1 사용자 핸들 내용을 참조하십시오.

사용자 존재

사용자 존재 여부 테스트가 성공적으로 완료되면 사용자는 "존재합니다"라고 합니다.

사용자 검증

인증자가 authenticatorMakeCredential 및 authenticatorGetAssertion 작업의 호출을 로컬에서 승인하는 기술적 프로세스입니다. 사용자 검증은 다양한 승인 제스처 방식을 통해 시작될 수 있습니다(MAY). 예를 들어 터치와 PIN 코드 입력, 암호 입력 또는 생체 인식(예: 지문 제시) [ISOBiometricVocabulary] 등이 있습니다. 그 목적은 개별 사용자를 구별하는 것입니다. § 6.2.3 인증 요소 기능도 참조하십시오.

사용자 검증은 신뢰 당사자에게 사용자의 구체적인 신원을 제공하지 않지만, 해당 자격 증명을 사용하여 사용자 검증이 포함된 절차를 2회 이상 수행했다면 모든 절차를 동일한 사용자가 수행했음을 나타냅니다. 다만 여러 자연인이 동일한 인증자에 대한 접근 권한을 공유하는 경우 동일한 사용자가 항상 동일한 자연인을 의미하지는 않을 수 있습니다.

참고: 자연인을 구별하는 것은 상당 부분 클라이언트 플랫폼과 인증자의 기능에 달려 있습니다. 예를 들어 일부 기기는 한 사람만 사용하도록 의도되지만, 여러 자연인이 지문을 등록하거나 동일한 PIN을 알고 그 기기를 사용하여 동일한 사용자 계정에 접근하는 것을 허용할 수 있습니다.

참고: authenticatorMakeCredential 및 authenticatorGetAssertion 작업의 호출은 인증자가 관리하는 키 자료의 사용을 의미합니다.

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

사용자 검증 절차는 무차별 대입 공격으로부터 보호하기 위해 요청 제한을 구현할 수 있습니다(MAY).

사용자 검증됨

사용자 검증 프로세스가 성공적으로 완료되면 사용자는 "검증되었습니다"라고 합니다.

5. 웹 인증 API

이 절에서는 공개 키 자격 증명을 생성하고 사용하는 API를 규범적으로 명시합니다. 기본 개념은 자격 증명이 사용자에게 속하며 관리를 WebAuthn 인증자가 담당하고, WebAuthn 신뢰 당사자는 클라이언트 플랫폼을 통해 인증자와 상호 작용한다는 것입니다. 신뢰 당사자 스크립트는 (사용자의 동의를 받아) 브라우저에 향후 신뢰 당사자가 사용할 새 자격 증명을 생성하도록 요청할 수 있습니다. 아래 그림 을 참조하십시오.

스크립트는 기존 자격 증명으로 인증 작업을 수행하기 위한 사용자의 허가를 요청할 수도 있습니다. 아래 그림 을 참조하십시오.

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

위의 스크립트 인터페이스 외에도 인증자는 관리를 위한 사용자 인터페이스를 구현할 수도 있고(MAY), 그러한 인터페이스를 구현하는 클라이언트 소프트웨어와 함께 제공될 수도 있습니다. 이러한 인터페이스는 예를 들어 인증자를 초기 상태로 재설정하거나 인증자의 현재 상태를 검사하는 데 사용될 수 있습니다(MAY). 즉, 이러한 인터페이스는 브라우저가 기록, 저장된 암호 및 쿠키와 같은 사용자 상태를 관리하기 위해 제공하는 사용자 인터페이스와 유사합니다. 자격 증명 삭제와 같은 인증자 관리 작업은 이러한 사용자 인터페이스의 책임으로 간주되며 스크립트에 노출되는 API에서는 의도적으로 제외됩니다.

이 API의 보안 속성은 클라이언트와 인증자가 함께 작동하여 제공합니다. 자격 증명을 보유하고 관리하는 인증자는 모든 작업이 특정 오리진의 범위로 지정되고, 응답에 오리진을 포함시켜 다른 오리진에 대해 재사용될 수 없도록 보장합니다. 구체적으로 § 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 인터페이스는 Credential [CREDENTIAL-MANAGEMENT-1]에서 상속되며, 새 자격 증명이 생성되거나 새 어설션이 요청될 때 호출자에게 반환되는 속성을 포함합니다.

[SecureContext, Exposed=Window]
interface PublicKeyCredential : Credential {
    [SameObject] readonly attribute ArrayBuffer              rawId;
    [SameObject] readonly attribute AuthenticatorResponse    response;
    readonly attribute DOMString?                            authenticatorAttachment;
    AuthenticationExtensionsClientOutputs getClientExtensionResults();
    static Promise<boolean> isConditionalMediationAvailable();
    PublicKeyCredentialJSON toJSON();
};

id

이 속성은 Credential에서 상속되지만, PublicKeyCredential은 Credential의 getter를 재정의하여, 대신 객체의 [[identifier]] 내부 슬롯에 포함된 데이터의 base64url 인코딩을 반환합니다.

rawId

이 속성은 [[identifier]] 내부 슬롯에 포함된 ArrayBuffer를 반환합니다.

response, 유형은 AuthenticatorResponse, 읽기 전용

이 속성은 공개 키 자격 증명을 생성하거나 인증 어설션을 생성하라는 클라이언트의 요청에 대한 인증자의 응답을 포함합니다. PublicKeyCredential이 create()에 대한 응답으로 생성된 경우, 이 속성의 값은 AuthenticatorAttestationResponse이 됩니다. 그렇지 않은 경우에는 PublicKeyCredential이 get()에 대한 응답으로 생성된 것이며, 이 속성의 값은 AuthenticatorAssertionResponse이 됩니다.

authenticatorAttachment, 유형은 DOMString, 읽기 전용, null 허용

이 속성은 navigator.credentials.create() 또는 navigator.credentials.get() 메서드가 성공적으로 완료되는 시점에 적용된 인증자 연결 방식을 보고합니다. 이 속성의 값은 AuthenticatorAttachment의 멤버여야 합니다(SHOULD). 신뢰 당사자는 알 수 없는 값을 null인 것처럼 처리해야 합니다(SHOULD).

참고: 등록 또는 인증 절차의 결과로 authenticatorAttachment의 값이 "cross-platform"이고 동시에 isUserVerifyingPlatformAuthenticatorAvailable이 true를 반환한다면, 사용자는 사용 가능한 플랫폼 인증자가 있는 상태에서 이 절차에 로밍 인증자를 사용한 것입니다. 따라서 신뢰 당사자는 사용 가능한 플랫폼 인증자를 등록하도록 사용자에게 안내할 기회를 얻으며, 이를 통해 보다 간소화된 사용자 경험 흐름을 제공할 수 있습니다.

인증자의 연결 방식은 시간이 지나면서 바뀔 수 있습니다. 예를 들어 휴대전화는 처음에는 플랫폼 연결만 지원하다가 나중에 업데이트를 통해 교차 플랫폼 연결도 지원할 수 있습니다.

getClientExtensionResults()

이 작업은 [[clientExtensionsResults]]의 값을 반환합니다. 이는 확장의 클라이언트 확장 처리에서 생성된 확장 식별자 → 클라이언트 확장 출력 항목을 포함하는 맵입니다.

isConditionalMediationAvailable()

PublicKeyCredential은 이 메서드를 재정의하여 navigator.credentials.get() 중 conditional 중재의 사용 가능 여부를 나타냅니다. WebAuthn 신뢰 당사자는 options.mediation을 conditional로 설정하려고 하기 전에 사용 가능 여부를 확인해야 합니다(SHOULD).

호출되면 conditional 사용자 중재가 가능하면 true로, 그렇지 않으면 false로 이행되는 promise가 반환됩니다.

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

conditionalGet 기능은 이 promise가 true로 이행되는 것과 동등합니다.

참고: 이 메서드가 존재하지 않으면 conditional 사용자 중재는 navigator.credentials.get()에서 사용할 수 없습니다.

참고: 이 메서드는 navigator.credentials.create()에서 conditional 사용자 중재를 사용할 수 있는지 여부는 나타내지 않습니다. 이에 대해서는 getClientCapabilities()의 conditionalCreate 기능을 참조하십시오.

toJSON()

이 작업은 RegistrationResponseJSON 또는 AuthenticationResponseJSON을 반환합니다. 이들은 PublicKeyCredential을 반영하는 JSON 유형 표현이며, 신뢰 당사자 서버에 application/json 페이로드로 제출하기에 적합합니다. 클라이언트는 일반적인 방식으로 값을 JSON 유형으로 직렬화하는 일을 담당하지만, 먼저 모든 ArrayBuffer 값을 base64url 인코딩을 사용하여 DOMString 값으로 인코딩하는 추가 단계를 수행해야 합니다(MUST).

RegistrationResponseJSON.clientExtensionResults 또는 AuthenticationResponseJSON.clientExtensionResults 멤버는 getClientExtensionResults()의 출력으로 설정되어야 하며(MUST), 모든 ArrayBuffer 값은 base64url 인코딩을 사용하여 DOMString 값으로 인코딩되어야 합니다. 여기에는 IANA "WebAuthn Extension Identifiers" 레지스트리 [IANA-WebAuthn-Registries]에 등록되었지만 § 9 WebAuthn 확장에 정의되지 않은 확장의 ArrayBuffer 값이 포함될 수 있습니다(MAY).

AuthenticatorAttestationResponseJSON.transports 멤버는 getTransports()의 출력으로 설정되어야 합니다(MUST).

AuthenticatorAttestationResponseJSON.publicKey 멤버는 getPublicKey()의 출력으로 설정되어야 합니다(MUST).

AuthenticatorAttestationResponseJSON.publicKeyAlgorithm 멤버는 getPublicKeyAlgorithm()의 출력으로 설정되어야 합니다(MUST).

typedef DOMString Base64URLString;
// 이 객체의 구조는 다음 중 하나가 됩니다
// RegistrationResponseJSON 또는 AuthenticationResponseJSON
typedef object PublicKeyCredentialJSON;

dictionary RegistrationResponseJSON {
    required DOMString id;
    required Base64URLString rawId;
    required AuthenticatorAttestationResponseJSON response;
    DOMString authenticatorAttachment;
    required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;
    required DOMString type;
};

dictionary AuthenticatorAttestationResponseJSON {
    required Base64URLString clientDataJSON;
    required Base64URLString authenticatorData;
    required sequence<DOMString> transports;
    // pubKeyCredParams를 사용하여 사용자 에이전트가
    // 이해하지 못하는 공개 키 알고리즘을 협상한 경우 publicKey 필드가
    // 누락됩니다. (사용자 에이전트가 지원해야 하는 알고리즘 목록은
    // “자격 증명 데이터에 쉽게 접근하기” 절을 참조하십시오.) 이러한
    // 알고리즘을 사용하는 경우 공개 키는 attestationObject 또는
    // authenticatorData에서 직접 파싱해야 합니다.
    Base64URLString publicKey;
    required COSEAlgorithmIdentifier publicKeyAlgorithm;
    // 이 값에는 위 필드 일부의 복사본이 포함됩니다. “자격 증명
    // 데이터에 쉽게 접근하기” 절을 참조하십시오.
    required Base64URLString attestationObject;
};

dictionary AuthenticationResponseJSON {
    required DOMString id;
    required Base64URLString rawId;
    required AuthenticatorAssertionResponseJSON response;
    DOMString authenticatorAttachment;
    required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;
    required DOMString type;
};

dictionary AuthenticatorAssertionResponseJSON {
    required Base64URLString clientDataJSON;
    required Base64URLString authenticatorData;
    required Base64URLString signature;
    Base64URLString userHandle;
};

dictionary AuthenticationExtensionsClientOutputsJSON {
};

[[type]]

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

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

[[discovery]]

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

[[identifier]]

이 내부 슬롯에는 인증자가 선택한 자격 증명 ID가 포함됩니다. 자격 증명 ID는 사용할 자격 증명을 조회하는 데 사용되므로, 모든 인증자에서 동일 유형의 모든 자격 증명 전체에 걸쳐 높은 확률로 전역적으로 고유할 것으로 기대됩니다.

이 API는 이 식별자의 형식을 제한하지 않지만, 길이는 1023바이트를 초과해서는 안 되며(MUST NOT), 인증자가 키를 고유하게 선택하기에 충분해야 합니다(MUST). 예를 들어 온보드 저장소가 없는 인증자는 인증자에 내장된 대칭 키로 감싼 자격 증명 개인 키를 포함하는 식별자를 생성할 수 있습니다.

[[clientExtensionsResults]]

이 내부 슬롯에는 신뢰 당사자가 navigator.credentials.create() 또는 navigator.credentials.get()을 호출할 때 신뢰 당사자가 요청한 클라이언트 확장 처리 결과가 포함됩니다.

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

CredentialsContainer의 preventSilentAccess() 메서드를 호출해도 PublicKeyCredential 자격 증명에는 아무런 영향을 주지 않습니다. 이 자격 증명은 항상 사용자 상호 작용을 요구하기 때문입니다.

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()을 호출하여 인증자에 바인딩된 새 공개 키 자격 증명 소스의 생성을 요청할 수 있습니다.

options.mediation을 conditional로 설정하면, 신뢰 당사자는 사용자가 이미 자격 증명 생성에 동의한 경우 눈에 띄는 모달 UI 없이 자격 증명을 등록하고자 함을 나타낼 수 있습니다. 신뢰 당사자는 이 기능을 사용할 수 없을 때 사용자에게 오류가 표시되는 것을 방지하기 위해 먼저 getClientCapabilities()을 사용하여 클라이언트가 conditionalCreate 기능을 지원하는지 확인해야 합니다(SHOULD). 클라이언트는 절차 중 명시적으로 수행할 수 있는 경우를 제외하고 options.mediation이 conditional로 설정된 경우 requireUserPresence와 requireUserVerification을 모두 FALSE로 설정해야 합니다(MUST).

모든 navigator.credentials.create() 작업은 AbortController를 활용하여 중단할 수 있습니다. 자세한 지침은 DOM § 3.3 API에서 AbortController 및 AbortSignal 객체 사용을 참조하십시오.

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

origin

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

options

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

sameOriginWithAncestors

이 인수는 호출자의 환경 설정 객체가 조상과 동일 오리진인 경우에만 true인 Boolean 값입니다. 호출자가 교차 오리진인 경우 false입니다.

참고: 이 내부 메서드가 호출되었다는 것은 [CREDENTIAL-MANAGEMENT-1] 수준에서 평가되는 Permissions Policy에 의해 허용되었음을 나타냅니다. § 5.9 Permissions Policy 통합을 참조하십시오.

참고: 이 알고리즘은 동기식입니다. Promise 이행/거부는 navigator.credentials.create()에서 처리됩니다.

잠재적인 동기화 문제를 방지하기 위해 이 알고리즘에서 사용하는 모든 BufferSource 객체는 알고리즘 시작 시 스냅샷을 만들어야 합니다(MUST). 구현은 버퍼 소스가 보유한 바이트의 복사본을 가져와 알고리즘의 관련 부분에 그 복사본을 사용해야 합니다(SHOULD).

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

단언: options.publicKey가 존재합니다.
sameOriginWithAncestors가 false인 경우:
1. options.mediation이 존재하고 값이 conditional인 경우:
  1. "NotAllowedError" DOMException을 throw합니다.
2. 호출하는 create() 구현이 결정한 관련 전역 객체에 일시적 활성화가 없는 경우:
  1. "NotAllowedError" DOMException을 throw합니다.
3. 관련 전역 객체의 사용자 활성화를 소비합니다.
4. 자격 증명을 생성하는 오리진이 관련 전역 객체의 최상위 오리진과 다른 경우 (즉, 사용자가 주소 표시줄에서 볼 수 있는 오리진과 다른 오리진인 경우), 클라이언트는 이 사실을 사용자에게 명확히 알려야 합니다(SHOULD).
pkOptions을 options.publicKey의 값으로 둡니다.
pkOptions.timeout이 존재하면 그 값이 클라이언트가 정의한 합리적인 범위 내에 있는지 확인하고, 그렇지 않으면 해당 범위 내에서 가장 가까운 값으로 수정합니다. 타이머 lifetimeTimer를 이 조정된 값으로 설정합니다. pkOptions.timeout이 존재하지 않으면 lifetimeTimer를 클라이언트별 기본값으로 설정합니다.

pkOptions.timeout의 합리적인 범위와 기본값을 결정하기 위한 지침은 WebAuthn 절차 시간 제한의 권장 범위 및 기본값을 참조하십시오.

클라이언트는 특별한 요구가 있는 사용자의 시간 제한과 관련하여 인지적 지침을 고려해야 합니다(SHOULD).
pkOptions.user.id의 길이가 1바이트 이상 64바이트 이하가 아니면 TypeError를 throw합니다.
callerOrigin을 origin으로 둡니다. callerOrigin이 불투명 오리진이면 "NotAllowedError" DOMException을 throw합니다.
effectiveDomain을 callerOrigin의 유효 도메인으로 둡니다. 유효 도메인이 유효한 도메인이 아니면 "SecurityError" DOMException을 throw합니다.

참고: 유효 도메인은 호스트로 해석될 수 있으며, 이는 도메인, ipv4 주소, ipv6 주소, 불투명 호스트 또는 빈 호스트 등 다양한 방식으로 표현될 수 있습니다. 여기에서는 호스트의 도메인 형식만 허용됩니다. 이는 단순화를 위한 것이며, PKI 기반 보안과 함께 직접 IP 주소 식별을 사용할 때 발생하는 여러 문제를 고려한 것이기도 합니다.
pkOptions.rp.id
존재함
pkOptions.rp.id가 effectiveDomain과 같지도 않고 등록 가능한 도메인 접미사도 아닌 경우, 그리고 클라이언트가
관련 오리진 요청을 지원함
rpIdRequested을 pkOptions.rp.id의 값으로 둡니다.

callerOrigin과 rpIdRequested를 인수로 하여 관련 오리진 검증 절차를 실행합니다. 결과가 false이면 "SecurityError" DOMException을 throw합니다.
관련 오리진 요청을 지원하지 않음

"SecurityError" DOMException을 throw합니다.
존재하지 않음

pkOptions.rp.id를 effectiveDomain으로 설정합니다.
참고: pkOptions.rp.id는 호출자의 RP ID를 나타냅니다. RP ID는 호출자가 create()을 호출할 때 pkOptions.rp.id를 명시적으로 설정하지 않는 한, 기본적으로 호출자의 오리진의 유효 도메인입니다.
credTypesAndPubKeyAlgs를 PublicKeyCredentialType과 COSEAlgorithmIdentifier의 쌍을 항목으로 갖는 새 목록으로 둡니다.
pkOptions.pubKeyCredParams의 크기가
0임
다음 PublicKeyCredentialType과 COSEAlgorithmIdentifier 값의 쌍을 credTypesAndPubKeyAlgs에 추가합니다.
- public-key 및 -7 ("ES256").
- public-key 및 -257 ("RS256").
0이 아님
pkOptions.pubKeyCredParams의 각 current에 대해 반복합니다.
1. current.type이 이 구현에서 지원하는 PublicKeyCredentialType을 포함하지 않으면 계속합니다.
2. alg를 current.alg로 둡니다.
3. current.type과 alg의 쌍을 credTypesAndPubKeyAlgs에 추가합니다.
credTypesAndPubKeyAlgs가 비어 있으면 "NotSupportedError" DOMException을 throw합니다.
clientExtensions를 새 맵으로 두고, authenticatorExtensions도 새 맵으로 둡니다.
pkOptions.extensions가 존재하면, pkOptions.extensions의 각 extensionId → clientExtensionInput에 대해 반복합니다.
1. extensionId가 이 클라이언트 플랫폼에서 지원되지 않거나 등록 확장이 아니면 계속합니다.
2. clientExtensions[extensionId]를 clientExtensionInput으로 설정합니다.
3. extensionId가 인증자 확장이 아니면 계속합니다.
4. authenticatorExtensionInput을 clientExtensionInput에 대해 extensionId의 클라이언트 확장 처리 알고리즘을 실행한 (CBOR) 결과로 둡니다. 알고리즘이 오류를 반환한 경우 계속합니다.
5. authenticatorExtensions[extensionId]를 authenticatorExtensionInput의 base64url 인코딩으로 설정합니다.
collectedClientData를 다음 필드를 가진 새 CollectedClientData 인스턴스로 둡니다.

type

문자열 "webauthn.create".

challenge

pkOptions.challenge의 base64url 인코딩.

origin

callerOrigin의 직렬화.

crossOrigin

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

topOrigin

이 내부 메서드에 전달된 sameOriginWithAncestors 인수가 false이면 callerOrigin의 최상위 오리진의 직렬화, 그렇지 않으면 undefined.
clientDataJSON을 collectedClientData에서 구성한 클라이언트 데이터의 JSON 호환 직렬화로 둡니다.
clientDataHash를 clientDataJSON이 나타내는 직렬화된 클라이언트 데이터의 해시로 둡니다.
options.signal이 존재하고 중단됨 상태이면, options.signal의 중단 사유를 throw합니다.
issuedRequests를 새 정렬된 집합으로 둡니다.
authenticators는 주어진 어떤 순간에도 클라이언트 플랫폼별 핸들의 집합인 값을 나타내며, 각 항목은 그 순간 이 클라이언트 플랫폼에서 현재 사용 가능한 인증자를 식별합니다.

참고: 인증자가 "사용 가능"한 것으로 간주되는 조건은 의도적으로 명시하지 않았습니다. 이는 인증자가 다양한 메커니즘을 통해 클라이언트에 핫 플러그될 수 있거나(예: USB를 통해), 검색될 수 있거나(예: NFC 또는 Bluetooth를 통해), 또는 클라이언트에 영구적으로 내장될 수 있음을 나타내기 위한 것입니다.
options.mediation이 존재하고 값이 conditional인 경우:
1. 사용자 에이전트가 최근에 인증을 중재하지 않았거나, 해당 인증의 오리진이 callerOrigin이 아니거나, 사용자가 이러한 유형의 자격 증명 생성에 동의하지 않으면 "NotAllowedError" DOMException을 throw합니다.
  
  인증 절차가 완료되었다고 판단하는 시점은 사용자 에이전트가 결정합니다. 해당 인증 절차는 웹 인증 API 이외의 수단을 통해 수행될 수도 있습니다(MAY).
hints의 값을 고려하고 사용자 에이전트가 적절하다고 판단하는 방식으로 사용자 인터페이스를 구성합니다.
lifetimeTimer를 시작합니다.
lifetimeTimer가 만료되지 않은 동안, lifetimeTimer 및 authenticators의 각 authenticator의 상태와 응답에 따라 다음 작업을 수행합니다.
lifetimeTimer가 만료되면,

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 호출하고, authenticator를 issuedRequests에서 제거합니다.

사용자가 사용자 에이전트의 사용자 인터페이스 옵션을 사용하여 프로세스를 취소하면,

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 호출하고, authenticator를 issuedRequests에서 제거합니다. "NotAllowedError" DOMException을 throw합니다.

options.signal이 존재하고 중단됨 상태이면,

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 호출하고 authenticator를 issuedRequests에서 제거합니다. 그런 다음 options.signal의 중단 사유를 throw합니다.

authenticator가 이 클라이언트 기기에서 사용 가능해지면,
참고: 여기에는 lifetimeTimer가 시작될 때 이미 authenticator를 사용할 수 있었던 경우도 포함됩니다.
1. 이 authenticator는 이제 후보 인증자입니다.
2. pkOptions.authenticatorSelection이 존재하는 경우:
  1. pkOptions.authenticatorSelection.authenticatorAttachment이 존재하고 그 값이 authenticator의 인증자 연결 방식과 같지 않으면 계속합니다.
  2. pkOptions.authenticatorSelection.residentKey가
    
    존재하고 required로 설정됨
    
    authenticator가 클라이언트 측에서 검색 가능한 공개 키 자격 증명 소스를 저장할 수 없으면 계속합니다.
    
    존재하고 preferred 또는 discouraged로 설정됨
    
    영향 없음.
    
    존재하지 않음
    
    pkOptions.authenticatorSelection.requireResidentKey가 true로 설정되어 있고 authenticator가 클라이언트 측에서 검색 가능한 공개 키 자격 증명 소스를 저장할 수 없으면 계속합니다.
  3. pkOptions.authenticatorSelection.userVerification이 required로 설정되어 있고 authenticator가 사용자 검증을 수행할 수 없으면 계속합니다.
3. requireResidentKey를 다음과 같이 결정되는 Boolean 값인 자격 증명 생성을 위한 유효 상주 키 요구사항으로 둡니다.
  
  pkOptions.authenticatorSelection.residentKey가
  
  존재하고 required로 설정됨
  
  requireResidentKey를 true로 둡니다.
  
  존재하고 preferred로 설정됨
  
  authenticator가
  
  클라이언트 측 자격 증명 저장 방식을 지원함
  
  requireResidentKey를 true로 둡니다.
  
  클라이언트 측 자격 증명 저장 방식을 지원하지 않거나 클라이언트가 인증자 기능을 확인할 수 없음
  
  requireResidentKey를 false로 둡니다.
  
  존재하고 discouraged로 설정됨
  
  requireResidentKey를 false로 둡니다.
  
  존재하지 않음
  
  requireResidentKey를 pkOptions.authenticatorSelection.requireResidentKey의 값으로 둡니다.
4. userVerification을 다음과 같이 결정되는 Boolean 값인 자격 증명 생성을 위한 유효 사용자 검증 요구사항으로 둡니다. pkOptions.authenticatorSelection.userVerification이
  required로 설정됨
  
  options.mediation이 conditional로 설정되어 있고 절차 중 사용자 검증을 수집할 수 없으면 ConstraintError DOMException을 throw합니다.
  
  userVerification을 true로 둡니다.
  
  preferred로 설정됨
  
  authenticator가
  
  사용자 검증을 수행할 수 있음
  
  userVerification을 true로 둡니다.
  
  사용자 검증을 수행할 수 없음
  
  userVerification을 false로 둡니다.
  
  discouraged로 설정됨
  
  userVerification을 false로 둡니다.
5. enterpriseAttestationPossible을 다음과 같이 결정되는 Boolean 값으로 둡니다. pkOptions.attestation이
  
  enterprise로 설정됨
  
  사용자 에이전트가 pkOptions.rp.id에 대해 엔터프라이즈 증명을 지원하려는 경우 enterpriseAttestationPossible을 true로 둡니다 (위의 8단계 참조). 그렇지 않으면 false입니다.
  
  그 외의 경우
  
  enterpriseAttestationPossible을 false로 둡니다.
6. attestationFormats를 문자열 목록으로 두고, 그 초기값을 pkOptions.attestationFormats의 값으로 설정합니다.
7. pkOptions.attestation이
  
  none으로 설정됨
  
  attestationFormats를 문자열 “none”만 포함하는 단일 요소 목록으로 설정합니다.
8. excludeCredentialDescriptorList를 새 목록으로 둡니다.
9. pkOptions.excludeCredentials의 각 자격 증명 설명자 C에 대해 반복합니다.
  1. C.transports가 비어 있지 않고, authenticator가 C.transports에 언급되지 않은 전송 방식으로 연결되어 있으면 클라이언트는 계속할 수 있습니다(MAY).
    
    참고: 클라이언트가 계속하기로 선택한 경우, C.transports의 전송 힌트가 정확하지 않다면 동일한 인증자에 바인딩된 여러 자격 증명을 의도치 않게 등록할 수 있습니다. 예를 들어 소프트웨어 업그레이드로 새 연결 옵션이 추가되면 저장된 전송 힌트가 부정확해질 수 있습니다.
  2. 그렇지 않으면 C를 excludeCredentialDescriptorList에 추가합니다.
  3. authenticator에서 authenticatorMakeCredential 작업을 호출하고 clientDataHash, pkOptions.rp, pkOptions.user, requireResidentKey, userVerification, credTypesAndPubKeyAlgs, excludeCredentialDescriptorList, enterpriseAttestationPossible, attestationFormats, 및 authenticatorExtensions를 매개변수로 전달합니다.
10. authenticator를 issuedRequests에 추가합니다.
authenticator를 이 클라이언트 기기에서 더 이상 사용할 수 없게 되면,

authenticator를 issuedRequests에서 제거합니다.

어떤 authenticator든 사용자가 작업을 취소했음을 나타내는 상태를 반환하면,
1. authenticator를 issuedRequests에서 제거합니다.
2. issuedRequests에 남아 있는 각 authenticator에 대해 authenticatorCancel 작업을 호출하고 issuedRequests에서 해당 인증자를 제거합니다.
  
  참고: 인증자는 "사용자가 전체 작업을 취소함"을 나타내는 표시를 반환할 수 있습니다. 사용자 에이전트가 이 상태를 사용자에게 어떻게 나타내는지는 명시하지 않습니다.
어떤 authenticator든 "InvalidStateError"와 동등한 오류 상태를 반환하면,
1. authenticator를 issuedRequests에서 제거합니다.
2. issuedRequests에 남아 있는 각 authenticator에 대해 authenticatorCancel 작업을 호출하고 issuedRequests에서 해당 인증자를 제거합니다.
3. "InvalidStateError" DOMException을 throw합니다.
참고: 이 오류 상태는 excludeCredentialDescriptorList가 authenticator에 바인딩된 자격 증명을 식별하고 사용자가 작업에 동의한 경우에만 authenticator가 이를 반환하기 때문에 별도로 처리됩니다. 이러한 명시적 동의가 있으므로 이 경우는 신뢰 당사자가 구분할 수 있어도 허용됩니다.
어떤 authenticator든 "InvalidStateError"와 동등하지 않은 오류 상태를 반환하면,

authenticator를 issuedRequests에서 제거합니다.

참고: 이 경우는 작업에 대한 사용자 동의를 의미하지 않으므로, 잠재적으로 식별 가능한 정보의 유출을 방지하기 위해 오류의 세부 정보는 신뢰 당사자에게 숨겨집니다. 자세한 내용은 § 14.5.1 등록 절차 개인정보 보호를 참조하십시오.

어떤 authenticator든 성공을 나타내면,
1. authenticator를 issuedRequests에서 제거합니다. 이 인증자는 이제 선택된 인증자입니다.
2. credentialCreationData를 다음 항목을 갖는 구조체로 둡니다.
  
  attestationObjectResult
  
  그 값은 성공한 authenticatorMakeCredential 작업에서 반환된 바이트입니다.
  
  참고: 이 값은 § 6.5.4 증명 객체 생성에 정의된 attObj입니다.
  
  clientDataJSONResult
  
  그 값은 clientDataJSON의 바이트입니다.
  
  attestationConveyancePreferenceOption
  
  그 값은 pkOptions.attestation의 값입니다.
  
  clientExtensionResults
  
  그 값은 확장 식별자 → 클라이언트 확장 출력 항목을 포함하는 AuthenticationExtensionsClientOutputs 객체입니다. 항목은 pkOptions.extensions의 각 클라이언트 확장에 대해 각 확장의 클라이언트 확장 처리 알고리즘을 실행하여 클라이언트 확장 출력을 생성함으로써 만들어집니다.
3. constructCredentialAlg을 전역 객체 global을 받고 다음 단계를 수행하는 알고리즘으로 둡니다.
  1. credentialCreationData.attestationConveyancePreferenceOption의 값이
    
    none
    
    잠재적으로 고유 식별이 가능한 정보를 동일한 정보의 비식별 버전으로 바꿉니다.
    
    증명된 자격 증명 데이터의 aaguid가 16개의 0 바이트이고, credentialCreationData.attestationObjectResult.fmt가 "packed"이며, credentialCreationData.attestationObjectResult에 "x5c"가 없으면 자체 증명이 사용 중인 것이며 추가 작업이 필요하지 않습니다.
    
    그렇지 않으면:
    
    credentialCreationData.attestationObjectResult.fmt의 값을 "none"으로 설정하고, credentialCreationData.attestationObjectResult.attStmt의 값을 빈 CBOR 맵으로 설정합니다. (§ 8.7 None 증명문 형식 및 § 6.5.4 증명 객체 생성 참조).
    
    indirect
    
    클라이언트는 aaguid와 증명문을 동일한 데이터의 더 개인정보 친화적이고/또는 더 쉽게 검증 가능한 버전으로 바꿀 수 있습니다(MAY)(예: 익명화 CA를 사용).
    
    direct 또는 enterprise
    
    인증자의 AAGUID와 증명문을 변경하지 않고 신뢰 당사자에게 전달합니다.
  2. attestationObject를 global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer로 두고, credentialCreationData.attestationObjectResult 값의 바이트를 포함하도록 합니다.
  3. id를 attestationObject.authData.attestedCredentialData.credentialId로 둡니다.
  4. pubKeyCred를 global과 연결된 새 PublicKeyCredential 객체로 두고 다음 필드를 갖도록 합니다.
    
    [[identifier]]
    
    id
    
    authenticatorAttachment
    
    authenticator의 현재 인증자 연결 방식과 일치하는 AuthenticatorAttachment 값.
    
    response
    
    global과 연결된 새 AuthenticatorAttestationResponse 객체이며, 다음 필드를 갖습니다.
    
    clientDataJSON
    
    global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer이며, credentialCreationData.clientDataJSONResult의 바이트를 포함합니다.
    
    attestationObject
    
    attestationObject
    
    [[transports]]
    
    authenticator가 지원한다고 간주되는 0개 이상의 고유한 DOMString의 사전식 순서 시퀀스입니다. 값은 AuthenticatorTransport의 멤버여야 하지만(SHOULD), 클라이언트 플랫폼은 알 수 없는 값을 무시해야 합니다(MUST).
    
    사용자 에이전트가 이 정보를 공개하지 않으려는 경우 개인정보 보호를 위해 설계된 임의의 시퀀스로 대체할 수 있습니다(MAY). 이 시퀀스는 여전히 유효해야 하며(MUST), 즉 사전식으로 정렬되어 있고 중복이 없어야 합니다. 예를 들어 빈 시퀀스를 사용할 수 있습니다. 어느 경우든 사용자 에이전트는 신뢰 당사자의 동작이 최적이 아닐 수 있는 위험을 감수합니다.
    
    사용자 에이전트에 전송 방식 정보가 전혀 없으면 이 필드를 빈 시퀀스로 설정해야 합니다(SHOULD).
    
    참고: 사용자 에이전트가 지정된 인증자가 지원하는 전송 방식을 어떻게 발견하는지는 이 명세의 범위를 벗어나지만, 증명 인증서의 정보(예: [FIDO-Transports-Ext]), CTAP2와 같은 인증자 프로토콜에서 전달되는 메타데이터, 또는 플랫폼 인증자에 대한 특수한 지식이 포함될 수 있습니다.
    
    [[clientExtensionsResults]]
    
    global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer이며, credentialCreationData.clientExtensionResults의 바이트를 포함합니다.
  5. pubKeyCred를 반환합니다.
4. issuedRequests에 남아 있는 각 authenticator에 대해 authenticatorCancel 작업을 호출하고, issuedRequests에서 해당 인증자를 제거합니다.
5. constructCredentialAlg를 반환하고 이 알고리즘을 종료합니다.
"NotAllowedError" DOMException을 throw합니다.

위 과정 중 사용자 에이전트는 인증자를 선택하고 승인하는 과정을 안내하기 위한 UI를 사용자에게 표시해야 합니다(SHOULD). options.mediation이 conditional로 설정된 경우, 사용자 에이전트가 정한 수단을 통해 자격 증명 생성에 미리 동의한 경우가 아니라면 눈에 띄는 모달 UI를 표시해서는 안 됩니다.

5.1.3.1. 생성 요청 예외

이 절은 규범적이지 않습니다.

WebAuthn 신뢰 당사자는 navigator.credentials.create()을 호출할 때 여러 예외가 발생할 수 있습니다. 일부 예외는 발생한 이유가 여러 가지일 수 있으므로, WebAuthn 신뢰 당사자는 WebAuthn 사용 방식에 따라 실제 원인을 추론해야 합니다.

참고: 이 명세 외부에서 정의된 것을 포함하여 모든 WebAuthn 확장을 처리하는 동안 발생할 수 있는 예외는 여기에 나열하지 않습니다.

다음 DOMException 예외가 발생할 수 있습니다.

AbortError: 절차가 AbortController에 의해 취소되었습니다. § 5.6 AbortSignal을 사용하여 작업 중단 및 § 1.3.4 인증 작업 중단을 참조하십시오.
ConstraintError: residentKey가 required로 설정되었지만 사용 가능한 인증자 중 상주 키를 지원하는 인증자가 없었거나, userVerification이 required로 설정되었지만 사용 가능한 인증자 중 사용자 검증을 수행할 수 있는 인증자가 없었습니다.
InvalidStateError: 절차에 사용된 인증자가 사용자가 자격 증명 등록에 동의한 후 excludeCredentials의 항목을 인식했습니다.
NotSupportedError: pubKeyCredParams의 어떤 항목에도 type 속성이 public-key인 항목이 없었거나, 인증자가 pubKeyCredParams에 지정된 서명 알고리즘을 하나도 지원하지 않았습니다.
SecurityError: 유효 도메인이 유효한 도메인이 아니었거나, rp.id가 유효 도메인과 같지 않고 그 등록 가능한 도메인 접미사도 아니었습니다. 후자의 경우 클라이언트가 관련 오리진 요청을 지원하지 않거나 관련 오리진 검증 절차가 실패한 것입니다.
NotAllowedError: 사용자가 절차를 취소하는 것과 같은 일반적인 경우를 포함하여 다양한 가능한 원인을 포괄하는 범용 오류입니다. 이러한 원인 중 일부는 이 명세 전반에 문서화되어 있으며, 다른 일부는 클라이언트별로 다릅니다.

다음 단순 예외가 발생할 수 있습니다.

TypeError: options 인수가 유효한 CredentialCreationOptions 값이 아니었거나, user.id의 값이 비어 있거나 64바이트보다 길었습니다.

5.1.4. 기존 자격 증명을 사용하여 어설션 생성

WebAuthn 신뢰 당사자는 navigator.credentials.get({publicKey:..., ...})을 호출하여 사용자의 동의를 받아 기존 공개 키 자격 증명을 검색하고 사용합니다. 신뢰 당사자 스크립트는 선택적으로 어떤 공개 키 자격 증명 소스를 허용할 것인지 나타내는 몇 가지 기준을 지정합니다. 클라이언트 플랫폼은 지정된 기준과 일치하는 공개 키 자격 증명 소스를 찾고, 스크립트가 사용할 수 있는 소스 중 하나를 사용자가 선택하도록 안내합니다. 사용자는 공개 키 자격 증명 소스가 존재하더라도 개인정보 보호 등을 위해 전체 상호 작용을 거부할 수 있습니다. 사용자가 공개 키 자격 증명 소스를 선택하면 사용자 에이전트는 § 6.3.3 authenticatorGetAssertion 작업을 사용하여 신뢰 당사자가 제공한 챌린지와 기타 수집된 데이터에 서명하여 인증 어설션을 생성하며, 이는 자격 증명으로 사용됩니다.

navigator.credentials.get() 구현 [CREDENTIAL-MANAGEMENT-1]은 PublicKeyCredential.[[CollectFromCredentialStore]]()을 호출하여 사용자 중재(대략 이 명세의 승인 제스처) 없이 사용할 수 있어야 하는 모든 자격 증명을 수집하고, 그중 정확히 하나를 찾지 못하면 PublicKeyCredential.[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)을 호출하여 사용자가 공개 키 자격 증명 소스를 선택하도록 합니다.

이 명세는 모든 어설션을 생성할 때 승인 제스처를 요구하므로, PublicKeyCredential은 빈 집합을 반환하는 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)의 기본 동작을 상속합니다. PublicKeyCredential의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 구현은 다음 절에서 명시합니다.

일반적으로 사용자 에이전트는 사용자가 작업을 완료할 인증자를 선택하고 승인하도록 안내하는 UI를 표시해야 합니다(SHOULD). options.mediation을 conditional로 설정하면, 신뢰 당사자는 자격 증명이 발견되지 않는 한 눈에 띄는 모달 UI를 표시해서는 안 된다는 것을 나타낼 수 있습니다. 신뢰 당사자는 이 기능을 사용할 수 없을 때 사용자에게 오류가 표시되는 것을 방지하기 위해 먼저 isConditionalMediationAvailable() 또는 getClientCapabilities()을 사용하여 클라이언트가 conditionalGet 기능을 지원하는지 확인해야 합니다(SHOULD).

모든 navigator.credentials.get() 작업은 AbortController를 사용하여 중단할 수 있습니다. 자세한 지침은 DOM § 3.3 API에서 AbortController 및 AbortSignal 객체 사용을 참조하십시오.

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

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

origin

이 인수는 호출하는 get() 구현, 즉 CredentialsContainer의 Credential 요청 추상 작업이 결정한 관련 설정 객체의 오리진입니다.

options

이 인수는 CredentialRequestOptions 객체이며, 그 options.publicKey 멤버에는 검색하려는 공개 키 자격 증명의 원하는 속성을 지정하는 PublicKeyCredentialRequestOptions 객체가 포함됩니다.

sameOriginWithAncestors

이 인수는 호출자의 환경 설정 객체가 조상과 동일 오리진인 경우에만 true인 Boolean 값입니다. 호출자가 교차 오리진인 경우 false입니다.

참고: 이 알고리즘은 동기식입니다. Promise 이행/거부는 navigator.credentials.get()에서 처리됩니다.

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

단언: options.publicKey가 존재합니다.
pkOptions을 options.publicKey의 값으로 둡니다.
options.mediation이 존재하고 값이 conditional인 경우:
1. credentialIdFilter를 pkOptions.allowCredentials의 값으로 둡니다.
2. pkOptions.allowCredentials를 빈 상태로 설정합니다.
  
  참고: 이렇게 하면 conditional 요청 중 검색 불가능한 자격 증명이 사용되는 것을 방지합니다.
3. lifetimeTimer 타이머를 무한대 값으로 설정합니다.
  
  참고: lifetimeTimer는 사용자가 "webauthn" 자동 완성 세부 토큰으로 표시된 input 폼 컨트롤과 Document의 전체 수명 동안 상호 작용할 수 있도록 무한대 값으로 설정됩니다. 예를 들어 사용자가 이러한 입력 필드를 클릭하면 사용자 에이전트는 발견된 자격 증명 목록을 표시하여 사용자가 선택하도록 할 수 있으며, "다른 방법 시도" 옵션을 제공할 수도 있습니다.
그렇지 않으면:
1. credentialIdFilter를 빈 목록으로 둡니다.
2. pkOptions.timeout이 존재하면 그 값이 클라이언트가 정의한 합리적인 범위 내에 있는지 확인하고, 그렇지 않으면 해당 범위 내에서 가장 가까운 값으로 수정합니다. lifetimeTimer 타이머를 이 조정된 값으로 설정합니다. pkOptions.timeout이 존재하지 않으면 lifetimeTimer를 클라이언트별 기본값으로 설정합니다.
  
  pkOptions.timeout의 합리적인 범위와 기본값을 결정하기 위한 지침은 WebAuthn 절차 시간 제한의 권장 범위 및 기본값을 참조하십시오.
  
  사용자 에이전트는 특별한 요구가 있는 사용자의 시간 제한과 관련하여 인지적 지침을 고려해야 합니다(SHOULD).
callerOrigin을 origin으로 둡니다. callerOrigin이 불투명 오리진이면 "NotAllowedError" DOMException을 throw합니다.
effectiveDomain을 callerOrigin의 유효 도메인으로 둡니다. 유효 도메인이 유효한 도메인이 아니면 "SecurityError" DOMException을 throw합니다.

참고: 유효 도메인은 호스트로 해석될 수 있으며, 이는 도메인, ipv4 주소, ipv6 주소, 불투명 호스트 또는 빈 호스트와 같은 다양한 방식으로 표현될 수 있습니다. 여기에서는 호스트의 도메인 형식만 허용됩니다. 이는 단순화를 위한 것이며, PKI 기반 보안과 함께 직접 IP 주소 식별을 사용할 때 발생하는 여러 문제를 고려한 것이기도 합니다.
pkOptions.rpId가
존재함
pkOptions.rpId가 effectiveDomain과 같지도 않고 등록 가능한 도메인 접미사도 아닌 경우, 그리고 클라이언트가
관련 오리진 요청을 지원함
rpIdRequested을 pkOptions.rpId의 값으로 둡니다.

callerOrigin과 rpIdRequested를 인수로 하여 관련 오리진 검증 절차를 실행합니다. 결과가 false이면 "SecurityError" DOMException을 throw합니다.
관련 오리진 요청을 지원하지 않음

"SecurityError" DOMException을 throw합니다.
존재하지 않음

pkOptions.rpId를 effectiveDomain으로 설정합니다.
참고: rpId는 호출자의 RP ID를 나타냅니다. RP ID는 호출자가 get()을 호출할 때 pkOptions.rpId를 명시적으로 설정하지 않는 한 기본적으로 호출자의 오리진의 유효 도메인입니다.
clientExtensions를 새 맵으로 두고 authenticatorExtensions도 새 맵으로 둡니다.
pkOptions.extensions가 존재하면, pkOptions.extensions의 각 extensionId → clientExtensionInput에 대해 반복합니다.
1. extensionId가 이 클라이언트 플랫폼에서 지원되지 않거나 인증 확장이 아니면 계속합니다.
2. clientExtensions[extensionId]를 clientExtensionInput으로 설정합니다.
3. extensionId가 인증자 확장이 아니면 계속합니다.
4. authenticatorExtensionInput을 clientExtensionInput에 대해 extensionId의 클라이언트 확장 처리 알고리즘을 실행한 (CBOR) 결과로 둡니다. 알고리즘이 오류를 반환한 경우 계속합니다.
5. authenticatorExtensions[extensionId]를 authenticatorExtensionInput의 base64url 인코딩으로 설정합니다.
collectedClientData를 다음 필드를 가진 새 CollectedClientData 인스턴스로 둡니다.

type

문자열 "webauthn.get".

challenge

pkOptions.challenge의 base64url 인코딩

origin

callerOrigin의 직렬화.

crossOrigin

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

topOrigin

이 내부 메서드에 전달된 sameOriginWithAncestors 인수가 false이면 callerOrigin의 최상위 오리진의 직렬화, 그렇지 않으면 undefined.
clientDataJSON을 collectedClientData에서 구성한 클라이언트 데이터의 JSON 호환 직렬화로 둡니다.
clientDataHash를 clientDataJSON이 나타내는 직렬화된 클라이언트 데이터의 해시로 둡니다.
options.signal이 존재하고 중단됨 상태이면 options.signal의 중단 사유를 throw합니다.
issuedRequests를 새 정렬된 집합으로 둡니다.
savedCredentialIds를 새 맵으로 둡니다.
authenticators는 주어진 어떤 순간에도 클라이언트 플랫폼별 핸들의 집합인 값을 나타내며, 각 항목은 그 순간 이 클라이언트 플랫폼에서 현재 사용 가능한 인증자를 식별합니다.

참고: 인증자가 "사용 가능"한 것으로 간주되는 조건은 의도적으로 명시하지 않았습니다. 이는 인증자가 다양한 메커니즘을 통해 클라이언트에 핫 플러그될 수 있거나(예: USB를 통해), 검색될 수 있거나(예: NFC 또는 Bluetooth를 통해), 또는 클라이언트에 영구적으로 내장될 수 있음을 나타내기 위한 것입니다.
silentlyDiscoveredCredentials를 DiscoverableCredentialMetadata → 인증자 형식의 항목을 갖는 새 맵으로 둡니다.
hints의 값을 고려하고 사용자 에이전트가 적절하다고 판단하는 방식으로 사용자 인터페이스를 구성합니다.
lifetimeTimer를 시작합니다.
lifetimeTimer가 만료되지 않은 동안, lifetimeTimer 및 authenticators의 각 authenticator의 상태와 응답에 따라 다음 작업을 반복합니다.
lifetimeTimer가 만료되면,

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 호출하고 authenticator를 issuedRequests에서 제거합니다.

사용자가 사용자 에이전트의 사용자 인터페이스 옵션을 사용하여 프로세스를 취소하면,

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 호출하고 authenticator를 issuedRequests에서 제거합니다. "NotAllowedError" DOMException을 throw합니다.

options.signal이 존재하고 중단됨 상태이면,

issuedRequests의 각 authenticator에 대해 authenticatorCancel 작업을 호출하고 authenticator를 issuedRequests에서 제거합니다. 그런 다음 options.signal의 중단 사유를 throw합니다.

options.mediation이 conditional이고 사용자가 input 또는 textarea 폼 컨트롤과 상호 작용하며, 해당 컨트롤의 autocomplete 속성의 비자동 완성 자격 증명 유형이 "webauthn"인 경우,
참고: "webauthn" 자동 완성 세부 토큰은 "Normal" 또는 "Contact" 유형의 마지막 자동 완성 세부 토큰 바로 뒤에 나타나야 합니다. 예:
- "username webauthn"
- "current-password webauthn"
1. silentlyDiscoveredCredentials가 비어 있지 않으면:
  1. 사용자에게 silentlyDiscoveredCredentials에서 DiscoverableCredentialMetadata를 선택적으로 하나 선택하도록 요청합니다. 프롬프트에는 각 DiscoverableCredentialMetadata의 otherUI에서 name 및 displayName과 같은 값을 표시해야 합니다(SHOULD).
    
    credentialMetadata를 사용자가 선택한 DiscoverableCredentialMetadata가 있다면 그 값으로 둡니다.
  2. 사용자가 credentialMetadata를 선택하면,
    
    publicKeyOptions을 pkOptions의 임시 복사본으로 둡니다.
    
    authenticator를 silentlyDiscoveredCredentials[credentialMetadata]의 값으로 둡니다.
    
    publicKeyOptions.allowCredentials를 하나의 PublicKeyCredentialDescriptor 항목을 포함하는 목록으로 설정합니다. 이 항목의 id 값은 credentialMetadata의 id 값으로 설정하고, type 값은 credentialMetadata의 type으로 설정합니다.
    
    authenticator, savedCredentialIds, publicKeyOptions, rpId, clientDataHash 및 authenticatorExtensions을 사용하여 인증자에 자격 증명 요청 발행 알고리즘을 실행합니다.
    
    이것이 false를 반환하면 계속합니다.
    
    authenticator를 issuedRequests에 추가합니다.
options.mediation이 conditional이 아니고, issuedRequests가 비어 있고, pkOptions.allowCredentials가 비어 있지 않으며, 그 안의 어떤 공개 키 자격 증명에 대해서도 사용 가능해질 authenticator가 없는 경우,

적합한 자격 증명을 찾을 수 없음을 사용자에게 알립니다. 사용자가 대화 상자를 확인하면 "NotAllowedError" DOMException을 throw합니다.

참고: 클라이언트 플랫폼이 어떤 authenticator도 사용 가능해지지 않을 것임을 판단하는 한 가지 방법은, 존재하는 경우 pkOptions.allowCredentials의 현재 PublicKeyCredentialDescriptor 항목의 transports 멤버를 검사하는 것입니다. 예를 들어 모든 PublicKeyCredentialDescriptor 항목이 internal만 나열하지만, 모든 플랫폼 authenticator를 이미 시도했다면 요청을 충족할 가능성은 없습니다. 또는 모든 PublicKeyCredentialDescriptor 항목이 클라이언트 플랫폼이 지원하지 않는 transports를 나열할 수도 있습니다.

authenticator가 이 클라이언트 기기에서 사용 가능해지면,
참고: 여기에는 lifetimeTimer가 시작될 때 이미 authenticator를 사용할 수 있었던 경우도 포함됩니다.
1. options.mediation이 conditional이고 authenticator가 silentCredentialDiscovery 작업을 지원하는 경우:
  1. collectedDiscoveredCredentialMetadata를 rpId를 매개변수로 하여 authenticator에서 silentCredentialDiscovery 작업을 호출한 결과로 둡니다.
  2. collectedDiscoveredCredentialMetadata의 각 credentialMetadata에 대해 반복합니다.
    
    credentialIdFilter가 비어 있거나 credentialIdFilter에 id 값이 credentialMetadata의 id로 설정된 항목이 포함되어 있으면, silentlyDiscoveredCredentials[credentialMetadata]를 authenticator로 설정합니다.
    
    참고: 특정 UI 컨텍스트와 상호 작용하여 사용자가 자격 증명을 선택하면 이 인증자에 요청이 발행됩니다(자세한 내용은 여기 참조).
2. 그렇지 않으면:
  1. authenticator, savedCredentialIds, pkOptions, rpId, clientDataHash 및 authenticatorExtensions을 사용하여 인증자에 자격 증명 요청 발행 알고리즘을 실행합니다.
    
    이것이 false를 반환하면 계속합니다.
    
    참고: 이 분기는 options.mediation이 conditional이고 authenticator가 silentCredentialDiscovery 작업을 지원하지 않는 경우에 실행되며, 이를 통해 이러한 인증자도 conditional 사용자 중재 요청 중 사용할 수 있습니다.
  2. authenticator를 issuedRequests에 추가합니다.
authenticator를 이 클라이언트 기기에서 더 이상 사용할 수 없게 되면,

authenticator를 issuedRequests에서 제거합니다.

어떤 authenticator든 사용자가 작업을 취소했음을 나타내는 상태를 반환하면,
1. authenticator를 issuedRequests에서 제거합니다.
2. issuedRequests에 남아 있는 각 authenticator에 대해 authenticatorCancel 작업을 호출하고 issuedRequests에서 해당 인증자를 제거합니다.
  
  참고: 인증자는 "사용자가 전체 작업을 취소함"을 나타내는 표시를 반환할 수 있습니다. 사용자 에이전트가 이 상태를 사용자에게 어떻게 나타내는지는 명시하지 않습니다.
어떤 authenticator든 오류 상태를 반환하면,

authenticator를 issuedRequests에서 제거합니다.

어떤 authenticator든 성공을 나타내면,
1. authenticator를 issuedRequests에서 제거합니다.
2. assertionCreationData를 다음 항목을 갖는 구조체로 둡니다.
  
  credentialIdResult
  
  savedCredentialIds[authenticator]가 존재하면 credentialIdResult의 값을 savedCredentialIds[authenticator]의 바이트로 설정합니다. 그렇지 않으면 credentialIdResult의 값을 § 6.3.3 authenticatorGetAssertion 작업에 정의된, 성공한 authenticatorGetAssertion 작업에서 반환된 자격 증명 ID의 바이트로 설정합니다.
  
  clientDataJSONResult
  
  그 값은 clientDataJSON의 바이트입니다.
  
  authenticatorDataResult
  
  그 값은 인증자 데이터의 바이트로, 인증자가 반환한 값입니다.
  
  signatureResult
  
  그 값은 인증자가 반환한 서명 값의 바이트입니다.
  
  userHandleResult
  
  인증자가 사용자 핸들을 반환했다면, userHandleResult의 값을 반환된 사용자 핸들의 바이트로 설정합니다. 그렇지 않으면 userHandleResult의 값을 null로 설정합니다.
  
  clientExtensionResults
  
  그 값은 확장 식별자 → 클라이언트 확장 출력 항목을 포함하는 AuthenticationExtensionsClientOutputs 객체입니다. 항목은 pkOptions.extensions의 각 클라이언트 확장에 대해 각 확장의 클라이언트 확장 처리 알고리즘을 실행하여 클라이언트 확장 출력을 생성함으로써 만들어집니다.
3. credentialIdFilter가 비어 있지 않고, credentialIdFilter에 id 값이 credentialIdResult 값으로 설정된 항목이 포함되어 있지 않으면 계속합니다.
4. credentialIdFilter가 비어 있고 userHandleResult가 null이면 계속합니다.
5. settings를 현재 설정 객체로 둡니다. global을 settings의 전역 객체로 둡니다.
6. pubKeyCred를 global과 연결된 새 PublicKeyCredential 객체로 두고 다음 필드를 갖도록 합니다.
  
  [[identifier]]
  
  global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer이며, assertionCreationData.credentialIdResult의 바이트를 포함합니다.
  
  authenticatorAttachment
  
  authenticator의 현재 인증자 연결 방식과 일치하는 AuthenticatorAttachment 값.
  
  response
  
  global과 연결된 새 AuthenticatorAssertionResponse 객체이며, 다음 필드를 갖습니다.
  
  clientDataJSON
  
  global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer이며, assertionCreationData.clientDataJSONResult의 바이트를 포함합니다.
  
  authenticatorData
  
  global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer이며, assertionCreationData.authenticatorDataResult의 바이트를 포함합니다.
  
  signature
  
  global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer이며, assertionCreationData.signatureResult의 바이트를 포함합니다.
  
  userHandle
  
  assertionCreationData.userHandleResult가 null이면 이 필드를 null로 설정합니다. 그렇지 않으면 이 필드를 global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer로 설정하고, assertionCreationData.userHandleResult의 바이트를 포함하도록 합니다.
  
  [[clientExtensionsResults]]
  
  global의 %ArrayBuffer%를 사용하여 생성한 새 ArrayBuffer이며, assertionCreationData.clientExtensionResults의 바이트를 포함합니다.
7. issuedRequests에 남아 있는 각 authenticator에 대해 authenticatorCancel 작업을 호출하고 issuedRequests에서 해당 인증자를 제거합니다.
8. pubKeyCred를 반환하고 이 알고리즘을 종료합니다.
"NotAllowedError" DOMException을 throw합니다.

5.1.4.2. 인증자에 자격 증명 요청 발행

[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)의 이 하위 알고리즘은 지정된 PublicKeyCredentialRequestOptions을 사용하여 지정된 인증자에서 자격 증명을 요청하는 데 필요한 특정 UI 컨텍스트와 무관한 단계를 포함합니다. 현재 인증 절차에 적용되는 사용자 중재(예: conditional 중재)에 따라 여러 지점에서 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)이 이 알고리즘을 호출합니다.

이 알고리즘은 다음 인수를 받습니다.

authenticator: 현재 이 클라이언트 플랫폼에서 사용 가능한 인증자를 식별하는 클라이언트 플랫폼별 핸들입니다.
savedCredentialIds: 인증자 → 자격 증명 ID를 포함하는 맵입니다. 이 인수는 이 알고리즘에서 수정됩니다.
pkOptions: 이 인수는 검색하려는 공개 키 자격 증명의 원하는 속성을 지정하는 PublicKeyCredentialRequestOptions 객체입니다.
rpId: 요청의 RP ID입니다.
clientDataHash: clientDataJSON이 나타내는 직렬화된 클라이언트 데이터의 해시입니다.
authenticatorExtensions: 인증자 확장에 대한 클라이언트 확장 처리 출력의 base64url 인코딩에 확장 식별자를 매핑하는 맵입니다.

이 알고리즘은 클라이언트가 authenticator가 요청을 처리할 수 없다고 판단하면 false를 반환하고, 요청이 성공적으로 발행되면 true를 반환합니다.

인증자에 자격 증명 요청 발행 단계는 다음과 같습니다.

pkOptions.userVerification이 required로 설정되어 있고 authenticator가 사용자 검증을 수행할 수 없으면 false를 반환합니다.
userVerification을 다음과 같이 결정되는 Boolean 값인 어설션을 위한 유효 사용자 검증 요구사항으로 둡니다. pkOptions.userVerification이

required로 설정됨

userVerification을 true로 둡니다.

preferred로 설정됨

authenticator가

사용자 검증을 수행할 수 있음

userVerification을 true로 둡니다.

사용자 검증을 수행할 수 없음

userVerification을 false로 둡니다.

discouraged로 설정됨

userVerification을 false로 둡니다.
pkOptions.allowCredentials가
비어 있지 않음
1. allowCredentialDescriptorList를 새 목록으로 둡니다.
2. rpId, pkOptions.allowCredentials.id 및 pkOptions.allowCredentials.type을 일치시켜 pkOptions.allowCredentials에서 설명하는 공개 키 자격 증명 중 어떤 것이 이 authenticator에 바인딩되어 있는지 판별하는 클라이언트 플랫폼별 절차를 실행합니다. allowCredentialDescriptorList를 이 필터링된 목록으로 설정합니다.
3. allowCredentialDescriptorList가 비어 있으면 false를 반환합니다.
4. distinctTransports를 새 정렬된 집합으로 둡니다.
5. allowCredentialDescriptorList에 값이 정확히 하나만 있으면 savedCredentialIds[authenticator]를 allowCredentialDescriptorList[0].id의 값으로 설정합니다 (자세한 내용은 § 6.3.3 authenticatorGetAssertion 작업의 여기 참조).
6. allowCredentialDescriptorList의 각 자격 증명 설명자 C에 대해 C.transports의 각 값이 있다면 distinctTransports에 추가합니다.
  
  참고: 정렬된 집합의 특성 때문에 distinctTransports에는 이 인증자에 대한 transports의 서로 다른 값만 모입니다.
7. distinctTransports가
  
  비어 있지 않음
  
  클라이언트는 distinctTransports에서 하나의 transport 값을 선택하며, 선택 시 authenticator에 사용할 적절한 전송 방식에 대한 로컬 구성 정보를 고려할 수 있습니다.
  
  그런 다음 transport를 사용하여 authenticator에서 authenticatorGetAssertion 작업을 호출하고 rpId, clientDataHash, allowCredentialDescriptorList, userVerification 및 authenticatorExtensions를 매개변수로 전달합니다.
  
  비어 있음
  
  authenticator에 사용할 적절한 전송 방식에 대한 로컬 구성 정보를 사용하여 authenticator에서 authenticatorGetAssertion 작업을 호출하고 rpId, clientDataHash, allowCredentialDescriptorList, userVerification 및 authenticatorExtensions를 매개변수로 전달합니다.
비어 있음

authenticator에 사용할 적절한 전송 방식에 대한 로컬 구성 정보를 사용하여 authenticator에서 authenticatorGetAssertion 작업을 호출하고 rpId, clientDataHash, userVerification 및 authenticatorExtensions를 매개변수로 전달합니다.

참고: 이 경우 신뢰 당사자는 허용 가능한 자격 증명 설명자 목록을 제공하지 않았습니다. 따라서 인증자는 rpId로 식별되는 신뢰 당사자의 범위로 지정된 자신이 보유한 모든 자격 증명을 사용하도록 요청받습니다.
true를 반환합니다.

5.1.4.3. 가져오기 요청 예외

이 절은 규범적이지 않습니다.

WebAuthn 신뢰 당사자는 navigator.credentials.get()을 호출할 때 여러 예외가 발생할 수 있습니다. 일부 예외는 발생한 이유가 여러 가지일 수 있으므로, WebAuthn 신뢰 당사자는 WebAuthn 사용 방식에 따라 실제 원인을 추론해야 합니다.

참고: 이 명세 외부에서 정의된 것을 포함하여 모든 WebAuthn 확장을 처리하는 동안 발생할 수 있는 예외는 여기에 나열하지 않습니다.

다음 DOMException 예외가 발생할 수 있습니다.

AbortError: 절차가 AbortController에 의해 취소되었습니다. § 5.6 AbortSignal을 사용하여 작업 중단 및 § 1.3.4 인증 작업 중단을 참조하십시오.
SecurityError: 유효 도메인이 유효한 도메인이 아니었거나, rp.id가 유효 도메인과 같지 않고 그 등록 가능한 도메인 접미사도 아니었습니다. 후자의 경우 클라이언트가 관련 오리진 요청을 지원하지 않거나 관련 오리진 검증 절차가 실패한 것입니다.
NotAllowedError: 사용자가 절차를 취소하는 것과 같은 일반적인 경우를 포함하여 다양한 가능한 원인을 포괄하는 범용 오류입니다. 이러한 원인 중 일부는 이 명세 전반에 문서화되어 있으며, 다른 일부는 클라이언트별로 다릅니다.

다음 단순 예외가 발생할 수 있습니다.

TypeError: options 인수가 유효한 CredentialRequestOptions 값이 아니었습니다.

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

[[Store]](credential, sameOriginWithAncestors) 메서드는 웹 인증의 PublicKeyCredential 유형에서 지원되지 않으므로, [[Store]](credential, sameOriginWithAncestors) 내부 메서드의 구현은 항상 오류를 throw합니다.

참고: 이 알고리즘은 동기식이며, Promise 이행/거부는 navigator.credentials.store()에서 처리됩니다.

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

credential: 이 인수는 PublicKeyCredential 객체입니다.
sameOriginWithAncestors: 이 인수는 호출자의 환경 설정 객체가 조상과 동일 오리진인 경우에만 true인 Boolean 값입니다.

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

"NotSupportedError" DOMException을 throw합니다.

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

WebAuthn 신뢰 당사자는 이 메서드를 사용하여 사용자 검증 플랫폼 인증자를 사용해 새 자격 증명을 생성할 수 있는지 확인합니다. 호출되면 클라이언트는 클라이언트 플랫폼별 절차를 사용하여 사용 가능한 사용자 검증 플랫폼 인증자를 검색합니다. 하나라도 발견되면 promise는 true 값으로 이행됩니다. 그렇지 않으면 promise는 false 값으로 이행됩니다. 결과에 따라 신뢰 당사자는 사용자가 자격 증명을 생성하도록 안내하기 위한 추가 작업을 수행할 수 있습니다.

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

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

5.1.7. 클라이언트 기능의 사용 가능 여부 - PublicKeyCredential의 `getClientCapabilities()` 메서드

WebAuthn 신뢰 당사자는 사용자에게 특정 워크플로 및 경험을 제공하기 위해 이 메서드로 제한된 집합의 클라이언트 기능의 사용 가능 여부를 확인합니다. 예를 들어 RP는 hybrid 전송만 사용할 수 있거나 conditional 중재를 사용할 수 없는 클라이언트에서 사용자 이름 필드를 표시하는 대신 로그인 버튼을 제공할 수 있습니다.

호출되면 클라이언트는 이러한 기능의 사용 가능 여부를 알아내기 위해 클라이언트 플랫폼별 절차를 사용합니다.

이 메서드는 인수를 받지 않으며 기능 키를 Boolean 값에 매핑한 레코드를 반환합니다.

partial interface PublicKeyCredential {
    static Promise<PublicKeyCredentialClientCapabilities> getClientCapabilities();
};

typedef record<DOMString, boolean> PublicKeyCredentialClientCapabilities;

PublicKeyCredentialClientCapabilities의 키는 오름차순 사전식 순서로 정렬되어야 합니다(MUST). 키 집합에는 ClientCapability의 열거형 값 집합이 포함되어야 하지만(SHOULD), 클라이언트는 필요하다고 판단하는 키를 생략할 수 있습니다(MAY). § 14.5.4 클라이언트 기능 공개를 참조하십시오.

지정된 기능의 값이 true이면 해당 기능은 현재 클라이언트에서 지원되는 것으로 알려진 것입니다. 지정된 기능의 값이 false이면 해당 기능은 현재 클라이언트에서 지원되지 않는 것으로 알려진 것입니다. 기능이 키로 존재하지 않으면 해당 클라이언트 기능의 사용 가능 여부는 알 수 없습니다.

키 집합에는 클라이언트가 구현한 각 확장에 대한 키도 포함되어야 하며(SHOULD), 키는 문자열 extension:을 확장 식별자 앞에 붙여 만듭니다. 구현된 각 확장에 연결된 값은 true여야 합니다(SHOULD). 클라이언트가 getClientCapabilities()을 지원하지만 어떤 확장이 true 값에 매핑되지 않은 경우, 신뢰 당사자는 이 클라이언트가 해당 확장에 대한 클라이언트 처리 단계를 수행하지 않을 것이며, 해당 확장이 인증자에게 전달되지 않을 수도 있다고(MAY) 가정할 수 있습니다.

확장이 true에 매핑되어 있더라도 특정 작업에 사용되는 인증자가 해당 확장을 지원하지 않을 수 있으므로, 신뢰 당사자는 이를 근거로 해당 확장에 대한 인증자 처리 단계가 수행될 것이라고 가정해서는 안 됩니다(MUST NOT).

5.1.8. 등록 절차 옵션 역직렬화 - PublicKeyCredential의 `parseCreationOptionsFromJSON()` 메서드

WebAuthn 신뢰 당사자는 이 메서드를 사용하여 navigator.credentials.create()의 옵션에 대한 JSON 유형 표현을 PublicKeyCredentialCreationOptions으로 변환합니다.

호출되면 클라이언트는 options 인수를 새롭고 동일한 구조의 PublicKeyCredentialCreationOptions 객체로 변환해야 하며(MUST), base64url 인코딩을 사용하여 PublicKeyCredentialCreationOptionsJSON에서 PublicKeyCredentialCreationOptions의 버퍼 소스 유형 속성에 대응하는 모든 DOMString 속성을 디코딩해야 합니다. 이 변환은 클라이언트가 처리하는 모든 클라이언트 확장 입력에도 적용되어야 합니다(MUST).

AuthenticationExtensionsClientInputsJSON에는 IANA "WebAuthn 확장 식별자" 레지스트리 [IANA-WebAuthn-Registries]에 등록되었지만 § 9 WebAuthn 확장에 정의되지 않은 확장이 포함될 수 있습니다(MAY).

클라이언트가 JSON 유형 표현을 파싱하는 중 문제가 발생하면, 호환되지 않는 값에 대한 설명과 함께 "EncodingError" DOMException을 throw하고 작업을 종료해야 합니다(MUST).

partial interface PublicKeyCredential {
    static PublicKeyCredentialCreationOptions parseCreationOptionsFromJSON(PublicKeyCredentialCreationOptionsJSON options);
};

dictionary PublicKeyCredentialCreationOptionsJSON {
    required PublicKeyCredentialRpEntity                    rp;
    required PublicKeyCredentialUserEntityJSON              user;
    required Base64URLString                                challenge;
    required sequence<PublicKeyCredentialParameters>        pubKeyCredParams;
    unsigned long                                           timeout;
    sequence<PublicKeyCredentialDescriptorJSON>             excludeCredentials = [];
    AuthenticatorSelectionCriteria                          authenticatorSelection;
    sequence<DOMString>                                     hints = [];
    DOMString                                               attestation = "none";
    sequence<DOMString>                                     attestationFormats = [];
    AuthenticationExtensionsClientInputsJSON                extensions;
};

dictionary PublicKeyCredentialUserEntityJSON {
    required Base64URLString        id;
    required DOMString              name;
    required DOMString              displayName;
};

dictionary PublicKeyCredentialDescriptorJSON {
    required DOMString              type;
    required Base64URLString        id;
    sequence<DOMString>             transports;
};

dictionary AuthenticationExtensionsClientInputsJSON {
};

5.1.9. 인증 절차 옵션 역직렬화 - PublicKeyCredential의 `parseRequestOptionsFromJSON()` 메서드

WebAuthn 신뢰 당사자는 이 메서드를 사용하여 navigator.credentials.get()의 옵션에 대한 JSON 유형 표현을 PublicKeyCredentialRequestOptions으로 변환합니다.

호출되면 클라이언트는 options 인수를 새롭고 동일한 구조의 PublicKeyCredentialRequestOptions 객체로 변환해야 하며(MUST), base64url 인코딩을 사용하여 PublicKeyCredentialRequestOptionsJSON에서 PublicKeyCredentialRequestOptions의 버퍼 소스 유형 속성에 대응하는 모든 DOMString 속성을 디코딩해야 합니다. 이 변환은 클라이언트 확장 입력에도 적용되어야 하며(MUST), 이는 클라이언트가 처리합니다.

클라이언트가 JSON 유형 표현을 파싱하는 중 문제가 발생하면 호환되지 않는 값에 대한 설명과 함께 "EncodingError" DOMException을 throw하고 작업을 종료해야 합니다(MUST).

partial interface PublicKeyCredential {
    static PublicKeyCredentialRequestOptions parseRequestOptionsFromJSON(PublicKeyCredentialRequestOptionsJSON options);
};

dictionary PublicKeyCredentialRequestOptionsJSON {
    required Base64URLString                                challenge;
    unsigned long                                           timeout;
    DOMString                                               rpId;
    sequence<PublicKeyCredentialDescriptorJSON>             allowCredentials = [];
    DOMString                                               userVerification = "preferred";
    sequence<DOMString>                                     hints = [];
    AuthenticationExtensionsClientInputsJSON                extensions;
};

5.1.10. 인증자에 자격 증명 변경 신호 전달 - PublicKeyCredential의 신호 메서드

partial interface PublicKeyCredential {
    static Promise<undefined> signalUnknownCredential(UnknownCredentialOptions options);
    static Promise<undefined> signalAllAcceptedCredentials(AllAcceptedCredentialsOptions options);
    static Promise<undefined> signalCurrentUserDetails(CurrentUserDetailsOptions options);
};

dictionary UnknownCredentialOptions {
    required DOMString                     rpId;
    required Base64URLString               credentialId;
};

dictionary AllAcceptedCredentialsOptions {
    required DOMString                     rpId;
    required Base64URLString               userId;
    required sequence<Base64URLString>     allAcceptedCredentialIds;
};

dictionary CurrentUserDetailsOptions {
    required DOMString                     rpId;
    required Base64URLString               userId;
    required DOMString                     name;
    required DOMString                     displayName;
};

WebAuthn 신뢰 당사자는 이러한 신호 메서드를 사용하여 인증자에 공개 키 자격 증명의 상태를 알려, 올바르지 않거나 폐기된 자격 증명이 업데이트, 제거 또는 숨김 처리되도록 할 수 있습니다. 클라이언트는 인증자가 자신의 자격 증명 맵 업데이트를 지원하지 않을 수도 있고 요청 시점에 연결되어 있지 않을 수도 있으므로 이 기능을 기회가 있을 때 제공합니다. 또한 사용자 동의 없이 사용자의 자격 증명에 관한 정보가 노출되는 것을 피하기 위해, 신호 메서드는 작업 성공 여부를 나타내지 않습니다. promise가 성공적으로 이행되었다는 것은 options 객체가 올바르게 구성되었다는 것만 의미합니다.

각 신호 메서드에는 인증자 작업이 포함됩니다. 인증자는 현재 명세의 인증자 작업과 다르게 동작할 수 있습니다(MAY). 예를 들어 사용자의 의사에 반한다고 합리적으로 판단되는 변경을 무시하거나, 일부 변경을 수행하기 전에 사용자에게 물을 수 있습니다. 따라서 인증자 작업은 신호 메서드를 처리하는 권장 방식으로 제공됩니다.

인증자가 인증자 작업을 처리할 기능이 없는 경우, 클라이언트는 [FIDO-CTAP]의 authenticatorCredentialManagement 명령과 같은 기존 인프라를 사용하여 동등한 효과를 얻을 수 있습니다(MAY).

참고: 신호 메서드는 의도적으로 인증자가 인증자 작업 실행을 완료할 때까지 기다리지 않습니다. 이는 요청 타이밍을 기반으로 WebAuthn 신뢰 당사자가 사용자 동의 없이 사용자의 자격 증명 사용 가능 여부에 관한 정보를 얻지 못하도록 보호하기 위한 조치입니다.

5.1.10.1. 비동기 RP ID 검증 알고리즘

비동기 RP ID 검증 알고리즘을 사용하면 신호 메서드가 RP ID를 병렬로 검증할 수 있습니다. 이 알고리즘은 DOMString rpId를 입력으로 받고, 검증에 실패하면 거부되는 promise를 반환합니다. 단계는 다음과 같습니다.

effectiveDomain을 관련 설정 객체의 오리진의 유효 도메인으로 둡니다. effectiveDomain이 유효한 도메인이 아니면 "SecurityError" DOMException으로 거부된 promise를 반환합니다.
rpId가 effectiveDomain과 같거나 등록 가능한 도메인 접미사이면, undefined로 이행된 promise를 반환합니다.
클라이언트가 관련 오리진 요청을 지원하지 않으면 "SecurityError" DOMException으로 거부된 promise를 반환합니다.
p를 새 promise로 둡니다.
다음 단계를 병렬로 실행합니다.
1. callerOrigin과 rpId를 인수로 하여 관련 오리진 검증 절차를 실행한 결과가 true이면 p를 이행합니다.
2. 그렇지 않으면 "SecurityError" DOMException으로 p를 거부합니다.
p를 반환합니다.

5.1.10.2. `signalUnknownCredential(options)`

signalUnknownCredential 메서드는 자격 증명 ID를 WebAuthn 신뢰 당사자가 인식하지 못했음을 알립니다. 예를 들어 사용자가 해당 자격 증명을 삭제했기 때문일 수 있습니다. signalAllAcceptedCredentials(options)과 달리 이 메서드는 허용된 자격 증명 ID의 전체 목록과 userHandle을 전달할 필요가 없으므로 인증되지 않은 호출자에게 개인정보가 유출되는 것을 방지합니다 (§ 14.6.3 자격 증명 ID를 통한 개인정보 유출 참조).

signalUnknownCredential(options)이 호출되면 클라이언트는 다음 단계를 실행합니다.

options.credentialId의 base64url 디코딩 결과가 오류이면 TypeError로 거부된 promise를 반환합니다.
p를 options.rpId를 사용하여 비동기 RP ID 검증 알고리즘을 실행한 결과로 둡니다.
p가 이행되면, 다음 단계를 병렬로 실행합니다.
1. 현재 이 클라이언트 플랫폼에서 사용할 수 있는 모든 인증자에 대해, options를 입력으로 사용하여 unknownCredentialId 인증자 작업을 호출합니다.
p를 반환합니다.

unknownCredentialId 인증자 작업은 UnknownCredentialOptions options를 받고 다음과 같이 수행됩니다.

인증자의 자격 증명 맵에 있는 각 공개 키 자격 증명 소스 credential에 대해 반복합니다.
1. credential의 rpId가 options.rpId와 같고, credential의 id가 options.credentialId를 base64url 디코딩한 결과와 같으면, credential을 자격 증명 맵에서 제거하거나, 향후 인증 절차에서 숨기기 위해 인증자별 절차를 사용합니다.

사용자가 WebAuthn 신뢰 당사자가 제공하는 UI에서 자격 증명을 삭제합니다. 나중에 WebAuthn 신뢰 당사자에 빈 allowCredentials로 인증하려고 할 때 인증자 UI가 이전에 삭제한 자격 증명을 사용자에게 제시합니다. 사용자는 해당 자격 증명을 선택합니다. 로그인 시도를 거부한 후 WebAuthn 신뢰 당사자는 다음을 실행합니다.

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc"  // 사용자가 방금 시도한 자격 증명 ID, base64url
});

그러면 인증자는 향후 인증 절차에서 해당 자격 증명을 삭제하거나 숨깁니다.

5.1.10.3. `signalAllAcceptedCredentials(options)`

지정된 사용자의 자격 증명 ID 전체 목록을 알립니다. WebAuthn 신뢰 당사자는 사용자가 인증되어 개인정보 유출 위험이 없는 경우 signalUnknownCredential()보다 이 메서드를 우선 사용해야 합니다(SHOULD)(§ 14.6.3 자격 증명 ID를 통한 개인정보 유출 참조). 이 목록은 사용자의 공개 키 자격 증명에 대한 전체 스냅샷을 제공하며, 현재 연결된 인증자에 아직 보고되지 않은 변경 사항을 반영할 수도 있기 때문입니다.

signalAllAcceptedCredentials(options)이 호출되면 클라이언트는 다음 단계를 실행합니다.

options.userId의 base64url 디코딩 결과가 오류이면 TypeError로 거부된 promise를 반환합니다.
options.allAcceptedCredentialIds의 각 credentialId에 대해 반복합니다.
1. credentialId를 base64url 디코딩한 결과가 오류이면 TypeError로 거부된 promise를 반환합니다.
p를 options.rpId를 사용하여 비동기 RP ID 검증 알고리즘을 실행한 결과로 둡니다.
p가 이행되면, 다음 단계를 병렬로 실행합니다.
1. 현재 이 클라이언트 플랫폼에서 사용 가능한 모든 인증자에 대해, options를 입력으로 사용하여 allAcceptedCredentialIds 인증자 작업을 호출합니다.
p를 반환합니다.

allAcceptedCredentialIds 인증자 작업은 AllAcceptedCredentialsOptions options를 받고 다음과 같이 수행됩니다.

userId를 options.userId를 base64url 디코딩한 결과로 둡니다.
단언: userId는 오류가 아닙니다.
credential을 자격 증명 맵[options.rpId, userId]로 둡니다.
credential이 존재하지 않으면 이 단계를 중단합니다.
options.allAcceptedCredentialIds에 credential의 id를 base64url 인코딩한 결과가 포함되어 있지 않으면, credential을 자격 증명 맵에서 제거하거나 향후 인증 절차에서 숨기기 위해 인증자별 절차를 사용합니다.
그렇지 않고 credential이 인증자별 절차에 의해 숨겨져 있다면, 해당 작업을 되돌려 credential이 향후 인증 절차에 나타나도록 합니다.

사용자에게 base64url 인코딩 시 aa와 bb가 되는 자격 증명 ID를 가진 두 개의 자격 증명이 있습니다. 사용자는 WebAuthn 신뢰 당사자가 제공하는 UI에서 aa 자격 증명을 삭제합니다. WebAuthn 신뢰 당사자는 다음을 실행합니다.

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc",  // 사용자 핸들, base64url.
    allAcceptedCredentialIds: [
        "bb",
    ]
});

실행 시점에 인증자가 연결되어 있으면, 향후 인증 절차에서 aa에 대응하는 자격 증명을 삭제하거나 숨깁니다.

참고: signalAllAcceptedCredentials(options)이 실행될 때 인증자가 연결되어 있지 않을 수도 있습니다. 따라서 WebAuthn 신뢰 당사자는 signalAllAcceptedCredentials(options)을 주기적으로, 예를 들어 로그인할 때마다 실행하도록 선택할 수 있습니다.

참고: allAcceptedCredentialIds에 없는 자격 증명은 제거되거나 숨겨지며, 되돌릴 수 없을 수도 있습니다. 신뢰 당사자는 유효한 자격 증명 ID가 목록에서 누락되지 않도록 주의해야 합니다. 유효한 자격 증명 ID를 실수로 누락한 경우, 신뢰 당사자는 인증자가 지원한다면 가능한 한 빨리 signalAllAcceptedCredentials(options)에 이를 다시 포함하여 "숨김 해제"해야 합니다.

인증자는 가능하면 WebAuthn 신뢰 당사자가 유효한 자격 증명 ID를 allAcceptedCredentialIds에서 실수로 누락한 경우 복구를 돕기 위해 공개 키 자격 증명을 영구적으로 제거하는 대신 일정 기간 숨기는 것을 선호해야 합니다(SHOULD).

5.1.10.4. `signalCurrentUserDetails(options)`

signalCurrentUserDetails 메서드는 사용자의 현재 name 및 displayName을 알립니다.

signalCurrentUserDetails(options)이 호출되면 클라이언트는 다음 단계를 실행합니다.

options.userId의 base64url 디코딩 결과가 오류이면 TypeError로 거부된 promise를 반환합니다.
p를 options.rpId를 사용하여 비동기 RP ID 검증 알고리즘을 실행한 결과로 둡니다.
p가 이행되면, 다음 단계를 병렬로 실행합니다.
1. 현재 이 클라이언트 플랫폼에서 사용 가능한 모든 인증자에 대해, options를 입력으로 사용하여 currentUserDetails 인증자 작업을 호출합니다.
p를 반환합니다.

currentUserDetails 인증자 작업은 CurrentUserDetailsOptions options를 받고 다음과 같이 수행됩니다.

userId를 options.userId를 base64url 디코딩한 결과로 둡니다.
단언: userId는 오류가 아닙니다.
credential을 자격 증명 맵[options.rpId, userId]로 둡니다.
credential이 존재하지 않으면 이 단계를 중단합니다.
credential의 otherUI를 options.name 및 options.displayName과 일치하도록 업데이트합니다.

사용자가 WebAuthn 신뢰 당사자가 제공하는 UI에서 자신의 이름을 업데이트합니다. WebAuthn 신뢰 당사자는 다음을 실행합니다.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc",  // 사용자 핸들, base64url.
    name: "새 사용자 이름",
    displayName: "새 표시 이름",
});

그러면 인증자는 일치하는 자격 증명의 otherUI를 업데이트합니다.

참고: signalCurrentUserDetails(options)이 실행될 때 인증자가 연결되어 있지 않을 수도 있습니다. 따라서 WebAuthn 신뢰 당사자는 signalCurrentUserDetails(options)을 주기적으로, 예를 들어 로그인할 때마다 실행하도록 선택할 수 있습니다.

5.2. 인증자 응답 (인터페이스 `AuthenticatorResponse`)

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

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

clientDataJSON, 유형은 ArrayBuffer, 읽기 전용: 이 속성에는 클라이언트 데이터의 JSON 호환 직렬화가 포함되며, 그 해시가 클라이언트가 create() 또는 get()을 호출할 때 인증자에 전달됩니다(즉, 클라이언트 데이터 자체는 인증자에 전송되지 않습니다).

5.2.1. 공개 키 자격 증명에 대한 정보 (인터페이스 `AuthenticatorAttestationResponse`)

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

[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 직렬화를 보존해야 합니다(MUST).
attestationObject, 유형은 ArrayBuffer, 읽기 전용: 이 속성에는 클라이언트에게 불투명하고 클라이언트의 변조로부터 암호학적으로 보호되는 증명 객체가 포함됩니다. 증명 객체에는 인증자 데이터와 증명문이 모두 포함됩니다. 전자에는 AAGUID, 고유한 자격 증명 ID, 그리고 자격 증명 공개 키가 포함됩니다. 증명문의 내용은 인증자가 사용하는 증명문 형식에 따라 결정됩니다. 또한 신뢰 당사자의 서버가 증명문을 검증하고, 클라이언트 데이터의 JSON 호환 직렬화와 함께 인증자 데이터를 디코딩하고 검증하는 데 필요한 추가 정보도 포함됩니다. 자세한 내용은 § 6.5 증명, § 6.5.4 증명 객체 생성, 및 그림 6을 참조하십시오.
getTransports(): 이 작업은 [[transports]]의 값을 반환합니다.
getAuthenticatorData(): 이 작업은 attestationObject에 포함된 인증자 데이터를 반환합니다. § 5.2.1.1 자격 증명 데이터에 쉽게 접근하기를 참조하십시오.
getPublicKey(): 이 작업은 새 자격 증명의 DER SubjectPublicKeyInfo를 반환하며, 사용할 수 없는 경우 null을 반환합니다. § 5.2.1.1 자격 증명 데이터에 쉽게 접근하기를 참조하십시오.
getPublicKeyAlgorithm(): 이 작업은 새 자격 증명의 COSEAlgorithmIdentifier를 반환합니다. § 5.2.1.1 자격 증명 데이터에 쉽게 접근하기를 참조하십시오.
[[transports]]: 이 내부 슬롯에는 사전식 순서로 정렬된 0개 이상의 고유한 DOMString 시퀀스가 포함됩니다. 이러한 값은 인증자가 지원한다고 간주되는 전송 방식이며, 해당 정보를 사용할 수 없는 경우 빈 시퀀스입니다. 값은 AuthenticatorTransport의 멤버여야 하지만(SHOULD), 신뢰 당사자는 알 수 없는 값을 허용하고 저장해야 합니다(SHOULD).

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

[[Create]](origin, options, sameOriginWithAncestors) 메서드의 모든 사용자는 향후 인증 어설션을 검증하기 위해 반환된 자격 증명 공개 키를 파싱하고 저장해야 합니다. 그러나 자격 증명 공개 키는 증명 객체 안의 인증자 데이터 안의 attestedCredentialData의 credentialPublicKey 멤버 안에 COSE 형식 [RFC9052]으로 있으며, 이 증명 객체는 AuthenticatorAttestationResponse.attestationObject를 통해 전달됩니다. 증명을 사용하려는 신뢰 당사자는 attestationObject을 파싱하고 자격 증명 공개 키를 얻는 작업을 수행해야 합니다. 그 공개 키 사본이 인증자가 서명한 것이기 때문입니다. 그러나 유효한 WebAuthn 사용 사례 중 상당수는 증명을 요구하지 않습니다. 이러한 용도의 경우 사용자 에이전트가 파싱 작업을 수행하고 인증자 데이터를 직접 노출하며, 자격 증명 공개 키를 더 편리한 형식으로 변환할 수 있습니다.

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

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

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

-7 (ES256), 여기서 kty는 2(비압축 포인트 사용)이고 crv는 1(P-256)입니다.
-257 (RS256).
-8 (EdDSA), 여기서 crv는 6(Ed25519)입니다.

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

많은 경우 CBOR을 전혀 파싱할 필요가 없도록 getAuthenticatorData()은 attestationObject의 인증자 데이터를 반환합니다. 인증자 데이터에는 이진 형식으로 인코딩된 다른 필드도 포함되어 있습니다. 그러나 신뢰 당사자는 이미 어설션을 가져올 때 이러한 필드를 추출해야 하므로 이를 접근하기 위한 도우미 함수는 제공되지 않습니다. 서명 검증이 선택 사항인 자격 증명 생성과 달리, 신뢰 당사자는 어설션의 서명을 항상 검증해야 하므로 서명된 인증자 데이터에서 필드를 추출해야 합니다. 여기에서 사용되는 동일한 함수는 자격 증명 생성 중에도 사용할 수 있습니다.

신뢰 당사자는 이러한 함수를 사용하기 전에 'getPublicKey' in AuthenticatorAttestationResponse.prototype의 값을 테스트하여 기능 감지를 해야 합니다(SHOULD).

참고: getPublicKey() 및 getAuthenticatorData()은 이 명세의 레벨 2에서야 추가되었습니다. 이러한 함수의 존재를 요구하는 신뢰 당사자는 오래된 사용자 에이전트와 상호 운용되지 않을 수 있습니다.

5.2.2. 웹 인증 어설션 (인터페이스 `AuthenticatorAssertionResponse`)

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

[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 서명에 사용되는 클라이언트 데이터 (딕셔너리 CollectedClientData) 참조)가 포함됩니다. 직렬화된 클라이언트 데이터의 해시가 이를 기반으로 계산되었으므로 정확한 JSON 직렬화를 보존해야 합니다(MUST).
authenticatorData, 유형은 ArrayBuffer, 읽기 전용: 이 속성에는 인증자가 반환한 인증자 데이터가 포함됩니다. § 6.1 인증자 데이터를 참조하십시오.
signature, 유형은 ArrayBuffer, 읽기 전용: 이 속성에는 인증자에서 반환한 원시 서명이 포함됩니다. § 6.3.3 authenticatorGetAssertion 작업을 참조하십시오.
userHandle, 유형은 ArrayBuffer, 읽기 전용, null 허용: 이 속성에는 인증자가 반환한 사용자 핸들이 포함되며, 인증자가 사용자 핸들을 반환하지 않은 경우 null입니다. § 6.3.3 authenticatorGetAssertion 작업을 참조하십시오. 인증 절차에 사용된 allowCredentials 옵션이 비어 있으면, 인증자는 항상 사용자 핸들을 반환해야 하며(MUST), 그렇지 않은 경우에는 반환할 수 있습니다(MAY).

5.3. 자격 증명 생성 매개변수 (딕셔너리 `PublicKeyCredentialParameters`)

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

이 딕셔너리는 새 자격 증명을 생성할 때 추가 매개변수를 제공하는 데 사용됩니다.

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

참고: 후자의 멤버 이름으로 "algorithm" 전체를 쓰지 않고 "alg"를 사용하는 이유는, 이 값이 인증자에 보내는 메시지로 직렬화되며 해당 메시지가 저대역폭 링크를 통해 전송될 수 있기 때문입니다.

5.4. 자격 증명 생성 옵션 (딕셔너리 `PublicKeyCredentialCreationOptions`)

dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp;
    required PublicKeyCredentialUserEntity       user;

    required BufferSource                             challenge;
    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;

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

rp, 유형은 PublicKeyCredentialRpEntity

이 멤버에는 요청을 담당하는 신뢰 당사자의 이름과 식별자가 포함됩니다.

그 값의 name 멤버는 필수입니다(REQUIRED). 자세한 내용은 § 5.4.1 공개 키 엔터티 설명 (딕셔너리 PublicKeyCredentialEntity)을 참조하십시오.

그 값의 id 멤버는 자격 증명이 범위가 지정될 RP ID를 지정합니다. 생략하면 그 값은 CredentialsContainer 객체의 관련 설정 객체의 오리진의 유효 도메인이 됩니다. 자세한 내용은 § 5.4.2 자격 증명 생성을 위한 신뢰 당사자 매개변수 (딕셔너리 PublicKeyCredentialRpEntity)를 참조하십시오.

user, 유형은 PublicKeyCredentialUserEntity

이 멤버에는 등록을 수행하는 사용자 계정의 이름과 식별자가 포함됩니다.

그 값의 name, displayName 및 id 멤버는 필수입니다(REQUIRED). id는 향후 일부 인증 절차에서 userHandle로 반환될 수 있으며, 동일한 인증자에서 동일한 rp.id 및 user.id를 가진 기존 검색 가능한 자격 증명을 덮어쓰는 데 사용됩니다. name 및 displayName은 향후 인증 절차에서 사용자가 자격 증명을 선택하는 데 도움이 되도록 인증자와 클라이언트가 사용할 수 있지만(MAY), 향후 인증 절차의 결과로 신뢰 당사자에게 반환되지는 않습니다.

자세한 내용은 § 5.4.1 공개 키 엔터티 설명 (딕셔너리 PublicKeyCredentialEntity) 및 § 5.4.3 자격 증명 생성을 위한 사용자 계정 매개변수 (딕셔너리 PublicKeyCredentialUserEntity)를 참조하십시오.

challenge, 유형은 BufferSource

이 멤버는 새로 생성된 자격 증명의 증명 객체를 생성할 때 인증자가 다른 데이터와 함께 서명하는 챌린지를 지정합니다. § 13.5.3 암호학적 챌린지 보안 고려사항을 참조하십시오.

pubKeyCredParams, 유형은 sequence<PublicKeyCredentialParameters>

이 멤버는 신뢰 당사자가 지원하는 키 유형과 서명 알고리즘을 가장 선호하는 것부터 가장 덜 선호하는 순서로 나열합니다. 중복은 허용되지만 실질적으로 무시됩니다. 클라이언트와 인증자는 가능한 한 가장 선호되는 유형의 자격 증명을 생성하기 위해 최선을 다합니다. 나열된 유형 중 어떤 것도 생성할 수 없으면 create() 작업이 실패합니다.

광범위한 인증자를 지원하려는 신뢰 당사자는 최소한 다음 COSEAlgorithmIdentifier 값을 포함해야 합니다(SHOULD).

-8 (EdDSA)
-7 (ES256)
-257 (RS256)

필요에 따라 추가 서명 알고리즘을 포함할 수 있습니다.

[RFC9864]에서 도입된 다음 완전 지정 COSEAlgorithmIdentifier 값은 pubKeyCredParams에서 권장되지 않습니다(NOT RECOMMENDED).

-9 (ESP256); 대신 또는 추가로 -7 (ES256)을 사용하십시오.
-51 (ESP384); 대신 또는 추가로 -35 (ES384)를 사용하십시오.
-52 (ESP512); 대신 또는 추가로 -36 (ES512)를 사용하십시오.
-19 (Ed25519); 대신 또는 추가로 -8 (EdDSA)을 사용하십시오.

참고: WebAuthn 내에서 값 -9 (ESP256), -51 (ESP384), -52 (ESP512) 및 -19 (Ed25519)는 § 5.8.5 암호화 알고리즘 식별자 (typedef COSEAlgorithmIdentifier)에 명시된 추가 제한으로 인해 각각 -7 (ES256), -35 (ES384), -36 (ES512) 및 -8 (EdDSA)과 동일한 것을 나타냅니다. 그러나 많은 구현이 후자의 식별자는 지원하지만 전자의 식별자는 지원하지 않으므로 실제로는 서로 바꿔 사용할 수 없습니다. 따라서 하위 호환성을 위해 pubKeyCredParams에서는 후자의 식별자가 선호됩니다.

timeout, 유형은 unsigned long

이 선택적(OPTIONAL) 멤버는 신뢰 당사자가 호출 완료를 기다릴 의향이 있는 시간을 밀리초 단위로 지정합니다. 이는 힌트로 처리되며 클라이언트가 재정의할 수 있습니다(MAY).

excludeCredentials, 유형은 sequence<PublicKeyCredentialDescriptor>, 기본값은 []

신뢰 당사자는 이 선택적(OPTIONAL) 멤버를 사용하여 이 사용자 계정(user.id로 식별됨)에 매핑된 기존 자격 증명을 나열해야 합니다(SHOULD). 이는 새 자격 증명이 이미 이 사용자 계정에 매핑된 자격 증명을 포함하는 인증자에 생성되지 않도록 합니다. 그렇게 될 경우 클라이언트는 대신 다른 인증자를 사용하도록 사용자에게 안내하거나, 실패하면 오류를 반환하도록 요청됩니다.

authenticatorSelection, 유형은 AuthenticatorSelectionCriteria

신뢰 당사자는 이 선택적(OPTIONAL) 멤버를 사용하여 create() 작업에 참여하기 위해 인증자가 충족해야 하는(MUST) 또는 충족해야 할(SHOULD) 기능과 설정을 지정할 수 있습니다(MAY). § 5.4.4 인증자 선택 기준 (딕셔너리 AuthenticatorSelectionCriteria)을 참조하십시오.

hints, 유형은 sequence<DOMString>, 기본값은 []

이 선택적(OPTIONAL) 멤버에는 사용자 에이전트가 사용자와 상호 작용하도록 안내하기 위한 PublicKeyCredentialHint의 요소가 0개 이상 포함됩니다. 요소가 해당 열거형에서 가져오지만 유형은 DOMString이라는 점에 유의하십시오. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

attestation, 유형은 DOMString, 기본값은 "none"

신뢰 당사자는 이 선택적(OPTIONAL) 멤버를 사용하여 증명 전달에 관한 기본 설정을 지정할 수 있습니다(MAY). 그 값은 AttestationConveyancePreference의 멤버여야 합니다(SHOULD). 클라이언트 플랫폼은 알 수 없는 값을 무시해야 하며(MUST), 알 수 없는 값을 멤버가 존재하지 않는 것처럼 처리해야 합니다.

기본값은 none입니다.

attestationFormats, 유형은 sequence<DOMString>, 기본값은 []

신뢰 당사자는 이 선택적(OPTIONAL) 멤버를 사용하여 인증자가 사용하는 증명문 형식에 관한 기본 설정을 지정할 수 있습니다(MAY). 값은 [RFC8809]에서 설정한 IANA "WebAuthn 증명문 형식 식별자" 레지스트리 [IANA-WebAuthn-Registries]에서 가져와야 합니다(SHOULD). 값은 가장 선호되는 것부터 가장 덜 선호되는 순서로 정렬됩니다. 중복은 허용되지만 실질적으로 무시됩니다. 이 매개변수는 권고용이며 인증자는 이 매개변수에 나열되지 않은 증명문을 사용할 수 있습니다(MAY).

기본값은 빈 목록이며, 기본 설정이 없음을 나타냅니다.

extensions, 유형은 AuthenticationExtensionsClientInputs

신뢰 당사자는 이 선택적(OPTIONAL) 멤버를 사용하여 클라이언트와 인증자에 추가 처리를 요청하는 클라이언트 확장 입력을 제공할 수 있습니다(MAY). 예를 들어 신뢰 당사자는 생성된 자격 증명에 관한 추가 정보를 클라이언트가 반환하도록 요청할 수 있습니다.

확장 프레임워크는 § 9 WebAuthn 확장에 정의되어 있습니다. 일부 확장은 § 10 정의된 확장에 정의되어 있으며, 등록된 WebAuthn 확장의 최신 목록은 [RFC8809]에서 설정한 IANA "WebAuthn 확장 식별자" 레지스트리 [IANA-WebAuthn-Registries]를 참조하십시오.

5.4.1. 공개 키 엔터티 설명 (딕셔너리 `PublicKeyCredentialEntity`)

PublicKeyCredentialEntity 딕셔너리는 공개 키 자격 증명이 각각 연결되거나 범위가 지정되는 사용자 계정 또는 WebAuthn 신뢰 당사자를 설명합니다.

dictionary PublicKeyCredentialEntity {
    required DOMString    name;
};

name, 유형은 DOMString

엔터티의 사람에게 친숙한 이름입니다. 그 기능은 PublicKeyCredentialEntity가 무엇을 나타내는지에 따라 달라집니다.

[사용 중단됨] PublicKeyCredentialRpEntity에 상속된 경우, 이는 표시 목적으로만 사용되는 신뢰 당사자의 사람에게 친숙한 식별자입니다. 예: "ACME Corporation", "Wonderful Widgets, Inc." 또는 "ОАО Примертех".

많은 클라이언트가 이를 표시하지 않기 때문에 이 멤버는 사용 중단되었지만, 하위 호환성을 위해 여전히 필수 딕셔너리 멤버로 남아 있습니다. 신뢰 당사자는 안전한 기본값으로 이를 RP ID와 같게 설정할 수 있습니다(MAY).
- 신뢰 당사자는 name의 값을 설정하거나 사용자에게 표시할 때, PRECIS FreeformClass [RFC8264]의 Nickname Profile에 대해 [RFC8266] 제2.3절에 명시된 대로 적용을 수행해야 합니다(SHOULD).
- 클라이언트는 name의 값을 사용자에게 표시하거나 authenticatorMakeCredential 작업의 매개변수로 포함하기 전에, PRECIS FreeformClass [RFC8264]의 Nickname Profile에 대해 [RFC8266] 제2.3절에 명시된 대로 적용을 수행해야 합니다(SHOULD).
PublicKeyCredentialUserEntity에 상속된 경우, 이는 사용자 계정의 사람에게 친숙한 식별자입니다. 이 식별자는 사용자가 자격 증명이 어떤 사용자 계정과 연결되어 있는지 이해하도록 돕기 위해 클라이언트가 사용자에게 표시하는 주요 값입니다.

이 식별자에 적합한 값의 예로는 "alexm", "+14255551234", "alex.mueller@example.com", "alex.mueller@example.com (prod-env)", 또는 "alex.mueller@example.com (ОАО Примертех)" 등이 있습니다.
- 신뢰 당사자는 사용자가 이 값을 선택하도록 할 수 있습니다(MAY). 신뢰 당사자는 name의 값을 설정하거나 사용자에게 표시할 때, PRECIS IdentifierClass [RFC8264]의 UsernameCasePreserved Profile에 대해 [RFC8265] 제3.4.3절에 명시된 대로 적용을 수행해야 합니다(SHOULD).
- 클라이언트는 name의 값을 사용자에게 표시하거나 authenticatorMakeCredential 작업의 매개변수로 포함하기 전에, PRECIS IdentifierClass [RFC8264]의 UsernameCasePreserved Profile에 대해 [RFC8265] 제3.4.3절에 명시된 대로 적용을 수행해야 합니다(SHOULD).

클라이언트, 클라이언트 플랫폼 또는 인증자가 name의 값을 표시할 때에는 표시되는 값 주위에 명확한 경계를 제공하는 UI 요소를 항상 사용해야 하며, 다른 요소로 넘쳐흐르는 것을 허용해서는 안 됩니다 [css-overflow-3].

name 멤버의 값을 저장할 때, 64바이트 이상의 크기 제한을 사용하여 § 6.4.1 문자열 잘라내기에 설명된 대로 값을 잘라낼 수 있습니다(MAY).

5.4.2. 자격 증명 생성을 위한 신뢰 당사자 매개변수 (딕셔너리 `PublicKeyCredentialRpEntity`)

PublicKeyCredentialRpEntity 딕셔너리는 새 자격 증명을 생성할 때 추가 신뢰 당사자 속성을 제공하는 데 사용됩니다.

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString      id;
};

id, 유형은 DOMString: 신뢰 당사자 엔터티의 고유 식별자로, RP ID를 설정합니다.

5.4.3. 자격 증명 생성을 위한 사용자 계정 매개변수 (딕셔너리 `PublicKeyCredentialUserEntity`)

PublicKeyCredentialUserEntity 딕셔너리는 새 자격 증명을 생성할 때 추가 사용자 계정 속성을 제공하는 데 사용됩니다.

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

id, 유형은 BufferSource

사용자 계정의 사용자 핸들입니다. 사용자 핸들은 최대 크기가 64바이트인 불투명한 바이트 시퀀스이며, 사용자에게 표시하기 위한 것이 아닙니다.

안전한 동작을 보장하기 위해 인증 및 권한 부여 결정은 id 멤버를 기준으로 해야 하며(MUST), displayName 또는 name 멤버를 기준으로 해서는 안 됩니다. [RFC8266] 제6.1절을 참조하십시오.

사용자 핸들에는 사용자 이름이나 이메일 주소와 같은 사용자의 개인 식별 정보를 포함해서는 안 됩니다(MUST NOT). 자세한 내용은 § 14.6.1 사용자 핸들 내용을 참조하십시오. 사용자 핸들은 비어 있어서는 안 됩니다(MUST NOT).

사용자 핸들은 검색 불가능한 자격 증명에서도 서로 다른 사용자 계정 전체에 걸쳐 일정한 값이어서는 안 됩니다(SHOULD NOT). 일부 인증자는 항상 검색 가능한 자격 증명을 생성하기 때문입니다. 따라서 일정한 사용자 핸들을 사용하면 사용자가 해당 인증자를 신뢰 당사자의 둘 이상의 사용자 계정에서 사용하는 것이 불가능해집니다.

displayName, 유형은 DOMString

사용자 계정의 사람에게 친숙한 이름으로, 표시 목적으로만 사용됩니다. 신뢰 당사자는 사용자가 이를 선택하도록 해야 하며(SHOULD), 필요 이상으로 선택을 제한해서는 안 됩니다(SHOULD NOT). 적절하거나 사람에게 친숙한 이름을 사용할 수 없다면 신뢰 당사자는 이 값을 빈 문자열로 설정해야 합니다(SHOULD).

이 식별자에 적합한 값의 예로는 "Alex Müller", "Alex Müller (ACME Co.)" 또는 "田中倫"이 있습니다.

신뢰 당사자는 displayName의 값을 비어 있지 않은 문자열로 설정하거나 비어 있지 않은 값을 사용자에게 표시할 때, PRECIS FreeformClass [RFC8264]의 Nickname Profile에 대해 [RFC8266] 제2.3절에 명시된 대로 적용을 수행해야 합니다(SHOULD).
클라이언트는 displayName의 비어 있지 않은 값을 사용자에게 표시하거나 authenticatorMakeCredential 작업의 매개변수로 포함하기 전에, PRECIS FreeformClass [RFC8264]의 Nickname Profile에 대해 [RFC8266] 제2.3절에 명시된 대로 적용을 수행해야 합니다(SHOULD).

클라이언트, 클라이언트 플랫폼 또는 인증자가 displayName의 값을 표시할 때에는 표시되는 값 주위에 명확한 경계를 제공하는 UI 요소를 항상 사용해야 하며, 다른 요소로 넘쳐흐르는 것을 허용해서는 안 됩니다 [css-overflow-3].

displayName 멤버의 값을 저장할 때, 64바이트 이상의 크기 제한을 사용하여 § 6.4.1 문자열 잘라내기에 설명된 대로 값을 잘라낼 수 있습니다(MAY).

5.4.4. 인증자 선택 기준 (딕셔너리 `AuthenticatorSelectionCriteria`)

WebAuthn 신뢰 당사자는 AuthenticatorSelectionCriteria 딕셔너리를 사용하여 인증자 속성에 관한 요구사항을 지정할 수 있습니다.

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

authenticatorAttachment, 유형은 DOMString

이 멤버가 존재하면 적합한 인증자는 지정된 인증자 연결 방식으로 연결된 인증자로만 필터링됩니다(§ 6.2.1 인증자 연결 방식도 참조). 이 멤버가 없으면 모든 연결 방식을 허용합니다. 값은 AuthenticatorAttachment의 멤버여야 하지만(SHOULD), 클라이언트 플랫폼은 알 수 없는 값을 무시해야 하며(MUST), 알 수 없는 값을 멤버가 존재하지 않는 것처럼 처리해야 합니다.

PublicKeyCredential의 authenticatorAttachment 멤버도 참조하십시오. 이 멤버는 성공한 create() 또는 get() 작업에서 어떤 인증자 연결 방식이 사용되었는지를 알려줄 수 있습니다.

residentKey, 유형은 DOMString

신뢰 당사자가 클라이언트 측에서 검색 가능한 자격 증명을 생성하고자 하는 정도를 지정합니다. 역사적인 이유로 이름에는 사용 중단된 “resident” 용어가 유지됩니다. 값은 ResidentKeyRequirement의 멤버여야 하지만(SHOULD), 클라이언트 플랫폼은 알 수 없는 값을 무시해야 하며(MUST), 알 수 없는 값을 멤버가 존재하지 않는 것처럼 처리해야 합니다. 값이 지정되지 않으면 requireResidentKey가 true이면 유효 값은 required이고, false이거나 존재하지 않으면 discouraged입니다.

ResidentKeyRequirement에서 residentKey의 값과 의미에 대한 설명을 참조하십시오.

requireResidentKey, 유형은 boolean, 기본값은 false

이 멤버는 WebAuthn 레벨 1과의 하위 호환성을 위해 유지되며, 역사적인 이유로 검색 가능한 자격 증명에 대해 사용 중단된 “resident” 용어를 이름에 유지합니다. 신뢰 당사자는 residentKey가 required로 설정된 경우에만 이를 true로 설정해야 합니다(SHOULD).

userVerification, 유형은 DOMString, 기본값은 "preferred"

이 멤버는 create() 작업의 사용자 검증에 관한 신뢰 당사자의 요구사항을 지정합니다. 값은 UserVerificationRequirement의 멤버여야 하지만(SHOULD), 클라이언트 플랫폼은 알 수 없는 값을 무시해야 하며(MUST), 알 수 없는 값을 멤버가 존재하지 않는 것처럼 처리해야 합니다.

UserVerificationRequirement에서 userVerification의 값과 의미에 대한 설명을 참조하십시오.

5.4.5. 인증자 연결 방식 열거형 (열거형 `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) 작업에는 인증자 연결 방식 선택 옵션이 없습니다. 클라이언트와 사용자는 allowCredentials 옵션에 따라 당시 사용 가능하고 편리한 자격 증명을 사용합니다.

5.4.6. 상주 키 요구사항 열거형 (열거형 `ResidentKeyRequirement`)

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

참고: ResidentKeyRequirement 열거형은 의도적으로 참조되지 않습니다. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

이 열거형의 값은 클라이언트 측에서 검색 가능한 자격 증명(이전에는 상주 자격 증명 또는 상주 키로 알려짐)에 대한 신뢰 당사자의 요구사항을 설명합니다.

discouraged

신뢰 당사자는 서버 측 자격 증명 생성을 선호하지만, 클라이언트 측에서 검색 가능한 자격 증명도 허용합니다. 클라이언트와 인증자는 가능하면 서버 측 자격 증명을 생성해야 합니다(SHOULD).

참고: 신뢰 당사자는 생성된 자격 증명이 서버 측 자격 증명일 것을 요구할 수 없으며, 자격 증명 속성 확장은 rk 속성의 값을 반환하지 않을 수 있습니다. 이 때문에 해당 자격 증명이 서버 측 자격 증명인지 여부를 알지 못할 수 있으며, 따라서 동일한 사용자 핸들로 두 번째 자격 증명을 생성할 때 첫 번째 자격 증명이 제거되는지 여부도 알지 못할 수 있습니다.

preferred

신뢰 당사자는 클라이언트 측에서 검색 가능한 자격 증명 생성을 강하게 선호하지만, 서버 측 자격 증명도 허용합니다. 클라이언트와 인증자는 가능하면 검색 가능한 자격 증명을 생성해야 합니다(SHOULD). 예를 들어 클라이언트는 검색 가능한 자격 증명을 생성하는 데 필요한 경우 사용자가 사용자 검증을 설정하도록 안내해야 합니다(SHOULD). 이는 userVerification 설정보다 우선합니다.

required

신뢰 당사자는 클라이언트 측에서 검색 가능한 자격 증명을 요구합니다. 클라이언트는 클라이언트 측에서 검색 가능한 자격 증명을 생성할 수 없으면 오류를 반환해야 합니다(MUST).

참고: 신뢰 당사자는 자격 증명 속성 확장의 상주 키 자격 증명 속성을 사용하여 인증자가 클라이언트 측에서 검색 가능한 자격 증명을 생성했는지 여부에 관한 정보를 얻을 수 있습니다. 이는 options.authenticatorSelection.residentKey에 discouraged 또는 preferred 값을 사용할 때 유용합니다. 이 경우 인증자가 클라이언트 측에서 검색 가능한 자격 증명 또는 서버 측 자격 증명 중 어느 쪽이든 생성할 수 있기 때문입니다.

5.4.7. 증명 전달 기본 설정 열거형 (열거형 `AttestationConveyancePreference`)

WebAuthn 신뢰 당사자는 자격 증명 생성 중 증명 전달에 관한 기본 설정을 지정하기 위해 AttestationConveyancePreference를 사용할 수 있습니다.

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

참고: AttestationConveyancePreference 열거형은 의도적으로 참조되지 않습니다. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

none

신뢰 당사자는 인증자 증명에 관심이 없습니다. 예를 들어 식별 정보를 신뢰 당사자에게 전달하기 위한 사용자 동의를 받아야 할 가능성을 피하거나, 증명 CA 또는 익명화 CA로의 왕복 통신을 줄이기 위해 사용할 수 있습니다. 인증자가 자체 증명이 아닌 증명문을 생성하면 클라이언트는 이를 None 증명문으로 교체합니다.

이 값이 기본값이며, 알 수 없는 값은 이 값의 동작으로 폴백합니다.

indirect

신뢰 당사자는 검증 가능한 증명문을 받기를 원하지만, 그러한 증명문을 얻는 방법은 클라이언트가 결정하도록 허용합니다. 클라이언트는 사용자의 개인정보를 보호하거나 이질적인 생태계에서 신뢰 당사자의 증명 검증을 돕기 위해 인증자가 생성한 증명문을 익명화 CA가 생성한 것으로 교체할 수 있습니다(MAY).

참고: 이 경우 신뢰 당사자가 검증 가능한 증명문을 얻는다는 보장은 없습니다. 예를 들어 인증자가 자체 증명을 사용하고 클라이언트가 증명문을 수정하지 않고 그대로 전달하는 경우가 있습니다.

direct

신뢰 당사자는 인증자가 생성한 증명문을 그대로 받기를 원합니다.

enterprise

신뢰 당사자는 엔터프라이즈 증명을 받기를 원합니다. 이는 인증자를 고유하게 식별하는 정보를 포함할 수 있는 증명문입니다. 이는 조직이 등록을 특정 인증자와 연결하려는 엔터프라이즈 내의 통제된 배포를 위한 것입니다. 요청된 RP ID에 대해 사용자 에이전트 또는 인증자 구성이 허용하지 않는 한 사용자 에이전트는 이러한 증명을 제공해서는 안 됩니다(MUST NOT).

허용된 경우 사용자 에이전트는 (호출 시점에) 엔터프라이즈 증명이 요청되었음을 인증자에 알리고(SHOULD), 결과 AAGUID와 증명문을 수정하지 않고 신뢰 당사자에게 전달해야 합니다.

5.5. 어설션 생성 옵션 (딕셔너리 `PublicKeyCredentialRequestOptions`)

PublicKeyCredentialRequestOptions 딕셔너리는 get()에 어설션을 생성하는 데 필요한 데이터를 제공합니다. 그 challenge 멤버는 반드시 존재해야 하며(MUST), 다른 멤버는 선택 사항입니다(OPTIONAL).

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

challenge, 유형은 BufferSource

이 멤버는 인증자가 인증 어설션을 생성할 때 다른 데이터와 함께 서명하는 챌린지를 지정합니다. § 13.5.3 암호학적 챌린지 보안 고려사항을 참조하십시오.

timeout, 유형은 unsigned long

이 선택적(OPTIONAL) 멤버는 신뢰 당사자가 호출 완료를 기다릴 의향이 있는 시간을 밀리초 단위로 지정합니다. 값은 힌트로 처리되며 클라이언트가 재정의할 수 있습니다(MAY).

rpId, 유형은 DOMString

이 선택적(OPTIONAL) 멤버는 신뢰 당사자가 주장하는 RP ID를 지정합니다. 클라이언트는 신뢰 당사자의 오리진이 이 RP ID의 범위와 일치하는지 검증해야 합니다(MUST). 인증자는 이 RP ID가 인증 절차에 사용할 자격 증명의 rpId와 정확히 같은지 검증해야 합니다(MUST).

지정하지 않으면 그 값은 CredentialsContainer 객체의 관련 설정 객체의 오리진의 유효 도메인이 됩니다.

allowCredentials, 유형은 sequence<PublicKeyCredentialDescriptor>, 기본값은 []

이 선택적(OPTIONAL) 멤버는 클라이언트가 이 인증 절차에 적합한 인증자를 찾는 데 사용합니다. 다음 두 가지 방식으로 사용할 수 있습니다.

인증할 사용자 계정이 이미 식별된 경우(예: 사용자가 사용자 이름을 입력한 경우), 신뢰 당사자는 이 멤버를 사용하여 사용자 계정의 자격 증명 레코드의 자격 증명 설명자를 나열해야 합니다(SHOULD). 일반적으로 여기에는 사용자 계정의 모든 자격 증명 레코드가 포함되어야 합니다(SHOULD).

항목은 가능하면 transports를 지정해야 합니다(SHOULD). 이는 클라이언트가 각 상황에서 사용자 경험을 최적화하는 데 도움이 됩니다. 또한 신뢰 당사자는 사용자 검증을 요청할 때 목록을 필터링할 필요가 없다는 점에도 유의하십시오. userVerification이 required로 설정되면 클라이언트가 적합하지 않은 자격 증명을 자동으로 무시합니다.

§ 14.6.3 자격 증명 ID를 통한 개인정보 유출 개인정보 보호 고려사항도 참조하십시오.
인증할 사용자 계정이 아직 식별되지 않은 경우, 신뢰 당사자는 이 멤버를 비워 두거나 지정하지 않을 수 있습니다(MAY). 이 경우 이 인증 절차에서는 검색 가능한 자격 증명만 사용되며, 결과 AuthenticatorAssertionResponse의 userHandle을 통해 사용자 계정을 식별할 수 있습니다(MAY). 사용 가능한 인증자가 신뢰 당사자의 범위로 지정된 둘 이상의 검색 가능한 자격 증명을 포함하는 경우, 사용자가 선택할 수 있도록 클라이언트 플랫폼 또는 인증자가 자격 증명을 표시합니다 (§ 6.3.3 authenticatorGetAssertion 작업의 7단계 참조).

비어 있지 않은 경우, 나열된 자격 증명 중 어떤 것도 사용할 수 없으면 클라이언트는 오류를 반환해야 합니다(MUST).

목록은 선호도가 높은 순서대로 정렬됩니다. 목록의 첫 번째 항목이 가장 선호되는 자격 증명이고, 마지막 항목이 가장 덜 선호되는 자격 증명입니다.

userVerification, 유형은 DOMString, 기본값은 "preferred"

이 선택적(OPTIONAL) 멤버는 get() 작업의 사용자 검증에 관한 신뢰 당사자의 요구사항을 지정합니다. 값은 UserVerificationRequirement의 멤버여야 하지만(SHOULD), 클라이언트 플랫폼은 알 수 없는 값을 무시해야 하며(MUST), 알 수 없는 값을 멤버가 존재하지 않는 것처럼 처리해야 합니다. 적합한 인증자는 이 요구사항을 충족할 수 있는 인증자로만 필터링됩니다.

UserVerificationRequirement에서 userVerification의 값과 의미에 대한 설명을 참조하십시오.

hints, 유형은 sequence<DOMString>, 기본값은 []

extensions, 유형은 AuthenticationExtensionsClientInputs

신뢰 당사자는 이 선택적(OPTIONAL) 멤버를 사용하여 클라이언트 및 인증자에 추가 처리를 요청하는 클라이언트 확장 입력을 제공할 수 있습니다(MAY).

5.6. `AbortSignal`을 사용하여 작업 중단

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

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

5.7. WebAuthn 확장 입력 및 출력

아래 하위 절에서는 WebAuthn 확장 입력 및 출력을 전달하는 데 사용되는 데이터 유형을 정의합니다.

참고: 인증자 확장 출력은 인증자 데이터의 일부로 전달됩니다(표 1 참조).

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

5.7.1. 인증 확장 클라이언트 입력 (딕셔너리 `AuthenticationExtensionsClientInputs`)

dictionary AuthenticationExtensionsClientInputs {
};

이는 0개 이상의 WebAuthn 확장에 대한 클라이언트 확장 입력 값을 포함하는 딕셔너리입니다.

5.7.2. 인증 확장 클라이언트 출력 (딕셔너리 `AuthenticationExtensionsClientOutputs`)

dictionary AuthenticationExtensionsClientOutputs {
};

이는 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 서명에 사용되는 클라이언트 데이터 (딕셔너리 `CollectedClientData`)

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

참고: CollectedClientData는 향후 확장될 수 있습니다. 따라서 파싱할 때 알 수 없는 키와 키 순서의 변경을 허용하는 것이 매우 중요합니다. § 5.8.1.2 제한된 검증 알고리즘도 참조하십시오.

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

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

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

type, 유형은 DOMString

이 멤버에는 새 자격 증명을 생성할 때 문자열 "webauthn.create"가 포함되고, 기존 자격 증명에서 어설션을 가져올 때 "webauthn.get"이 포함됩니다. 이 멤버의 목적은 특정 유형의 서명 혼동 공격(공격자가 하나의 적법한 서명을 다른 적법한 서명으로 바꾸는 공격)을 방지하는 것입니다.

challenge, 유형은 DOMString

이 멤버에는 신뢰 당사자가 제공한 챌린지의 base64url 인코딩이 포함됩니다. § 13.5.3 암호학적 챌린지 보안 고려사항을 참조하십시오.

origin, 유형은 DOMString

이 멤버에는 클라이언트가 인증자에 제공한 요청자의 정규화된 전체 오리진이 [RFC6454]에서 정의한 구문으로 포함됩니다.

crossOrigin, 유형은 boolean

이 선택적(OPTIONAL) 멤버에는 내부 메서드에 전달된 sameOriginWithAncestors 인수 값의 반대값이 포함됩니다.

topOrigin, 유형은 DOMString

이 선택적(OPTIONAL) 멤버에는 요청자의 정규화된 전체 최상위 오리진이 [RFC6454]에서 정의한 구문으로 포함됩니다. 이는 호출이 조상과 동일 오리진이 아닌 컨텍스트에서 이루어진 경우, 즉 crossOrigin이 true인 경우에만 설정됩니다.

[예약됨] tokenBinding

이 선택적(OPTIONAL) 멤버에는 신뢰 당사자와 통신할 때 사용되는 토큰 바인딩 프로토콜 [TokenBinding]의 상태에 관한 정보가 포함됩니다. 이 멤버가 없으면 클라이언트가 토큰 바인딩을 지원하지 않음을 나타냅니다.

참고: 토큰 바인딩은 WebAuthn 레벨 1 및 레벨 2에 존재했지만, 레벨 3에서는 사용할 것으로 예상되지 않습니다. tokenBinding 필드는 다른 용도로 재사용되지 않도록 예약되어 있습니다.

status, 유형은 DOMString

이 멤버는 TokenBindingStatus의 멤버여야 하지만(SHOULD), 클라이언트 플랫폼은 알 수 없는 값을 무시해야 하며(MUST), 알 수 없는 값을 tokenBinding 멤버가 존재하지 않는 것처럼 처리해야 합니다. 알려진 경우 이 멤버는 다음 중 하나입니다.

supported: 클라이언트가 토큰 바인딩을 지원하지만 신뢰 당사자와 통신할 때 협상되지 않았음을 나타냅니다.
present: 신뢰 당사자와 통신할 때 토큰 바인딩이 사용되었음을 나타냅니다. 이 경우 id 멤버가 존재해야 합니다(MUST).

참고: TokenBindingStatus 열거형은 의도적으로 참조되지 않습니다. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

id, 유형은 DOMString

status가 present이면 이 멤버가 존재해야 하며(MUST), 신뢰 당사자와 통신할 때 사용된 토큰 바인딩 ID의 base64url 인코딩이어야 합니다(MUST).

참고: 토큰 바인딩 ID를 얻는 것은 클라이언트 플랫폼별 작업입니다.

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

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

5.8.1.1. 직렬화

CollectedClientData의 직렬화는 JSON을 바이트로 직렬화하는 알고리즘의 하위 집합입니다. 즉, CollectedClientData의 유효한 JSON 인코딩을 생성하면서도 검증자가 전체 JSON 파서를 통합하지 않고 사용할 수 있는 추가 구조를 제공합니다. 검증자는 표준 JSON 파싱을 수행하는 것이 권장되지만, 전체 JSON 파서가 너무 큰 컨텍스트에서는 아래의 더 제한된 알고리즘을 사용할 수 있습니다. 이 검증 알고리즘에는 base64url 인코딩, 바이트 문자열 추가 (고정 템플릿에 기록하는 방식으로 구현할 수 있음), 그리고 단순한 조건 검사 (입력에 이스케이프가 필요하지 않다고 알려져 있다고 가정)만 필요합니다.

직렬화 알고리즘은 처음에는 비어 있는 부분 결과에 연속된 바이트 문자열을 추가하여 완전한 결과를 얻을 때까지 수행됩니다.

result를 빈 바이트 문자열로 둡니다.
result에 0x7b2274797065223a ({"type":)를 추가합니다.
result에 CCDToString(type)을 추가합니다.
result에 0x2c226368616c6c656e6765223a (,"challenge":)를 추가합니다.
result에 CCDToString(challenge)를 추가합니다.
result에 0x2c226f726967696e223a (,"origin":)를 추가합니다.
result에 CCDToString(origin)을 추가합니다.
result에 0x2c2263726f73734f726967696e223a (,"crossOrigin":)를 추가합니다.
crossOrigin이 존재하지 않거나 false이면:
1. result에 0x66616c7365 (false)를 추가합니다.
그렇지 않으면:
1. result에 0x74727565 (true)를 추가합니다.
topOrigin이 존재하면:
1. result에 0x2c22746f704f726967696e223a (,"topOrigin":)를 추가합니다.
2. result에 CCDToString(topOrigin)을 추가합니다.
CollectedClientData의 임시 복사본을 만들고 type, challenge, origin, crossOrigin (존재하는 경우), 그리고 topOrigin (존재하는 경우) 필드를 제거합니다.
임시 복사본에 필드가 남아 있지 않으면:
1. result에 0x7d (})를 추가합니다.
그렇지 않으면:
1. 임시 복사본에 JSON을 바이트로 직렬화를 호출하여 바이트 문자열 remainder를 생성합니다.
2. result에 0x2c (,)를 추가합니다.
3. remainder의 선행 바이트를 제거합니다.
4. result에 remainder를 추가합니다.
직렬화 결과는 result의 값입니다.

함수 CCDToString은 위 알고리즘에서 사용되며 다음과 같이 정의됩니다.

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

집합 {U+0020, U+0021, U+0023–U+005B, U+005D–U+10FFFF}에 속함

해당 코드 포인트의 UTF-8 인코딩을 encoded에 추가합니다.

U+0022임

encoded에 0x5c22 (\")를 추가합니다.

U+005C임

encoded에 0x5c5c (\\)를 추가합니다.

그 외의 경우

encoded에 0x5c75 (\u)를 추가한 다음, 16진수로 해석했을 때 해당 코드 포인트를 나타내는 소문자 16진수 네 자리를 추가합니다.
encoded에 0x22 (")를 추가합니다.
이 함수의 결과는 encoded의 값입니다.

5.8.1.2. 제한된 검증 알고리즘

검증자가 전체 JSON 파서를 지원할 수 없는 경우 다음 알고리즘을 사용하여 인코딩된 CollectedClientData를 검증할 수 있습니다.

알고리즘의 입력은 다음과 같습니다.
1. 검증할 직렬화된 CollectedClientData인 clientDataJSON을 포함하는 바이트 문자열 clientDataJSON.
2. 예상되는 type을 포함하는 문자열 type.
3. PublicKeyCredentialRequestOptions 또는 PublicKeyCredentialCreationOptions에 주어진 챌린지 바이트 문자열을 포함하는 바이트 문자열 challenge.
4. 사용자 에이전트에 요청을 발행한 예상 origin을 포함하는 문자열 origin.
5. 사용 가능한 경우 사용자 에이전트에 요청을 발행한 예상 topOrigin을 포함하는 선택적 문자열 topOrigin.
6. topOrigin이 정의되어 있고 topOrigin 속성이 clientDataJSON에 존재하지 않을 때에만 검증이 실패해야 하는 경우 true인 Boolean 값 requireTopOrigin.
  
  이는 requireTopOrigin이 false인 경우에만 검증 알고리즘이 웹 인증 레벨 2 [webauthn-2-20210408]의 JSON 호환 직렬화 알고리즘과 하위 호환됨을 의미합니다.
expected를 빈 바이트 문자열로 둡니다.
expected에 0x7b2274797065223a ({"type":)를 추가합니다.
expected에 CCDToString(type)을 추가합니다.
expected에 0x2c226368616c6c656e6765223a (,"challenge":)를 추가합니다.
challenge에 base64url 인코딩을 수행하여 문자열 challengeBase64을 생성합니다.
expected에 CCDToString(challengeBase64)을 추가합니다.
expected에 0x2c226f726967696e223a (,"origin":)를 추가합니다.
expected에 CCDToString(origin)을 추가합니다.
expected에 0x2c2263726f73734f726967696e223a (,"crossOrigin":)를 추가합니다.
topOrigin이 정의되어 있으면:
1. expected에 0x74727565 (true)를 추가합니다.
2. requireTopOrigin이 true이거나 0x2c22746f704f726967696e223a (,"topOrigin":)가 expected의 길이와 같은 오프셋에서 시작하는 clientDataJSON 부분 문자열의 접두사이면:
  1. expected에 0x2c22746f704f726967696e223a (,"topOrigin":)를 추가합니다.
  2. expected에 CCDToString(topOrigin)을 추가합니다.
그렇지 않으면, 즉 topOrigin이 정의되어 있지 않으면:
1. expected에 0x66616c7365 (false)를 추가합니다.
expected가 clientDataJSON의 접두사가 아니면 검증에 실패한 것입니다.
clientDataJSON이 expected보다 최소 1바이트 이상 길지 않으면 검증에 실패한 것입니다.
expected의 길이와 같은 오프셋에 있는 clientDataJSON의 바이트가:

0x7d임

검증에 성공했습니다.

0x2c임

검증에 성공했습니다.

그 외의 경우

검증에 실패했습니다.

5.8.1.3. 향후 개발

제한된 검증 알고리즘과의 호환성을 유지하기 위해 이 명세의 향후 버전에서는 CollectedClientData에서 type, challenge, origin, crossOrigin, 또는 topOrigin 필드 중 어느 것도 제거해서는 안 됩니다. 또한 직렬화 알고리즘을 변경하여 이러한 필드가 직렬화되는 순서를 변경하거나 그 사이에 새 필드를 삽입해서도 안 됩니다.

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

5.8.2. 자격 증명 유형 열거형 (열거형 `PublicKeyCredentialType`)

enum PublicKeyCredentialType {
    "public-key"
};

참고: PublicKeyCredentialType 열거형은 의도적으로 참조되지 않습니다. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

이 열거형은 유효한 자격 증명 유형을 정의합니다. 이는 확장 지점이며, 더 많은 자격 증명 유형이 정의됨에 따라 향후 값을 추가할 수 있습니다. 이 열거형의 값은 인증자 유형에 따라 인증 어설션 및 증명 구조의 버전을 구분하는 데 사용됩니다.

현재 하나의 자격 증명 유형, 즉 "public-key"가 정의되어 있습니다.

5.8.3. 자격 증명 설명자 (딕셔너리 `PublicKeyCredentialDescriptor`)

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

이 딕셔너리는 특정 공개 키 자격 증명을 식별합니다. 동일한 인증자에 중복 자격 증명이 생성되는 것을 방지하기 위해 create()에서 사용되고, 현재 클라이언트가 해당 자격 증명에 접근할 수 있는지, 그리고 어떤 방식으로 접근할 수 있는지를 판단하기 위해 get()에서 사용됩니다.

자격 증명 레코드의 자격 증명 설명자는 해당 자격 증명 레코드 속성의 하위 집합이며, create() 및 get()이 반환하는 PublicKeyCredential 객체의 일부 필드를 반영합니다.

type, 유형은 DOMString

이 멤버에는 호출자가 참조하는 공개 키 자격 증명의 유형이 포함됩니다. 값은 PublicKeyCredentialType의 멤버여야 하지만(SHOULD), 클라이언트 플랫폼은 알 수 없는 type을 가진 모든 PublicKeyCredentialDescriptor를 무시해야 합니다(MUST). 그러나 알 수 없는 type 때문에 모든 요소가 무시되는 경우에는, 빈 allowCredentials가 의미상 다르므로 오류가 발생해야 합니다(MUST).

이는 식별된 공개 키 자격 증명 소스를 나타내는 자격 증명 레코드의 type 항목 값으로 설정해야 합니다(SHOULD). 이는 PublicKeyCredential의 type 필드를 반영합니다.

id, 유형은 BufferSource

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

이는 식별된 공개 키 자격 증명 소스를 나타내는 자격 증명 레코드의 id 항목 값으로 설정해야 합니다(SHOULD). 이는 PublicKeyCredential의 rawId 필드를 반영합니다.

transports, 유형은 sequence<DOMString>

이 선택적(OPTIONAL) 멤버에는 호출자가 참조하는 공개 키 자격 증명의 관리 인증자와 클라이언트가 통신할 수 있는 방법에 관한 힌트가 포함됩니다. 값은 AuthenticatorTransport의 멤버여야 하지만(SHOULD), 클라이언트 플랫폼은 알 수 없는 값을 무시해야 합니다(MUST).

이는 식별된 공개 키 자격 증명 소스를 나타내는 자격 증명 레코드의 transports 항목 값으로 설정해야 합니다(SHOULD). 이는 create() 작업으로 생성된 PublicKeyCredential 구조의 response.getTransports() 메서드를 반영합니다.

5.8.4. 인증자 전송 열거형 (열거형 `AuthenticatorTransport`)

enum AuthenticatorTransport {
    "usb",
    "nfc",
    "ble",
    "smart-card",
    "hybrid",
    "internal"
};

참고: AuthenticatorTransport 열거형은 의도적으로 참조되지 않습니다. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

인증자는 클라이언트와 통신하기 위한 다양한 전송 방식을 구현할 수 있습니다. 이 열거형은 특정 자격 증명에 대한 어설션을 얻기 위해 클라이언트가 특정 인증자와 어떻게 통신할 수 있는지에 관한 힌트를 정의합니다. 이러한 힌트는 인증자에 접근하는 방법에 관한 WebAuthn 신뢰 당사자의 최선의 판단을 나타낸다는 점에 유의하십시오. 신뢰 당사자는 일반적으로 getTransports()를 통해 공개 키 자격 증명이 지원하는 전송 방식을 알게 됩니다.

usb: 해당 인증자에 이동식 USB를 통해 접근할 수 있음을 나타냅니다.
nfc: 해당 인증자에 근거리 무선 통신(NFC)을 통해 접근할 수 있음을 나타냅니다.
ble: 해당 인증자에 Bluetooth Smart (Bluetooth Low Energy / BLE)를 통해 접근할 수 있음을 나타냅니다.
smart-card: 해당 인증자에 접촉식 ISO/IEC 7816 스마트 카드를 통해 접근할 수 있음을 나타냅니다.
hybrid: 해당 인증자에 (흔히 서로 분리된) 데이터 전송 및 근접 메커니즘의 조합을 사용하여 접근할 수 있음을 나타냅니다. 예를 들어 스마트폰을 사용하여 데스크톱 컴퓨터에서 인증하는 것을 지원합니다.
internal: 해당 인증자에 클라이언트 기기별 전송 방식을 사용하여 접근함을 나타냅니다. 즉, 이는 플랫폼 인증자입니다. 이러한 인증자는 클라이언트 기기에서 분리할 수 없습니다.

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

typedef long COSEAlgorithmIdentifier;

COSEAlgorithmIdentifier의 값은 암호화 알고리즘을 식별하는 숫자입니다. 알고리즘 식별자는 IANA COSE 알고리즘 레지스트리 [IANA-COSE-ALGS-REG]에 등록된 값이어야 합니다(SHOULD). 예를 들어 "ES256"은 -7, "RS256"은 -257입니다.

COSE 알고리즘 레지스트리는 COSE 키의 다른 매개변수로 지정할 수 있는 자유도를 남겨 둡니다. 상호 운용성을 촉진하기 위해 이 명세는 자격 증명 공개 키에 대해 다음과 같은 추가 보장을 제공합니다.

알고리즘 -7 (ES256)을 사용하는 키는 crv 매개변수로 1 (P-256)을 지정해야 하며(MUST), 압축 포인트 형식을 사용해서는 안 됩니다(MUST NOT).
알고리즘 -9 (ESP256)을 사용하는 키는 압축 포인트 형식을 사용해서는 안 됩니다(MUST NOT).
알고리즘 -35 (ES384)를 사용하는 키는 crv 매개변수로 2 (P-384)를 지정해야 하며(MUST), 압축 포인트 형식을 사용해서는 안 됩니다(MUST NOT).
알고리즘 -51 (ESP384)을 사용하는 키는 압축 포인트 형식을 사용해서는 안 됩니다(MUST NOT).
알고리즘 -36 (ES512)을 사용하는 키는 crv 매개변수로 3 (P-521)을 지정해야 하며(MUST), 압축 포인트 형식을 사용해서는 안 됩니다(MUST NOT).
알고리즘 -52 (ESP512)를 사용하는 키는 압축 포인트 형식을 사용해서는 안 됩니다(MUST NOT).
알고리즘 -8 (EdDSA)을 사용하는 키는 crv 매개변수로 6 (Ed25519)을 지정해야 합니다(MUST). (이 키는 COSE에서 항상 압축 형식을 사용합니다.)

이러한 제한은 [RFC9053]의 제2.1절에 있는 권장사항과 일치합니다.

참고: 이러한 알고리즘을 사용하여 서명 검증을 올바르게 구현하려면 많은 검사가 필요합니다. 그중 하나는 압축되지 않은 타원 곡선 포인트를 처리할 때 구현이 해당 포인트가 실제로 곡선 위에 있는지 확인해야 한다는 것입니다. 이 검사는 암호화 라이브러리와 다른 코드 사이의 경계에서 누락될 위험이 특히 크다고 판단되므로 강조합니다.

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

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

WebAuthn 신뢰 당사자는 일부 작업에는 사용자 검증을 요구하지만 다른 작업에는 요구하지 않을 수 있으며, 이 유형을 사용하여 요구사항을 표현할 수 있습니다.

참고: UserVerificationRequirement 열거형은 의도적으로 참조되지 않습니다. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

required: 신뢰 당사자는 작업에 사용자 검증을 요구하며, 응답에서 UV 플래그가 설정되어 있지 않으면 전체 절차가 실패합니다. 클라이언트는 사용자 검증을 수행할 수 없으면 오류를 반환해야 합니다(MUST).
preferred: 신뢰 당사자는 가능한 경우 작업에 사용자 검증을 선호하지만, 응답에서 UV 플래그가 설정되어 있지 않더라도 작업을 실패시키지는 않습니다.
discouraged: 신뢰 당사자는 작업 중 사용자 검증을 사용하기를 원하지 않습니다(예: 사용자 상호 작용 흐름의 중단을 최소화하기 위해).

5.8.7. 클라이언트 기능 열거형 (열거형 `ClientCapability`)

enum ClientCapability {
    "conditionalCreate",
    "conditionalGet",
    "hybridTransport",
    "passkeyPlatformAuthenticator",
    "userVerifyingPlatformAuthenticator",
    "relatedOrigins",
    "signalAllAcceptedCredentials",
    "signalCurrentUserDetails",
    "signalUnknownCredential"
};

이 열거형은 WebAuthn 신뢰 당사자가 사용자에게 특정 워크플로와 경험을 제공하기 위해 평가할 수 있는 제한된 클라이언트 기능 집합을 정의합니다.

신뢰 당사자는 사용 가능한 기능에 대한 설명을 얻기 위해 PublicKeyCredential의 getClientCapabilities() 메서드를 사용할 수 있습니다.

참고: ClientCapability 열거형은 의도적으로 참조되지 않습니다. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

conditionalCreate

WebAuthn 클라이언트는 등록 절차에서 conditional 중재를 수행할 수 있습니다..

자세한 내용은 § 5.1.3 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드를 참조하십시오.

conditionalGet

WebAuthn 클라이언트는 인증 절차에서 conditional 중재를 수행할 수 있습니다.

이 기능은 isConditionalMediationAvailable()이 true로 이행되는 것과 동등합니다.

자세한 내용은 § 5.1.4 기존 자격 증명을 사용하여 어설션 생성을 참조하십시오.

hybridTransport

WebAuthn 클라이언트는 hybrid 전송 방식 사용을 지원합니다.

passkeyPlatformAuthenticator

WebAuthn 클라이언트는 로컬 및/또는 hybrid 전송을 통해 패스키 플랫폼 인증자 사용을 지원합니다.

userVerifyingPlatformAuthenticator

WebAuthn 클라이언트는 사용자 검증 플랫폼 인증자 사용을 지원합니다.

relatedOrigins

WebAuthn 클라이언트는 관련 오리진 요청을 지원합니다.

signalAllAcceptedCredentials

WebAuthn 클라이언트는 signalAllAcceptedCredentials()을 지원합니다.

signalCurrentUserDetails,

WebAuthn 클라이언트는 signalCurrentUserDetails()을 지원합니다.

signalUnknownCredential

WebAuthn 클라이언트는 signalUnknownCredential()을 지원합니다.

5.8.8. 사용자 에이전트 힌트 열거형 (열거형 `PublicKeyCredentialHint`)

enum PublicKeyCredentialHint {
    "security-key",
    "client-device",
    "hybrid",
};

참고: PublicKeyCredentialHint 열거형은 의도적으로 참조되지 않습니다. § 2.1.1 DOMString 유형으로서의 열거형을 참조하십시오.

WebAuthn 신뢰 당사자는 이 열거형을 사용하여 요청을 가장 잘 완료할 수 있는 방법에 관한 힌트를 사용자 에이전트에 전달할 수 있습니다. 이러한 힌트는 요구사항이 아니며 사용자 에이전트를 구속하지 않지만, 신뢰 당사자가 요청에 대해 가지고 있는 컨텍스트 정보를 사용하여 최상의 경험을 제공하도록 사용자 에이전트를 안내할 수 있습니다. 힌트는 선호도가 낮아지는 순서로 제공되므로, 두 힌트가 서로 모순되는 경우 첫 번째 힌트가 우선합니다. 힌트는 서로 겹칠 수도 있습니다. 더 구체적인 힌트가 정의되어 있더라도 신뢰 당사자는 더 구체적인 힌트를 인식하지 못할 수 있는 사용자 에이전트를 위해 덜 구체적인 힌트도 보내고자 할 수 있습니다. 이 경우 가장 구체적인 힌트를 덜 구체적인 힌트보다 먼저 보내야 합니다. 동일한 힌트가 두 번 이상 나타나면 두 번째 이후의 항목은 무시됩니다.

힌트는 자격 증명의 transports 및 authenticatorAttachment에 포함된 정보와 모순될 수 있습니다(MAY). 이러한 경우 힌트가 우선합니다. (검색 가능한 자격 증명을 사용할 때에는 transports 값이 제공되지 않으므로 이러한 요청의 일부 측면을 표현하는 유일한 수단은 힌트라는 점에 유의하십시오.)

security-key

신뢰 당사자가 사용자가 물리적 보안 키를 사용하여 이 요청을 충족할 것으로 판단함을 나타냅니다. 예를 들어 엔터프라이즈 신뢰 당사자가 직원들에게 보안 키를 지급했으며 등록 및 인증에 해당 인증자만 허용하는 경우 이 힌트를 설정할 수 있습니다.

이전 사용자 에이전트와의 호환성을 위해 이 힌트를 PublicKeyCredentialCreationOptions에서 사용할 때 authenticatorAttachment를 cross-platform으로 설정해야 합니다(SHOULD).

client-device

신뢰 당사자가 사용자가 클라이언트 기기에 연결된 플랫폼 인증자를 사용하여 이 요청을 충족할 것으로 판단함을 나타냅니다.

이전 사용자 에이전트와의 호환성을 위해 이 힌트를 PublicKeyCredentialCreationOptions에서 사용할 때 authenticatorAttachment를 platform으로 설정해야 합니다(SHOULD).

hybrid

신뢰 당사자가 사용자가 스마트폰과 같은 범용 인증자를 사용하여 이 요청을 충족할 것으로 판단함을 나타냅니다. 예를 들어 소비자 대상 신뢰 당사자는 고객 중 전용 보안 키를 보유한 비율이 매우 낮다고 판단할 수 있습니다. 이 옵션은 로컬 플랫폼 인증자가 UI에서 강조되어서는 안 된다는 것도 의미합니다.

5.9. 권한 정책 통합

이 명세는 세 개의 정책 제어 기능 [Permissions-Policy]을 정의합니다.

두 기능은 기능 식별자 토큰 "publickey-credentials-create" 및 "publickey-credentials-get"으로 식별됩니다. 두 기능의 기본 허용 목록은 모두 'self'입니다.

세 번째 기능은 기능 식별자 토큰 "publickey-credentials-remote-client-data-json"으로 식별됩니다. 그 기본 허용 목록은 'none'이며, 이는 기본적으로 모든 오리진에서 비활성화됨을 의미합니다. 이 기능은 또한 "publickey-credentials-remote-client-data-json"이라는 이름으로 식별되는 강력한 기능 ([Permissions])이며, 기본 권한 상태는 "denied"입니다.

Document의 권한 정책은 해당 문서의 콘텐츠가 웹 인증 API, 즉 navigator.credentials.create({publicKey:..., ...}) 또는 navigator.credentials.get({publicKey:..., ...})을 성공적으로 호출하도록 허용되는지를 결정합니다. 어떤 문서에서 비활성화된 경우 그 문서의 어떤 콘텐츠도 앞의 메서드를 사용하도록 허용되지 않으며, 이를 시도하면 오류가 반환됩니다.

참고: [CREDENTIAL-MANAGEMENT-1]에 명시된 알고리즘이 실제 권한 정책 평가를 수행합니다. 이러한 정책 평가는 현재 설정 객체에 접근할 수 있을 때 수행되어야 하기 때문입니다. [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드는 CredentialsContainer의 Credential 생성 및 Credential 요청 추상 작업 [CREDENTIAL-MANAGEMENT-1]에 의해 병렬로 호출되므로 이러한 접근 권한이 없습니다.

5.10. `iframe` 요소 내에서 웹 인증 사용

웹 인증 API는 교차 오리진 iframe에서 기본적으로 비활성화되어 있습니다. 이 기본 정책을 재정의하고 교차 오리진 iframe이 웹 인증 API의 [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 메서드를 호출하도록 허용됨을 나타내려면, iframe 요소에 allow 속성을 지정하고 해당 allow 속성 값에 각각 publickey-credentials-create 또는 publickey-credentials-get 기능 식별자 토큰을 포함하십시오.

임베디드 컨텍스트에서 WebAuthn API를 사용하는 신뢰 당사자는 UI 리드레싱 및 가능한 완화 방법에 관한 § 13.5.2 임베디드 사용의 가시성 고려사항을 검토해야 합니다.

WebAuthn 클라이언트와 클라이언트 플랫폼은 추가적인 개인정보 보호 고려사항에 대해 § 14.5.5 WebAuthn 자격 증명의 교차 오리진 사용을 참조해야 합니다.

기본적으로 웹 인증에서는 RP ID가 오리진의 유효 도메인과 같거나, 오리진의 유효 도메인의 등록 가능한 도메인 접미사여야 합니다.

이는 여러 국가별 도메인을 사용하는 대규모 환경(예: example.com 대 example.co.uk 대 example.sg), 대체 도메인 또는 브랜드 도메인이 필요한 환경(예: myexampletravel.com 대 examplecruises.com), 그리고/또는 모바일 앱을 지원하기 위해 서비스형 플랫폼 제공업체를 사용하는 환경에서 배포를 어렵게 만들 수 있습니다.

WebAuthn 신뢰 당사자는 WebAuthn 클라이언트가 제한된 관련 오리진 집합에서 자격 증명을 생성하고 사용할 수 있도록 허용하는 기능을 선택적으로 활성화할 수 있습니다. 이러한 신뢰 당사자는 관련 오리진에서 수행되는 모든 절차에 공통으로 사용할 RP ID를 선택해야 합니다(MUST).

RP ID의 webauthn 잘 알려진 URL [RFC8615]에 JSON 문서를 호스팅해야 하며(MUST), HTTPS를 사용하여 제공해야 합니다(MUST). JSON 문서는 다음과 같이 반환되어야 합니다(MUST).

콘텐츠 유형은 application/json이어야 합니다(MUST).
최상위 JSON 객체는 origins라는 이름의 키를 포함해야 하며(MUST), 그 값은 웹 오리진을 포함하는 하나 이상의 문자열 배열이어야 합니다(MUST).

예를 들어 RP ID가 example.com인 경우:

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example.sg",
        "https://example.net",
        "https://exampledelivery.com",
        "https://exampledelivery.co.uk",
        "https://exampledelivery.de",
        "https://exampledelivery.sg",
        "https://myexamplerewards.com",
        "https://examplecars.com"
    ]
}

이 기능을 지원하는 WebAuthn 클라이언트는 최소 5개의 등록 가능한 오리진 레이블을 지원해야 합니다(MUST). 악용을 방지하기 위해 클라이언트 정책에서 상한을 정의해야 합니다(SHOULD).

WebAuthn 클라이언트가 이 잘 알려진 엔드포인트에 요청할 때는 자격 증명 없이, 리퍼러 없이, 그리고 https: 스킴을 사용하여 수행해야 합니다(MUST). 리디렉션을 따를 때 WebAuthn 클라이언트는 모든 리디렉션에서도 https: 스킴을 사용하도록 명시적으로 요구해야 합니다(MUST).

이 기능을 지원하는 WebAuthn 클라이언트는 getClientCapabilities()에 대한 응답에 relatedOrigins를 포함해야 합니다(SHOULD).

WebAuthn 클라이언트와 클라이언트 플랫폼은 추가적인 개인정보 보호 고려사항에 대해 § 14.5.5 WebAuthn 자격 증명의 교차 오리진 사용을 참조해야 합니다.

5.11.1. 관련 오리진 검증

인수 callerOrigin과 rpIdRequested가 주어졌을 때 관련 오리진 검증 절차는 다음과 같습니다.

maxLabels를 클라이언트 정책에서 허용하는 등록 가능한 오리진 레이블의 최대 개수로 둡니다.
RP ID rpIdRequested에 대한 webauthn 잘 알려진 URL [RFC8615] (즉, https://rpIdRequested/.well-known/webauthn)을 자격 증명 없이, 리퍼러 없이, 그리고 https: 스킴을 사용하여 가져옵니다.
1. 가져오기에 실패하거나, 응답의 콘텐츠 유형이 application/json이 아니거나, (리디렉션을 따른 후) 상태 코드가 200이 아니면 "SecurityError" DOMException을 throw합니다.
2. 리소스 본문이 유효한 JSON 객체가 아니면 "SecurityError" DOMException을 throw합니다.
3. JSON 객체의 origins 속성 값이 없거나 문자열 배열이 아니면 "SecurityError" DOMException을 throw합니다.
labelsSeen을 새 빈 집합으로 둡니다.
origins의 각 originItem에 대해 반복합니다.
1. originItem을 입력으로 하여 URL 파서를 실행한 결과를 url로 둡니다. 실패하면 계속합니다.
2. domain을 url의 유효 도메인으로 둡니다. null이면 계속합니다.
3. label을 domain의 등록 가능한 오리진 레이블로 둡니다.
4. label이 비어 있거나 null이면 계속합니다.
5. labelsSeen의 크기가 maxLabels 이상이고 labelsSeen에 label이 포함되어 있지 않으면 계속합니다.
6. callerOrigin과 url이 동일 오리진이면 true를 반환합니다.
7. labelsSeen의 크기가 maxLabels보다 작으면 label을 labelsSeen에 추가합니다.
false를 반환합니다.

6. WebAuthn 인증자 모델

웹 인증 API는 WebAuthn 인증자에 대한 특정 추상 기능 모델을 전제로 합니다. 이 절에서는 해당 인증자 모델을 설명합니다.

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

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

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

신뢰 당사자는 필요하다고 판단하는 경우 자격 증명을 생성하거나 어설션을 생성할 때 각각 자격 증명 생성 옵션 또는 어설션 생성 옵션을 사용하여 다양한 인증자 특성을 지정함으로써 인증자 선택에 영향을 줄 수 있습니다. WebAuthn API의 기반 알고리즘은 이러한 옵션을 정리하여 아래에 정의된 해당 인증자 작업에 전달합니다.

이 추상 모델에서 인증자는 키 관리와 암호학적 서명을 제공합니다. 인증자는 WebAuthn 클라이언트에 내장되거나 완전히 별도의 기기에 위치할 수 있습니다. 인증자 자체는 인증자의 나머지 부분보다 더 높은 보안 수준에서 작동하는 암호화 모듈을 포함할 수 있습니다. 이는 특히 WebAuthn 클라이언트에 내장된 인증자에서 중요합니다. 이러한 경우 이 암호화 모듈(예를 들어 TPM일 수 있음)은 인증자의 나머지 부분보다 더 신뢰할 수 있는 것으로 간주될 수 있기 때문입니다.

각 인증자는 자격 증명 맵, 즉 (rpId, userHandle)에서 공개 키 자격 증명 소스로 매핑되는 맵을 저장합니다.

또한 각 인증자는 Authenticator Attestation Globally Unique Identifier, 즉 AAGUID를 가지며, 이는 인증자의 유형(예: 제조사와 모델)을 나타내는 128비트 식별자입니다. AAGUID는 제조사가 만든 실질적으로 동일한 모든 인증자에서 동일하고, 다른 모든 유형의 인증자 AAGUID와는 높은 확률로 다르도록 제조사가 선택해야 합니다(MUST). 주어진 유형의 인증자에 대한 AAGUID는 이를 보장하기 위해 무작위로 생성해야 합니다(SHOULD). 신뢰 당사자는 다른 출처의 정보를 사용하여 AAGUID로 인증 수준과 키 보호 강도 같은 인증자의 특정 속성을 추론할 수 있습니다(MAY). 신뢰 당사자는 증명을 요청하고 검증하지 않고도 AAGUID를 사용하여 인증자의 제조사를 식별하려고 할 수 있지만(MAY), 증명 없이는 AAGUID가 진짜임을 증명할 수 없습니다.

인증자의 주된 기능은 다양한 컨텍스트 데이터에 바인딩되는 WebAuthn 서명을 제공하는 것입니다. 이러한 데이터는 서명 요청이 서버에서 인증자로 전달되는 동안 스택의 서로 다른 수준에서 관찰되고 추가됩니다. 서버는 서명을 검증할 때 이러한 바인딩을 예상 값과 대조합니다. 이러한 컨텍스트 바인딩은 두 가지로 나뉩니다. 신뢰 당사자 또는 클라이언트가 추가하는 것은 클라이언트 데이터라고 하고, 인증자가 추가하는 것은 인증자 데이터라고 합니다. 인증자는 클라이언트 데이터에 대해 서명하지만 그 외에는 내용에 관심을 두지 않습니다. 인증자의 대역폭과 처리 요구사항을 줄이기 위해 클라이언트는 클라이언트 데이터를 해시하고 그 결과만 인증자에 보냅니다. 인증자는 직렬화된 클라이언트 데이터의 해시와 자신의 인증자 데이터를 결합한 값에 서명합니다.

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

서명을 생성하는 방식은 클라이언트 기기와 인증자 사이의 연결이 대역폭 및/또는 지연 측면에서 매우 제한적인 경우를 수용해야 합니다. 예로 Bluetooth Low Energy와 Near-Field Communication이 있습니다.
인증자가 처리하는 데이터는 작고 저수준 코드에서 해석하기 쉬워야 합니다. 특히 인증자는 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: 백업 적격성 (BE). `1`은 공개 키 자격 증명 소스가 백업 가능함을 의미합니다. `0`은 공개 키 자격 증명 소스가 백업 가능하지 않음을 의미합니다. 비트 4: 백업 상태 (BS). `1`은 공개 키 자격 증명 소스가 현재 백업됨을 의미합니다. `0`은 공개 키 자격 증명 소스가 현재 백업되지 않음을 의미합니다. 비트 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 플래그를 설정해야 합니다(SHALL). 인증자가 사용자 검증을 수행한 경우에만 UV 플래그를 설정해야 합니다(SHALL). RFU 비트는 0으로 설정해야 합니다(SHALL).

참고: 인증자가 사용자 존재 테스트와 사용자 검증을 모두 수행했다면, 하나의 승인 제스처로 결합되었을 수도 있으며, 인증자는 UP 플래그와 UV 플래그를 모두 설정합니다.
자격 증명이 다중 기기 자격 증명인 경우에만 BE 플래그를 설정해야 합니다(SHALL). 이 값은 § 6.1.3 자격 증명 백업 상태에 정의된 등록 절차 이후 변경되어서는 안 됩니다(MUST NOT).
자격 증명이 다중 기기 자격 증명이고 현재 백업됨 상태인 경우에만 BS 플래그를 설정해야 합니다(SHALL).

자격 증명의 백업 상태가 불확실하거나 인증자가 백업된 자격 증명에 문제가 있다고 의심하는 경우, BS 플래그를 설정하지 않아야 합니다(SHOULD NOT).
증명 서명의 경우 인증자는 AT 플래그를 설정하고 attestedCredentialData를 포함해야 합니다(MUST). 어설션 서명의 경우 AT 플래그를 설정해서는 안 되며(MUST NOT), attestedCredentialData를 포함해서도 안 됩니다(MUST NOT).
인증자가 확장 데이터를 포함하지 않으면 ED 플래그를 0으로 설정해야 하며(MUST), 확장 데이터가 포함되면 1로 설정해야 합니다.

그림 은 인증자 데이터 구조를 시각적으로 나타냅니다.

참고: 인증자 데이터는 자체 길이를 설명합니다. AT 및 ED 플래그가 설정되지 않은 경우 항상 37바이트입니다. 증명된 자격 증명 데이터(AT 플래그가 설정된 경우에만 존재)는 자체 길이를 설명합니다. ED 플래그가 설정된 경우 전체 길이는 37바이트에 증명된 자격 증명 데이터의 길이(AT 플래그가 설정된 경우)와 뒤따르는 확장 출력 (CBOR 맵)의 길이를 더한 값입니다.

가변 길이인 증명된 자격 증명 데이터의 길이를 결정하려면, 앞선 credentialId의 길이를 바탕으로 credentialPublicKey의 시작 위치를 결정한 다음 credentialPublicKey의 길이를 결정해야 합니다([RFC9052]의 제7절도 참조).

6.1.1. 서명 카운터 고려사항

인증자는 서명 카운터 기능을 구현해야 합니다(SHOULD). 개념적으로 이러한 카운터는 인증자가 각 자격 증명별로 또는 인증자 전체에 대해 전역적으로 저장합니다. 자격 증명의 서명 카운터 초기값은 authenticatorMakeCredential이 반환한 인증자 데이터의 signCount 값으로 지정됩니다. 서명 카운터는 성공한 각 authenticatorGetAssertion 작업마다 양의 값만큼 증가하며, 이후 값은 다시 WebAuthn 신뢰 당사자에게 인증자 데이터 안에서 반환됩니다. 서명 카운터의 목적은 신뢰 당사자가 복제된 인증자를 탐지하는 데 도움을 주는 것입니다. 보호 조치가 제한된 인증자에서는 복제 탐지가 더 중요합니다.

서명 카운터를 구현하지 않는 인증자는 인증자 데이터의 signCount를 항상 0으로 유지합니다.

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

서명 카운터 불일치를 탐지했다고 해서 현재 작업이 복제된 인증자와 원래 인증자 중 어느 쪽에서 수행되었는지를 나타내는 것은 아닙니다. 신뢰 당사자는 각자의 상황, 즉 위험 허용 수준이나 값이 증가하지 않아도 허용할 만한 이유가 될 수 있는 운영상 요소에 맞게 이 상황을 적절히 처리해야 합니다.

인증자는:

자격 증명별 서명 카운터를 구현해야 합니다(SHOULD). 이렇게 하면 서명 카운터 값이 신뢰 당사자 간에 공유되어 사용자의 상관관계 식별자로 사용될 가능성을 방지합니다. 인증자는 전역 서명 카운터, 즉 인증자별 카운터를 구현할 수 있지만(MAY), 이는 사용자의 개인정보 보호 측면에서 덜 바람직합니다.
서명 카운터 값이 우발적으로 감소하지 않도록 해야 합니다(SHOULD)(예: 하드웨어 오류로 인해).

6.1.2. FIDO U2F 서명 형식 호환성

인증자 데이터 구조와 직렬화된 클라이언트 데이터의 해시를 연결한 값에 서명하는 어설션 서명 형식은 FIDO U2F 인증 서명 형식과 호환됩니다(제5.4절, [FIDO-U2F-Message-Formats] 참조).

이는 FIDO U2F 인증 응답 메시지에서 서명된 데이터의 처음 37바이트가 유효한 인증자 데이터 구조를 구성하고, 나머지 32바이트가 직렬화된 클라이언트 데이터의 해시이기 때문입니다. 이 인증자 데이터 구조에서 rpIdHash는 FIDO U2F 애플리케이션 매개변수이고, 플래그는 UP을 제외하면 항상 0이며, attestedCredentialData 및 extensions는 존재하지 않습니다. 따라서 FIDO U2F 인증 서명은 authenticatorGetAssertion 작업으로 생성된 다른 어설션 서명과 동일한 절차로 검증할 수 있습니다.

6.1.3. 자격 증명 백업 상태

자격 증명의 백업 적격성과 현재 백업 상태는 표 에 정의된 대로 인증자 데이터의 BE 및 BS 플래그로 전달됩니다.

BE 플래그의 값은 authenticatorMakeCredential 작업 중 설정되며 변경되어서는 안 됩니다(MUST NOT).

BS 플래그 값은 공개 키 자격 증명 소스의 현재 상태에 따라 시간이 지나면서 변경될 수 있습니다. 아래 표 는 유효한 조합과 그 의미를 정의합니다.

BE	BS	설명
`0`	`0`	자격 증명은 단일 기기 자격 증명입니다.
`0`	`1`	이 조합은 허용되지 않습니다.
`1`	`0`	자격 증명은 다중 기기 자격 증명이며 현재 백업되지 않았습니다.
`1`	`1`	자격 증명은 다중 기기 자격 증명이며 현재 백업되어 있습니다.

BE 및 BS 플래그 조합

신뢰 당사자는 향후 평가를 위해 이러한 플래그의 가장 최근 값을 사용자 계정과 함께 저장하는 것이 권장됩니다(RECOMMENDED).

다음은 신뢰 당사자가 이러한 플래그를 사용할 수 있는 방법의 일부 예입니다.

추가 인증자 요구:

BE 플래그가 0으로 설정되면 자격 증명은 단일 기기 자격 증명이며 생성 인증자는 해당 자격 증명이 백업되는 것을 절대로 허용하지 않습니다.

단일 기기 자격 증명은 단일 기기 손실에 대한 복원력이 없습니다. 신뢰 당사자는 각 사용자 계정에 추가 인증자가 등록되어 있거나 계정 복구 절차가 마련되어 있도록 해야 합니다(SHOULD). 예를 들어 사용자에게 로밍 인증자 또는 다중 기기 자격 증명을 지원하는 인증자 같은 추가 인증자를 설정하도록 안내할 수 있습니다.
사용자를 암호 없는 계정으로 업그레이드:

BS 플래그가 0에서 1로 변경되면 인증자는 자격 증명이 백업되었고 단일 기기 손실로부터 보호됨을 알리는 것입니다.

신뢰 당사자는 사용자에게 계정 보안을 업그레이드하고 암호를 제거하도록 안내할 수 있습니다(MAY).
상태 변경 후 추가 요소 추가:

BS 플래그가 1에서 0으로 변경되면 인증자는 자격 증명이 더 이상 백업되지 않으며 단일 기기 손실로부터 더 이상 보호되지 않음을 알리는 것입니다. 이는 백업 서비스 비활성화 같은 사용자 작업이나 백업 서비스 문제 같은 오류로 인해 발생할 수 있습니다.

이 전환이 발생하면 신뢰 당사자는 사용자가 다른 인증 요소를 검증하는 절차를 진행하도록 안내해야 합니다(SHOULD). 사용자가 자신의 계정에 다른 자격 증명을 가지고 있지 않다면 계정 접근을 잃지 않도록 추가 자격 증명을 추가하는 절차로 안내해야 합니다(SHOULD). 예를 들어 사용자에게 로밍 인증자 또는 다중 기기 자격 증명을 지원하는 인증자 같은 추가 인증자를 설정하도록 안내할 수 있습니다.

6.2. 인증자 분류

많은 사용 사례는 사용하는 인증자의 기능에 따라 달라집니다. 이 절에서는 이러한 기능과 가장 중요한 조합, 그리고 그러한 조합이 가능하게 하는 사용 사례에 관한 몇 가지 용어를 정의합니다.

예를 들면:

특정 클라이언트 기기에서 처음 인증할 때는 사용자가 아직 해당 클라이언트 기기에 플랫폼 자격 증명을 가지고 있지 않으므로 일반적으로 로밍 인증자가 필요합니다.
동일한 클라이언트 기기에서 이후 다시 인증할 때는 플랫폼 인증자가 별도로 찾아야 할 수 있는 기기가 아니라 클라이언트 기기에 직접 내장되어 있으므로 대체로 가장 편리합니다.
전통적인 사용자 이름과 암호에 추가하는 제2 요소 인증에는 어떤 인증자든 사용할 수 있습니다.
암호 없는 다중 요소 인증에는 사용자 검증을 수행할 수 있는 인증자가 필요하며, 경우에 따라 검색 가능한 자격 증명 지원 기능도 필요합니다.
노트북 컴퓨터는 USB와 Bluetooth를 통해 로밍 인증자에 연결하는 것을 지원할 수 있는 반면, 휴대전화는 NFC만 지원할 수 있습니다.

위 예는 주요 인증자 유형 특성을 보여줍니다.

인증자가 로밍 인증자인지, 플랫폼 인증자인지, 또는 경우에 따라 둘 다인지 여부 — 인증자 연결 방식. 로밍 인증자는 클라이언트와 통신하기 위해 하나 이상의 전송 방식을 지원할 수 있습니다.
인증자가 사용자 검증을 수행할 수 있는지 여부 — 인증 요소 기능.
인증자가 검색 가능한 자격 증명 지원 기능을 갖는지 여부 — 자격 증명 저장 방식.

이러한 특성은 서로 독립적이며 이론적으로 어떤 방식으로도 조합할 수 있지만, 표 에는 특히 관심 있는 몇 가지 인증자 유형의 이름을 나열하고 정의합니다.

인증자 유형	인증자 연결 방식	자격 증명 저장 방식	인증 요소 기능
제2 요소 플랫폼 인증자	플랫폼	둘 중 하나	단일 요소 지원
사용자 검증 플랫폼 인증자	플랫폼	둘 중 하나	다중 요소 지원
제2 요소 로밍 인증자	교차 플랫폼	서버 측 저장	단일 요소 지원
패스키 로밍 인증자	교차 플랫폼	클라이언트 측 저장	다중 요소 지원
패스키 플랫폼 인증자	플랫폼 (`transport` = `internal`) 또는 교차 플랫폼 (`transport` = `hybrid`)	클라이언트 측 저장	다중 요소 지원

일부 인증자 유형 이름의 정의.

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

패스키 플랫폼 인증자와 패스키 로밍 인증자는 암호 없는 다중 요소 인증을 가능하게 합니다. 자격 증명 개인 키를 보유했다는 증명 외에도 이러한 인증자는 일반적으로 PIN 또는 생체 인식인 두 번째 인증 요소로서 사용자 검증을 지원합니다. 따라서 인증자는 두 종류의 인증 요소로 작동할 수 있으므로, 다중 요소 인증을 가능하게 하면서 신뢰 당사자와 암호를 공유할 필요를 없앱니다. 이러한 인증자는 검색 가능한 자격 증명, 즉 패스키도 지원하므로, 사용자 이름 입력이 필요하지 않은 인증 흐름도 가능하게 합니다.

사용자 검증 플랫폼 인증자 클래스는 패스키 플랫폼 인증자 클래스에 의해 대부분 대체되었지만, 그 정의는 여전히 isUserVerifyingPlatformAuthenticatorAvailable 메서드에서 사용됩니다.

표 에 이름이 붙지 않은 조합은 두드러진 사용 사례가 적습니다.

검색 가능한 자격 증명 지원 기능은 있지만 다중 요소 지원 기능은 없는 로밍 인증자는 사용자 이름 없이 단일 요소 인증에 사용할 수 있습니다. 이 경우 사용자는 사용자 핸들로 자동 식별되고 자격 증명 개인 키의 보유가 유일한 인증 요소로 사용됩니다. 이는 일부 상황에서 유용할 수 있지만 사용자가 인증자 도난에 특히 취약해집니다.
다중 요소 지원 기능은 있지만 검색 가능한 자격 증명 지원 기능은 없는 로밍 인증자는 다중 요소 인증에 사용할 수 있지만 사용자를 먼저 식별해야 하므로 개인 식별 정보가 유출될 위험이 있습니다. § 14.6.3 자격 증명 ID를 통한 개인정보 유출을 참조하십시오.

다음 하위 절에서는 인증자 연결 방식, 자격 증명 저장 방식 및 인증 요소 기능 측면을 더 자세히 정의합니다.

6.2.1. 인증자 연결 방식

클라이언트는 다양한 메커니즘을 사용하여 인증자와 통신할 수 있습니다. 예를 들어 클라이언트는 클라이언트 기기에 물리적으로 결합된 인증자와 통신하기 위해 클라이언트 기기별 API를 사용할 수 있습니다(MAY). 반면 클라이언트는 Bluetooth와 같은 다양한 표준화된 교차 플랫폼 전송 프로토콜(§ 5.8.4 인증자 전송 열거형 (열거형 AuthenticatorTransport) 참조)을 사용하여 교차 플랫폼으로 연결된 인증자를 검색하고 통신할 수 있습니다. 클라이언트 기기의 일부인 인증자를 플랫폼 인증자라고 하며, 교차 플랫폼 전송 프로토콜을 통해 접근할 수 있는 인증자를 로밍 인증자라고 합니다.

플랫폼 인증자는 플랫폼 연결이라고 하는 클라이언트 기기별 전송 방식을 사용하여 연결되며 일반적으로 클라이언트 기기에서 분리할 수 없습니다. 플랫폼 인증자에 바인딩된 공개 키 자격 증명을 플랫폼 자격 증명이라고 합니다.
로밍 인증자는 교차 플랫폼 연결이라고 하는 교차 플랫폼 전송 방식을 사용하여 연결됩니다. 이 클래스의 인증자는 클라이언트 기기에서 분리할 수 있고 기기 사이를 "이동"할 수 있습니다. 로밍 인증자에 바인딩된 공개 키 자격 증명을 로밍 자격 증명이라고 합니다.

일부 플랫폼 인증자는 컨텍스트에 따라 로밍 인증자로도 작동할 수 있습니다. 예를 들어 모바일 기기에 통합된 플랫폼 인증자는 Bluetooth를 통해 로밍 인증자로 사용할 수 있도록 자신을 노출할 수 있습니다. 이 경우 모바일 기기에서 실행되는 클라이언트는 인증자를 플랫폼 인증자로 인식하는 반면, 다른 클라이언트 기기에서 실행되며 Bluetooth를 통해 동일한 인증자와 통신하는 클라이언트는 이를 로밍 인증자로 인식합니다.

플랫폼 인증자의 주요 사용 사례는 특정 클라이언트 기기를 "신뢰할 수 있는 기기"로 등록하여 클라이언트 기기 자체가 향후 인증을 위한 소유한 것 인증 요소로 작동하도록 하는 것입니다. 이는 향후 인증 절차에서 로밍 인증자가 필요하지 않게 하는 편의성을 사용자에게 제공합니다. 예를 들어 사용자는 열쇠고리나 휴대전화를 찾기 위해 주머니를 뒤질 필요가 없습니다.

로밍 인증자의 사용 사례에는 다음이 포함됩니다. 새 클라이언트 기기에서 처음 인증하는 경우, 자주 사용하지 않는 클라이언트 기기, 여러 사용자가 공유하는 클라이언트 기기, 또는 플랫폼 인증자가 없는 클라이언트 기기에서 인증하는 경우, 그리고 정책이나 기본 설정에 따라 인증자를 함께 사용하는 클라이언트 기기와 분리해 두어야 하는 경우입니다. 또한 로밍 인증자는 다른 인증자를 잃어버린 경우를 대비해 백업 자격 증명을 보관하는 데 사용할 수 있습니다.

6.2.2. 자격 증명 저장 방식

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

인증자, 클라이언트 또는 클라이언트 기기에 내장된 영구 저장소, 예를 들어 보안 요소에 저장합니다. 이는 클라이언트 측에서 검색 가능한 공개 키 자격 증명 소스에 대한 기술적 요구사항입니다.
공개 키 자격 증명 소스를 이 인증자만 복호화(즉, 래핑 해제)할 수 있도록 암호화(즉, 래핑)하고, 그 결과 암호문을 공개 키 자격 증명 소스의 자격 증명 ID로 사용합니다. 자격 증명 ID는 신뢰 당사자가 저장하고, get()의 allowCredentials 옵션을 통해 인증자에 반환되며, 이를 통해 인증자는 공개 키 자격 증명 소스를 복호화하고 사용할 수 있습니다.

이렇게 하면 암호화된 공개 키 자격 증명 소스가 인증자가 아니라 신뢰 당사자에 저장되므로 인증자는 사실상 무제한 자격 증명 저장 용량을 가질 수 있습니다. 하지만 이런 방식으로 저장된 자격 증명은 인증자가 사용하기 전에 신뢰 당사자에서 가져와야 합니다.

인증자가 어떤 저장 전략을 지원하는지에 따라 인증자의 자격 증명 저장 방식은 다음과 같이 정의됩니다.

인증자가 클라이언트 측에서 검색 가능한 공개 키 자격 증명 소스를 지원하면 클라이언트 측 자격 증명 저장 방식을 갖습니다. 클라이언트 측 자격 증명 저장 방식을 가진 인증자는 검색 가능한 자격 증명 지원이라고도 합니다.
인증자가 클라이언트 측 자격 증명 저장 방식을 갖지 않는 경우, 즉 공개 키 자격 증명 소스를 자격 증명 ID 안의 암호문으로 저장하는 것만 지원하면 서버 측 자격 증명 저장 방식을 갖습니다.

검색 가능한 자격 증명 지원 인증자는 두 저장 전략을 모두 지원할 수 있습니다(MAY). 이 경우 인증자는 residentKey 및 requireResidentKey 옵션의 제약을 받으면서 재량에 따라 서로 다른 자격 증명에 서로 다른 저장 전략을 사용할 수 있습니다(MAY).

6.2.3. 인증 요소 기능

인증 절차에서 신원을 증명하는 데 사용할 수 있는 인증 요소에는 크게 세 종류가 있습니다. 소유한 것, 알고 있는 것, 그리고 본인인 것입니다. 각각 물리적 키, 암호, 지문 등이 그 예입니다.

모든 WebAuthn 인증자는 소유한 것 클래스에 속하지만 사용자 검증을 지원하는 인증자는 추가로 한두 종류의 인증 요소로도 작동할 수 있습니다. 예를 들어 인증자가 PIN을 검증할 수 있다면 PIN은 알고 있는 것이고, 생체 인증자는 본인인 것을 검증할 수 있습니다. 따라서 사용자 검증을 지원하는 인증자는 다중 요소 지원입니다. 반대로 다중 요소 지원이 아닌 인증자는 단일 요소 지원입니다. 하나의 다중 요소 지원 인증자가 여러 방식의 사용자 검증을 지원하여 세 종류의 인증 요소 모두로 작동할 수도 있다는 점에 유의하십시오.

사용자 검증은 신뢰 당사자가 아니라 인증자에서 로컬로 수행되지만, 인증자는 신뢰 당사자에게 반환하는 서명된 응답의 UV 플래그를 설정하여 사용자 검증이 수행되었는지 나타냅니다. 따라서 신뢰 당사자는 UV 플래그를 사용하여 등록 또는 인증 절차에서 추가 인증 요소가 사용되었는지 검증할 수 있습니다. UV 플래그의 진위는 다시 인증자의 증명문을 검사하여 평가할 수 있습니다.

6.3. 인증자 작업

WebAuthn 클라이언트는 인증자의 작업을 호출하려면 해당 인증자에 연결해야 합니다(MUST). 이 연결은 인증자 세션을 정의합니다. 인증자는 세션 간 격리를 유지해야 합니다. 이는 특정 시점에 하나의 세션만 존재하도록 허용하거나 더 복잡한 세션 관리를 제공하는 방식으로 구현할 수 있습니다.

클라이언트는 인증자 세션에서 다음 작업을 호출할 수 있습니다.

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

인증자 authenticator에서 자격 증명 ID credentialId를 조회한 결과는 다음 알고리즘의 결과입니다.

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

6.3.2. authenticatorMakeCredential 작업

이 작업을 호출하기 전에 클라이언트는 인증자 세션에서 진행 중인 다른 모든 작업을 중단하기 위해 authenticatorCancel 작업을 호출해야 합니다(MUST).

이 작업은 다음 입력 매개변수를 받습니다.

hash: 클라이언트가 제공한 직렬화된 클라이언트 데이터의 해시.
rpEntity: 신뢰 당사자의 PublicKeyCredentialRpEntity.
userEntity: 신뢰 당사자가 제공한 사용자 핸들을 포함하는 사용자 계정의 PublicKeyCredentialUserEntity.
requireResidentKey: 클라이언트가 결정한 Boolean 값인 자격 증명 생성을 위한 유효 상주 키 요구사항.
requireUserPresence: 상수 Boolean 값 true, 또는 options.mediation이 conditional로 설정되고 사용자 에이전트가 이전에 사용자로부터 동의를 수집했다면 FALSE.
requireUserVerification: 클라이언트가 결정한 Boolean 값인 자격 증명 생성을 위한 유효 사용자 검증 요구사항.
credTypesAndPubKeyAlgs: 신뢰 당사자가 요청한 PublicKeyCredentialType과 공개 키 알고리즘(COSEAlgorithmIdentifier) 쌍의 시퀀스입니다. 이 시퀀스는 가장 선호되는 것부터 가장 덜 선호되는 순서로 정렬됩니다. 인증자는 생성할 수 있는 가장 선호되는 자격 증명을 생성하기 위해 최선을 다합니다.
excludeCredentialDescriptorList: 신뢰 당사자가 제공하는 선택적(OPTIONAL) PublicKeyCredentialDescriptor 객체 목록으로, 이들 중 하나라도 인증자에 알려져 있으면 새 자격 증명을 생성하지 않아야 한다는(SHOULD NOT) 의도로 제공됩니다. excludeCredentialDescriptorList에는 알려진 자격 증명 목록이 포함됩니다.
enterpriseAttestationPossible: 인증자가 개별 식별 가능한 증명을 반환할 수 있음을(MAY) 나타내는 Boolean 값입니다.
attestationFormats: 신뢰 당사자의 증명문 형식 기본 설정을 가장 선호되는 것부터 가장 덜 선호되는 순서로 나타내는 문자열 시퀀스입니다. 인증자가 증명을 반환하면 지원하는 형식 중 가장 선호되는 형식을 사용하기 위해 최선을 다합니다.
extensions: 확장 식별자에서 해당 인증자 확장 입력으로 매핑되는 CBOR 맵으로, 신뢰 당사자가 요청한 확장이 있는 경우 이를 기반으로 클라이언트가 생성합니다.

이 작업이 호출되면 인증자는 다음 절차를 수행해야 합니다(MUST).

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

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

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

U2F 기기임

새 자격 증명의 서명 카운터 값을 0으로 둡니다. (U2F 기기는 서명 카운터를 지원할 수 있지만 자격 증명을 생성할 때는 카운터를 반환하지 않습니다. [FIDO-U2F-Message-Formats]을 참조하십시오.)

전역 서명 카운터를 지원함

인증자 데이터를 생성할 때 전역 서명 카운터의 실제 값을 사용합니다.

자격 증명별 서명 카운터를 지원함

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

서명 카운터를 지원하지 않음

새 자격 증명의 서명 카운터 값을 항상 0으로 둡니다.
attestedCredentialData를 credentialId와 publicKey를 포함하는 증명된 자격 증명 데이터 바이트 배열로 둡니다.
enterpriseAttestationPossible을 고려하여 attestationFormats에서 지원되는 첫 번째 증명문 형식 식별자를 attestationFormat으로 둡니다. attestationFormats에 지원되는 값이 없으면 attestationFormat을 이 인증자가 가장 선호하는 증명문 형식 식별자로 둡니다.
authenticatorData를 § 6.1 인증자 데이터에 지정된 바이트 배열로 두며, attestedCredentialData를 attestedCredentialData로, processedExtensions가 있다면 이를 extensions로 포함합니다.
§ 6.5.4 증명 객체 생성에 명시된 절차, 증명문 형식 attestationFormat, 그리고 authenticatorData 및 hash 값을 사용하여 새 자격 증명의 증명 객체를 생성하며, enterpriseAttestationPossible의 값을 고려합니다. 증명에 대한 자세한 내용은 § 6.5 증명을 참조하십시오.

이 작업이 성공적으로 완료되면 인증자는 증명 객체를 클라이언트에 반환합니다.

6.3.3. authenticatorGetAssertion 작업

이 작업을 호출하기 전에 클라이언트는 인증자 세션에서 진행 중인 다른 모든 작업을 중단하기 위해 authenticatorCancel 작업을 호출해야 합니다(MUST).

이 작업은 다음 입력 매개변수를 받습니다.

rpId: 사용자 에이전트와 클라이언트가 결정한 호출자의 RP ID.
hash: 클라이언트가 제공한 직렬화된 클라이언트 데이터의 해시.
allowCredentialDescriptorList: 존재하는 경우 신뢰 당사자가 허용하는 자격 증명을 설명하는, 클라이언트가 필터링했을 수도 있는 선택적(OPTIONAL) PublicKeyCredentialDescriptor의 목록.
requireUserPresence: 상수 Boolean 값 true. WebAuthn은 선택적으로 만들지 않지만 사용자 존재 테스트를 선택적으로 만들고자 할 수 있는 구현에 이 추상 인증자 모델을 적용하기 쉽게 하기 위해 여기에서는 의사 매개변수로 포함합니다.
requireUserVerification: 클라이언트가 제공하는 Boolean 값인 어설션을 위한 유효 사용자 검증 요구사항.
extensions: 확장 식별자에서 해당 인증자 확장 입력으로 매핑되는 CBOR 맵으로, 존재하는 경우 신뢰 당사자가 요청한 확장을 기반으로 클라이언트가 생성합니다.

이 메서드가 호출되면 인증자는 다음 절차를 수행해야 합니다(MUST).

제공된 모든 매개변수가 구문적으로 올바르고 길이가 정확한지 확인합니다. 그렇지 않으면 "UnknownError"와 동등한 오류 코드를 반환하고 작업을 종료합니다.
credentialOptions를 공개 키 자격 증명 소스의 새 빈 집합으로 둡니다.
allowCredentialDescriptorList가 제공된 경우 allowCredentialDescriptorList의 각 descriptor에 대해 반복합니다.
1. credSource를 이 인증자에서 descriptor.id를 조회한 결과로 둡니다.
2. credSource가 null이 아니면 이를 credentialOptions에 추가합니다.
그렇지 않으면(allowCredentialDescriptorList가 제공되지 않음), 이 인증자의 자격 증명 맵의 각 key → credSource에 대해 반복하여 credSource를 credentialOptions에 추가합니다.
credentialOptions에서 rpId가 rpId와 같지 않은 모든 항목을 제거합니다.
credentialOptions가 이제 비어 있으면 "NotAllowedError"와 동등한 오류 코드를 반환하고 작업을 종료합니다.
사용자에게 credentialOptions에서 공개 키 자격 증명 소스 selectedCredential을 선택하도록 요청합니다. selectedCredential 사용에 대한 사용자 동의를 확인하는 승인 제스처를 수집합니다. 승인 제스처의 프롬프트는 자체 출력 기능이 있다면 인증자가, 그렇지 않으면 사용자 에이전트가 표시할 수 있습니다.
requireUserVerification이 true이면 승인 제스처에는 사용자 검증이 포함되어야 합니다(MUST).

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

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

어설션 서명 생성.
어설션 서명을 생성하는 동안 오류가 발생하면 "UnknownError"와 동등한 오류 코드를 반환하고 작업을 종료합니다.
사용자 에이전트에 다음을 반환합니다.
- 클라이언트가 길이 2 이상의 자격 증명 목록 (즉, allowCredentialDescriptorList)을 제공했거나 그러한 목록을 제공하지 않은 경우 selectedCredential.id.
  
  참고: allowCredentialDescriptorList 안에서 클라이언트가 정확히 하나의 자격 증명을 제공했고 이를 성공적으로 사용했다면 클라이언트가 이미 알고 있으므로 그 자격 증명 ID는 반환하지 않습니다. 이는 일반적인 경우일 가능성이 높은 상황에서 제한된 연결일 수 있는 경로로 이러한 바이트를 전송하는 비용을 줄여 줍니다.
- authenticatorData
- signature
- selectedCredential.userHandle
  
  참고: allowCredentialDescriptorList가 제공된 경우 반환된 userHandle 값은 null일 수 있습니다. userHandleResult를 참조하십시오.

인증자가 지정된 신뢰 당사자에 대응하면서 지정된 기준과 일치하는 자격 증명을 찾지 못하면 작업을 종료하고 오류를 반환합니다.

6.3.4. authenticatorCancel 작업

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

클라이언트가 인증자 세션에서 이 작업을 호출하면 해당 인증자 세션에서 현재 진행 중인 authenticatorMakeCredential 또는 authenticatorGetAssertion 작업을 종료하는 효과가 있습니다. 인증자는 취소된 작업의 승인과 관련된 사용자 입력을 더 이상 요청하거나 수락하지 않습니다. 클라이언트는 취소된 작업에 대해 인증자가 보내는 이후의 모든 응답을 무시합니다.

현재 진행 중인 authenticatorMakeCredential 또는 authenticatorGetAssertion 작업이 없는 인증자 세션에서 호출되면 이 작업은 무시됩니다.

6.3.5. silentCredentialDiscovery 작업

이는 conditional 사용자 중재를 가능하게 하기 위해 인증자가 지원할 수 있는(MAY) 선택적(OPTIONAL) 작업입니다.

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

rpId: 클라이언트가 결정한 호출자의 RP ID.

이 작업이 호출되면 인증자는 다음 절차를 수행해야 합니다(MUST).

collectedDiscoverableCredentialMetadata를 다음 항목을 가진 DiscoverableCredentialMetadata 구조체를 항목으로 갖는 새 목록으로 둡니다.

type

PublicKeyCredentialType.

id

자격 증명 ID.

rpId

신뢰 당사자 식별자.

userHandle

사용자 핸들.

otherUI

인증자가 UI에 정보를 제공하는 데 사용하는 기타 정보.
authenticator의 자격 증명 맵에 있는 각 공개 키 자격 증명 소스 credSource에 대해 반복합니다.
1. credSource가 클라이언트 측에서 검색 가능한 자격 증명이 아니면 계속합니다.
2. credSource.rpId가 rpId가 아니면 계속합니다.
3. discoveredCredentialMetadata를 credSource의 type, id, rpId, userHandle 및 otherUI의 복사본을 항목으로 갖는 새 DiscoverableCredentialMetadata 구조체로 둡니다.
4. discoveredCredentialMetadata를 collectedDiscoverableCredentialMetadata에 추가합니다.
collectedDiscoverableCredentialMetadata를 반환합니다.

6.4. 문자열 처리

인증자는 신뢰 당사자가 선택한 임의의 문자열, 예를 들어 name 및 displayName을 PublicKeyCredentialUserEntity에 저장해야 할 수 있습니다. 이 절에서는 사람에게 표시될 수 있는 임의의 문자열을 처리할 때 발생하는 몇 가지 실질적인 결과를 설명합니다.

6.4.1. 문자열 잘라내기

API의 각 임의 문자열에는 인증자에서 사용할 수 있는 잠재적으로 제한된 리소스를 고려한 어떤 대응 방식이 있습니다. 선택한 대응 방식이 문자열 잘라내기라면 문자열 값이 손상되지 않도록 주의해야 합니다.

예를 들어 Unicode 코드 포인트만을 기준으로 잘라내면 자소 클러스터가 잘릴 수 있습니다. 이렇게 되면 글리프가 완전히 제거되는 대신 자소 클러스터가 다른 글리프로 렌더링되어 문자열의 의미가 바뀔 수 있습니다. 예를 들어 그림 은 인코딩 길이가 65바이트인 UTF-8 인코딩 문자열의 끝부분을 보여줍니다. 64바이트로 잘라내면 크기 제한을 충족하기 위해 마지막 0x88 바이트가 먼저 제거됩니다. 이렇게 하면 불완전한 UTF-8 코드 포인트가 남으므로 해당 코드 포인트의 나머지도 제거해야 합니다. 그러면 불완전한 자소 클러스터가 남으므로 해당 클러스터의 나머지도 제거해야 합니다.

서로 다른 잘라내기 경계의 위치를 보여주는 UTF-8 인코딩 문자열의 끝부분.

이러한 문제를 처리할 책임은 주로 클라이언트에 있으며, 인증자가 문자 인코딩과 Unicode 문자 속성을 이해해야 하는 부담을 피하기 위한 것입니다. 다음 하위 절에서는 각각 클라이언트와 인증자가 문자열 잘라내기를 수행할 수 있는 방법에 관한 요구사항을 정의합니다.

6.4.1.1. 클라이언트에 의한 문자열 잘라내기

WebAuthn 클라이언트가 문자열을 잘라낼 때 신뢰 당사자가 관찰할 수 있는 잘라내기 동작은 다음 요구사항을 충족해야 합니다(MUST).

지정된 최소 지원 길이 이상인 크기 제한을 선택합니다. UTF-8 문자 인코딩에서 문자열의 바이트 길이가 해당 제한을 충족하도록 문자열을 잘라낼 수 있습니다(MAY). 이 잘라내기는 UTF-8 코드 포인트 경계를 준수해야 하며(MUST), 자소 클러스터 경계를 준수해야 합니다(SHOULD) [UAX29]. 잘라낸 결과 값은 선택한 크기 제한보다 짧을 수 있지만(MAY), 크기 제한을 충족하면서 자소 클러스터 경계에서 끝나는 가장 긴 접두 부분 문자열보다 짧아서는 안 됩니다(MUST NOT).

인증자가 이러한 요구사항을 충족한다면 클라이언트는 인증자가 잘라내기를 수행하도록 할 수 있습니다(MAY). 그렇지 않으면 클라이언트는 문자열 값을 인증자에 전달하기 전에 잘라내기를 수행해야 합니다(MUST).

위 내용 외에도 바이트 경계만을 기준으로 잘라내면 사용자 에이전트가 알아야 하는 알려진 문제가 발생합니다. 인증자가 [FIDO-CTAP]을 사용하는 경우 해당 값은 CBOR 문자열로 유형이 지정되어 있어 유효한 UTF-8이어야 하므로 이후 인증자 메시지에 유효하지 않은 CBOR이 포함될 수 있습니다. 따라서 인증자를 다룰 때 사용자 에이전트는 다음을 수행해야 합니다(SHOULD).

인증자에 전송되는 모든 문자열이 유효하게 인코딩되어 있는지 확인합니다.
문자열이 잘려 유효하지 않은 인코딩이 된 경우를 처리합니다. 예를 들어 끝부분의 불완전한 코드 포인트를 제거하거나 U+FFFD로 대체할 수 있습니다.

6.4.1.2. 인증자에 의한 문자열 잘라내기

WebAuthn 인증자는 제한된 환경에서 구현될 수 있으므로 인증자에 대한 요구사항은 클라이언트에 대한 요구사항보다 완화되어 있습니다.

WebAuthn 인증자가 문자열을 잘라낼 때 잘라내기 동작은 다음 요구사항을 충족해야 합니다(MUST).

지정된 최소 지원 길이 이상인 크기 제한을 선택합니다. UTF-8 문자 인코딩에서 문자열의 바이트 길이가 해당 제한을 충족하도록 문자열을 잘라낼 수 있습니다(MAY). 이 잘라내기는 UTF-8 코드 포인트 경계를 준수해야 하며(SHOULD), 자소 클러스터 경계를 준수할 수 있습니다(MAY) [UAX29]. 잘라낸 결과 값은 선택한 크기 제한보다 짧을 수 있지만(MAY), 크기 제한을 충족하면서 자소 클러스터 경계에서 끝나는 가장 긴 접두 부분 문자열보다 짧아서는 안 됩니다(MUST NOT).

6.4.2. 언어 및 방향 인코딩

문자열을 컨텍스트에 맞게 올바르게 표시하려면 문자열의 언어와 기본 방향이 필요할 수 있습니다. 이 API의 문자열은 고정 기능 인증자에 기록된 뒤 나중에 다른 플랫폼에서 다시 읽혀 표시될 수 있습니다.

전용 언어 및 방향 메타데이터 필드를 지원하지 않는 기존 고정 기능 인증자와의 호환성을 위해 웹 인증 레벨 2에는 이러한 메타데이터를 문자열 자체에 삽입하여 원자적으로 전송되도록 하는 규정이 포함되어 있었습니다. 이 인코딩은 권장되지 않습니다(NOT RECOMMENDED). 클라이언트와 인증자는 새 값에서 이러한 인코딩을 무시할 수 있습니다(MAY). 클라이언트와 인증자는 웹 인증 레벨 2 §6.4.2. 언어 및 방향 인코딩에 설명된 대로 기존 문자열에 인코딩된 언어 및 방향 메타데이터를 감지하고 처리할 수 있습니다(MAY).

대신 향후 버전의 웹 인증 API는 전용 언어 및 방향 메타데이터 필드를 제공할 수 있습니다.

6.5. 증명

인증자는 가능하면 어떤 형태로든 증명을 제공해야 합니다(SHOULD). 인증자가 이를 제공한다면 기본 요구사항은 인증자가 각 자격 증명 공개 키에 대해 WebAuthn 신뢰 당사자가 검증할 수 있는 증명문을 생성할 수 있어야 한다는 것입니다. 일반적으로 이 증명문에는 증명된 자격 증명 공개 키와 챌린지에 대해 증명 개인 키로 생성한 서명과, 증명 공개 키의 출처 정보를 제공하는 인증서 또는 유사한 데이터가 포함되어 신뢰 당사자가 신뢰 여부를 판단할 수 있게 합니다. 그러나 증명 키 쌍을 사용할 수 없다면 인증자는 해당 자격 증명 개인 키로 자격 증명 공개 키의 자체 증명을 수행하거나, 그렇지 않으면 증명을 수행하지 않을 수 있습니다(MAY). 이 모든 정보는 새 공개 키 자격 증명이 생성될 때마다 인증자가 전체적으로 증명 객체 형태로 반환합니다. 증명 객체와 인증자 데이터(증명된 자격 증명 데이터 포함), 그리고 증명문 간의 관계는 아래 그림 에 나타나 있습니다.

인증자가 자체 증명 또는 증명 없음을 사용하면, 신뢰 당사자가 신뢰 판단의 근거로 사용할 출처 정보가 제공되지 않습니다. 이러한 경우 인증자는 자신의 작동에 관해 신뢰 당사자에게 어떠한 보장도 제공하지 않습니다.

포함된 인증자 데이터(증명된 자격 증명 데이터 포함)와 증명문을 보여주는 증명 객체 배치.

참고: 이 그림은 packed 증명문 형식만 보여줍니다. 여러 추가 증명문 형식은 § 8 정의된 증명문 형식에 정의되어 있습니다.

증명 객체의 중요한 구성 요소는 증명문입니다. 이는 공개 키 자격 증명 자체와 이를 생성한 인증자에 관한 진술을 포함하는 특정 유형의 서명된 데이터 객체입니다. 여기에는 증명 기관의 키를 사용하여 생성한 증명 서명이 포함됩니다(자체 증명의 경우에는 자격 증명 개인 키를 사용하여 생성). 증명문을 올바르게 해석하려면 신뢰 당사자는 증명의 다음 두 측면을 이해해야 합니다.

증명문 형식은 서명이 표현되는 방식과 다양한 컨텍스트 바인딩이 인증자에 의해 증명문에 통합되는 방식입니다. 즉, 이는 문의 구문을 정의합니다. 다양한 기존 구성 요소와 OS 플랫폼(TPM 및 Android OS 등)은 이미 증명문 형식을 정의해 왔습니다. 이 명세는 § 6.5.2 증명문 형식에 정의된 대로 이러한 여러 형식을 확장 가능한 방식으로 지원합니다. 형식 자체는 § 8.1 증명문 형식 식별자에 설명된 대로 문자열로 식별됩니다.
증명 유형은 증명문과 그 기반 신뢰 모델의 의미를 정의합니다. 구체적으로는 암호학적으로 유효함을 검증한 후 신뢰 당사자가 특정 증명문에 대한 신뢰를 설정하는 방법을 정의합니다. 이 명세는 § 6.5.3 증명 유형에 설명된 여러 증명 유형을 지원합니다.

일반적으로 증명문 형식과 증명 유형 사이에는 단순한 매핑이 없습니다. 예를 들어 § 8.2 Packed 증명문 형식에 정의된 "packed" 증명문 형식은 모든 증명 유형과 함께 사용할 수 있지만, 다른 형식과 유형은 적용 범위가 더 제한적입니다.

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

신뢰 모델을 결정하는 증명 유형,
증명문에서 표현할 수 있는 내용을 제한함으로써 증명의 강도를 제한할 수 있는(MAY) 증명문 형식, 그리고
구성 방식, 일부 또는 전체가 보안 운영 환경에서 실행되는지 여부 등 개별 인증자의 특성.

증명 유형과 증명문 형식은 인증자가 선택하며, 신뢰 당사자는 attestation 및 attestationFormats 매개변수를 설정하여 기본 설정만 알릴 수 있습니다.

대부분의 인증자는 소수의 증명 유형과 증명문 형식을 지원하고, 신뢰 당사자는 정책에 따라 허용할 증명 유형을 결정할 것으로 예상됩니다. 신뢰 당사자는 또한 신뢰하는 인증자에 관해 보유한 정보를 바탕으로 해당 인증자의 특성을 이해해야 합니다. 예를 들어 FIDO Metadata Service [FIDOMetadataService]는 이러한 정보에 접근하는 한 가지 방법을 제공합니다.

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

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

이름	길이(바이트)	설명
aaguid	16	인증자의 AAGUID.
credentialIdLength	2	credentialId의 바이트 길이 L, 16비트 부호 없는 빅 엔디언 정수. 값은 1023 이하여야 합니다.
credentialId	L	자격 증명 ID
credentialPublicKey	가변	자격 증명 공개 키는 [RFC9052]의 제7절에 정의된 COSE_Key 형식으로 인코딩되며, CTAP2 정규 CBOR 인코딩 형식을 사용합니다. COSE_Key로 인코딩된 자격 증명 공개 키는 "alg" 매개변수를 포함해야 하며 다른 선택적 매개변수를 포함해서는 안 됩니다. "alg" 매개변수에는 `COSEAlgorithmIdentifier` 값이 포함되어야 합니다. 인코딩된 자격 증명 공개 키는 관련 키 유형 명세에서 규정하는 추가 필수 매개변수, 즉 키 유형 "kty"와 알고리즘 "alg"에 필수인 매개변수도 포함해야 합니다 ([RFC9053]의 제2절 참조).

증명된 자격 증명 데이터 배치. 이름 열의 이름은 이 문서 내에서 참조하기 위한 것일 뿐이며 실제 증명된 자격 증명 데이터 표현에는 존재하지 않습니다.

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

이 절에서는 ES256, PS256 및 RS256 서명 알고리즘을 위한 COSE_Key 인코딩 타원 곡선 및 RSA 공개 키의 예를 제공합니다. 이 예들은 위에서 정의한 credentialPublicKey 값에 대한 규칙을 준수하며, 명확성을 위해 CDDL [RFC8610] 로 표시됩니다.

[RFC9052]의 제7절은 모든 COSE_Key 인코딩 키의 일반적인 프레임워크를 정의합니다. 특정 알고리즘을 위한 특정 키 유형은 아래에서 설명하는 다른 명세뿐만 아니라 [RFC9053]에도 정의되어 있습니다.

다음은 EC2 형식의 COSE_Key 인코딩 타원 곡선 공개 키([RFC9053]의 제7.1절 참조)를 P-256 곡선에서 ES256 서명 알고리즘(ECDSA w/ SHA-256, [RFC9053]의 제2.1절 참조)과 함께 사용하는 예입니다.

{
  1:   2,  ; kty: EC2 키 유형
  3:  -7,  ; alg: ES256 서명 알고리즘
 -1:   1,  ; crv: P-256 곡선
 -2:   x,  ; 길이가 32바이트인 바이트 문자열 형태의 x 좌표
           ; 예: 16진수: 65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d
 -3:   y   ; 길이가 32바이트인 바이트 문자열 형태의 y 좌표
           ; 예: 16진수: 1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
}

다음은 위의 타원 곡선 공개 키를 CTAP2 정규 CBOR 인코딩 형식으로 인코딩한 것입니다. 공백과 줄바꿈은 명확성을 위해, 그리고 위의 CDDL [RFC8610] 표현과 일치시키기 위해 포함되어 있습니다.

A5
   01  02

   03  26

   20  01

   21  58 20   65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d

   22  58 20   1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c

다음은 2048비트 COSE_Key 인코딩 RSA 공개 키의 예([RFC8230] 제4절 참조)이며, PS256 서명 알고리즘 (SHA-256을 사용하는 RSASSA-PSS, [RFC8230]의 제2절 참조)과 함께 사용합니다.

{
  1:   3,  ; kty: RSA 키 유형
  3: -37,  ; alg: PS256
 -1:   n,  ; n:   길이가 256바이트인 RSA 모듈러스 n 바이트 문자열
           ;      예: 16진수(간결성을 위해 중간 바이트 생략): DB5F651550...6DC6548ACC3
 -2:   e   ; e:   길이가 3바이트인 RSA 공개 지수 e 바이트 문자열
           ;      예: 16진수: 010001
}

다음은 위와 동일한 COSE_Key 인코딩 RSA 공개 키의 예이며, RS256 서명 알고리즘(SHA-256을 사용하는 RSASSA-PKCS1-v1_5)과 함께 사용합니다.

{
  1:   3,  ; kty: RSA 키 유형
  3:-257,  ; alg: RS256
 -1:   n,  ; n:   길이가 256바이트인 RSA 모듈러스 n 바이트 문자열
           ;      예: 16진수(간결성을 위해 중간 바이트 생략): DB5F651550...6DC6548ACC3
 -2:   e   ; e:   길이가 3바이트인 RSA 공개 지수 e 바이트 문자열
           ;      예: 16진수: 010001
}

6.5.2. 증명문 형식

위에서 설명한 것처럼 증명문 형식은 일련의 컨텍스트 바인딩에 대한 인증자의 암호학적 서명을 표현하는 데이터 형식입니다. 각 증명문 형식은 다음 템플릿을 사용하여 정의해야 합니다.

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

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

6.5.3. 증명 유형

WebAuthn은 증명문과 그 기반 신뢰 모델의 의미를 정의하는 여러 증명 유형을 지원합니다.

참고: 이 명세는 인증자가 사용하는 증명 유형을 명시적으로 표현하는 데이터 구조를 정의하지 않습니다. 증명문 검증을 수행하는 신뢰 당사자, 즉 navigator.credentials.create()을 호출할 때 none 이외의 증명 전달을 선택하고 수신한 증명문을 검증하는 신뢰 당사자는 검증의 일부로 사용된 증명 유형을 결정합니다. § 8 정의된 증명문 형식의 "검증 절차" 하위 절을 참조하십시오. 또한 § 14.4.1 증명 개인정보 보호를 참조하십시오. 이 절에 정의된 증명 유형 중 자체 및 없음을 제외한 모든 유형에서는 신뢰 당사자의 검증 뒤에 § 7.1 새 자격 증명 등록의 24단계에 따라 신뢰 경로를 허용 가능한 루트 인증서와 일치시키는 작업이 이어집니다. 이러한 증명 유형의 구분은 주로 신뢰 당사자 정책에 따라 증명이 허용되는지 판단하는 수단으로 유용합니다.

기본 증명 (기본)

기본 증명 [UAFProtocol]의 경우 인증자의 증명 키 쌍은 인증자 "모델", 즉 인증자 "배치"에 고유합니다. 따라서 동일하거나 유사한 모델의 인증자는 종종 동일한 증명 키 쌍을 공유합니다. 자세한 내용은 § 14.4.1 증명 개인정보 보호를 참조하십시오.

기본 증명은 배치 증명이라고도 합니다.

자체 증명 (자체)

대리 기본 증명 [UAFProtocol]이라고도 하는 자체 증명의 경우 인증자는 특정 증명 키 쌍을 갖지 않습니다. 대신 자격 증명 개인 키를 사용하여 증명 서명을 생성합니다. 증명 개인 키에 의미 있는 보호 조치가 없는 인증자는 일반적으로 이 증명 유형을 사용합니다.

증명 CA (AttCA)

이 경우 인증자는 신뢰할 수 있는 플랫폼 모듈(TPM)을 기반으로 하며 인증자별 "보증 키"(EK)를 보유합니다. 이 키는 신뢰할 수 있는 제3자인 증명 CA [TCG-CMCProfile-AIKCertEnroll] (이전에는 "Privacy CA"로 알려짐)와 안전하게 통신하는 데 사용됩니다. 인증자는 여러 증명 식별 키 쌍(AIK)을 생성하고 각 AIK에 대해 증명 CA에 AIK 인증서 발급을 요청할 수 있습니다. 이 방식을 사용하면 이러한 인증자는 전역 상관관계 식별자인 EK의 노출을 증명 CA로 제한할 수 있습니다. AIK는 인증자가 생성한 각 공개 키 자격 증명마다 개별적으로 요청할 수 있으며 신뢰 당사자에게 증명 인증서로 전달할 수 있습니다.

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

익명화 CA (AnonCA)

이 경우 인증자는 익명화 CA를 사용합니다. 익명화 CA는 자격 증명별 증명 인증서를 동적으로 생성하여 신뢰 당사자에게 제시되는 증명문이 추적 목적으로 사용될 수 있는 고유 식별 정보를 제공하지 않도록 합니다.

참고: AttCA 또는 AnonCA 유형의 증명을 전달하는 증명문은 기본 유형과 동일한 데이터 구조를 사용하므로 세 증명 유형은 일반적으로 증명문에 전달되는 증명 인증서 내용에 관한 외부 제공 지식이 있어야만 구분할 수 있습니다.

증명문 없음 (없음)

이 경우 사용할 수 있는 증명 정보가 없습니다. § 8.7 없음 증명문 형식도 참조하십시오.

6.5.4. 증명 객체 생성

다음이 주어졌을 때 증명 객체(그림 6 참조)를 생성하려면:

attestationFormat: 증명문 형식.
authData: 인증자 데이터를 포함하는 바이트 배열.
hash: 직렬화된 클라이언트 데이터의 해시.

인증자는 다음을 수행해야 합니다.

attStmt를 authData 및 hash가 주어졌을 때 attestationFormat의 서명 절차를 실행한 결과로 둡니다.
fmt를 attestationFormat의 증명문 형식 식별자로 둡니다.

이 알고리즘에서 초기화된 변수로 채운 다음 구문을 갖는 CBOR 맵으로 증명 객체를 반환합니다.

attObj = {
    authData: bytes,

    ; $$attStmtType의 각 선택지는 fmt 값과 attStmt 구조를 정의합니다
    $$attStmtType
} .within attStmtTemplate

attStmtTemplate = {
    authData: bytes,
    fmt: text,
    attStmt: (
      { * tstr => any } ; 맵은 각 구체적인 attStmtType에 의해 채워집니다
      //
      [ * any ]         ; attStmt는 배열일 수도 있습니다
    )
}

6.5.5. Packed 증명, FIDO U2F 증명 및 어설션 서명의 서명 형식

COSEAlgorithmIdentifier -7 (ES256) 및 기타 ECDSA 기반 알고리즘의 경우 sig 값은 [RFC3279] 제2.2.3절에 정의된 ASN.1 DER Ecdsa-Sig-Value로 인코딩되어야 합니다.

예:
참고: 인코딩 길이는 INTEGER 크기와 곡선 크기에 따라 달라집니다.
30 43                                ; SEQUENCE (67바이트)
    02 21                            ; INTEGER (33바이트)
    | 00 89 90 95 04 e1 4f 1e 29 db a8 15 8f a7 c3 87
    | e8 88 ff be 07 d8 24 bb 21 43 20 55 06 ab 15 9c
    | 3e
    02 1e                            ; INTEGER (30바이트)
    | 56 55 4f b5 81 9b 12 84 5e 85 be 2f 78 37 1c f3
    | cb 95 e3 87 f4 51 cb 36 2b 94 78 d1 83 d2

참고: CTAP1/U2F 인증자가 이미 이 형식의 서명 값을 생성하고 있으므로, 일관성을 위해 CTAP2 인증자도 동일한 형식의 서명 값을 생성합니다.

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

아래의 서명 형식 정의는 이 요구사항을 충족하며 여기에서 명시적으로 언급하지 않은 다른 서명 알고리즘에 동일한 형식을 도출하기 위한 예로 사용됩니다.

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

7. WebAuthn 신뢰 당사자 작업

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

create() 또는 get()이 성공적으로 실행되면 신뢰 당사자의 스크립트는 클라이언트로부터 각각 AuthenticatorAttestationResponse 또는 AuthenticatorAssertionResponse 구조를 포함하는 PublicKeyCredential을 받습니다. 그런 다음 이 구조의 내용을 이 명세의 범위를 벗어난 방법을 사용하여 신뢰 당사자 서버에 전달해야 합니다. 이 절에서는 이러한 구조를 수신했을 때 신뢰 당사자가 수행해야 하는 작업을 설명합니다.

7.1. 새 자격 증명 등록

등록 절차를 수행하려면 신뢰 당사자는 다음과 같이 진행해야 합니다.

options를 절차에 대한 신뢰 당사자의 요구에 맞게 구성된 새 CredentialCreationOptions 구조로 둡니다. pkOptions를 options.publicKey로 둡니다.
navigator.credentials.create()을 호출하고 options를 인수로 전달합니다. 성공적으로 이행된 promise의 결과를 credential로 둡니다. promise가 거부되면 사용자에게 표시되는 오류와 함께 절차를 중단하거나, 거부된 promise에서 사용할 수 있는 컨텍스트에 따라 판단 가능한 방식으로 사용자 경험을 안내합니다. 예를 들어 promise가 "InvalidStateError"와 동등한 오류 코드로 거부되면 사용자에게 다른 인증자를 사용하도록 안내할 수 있습니다. 서로 다른 오류 컨텍스트와 이를 발생시키는 상황에 관한 정보는 § 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의 값이 pkOptions.challenge의 base64url 인코딩과 같은지 검증합니다.
C.origin의 값이 신뢰 당사자가 예상하는 오리진인지 검증합니다. 지침은 § 13.5.9 자격 증명의 오리진 검증을 참조하십시오.
C.crossOrigin이 존재하고 true로 설정되어 있으면, 신뢰 당사자가 이 자격 증명이 조상과 동일 오리진이 아닌 iframe 내에서 생성되었을 것으로 예상하는지 검증합니다.
C.topOrigin이 존재하면:
1. 신뢰 당사자가 이 자격 증명이 조상과 동일 오리진이 아닌 iframe 내에서 생성되었을 것으로 예상하는지 검증합니다.
2. C.topOrigin의 값이 신뢰 당사자가 그 안에 하위 프레임으로 포함될 것으로 예상하는 페이지의 오리진과 일치하는지 검증합니다. 지침은 § 13.5.9 자격 증명의 오리진 검증을 참조하십시오.
hash를 response.clientDataJSON에 SHA-256을 사용하여 해시를 계산한 결과로 둡니다.
AuthenticatorAttestationResponse 구조의 attestationObject 필드에 CBOR 디코딩을 수행하여 증명문 형식 fmt, 인증자 데이터 authData, 그리고 증명문 attStmt를 얻습니다.
authData의 rpIdHash가 신뢰 당사자가 예상하는 RP ID의 SHA-256 해시인지 검증합니다.
options.mediation이 conditional로 설정되지 않았다면 authData의 flags에서 UP 비트가 설정되어 있는지 검증합니다.
신뢰 당사자가 이 등록에 사용자 검증을 요구한다면 authData의 flags에서 UV 비트가 설정되어 있는지 검증합니다.
authData의 flags에서 BE 비트가 설정되어 있지 않다면 BS 비트도 설정되어 있지 않은지 검증합니다.
신뢰 당사자가 사용자 경험 흐름 및/또는 정책을 결정하는 데 자격 증명의 백업 적격성을 사용한다면 authData의 flags에서 BE 비트를 평가합니다.
신뢰 당사자가 사용자 경험 흐름 및/또는 정책을 결정하는 데 자격 증명의 백업 상태를 사용한다면 authData의 flags에서 BS 비트를 평가합니다.
authData의 자격 증명 공개 키에 있는 "alg" 매개변수가 pkOptions.pubKeyCredParams의 항목 중 하나의 alg 속성과 일치하는지 검증합니다.
fmt를 지원되는 WebAuthn 증명문 형식 식별자 값 집합과 USASCII 대소문자 구분 방식으로 일치시켜 증명문 형식을 결정합니다. 등록된 WebAuthn 증명문 형식 식별자 값의 최신 목록은 [RFC8809]에서 설정한 IANA "WebAuthn 증명문 형식 식별자" 레지스트리 [IANA-WebAuthn-Registries]에서 관리됩니다.
attStmt, authData 및 hash가 주어졌을 때 증명문 형식 fmt의 검증 절차를 사용하여 attStmt가 유효한 증명 서명을 전달하는 올바른 증명문인지 검증합니다.
참고: 각 증명문 형식은 자체 검증 절차를 지정합니다. 초기 정의 형식은 § 8 정의된 증명문 형식을, 최신 목록은 [IANA-WebAuthn-Registries]를 참조하십시오.
검증에 성공하면 신뢰할 수 있는 출처 또는 정책에서 해당 증명 유형 및 증명문 형식 fmt에 대한 허용 가능한 신뢰 앵커(즉, 증명 루트 인증서) 목록을 얻습니다. 예를 들어 FIDO Metadata Service [FIDOMetadataService]는 authData의 attestedCredentialData에 있는 aaguid를 사용하여 이러한 정보를 얻는 한 가지 방법을 제공합니다.
22단계의 검증 절차 출력을 사용하여 다음과 같이 증명의 신뢰성을 평가합니다.
- 증명 없음이 제공되었다면 없음 증명이 신뢰 당사자 정책에서 허용되는지 검증합니다.
- 자체 증명이 사용되었다면 자체 증명이 신뢰 당사자 정책에서 허용되는지 검증합니다.
- 그렇지 않으면 검증 절차에서 증명 신뢰 경로로 반환된 X.509 인증서를 사용하여 증명 공개 키가 허용 가능한 루트 인증서까지 올바르게 체인되는지 또는 그 자체가 허용 가능한 인증서인지 검증합니다(즉, 이 인증서와 23단계에서 얻은 루트 인증서가 동일할 수도 있습니다).
증명문이 신뢰할 수 있는 것으로 판단되지 않으면 신뢰 당사자는 등록 절차를 실패시켜야 합니다.

참고: 그러나 정책에서 허용한다면 신뢰 당사자는 자격 증명 ID와 자격 증명 공개 키를 등록하되 해당 자격 증명을 자체 증명을 가진 것으로 취급할 수 있습니다(§ 6.5.3 증명 유형 참조). 그렇게 하는 경우 신뢰 당사자는 해당 공개 키 자격 증명이 특정 인증자 모델에서 생성되었다는 암호학적 증거가 없음을 주장하는 것입니다. 자세한 논의는 [FIDOSecRef] 및 [UAFProtocol]을 참조하십시오.
credentialId가 1023바이트 이하인지 검증합니다. 이보다 큰 자격 증명 ID는 RP가 이 등록 절차를 실패시키게 해야 합니다.
credentialId가 아직 어떤 사용자에게도 등록되지 않았는지 검증합니다. credentialId가 이미 알려져 있다면 신뢰 당사자는 이 등록 절차를 실패시켜야 합니다.

참고: 신뢰 당사자가 중복 자격 증명 ID를 거부하는 이유는 다음과 같습니다. 자격 증명 ID에는 충분한 엔트로피가 포함되어 있어 우연한 중복 가능성이 매우 낮습니다. 그러나 자체 증명 이외의 증명 유형에는 등록 시점에 자격 증명 개인 키의 보유를 명시적으로 증명하는 자체 서명이 포함되지 않습니다. 따라서 어떤 방식으로든 한 사이트의 사용자의 자격 증명 ID와 자격 증명 공개 키를 확보한 공격자는 피해자의 자격 증명을 해당 사이트에서 자신의 것으로 등록하려 시도할 수 있습니다. 신뢰 당사자가 이 새 등록을 허용하여 피해자의 기존 자격 증명 등록을 대체하고 자격 증명이 검색 가능한 경우, 피해자는 다음 로그인 시 공격자의 계정에 로그인하도록 강제될 수 있습니다. 그 상태에서 피해자가 사이트에 저장한 데이터는 공격자가 접근할 수 있게 됩니다.
credentialRecord를 다음 내용을 가진 새 자격 증명 레코드로 둡니다.

type

credential.type.

id

credential.id 또는 credential.rawId 중 신뢰 당사자가 선호하는 형식.

publicKey

authData의 자격 증명 공개 키.

signCount

authData.signCount.

uvInitialized

authData의 UV 플래그 값.

transports

response.getTransports()에서 반환된 값.

backupEligible

authData의 BE 플래그 값.

backupState

authData의 BS 플래그 값.

새 자격 증명 레코드에는 다음 선택적 내용도 포함될 수 있습니다.

attestationObject

response.attestationObject.

attestationClientDataJSON

response.clientDataJSON.

rpId

pkOptions.rp.id.

신뢰 당사자는 필요에 따라 추가 항목을 포함할 수도 있습니다. 비규범적 예로 신뢰 당사자는 사용자가 계정 설정과 상호 작용할 때 어떤 자격 증명이 어떤 인증자에 바인딩되어 있는지 기억하는 데 도움이 되도록 자격 증명에 "별칭"을 설정할 수 있게 할 수 있습니다.
신뢰 당사자의 요구에 따라 clientExtensionResults의 클라이언트 확장 출력과 authData의 extensions에 있는 인증자 확장 출력을 처리합니다. 각 확장에 따라 처리 단계가 구체적으로 지정될 수도 있고 확장 출력을 어떻게 처리할지는 신뢰 당사자가 결정할 수도 있습니다. 신뢰 당사자는 일부 또는 모든 확장 출력을 무시할 수 있습니다.
클라이언트는 추가 인증자 확장 또는 클라이언트 확장을 설정할 수 있으며, 이로 인해 pkOptions.extensions에서 신뢰 당사자가 요청하지 않은 값이 인증자 확장 출력 또는 클라이언트 확장 출력에 나타날 수 있습니다. 신뢰 당사자는 요청하지 않은 확장을 무시하거나 증명을 거부하는 방식 등으로 이러한 상황을 처리할 준비가 되어 있어야 합니다. 신뢰 당사자는 로컬 정책과 사용 중인 확장을 바탕으로 이 결정을 내릴 수 있습니다.

모든 확장은 클라이언트와 인증자 모두에게 선택 사항이므로 신뢰 당사자는 요청한 확장 중 일부 또는 전부가 처리되지 않은 경우도 처리할 준비가 되어 있어야 합니다.
위의 모든 단계가 성공하면 pkOptions.user에서 나타낸 사용자 계정에 credentialRecord를 저장하고 등록 절차를 적절히 계속합니다. 그렇지 않으면 등록 절차를 실패시킵니다.

이 경우 신뢰 당사자가 등록 절차를 실패시키지 않는다면 신뢰 당사자는 해당 공개 키 자격 증명이 특정 인증자 모델에서 생성되었다는 암호학적 증거가 없음을 허용하는 것입니다. 신뢰 당사자는 해당 자격 증명을 증명 없음을 가진 것과 동등하게 간주할 수 있습니다(§ 6.5.3 증명 유형 참조). 자세한 논의는 [FIDOSecRef] 및 [UAFProtocol]을 참조하십시오.

증명 객체를 검증하려면 신뢰 당사자가 위의 23단계에서 허용 가능한 신뢰 앵커를 결정할 수 있는 신뢰할 수 있는 방법을 가지고 있어야 합니다. 또한 인증서를 사용하는 경우 신뢰 당사자는 중간 CA 인증서의 인증서 상태 정보에 접근할 수 있어야 합니다. 클라이언트가 증명 정보에 증명 인증서 체인을 제공하지 않았다면 신뢰 당사자는 해당 체인을 구성할 수도 있어야 합니다.

7.2. 인증 어설션 검증

인증 절차를 수행하려면 신뢰 당사자는 다음과 같이 진행해야 합니다.

options를 절차에 대한 신뢰 당사자의 요구에 맞게 구성된 새 CredentialRequestOptions 구조로 둡니다. pkOptions를 options.publicKey로 둡니다.
navigator.credentials.get()을 호출하고 options를 인수로 전달합니다. 성공적으로 이행된 promise의 결과를 credential로 둡니다. promise가 거부되면 사용자에게 표시되는 오류와 함께 절차를 중단하거나, 거부된 promise에서 사용할 수 있는 컨텍스트에 따라 판단 가능한 방식으로 사용자 경험을 안내합니다. 서로 다른 오류 컨텍스트와 이를 발생시키는 상황에 관한 정보는 § 6.3.3 authenticatorGetAssertion 작업을 참조하십시오.
response를 credential.response로 둡니다. response가 AuthenticatorAssertionResponse의 인스턴스가 아니면 사용자에게 표시되는 오류와 함께 절차를 중단합니다.
clientExtensionResults를 credential.getClientExtensionResults()을 호출한 결과로 둡니다.
pkOptions.allowCredentials가 비어 있지 않으면, credential.id가 pkOptions.allowCredentials에 나열된 공개 키 자격 증명 중 하나를 식별하는지 검증합니다.
인증 중인 사용자를 식별하고 credentialRecord를 해당 자격 증명의 자격 증명 레코드로 둡니다.

인증 절차가 시작되기 전에 사용자 이름이나 쿠키 등을 통해 사용자가 식별된 경우,

식별된 사용자 계정에 credential.rawId와 동일한 id를 가진 자격 증명 레코드가 포함되어 있는지 검증합니다. credentialRecord를 해당 자격 증명 레코드로 둡니다. response.userHandle이 존재한다면 식별된 사용자 계정의 사용자 핸들과 같은지 검증합니다.

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

response.userHandle이 존재하는지 검증합니다. response.userHandle로 식별된 사용자 계정에 credential.rawId와 동일한 id를 가진 자격 증명 레코드가 포함되어 있는지 검증합니다. credentialRecord를 해당 자격 증명 레코드로 둡니다.
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의 값이 pkOptions.challenge의 base64url 인코딩과 같은지 검증합니다.
C.origin의 값이 신뢰 당사자가 예상하는 오리진인지 검증합니다. 지침은 § 13.5.9 자격 증명의 오리진 검증을 참조하십시오.
C.crossOrigin이 존재하고 true로 설정되어 있으면, 신뢰 당사자가 이 자격 증명이 조상과 동일 오리진이 아닌 iframe 내에서 사용될 것으로 예상하는지 검증합니다.
C.topOrigin이 존재하면:
1. 신뢰 당사자가 이 자격 증명이 조상과 동일 오리진이 아닌 iframe 내에서 사용될 것으로 예상하는지 검증합니다.
2. C.topOrigin의 값이 신뢰 당사자가 그 안에 하위 프레임으로 포함될 것으로 예상하는 페이지의 오리진과 일치하는지 검증합니다. 지침은 § 13.5.9 자격 증명의 오리진 검증을 참조하십시오.
authData의 rpIdHash가 신뢰 당사자가 예상하는 RP ID의 SHA-256 해시인지 검증합니다.
참고: appid 확장을 사용하는 경우 이 단계에는 특별한 로직이 필요합니다. 자세한 내용은 § 10.1.1 FIDO AppID 확장 (appid)을 참조하십시오.
authData의 flags에서 UP 비트가 설정되어 있는지 검증합니다.
이 어설션에 사용자 검증이 필요한지 결정합니다. 사용자 검증은 pkOptions.userVerification이 required로 설정된 경우에만 요구해야 합니다.

사용자 검증이 필요하다고 결정된 경우 authData의 flags에서 UV 비트가 설정되어 있는지 검증합니다. 그렇지 않으면 UV 플래그 값을 무시합니다.
authData의 flags에서 BE 비트가 설정되어 있지 않다면 BS 비트도 설정되어 있지 않은지 검증합니다.
자격 증명의 백업 상태가 신뢰 당사자 비즈니스 로직 또는 정책의 일부로 사용된다면, currentBe와 currentBs를 각각 authData의 flags에서 BE 및 BS 비트의 값으로 둡니다. currentBe와 currentBs를 credentialRecord.backupEligible 및 credentialRecord.backupState와 비교합니다.
1. credentialRecord.backupEligible이 설정되어 있으면 currentBe가 설정되어 있는지 검증합니다.
2. credentialRecord.backupEligible이 설정되어 있지 않으면 currentBe가 설정되어 있지 않은지 검증합니다.
3. 존재하는 경우 신뢰 당사자 정책을 적용합니다.
참고: 신뢰 당사자가 BS 플래그 값을 처리할 수 있는 방법의 예는 § 6.1.3 자격 증명 백업 상태를 참조하십시오.
hash를 cData에 SHA-256을 사용하여 해시를 계산한 결과로 둡니다.
credentialRecord.publicKey를 사용하여 sig가 authData와 hash의 이진 연결 값에 대한 유효한 서명인지 검증합니다.

참고: 이 검증 단계는 FIDO U2F 인증자가 생성한 서명과 호환됩니다. § 6.1.2 FIDO U2F 서명 형식 호환성을 참조하십시오.
authData.signCount가 0이 아니거나 credentialRecord.signCount가 0이 아니면 다음 하위 단계를 실행합니다.
- authData.signCount가
  credentialRecord.signCount보다 큼:
  서명 카운터가 유효합니다.
  credentialRecord.signCount보다 작거나 같음:
  이는 인증자가 복제되었을 수 있다는 신호이지만 증거는 아닙니다. 예를 들어 다음을 의미할 수 있습니다.
  - 자격 증명 개인 키의 복사본이 둘 이상 존재하며 병렬로 사용되고 있을 수 있습니다.
  - 인증자가 오작동하고 있습니다.
  - 신뢰 당사자가 인증자에서 어설션 응답이 생성된 순서와 다른 순서로 이를 처리하는 경쟁 조건이 존재합니다.
  신뢰 당사자는 자체 운영 특성을 평가하고 이 정보를 위험 점수 산정에 반영해야 합니다. 이 경우 신뢰 당사자가 아래의 credentialRecord.signCount를 업데이트할지 여부, 또는 인증 절차를 실패시킬지 여부는 신뢰 당사자에 따라 결정됩니다.
  
  서명 카운터 고려사항에 대한 자세한 내용은 § 6.1.1 서명 카운터 고려사항을 참조하십시오.
신뢰 당사자의 요구에 따라 clientExtensionResults의 클라이언트 확장 출력과 authData의 extensions에 있는 인증자 확장 출력을 처리합니다. 각 확장에 따라 처리 단계가 구체적으로 지정될 수도 있고 확장 출력을 어떻게 처리할지는 신뢰 당사자가 결정할 수도 있습니다. 신뢰 당사자는 일부 또는 모든 확장 출력을 무시할 수 있습니다.
클라이언트는 추가 인증자 확장 또는 클라이언트 확장을 설정할 수 있으며, 이로 인해 pkOptions.extensions에서 신뢰 당사자가 요청하지 않은 값이 인증자 확장 출력 또는 클라이언트 확장 출력에 나타날 수 있습니다. 신뢰 당사자는 요청하지 않은 확장을 무시하거나 어설션을 거부하는 방식 등으로 이러한 상황을 처리할 준비가 되어 있어야 합니다. 신뢰 당사자는 로컬 정책과 사용 중인 확장을 바탕으로 이 결정을 내릴 수 있습니다.

모든 확장은 클라이언트와 인증자 모두에게 선택 사항이므로 신뢰 당사자는 요청한 확장 중 일부 또는 전부가 처리되지 않은 경우도 처리할 준비가 되어 있어야 합니다.
credentialRecord를 새 상태 값으로 업데이트합니다.
1. credentialRecord.signCount를 authData.signCount의 값으로 업데이트합니다.
2. credentialRecord.backupState를 currentBs의 값으로 업데이트합니다.
3. credentialRecord.uvInitialized가 false이면 authData의 flags에서 UV 비트의 값으로 업데이트합니다. 이 변경에는 WebAuthn 사용자 검증과 동등한 추가 인증 요소에 의한 승인이 필요해야 합니다. 승인되지 않으면 이 단계를 건너뜁니다.
신뢰 당사자가 이러한 WebAuthn 인증 절차 단계 이외에 추가 보안 검사를 수행한다면 위의 상태 업데이트는 해당 추가 검사가 성공적으로 완료된 후까지 미뤄야 합니다.
위의 모든 단계가 성공하면 인증 절차를 적절히 계속합니다. 그렇지 않으면 인증 절차를 실패시킵니다.

8. 정의된 증명문 형식

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

8.1. 증명문 형식 식별자

증명문 형식은 증명문 형식의 작성자가 선택한 문자열인 증명문 형식 식별자로 식별됩니다.

증명문 형식 식별자는 [RFC8809]에서 설정한 IANA "WebAuthn 증명문 형식 식별자" 레지스트리 [IANA-WebAuthn-Registries]에 등록해야 합니다. 등록된 모든 증명문 형식 식별자는 당연히 서로 고유합니다.

등록되지 않은 증명문 형식 식별자는 식별자의 고유성을 보장하기 위해 개발자가 등록한 도메인 이름을 사용하여 소문자 역방향 도메인 이름 명명 방식을 사용해야 합니다. 모든 증명문 형식 식별자는 최대 32옥텟 길이여야 하며 백슬래시와 큰따옴표를 제외한 인쇄 가능한 USASCII 문자, 즉 [RFC5234]에 정의된 VCHAR에서 %x22와 %x5c를 제외한 문자로만 구성되어야 합니다.

참고: 이는 도메인 이름 기반 증명문 형식 식별자에는 LDH 레이블 [RFC5890]만 포함할 수 있음을 의미합니다.

구현은 WebAuthn 증명문 형식 식별자를 대소문자를 구분하여 일치시켜야 합니다.

여러 버전이 존재할 수 있는 증명문 형식은 식별자에 버전을 포함해야 합니다. 결과적으로 서로 다른 버전은 서로 다른 형식으로 취급됩니다. 예를 들어 § 8.2 Packed 증명문 형식의 새 버전으로 packed2를 사용할 수 있습니다.

다음 절에서는 현재 정의되고 등록된 증명문 형식과 해당 식별자 집합을 제시합니다. 등록된 증명문 형식 식별자의 최신 목록은 [RFC8809]에서 설정한 IANA "WebAuthn 증명문 형식 식별자" 레지스트리 [IANA-WebAuthn-Registries]에서 관리됩니다.

8.2. Packed 증명문 형식

이는 WebAuthn에 최적화된 증명문 형식입니다. 매우 간결하면서도 확장 가능한 인코딩 방식을 사용합니다. 제한된 리소스(예: 보안 요소)를 가진 인증자에서도 구현할 수 있습니다.

증명문 형식 식별자

packed

지원되는 증명 유형

기본, 자체, 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: 이 배열의 요소에는 각각 X.509 형식으로 인코딩된 attestnCert와 그 인증서 체인(있는 경우)이 포함됩니다. 증명 인증서 attestnCert는 배열의 첫 번째 요소여야 합니다.
attestnCert: X.509 형식으로 인코딩된 증명 인증서.

서명 절차

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

authenticatorData를 증명을 위한 인증자 데이터로 두고, clientDataHash를 직렬화된 클라이언트 데이터의 해시로 둡니다.
기본 또는 AttCA 증명을 사용하는 경우 인증자는 authenticatorData와 clientDataHash를 연결하고 인증자별 메커니즘을 통해 선택한 증명 개인 키로 결과에 서명하여 sig를 생성합니다. x5c를 attestnCert와 뒤따르는 관련 인증서 체인(있는 경우)으로 설정합니다. alg를 증명 개인 키의 알고리즘으로 설정합니다.
자체 증명을 사용하는 경우 인증자는 authenticatorData와 clientDataHash를 연결하고 자격 증명 개인 키로 결과에 서명하여 sig를 생성합니다. alg를 자격 증명 개인 키의 알고리즘으로 설정하고 다른 필드는 생략합니다.

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같습니다.

attStmt가 위에 정의된 구문을 준수하는 유효한 CBOR인지 검증하고 CBOR 디코딩을 수행하여 포함된 필드를 추출합니다.
x5c가 존재하면:
- alg에 지정된 알고리즘을 사용하여 attestnCert의 증명 공개 키로 authenticatorData와 clientDataHash의 연결 값에 대한 sig가 유효한 서명인지 검증합니다.
- 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가 기본 또는 AttCA 증명을 전달하는지 결정합니다.
- 성공하면 증명 유형 기본, AttCA 또는 불확실성, 그리고 증명 신뢰 경로 x5c를 나타내는 구현별 값을 반환합니다.
x5c가 존재하지 않으면 자체 증명을 사용하는 것입니다.
- alg가 authenticatorData의 credentialPublicKey의 알고리즘과 일치하는지 검증합니다.
- alg를 사용하여 자격 증명 공개 키로 authenticatorData와 clientDataHash의 연결 값에 대한 sig가 유효한 서명인지 검증합니다.
- 성공하면 증명 유형 자체와 비어 있는 증명 신뢰 경로를 나타내는 구현별 값을 반환합니다.

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

증명 인증서는 다음 필드/확장을 가져야 합니다.

Version은 3으로 설정되어야 합니다(값이 2인 ASN.1 INTEGER로 표시됨).
Subject 필드는 다음과 같이 설정되어야 합니다.

Subject-C

인증자 공급업체가 설립된 국가를 지정하는 ISO 3166 코드 (PrintableString)

Subject-O

인증자 공급업체의 법적 이름(UTF8String)

Subject-OU

리터럴 문자열 “Authenticator Attestation” (UTF8String)

Subject-CN

공급업체가 선택한 UTF8String
관련 증명 루트 인증서가 여러 인증자 모델에 사용되는 경우 확장 OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid)가 존재해야 하며 AAGUID를 16바이트 OCTET STRING으로 포함해야 합니다. 이 확장은 critical로 표시되어서는 안 됩니다.

신뢰 당사자는 증명 루트 인증서가 여러 인증자 모델에 사용되는지 알지 못할 수 있으므로 신뢰 당사자는 해당 확장이 존재하는지 확인하고, 존재한다면 증명 객체에 제시된 것과 동일한 AAGUID가 포함되어 있는지 검증하는 것이 좋습니다.

X.509 Extension은 값의 DER 인코딩을 OCTET STRING 안에 인코딩한다는 점에 유의하십시오. 따라서 유효하려면 AAGUID가 두 개의 OCTET STRING으로 래핑되어야 합니다.
Basic Constraints 확장의 CA 구성 요소는 false로 설정되어야 합니다.

또한 id-ad-ocsp 항목이 있는 Authority Information Access(AIA) 확장과 CRL Distribution Point 확장 [RFC5280]은 많은 증명 인증서의 상태를 인증자 메타데이터 서비스에서 확인할 수 있으므로 둘 다 선택 사항입니다. 예를 들어 FIDO Metadata Service [FIDOMetadataService]를 참조하십시오.

특정 인증자 모델의 펌웨어는 확장 OID 1.3.6.1.4.1.45724.1.1.5 (id-fido-gen-ce-fw-version)를 사용하여 구분할 수 있습니다. 존재하는 경우 이 속성은 음이 아닌 INTEGER를 포함하며 새 펌웨어 릴리스 버전마다 증가합니다. 이 확장은 critical로 표시되어서는 안 됩니다.

예를 들어 다음은 위 확장 OID와 필수 필드를 포함하는 증명 인증서입니다.

위 속성은 이 인증서 안에서 다음과 같이 구성됩니다.

30 21                                    -- SEQUENCE
  06 0B 2B 06 01 04 01 82 E5 1C 01 01 04 -- OID 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 cd8c395c-26ed-eede-653b-00797d03ca3c
      65 3B 00 79 7D 03 CA 3C 

30 12                                    -- SEQUENCE
  06 0B 2B 06 01 04 01 82 E5 1C 01 01 05 -- OID 1.3.6.1.4.1.45724.1.1.5
  04 03                                  -- OCTET STRING
    02 01                                -- INTEGER
      2A                                 -- 펌웨어 버전: 42

8.2.2. 엔터프라이즈 Packed 증명문의 인증서 요구사항

확장 OID 1.3.6.1.4.1.45724.1.1.2 ( id-fido-gen-ce-sernum )는 엔터프라이즈용 packed 증명에 추가로 존재할 수 있습니다. 존재하는 경우 이 확장은 특정 AAGUID에 대해 기기별로 고유한 옥텟 문자열 값을 나타내야 합니다. 이 값은 공장 초기화 후에도 일정하게 유지되어야 하지만 기기와 연결된 다른 일련번호나 다른 하드웨어 식별자와 달라도 됩니다. 이 확장은 critical로 표시되어서는 안 되며 해당 값은 OCTET STRING으로 인코딩됩니다. 이 확장은 엔터프라이즈가 아닌 증명에는 존재해서는 안 됩니다.

8.3. 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: X.509 인코딩으로 증명에 사용되는 AIK 인증서.
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 매개변수를 "alg" 서명 알고리즘에 대응하는 해시 알고리즘을 사용한 attToBeSigned의 다이제스트로 설정합니다. ("RS256" 알고리즘의 경우 SHA-256 다이제스트가 됩니다.)

pubArea 필드를 자격 증명 공개 키의 공개 영역(TPMT_PUBLIC 구조)으로, certInfo 필드(TPMS_ATTEST 구조)를 동일한 이름의 출력 매개변수로, sig 필드를 위 절차에서 얻은 서명으로 설정합니다.

참고: pubArea를 TPM2_ReadPublic 명령을 사용하여 TPM에서 읽으면 해당 명령은 TPM2B_PUBLIC 구조를 반환합니다. TPM2B_PUBLIC은 2바이트 길이 뒤에 TPMT_PUBLIC 구조가 이어집니다. pubArea에 넣기 전에 2바이트 길이를 제거해야 합니다.

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같습니다.

attStmt가 위에 정의된 구문을 준수하는 유효한 CBOR인지 검증하고 CBOR 디코딩을 수행하여 포함된 필드를 추출합니다.

pubArea의 parameters 및 unique 필드로 지정된 공개 키가 authenticatorData의 attestedCredentialData에 있는 credentialPublicKey와 동일한지 검증합니다.

authenticatorData와 clientDataHash를 연결하여 attToBeSigned를 구성합니다.

certInfo의 무결성을 검증합니다.

x5c가 존재하는지 검증합니다.
aikCert가 § 8.3.1 TPM 증명문 인증서 요구사항을 충족하는지 검증합니다.
aikCert에 OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid)인 확장이 포함되어 있으면 이 확장의 값이 authenticatorData의 aaguid와 일치하는지 검증합니다.
alg에 지정된 알고리즘을 사용하여 aikCert의 증명 공개 키로 certInfo에 대한 sig가 유효한 서명인지 검증합니다.

certInfo가 유효한지 검증합니다. 참고: certInfo는 TPMS_ATTEST 구조입니다.

magic이 TPM_GENERATED_VALUE로 설정되어 있는지 검증합니다.
type이 TPM_ST_ATTEST_CERTIFY로 설정되어 있는지 검증합니다.
extraData가 "alg"에서 사용하는 해시 알고리즘으로 계산한 attToBeSigned의 해시로 설정되어 있는지 검증합니다.
attested가 [TPMv2-Part2] 제10.12.3절에 명시된 TPMS_CERTIFY_INFO 구조를 포함하고 있으며, 그 name 필드가 pubArea의 nameAlg를 사용하여 [TPMv2-Part1] 제16절에 명시된 절차로 계산한 pubArea의 유효한 Name을 포함하는지 검증합니다.

참고: TPM은 항상 pubArea의 nameAlg와 name의 nameAlg가 동일한 TPMS_CERTIFY_INFO 구조를 반환합니다.

참고: "표준 증명 구조" [TPMv2-Part1] 제31.2절의 나머지 필드, 즉 qualifiedSigner, clockInfo 및 firmwareVersion은 무시됩니다. 사용된 aikCert 키의 속성에 따라 이러한 필드는 난독화될 수 있습니다. 유효한 경우 위험 엔진의 입력으로 사용할 수 있습니다.
성공하면 증명 유형 AttCA와 증명 신뢰 경로 x5c를 나타내는 구현별 값을 반환합니다.

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

TPM 증명 인증서는 다음 필드/확장을 가져야 합니다.

Version은 3으로 설정되어야 합니다.
Subject 필드는 비어 있도록 설정해야 합니다.
Subject Alternative Name 확장은 [TPMv2-EK-Profile] 제3.2.9절에 정의된 대로 설정해야 합니다.

참고: 이전 버전의 [TPMv2-EK-Profile]에서는 EK 인증서에 TPM 일련번호를 포함하는 HardwareModuleName이라는 선택적 속성을 포함할 수 있었습니다. HardwareModuleName은 증명 인증서의 Subject Alternative Name에 넣지 않아야 합니다.
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로 설정되어야 합니다.
id-ad-ocsp 항목이 있는 Authority Information Access(AIA) 확장과 CRL Distribution Point 확장 [RFC5280]은 많은 증명 인증서의 상태를 메타데이터 서비스를 통해 확인할 수 있으므로 둘 다 선택 사항입니다. 예를 들어 FIDO Metadata Service [FIDOMetadataService]를 참조하십시오.

8.4. Android 키 증명문 형식

해당 인증자가 Android "N" 이상 플랫폼의 플랫폼 인증자인 경우 증명문은 Android 키 증명을 기반으로 합니다. 이 경우 증명문은 보안 운영 환경에서 실행되는 구성 요소가 생성하지만 증명을 위한 인증자 데이터는 이 환경 밖에서 생성됩니다. WebAuthn 신뢰 당사자는 증명에 사용되었다고 주장되는 인증자 데이터가 증명 인증서 확장 데이터의 필드와 일치하는지 확인해야 합니다.

증명문 형식 식별자

android-key

지원되는 증명 유형

기본

구문

Android 키 증명문은 DER로 인코딩된 일련의 X.509 인증서인 Android 증명문만으로 구성됩니다. Android 개발자 문서를 참조하십시오. 구문은 다음과 같이 정의됩니다.

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

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

서명 절차

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

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

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

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같습니다.

attStmt가 위에 정의된 구문을 준수하는 유효한 CBOR인지 검증하고 CBOR 디코딩을 수행하여 포함된 필드를 추출합니다.
alg에 지정된 알고리즘을 사용하여 x5c의 첫 번째 인증서에 있는 공개 키로 authenticatorData와 clientDataHash의 연결 값에 대한 sig가 유효한 서명인지 검증합니다.
x5c의 첫 번째 인증서에 있는 공개 키가 authenticatorData의 attestedCredentialData에 있는 credentialPublicKey와 일치하는지 검증합니다.
확장 데이터인 증명 인증서의 attestationChallenge 필드가 clientDataHash와 동일한지 검증합니다.
증명 인증서 확장 데이터의 적절한 권한 부여 목록을 사용하여 다음을 검증합니다.
- AuthorizationList.allApplications 필드가 어느 권한 부여 목록(softwareEnforced 또는 teeEnforced)에도 존재하지 않습니다. PublicKeyCredential은 RP ID로 범위가 지정되어야 하기 때문입니다.
- 다음 항목의 경우 RP가 신뢰할 수 있는 실행 환경에서 생성된 키만 허용하려면 teeEnforced 권한 부여 목록만 사용하고, 그렇지 않으면 teeEnforced와 softwareEnforced의 합집합을 사용합니다.
  - AuthorizationList.origin 필드의 값이 KM_ORIGIN_GENERATED와 같습니다.
  - AuthorizationList.purpose 필드의 값이 KM_PURPOSE_SIGN과 같습니다.
성공하면 증명 유형 기본과 증명 신뢰 경로 x5c를 나타내는 구현별 값을 반환합니다.

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

Android 키 증명 증명 인증서의 Android 키 증명 인증서 확장 데이터는 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

지원되는 증명 유형

기본

구문

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로 둡니다.

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

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같습니다.

attStmt가 위에 정의된 구문을 준수하는 유효한 CBOR인지 검증하고 CBOR 디코딩을 수행하여 포함된 필드를 추출합니다.
SafetyNet 온라인 문서에 명시된 단계를 따라 response가 버전 ver의 유효한 SafetyNet 응답인지 검증합니다. 이 문서를 작성하는 현재 SafetyNet 응답 형식은 하나뿐이며 ver는 향후 사용을 위해 예약되어 있습니다.
response 페이로드의 nonce 속성이 authenticatorData와 clientDataHash의 연결 값에 대한 SHA-256 해시의 Base64 인코딩과 동일한지 검증합니다.
SafetyNet 온라인 문서의 단계를 따라 SafetyNet 응답이 실제로 SafetyNet 서비스에서 온 것인지 검증합니다.
성공하면 증명 유형 기본과 증명 신뢰 경로 x5c를 나타내는 구현별 값을 반환합니다.

8.6. FIDO U2F 증명문 형식

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

증명문 형식 식별자

fido-u2f

지원되는 증명 유형

기본, AttCA

구문

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

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

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

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

x5c: X.509 형식의 증명 인증서를 포함하는 단일 요소 배열.
sig: 증명 서명. 서명은 클라이언트가 인증자로부터 받은 (원시) U2F 등록 응답 메시지 [FIDO-U2F-Message-Formats]에 대해 계산되었습니다.

서명 절차

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

[FIDO-U2F-Message-Formats]의 제4.3절에 명시된 등록 응답 메시지를 생성하되, application 매개변수는 주어진 자격 증명이 범위로 지정된 RP ID의 SHA-256 해시로 설정하고, challenge 매개변수는 clientDataHash로, key handle 매개변수는 주어진 자격 증명의 자격 증명 ID로 설정합니다. 이 등록 응답 메시지의 원시 서명 부분(즉, 사용자 공개 키, key handle 및 증명 인증서를 제외한 부분)을 sig로 설정하고 증명 공개 키의 증명 인증서를 x5c로 설정합니다.

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같습니다.

attStmt가 위에 정의된 구문을 준수하는 유효한 CBOR인지 검증하고 CBOR 디코딩을 수행하여 포함된 필드를 추출합니다.
x5c에 정확히 하나의 요소가 있는지 확인하고 그 요소를 attCert로 둡니다. certificate public key를 attCert가 전달하는 공개 키로 둡니다. certificate public key가 P-256 곡선의 타원 곡선(EC) 공개 키가 아니면 이 알고리즘을 종료하고 적절한 오류를 반환합니다.
authenticatorData에서 주장된 rpIdHash를, authenticatorData.attestedCredentialData에서 주장된 credentialId와 credentialPublicKey를 추출합니다.
COSE_KEY 형식의 credentialPublicKey([RFC9052]의 제7절 참조)를 Raw ANSI X9.62 공개 키 형식([FIDO-Registry]의 제3.6.2절 공개 키 표현 형식의 ALG_KEY_ECC_X962_RAW 참조)으로 변환합니다.
- x를 credentialPublicKey에서 "-2" 키(x 좌표를 나타냄)에 대응하는 값으로 두고 크기가 32바이트인지 확인합니다. 크기가 다르거나 "-2" 키를 찾을 수 없으면 이 알고리즘을 종료하고 적절한 오류를 반환합니다.
- y를 credentialPublicKey에서 "-3" 키(y 좌표를 나타냄)에 대응하는 값으로 두고 크기가 32바이트인지 확인합니다. 크기가 다르거나 "-3" 키를 찾을 수 없으면 이 알고리즘을 종료하고 적절한 오류를 반환합니다.
- publicKeyU2F를 0x04 || x || y의 연결 값으로 둡니다.
  
  참고: 이는 압축되지 않은 ECC 키 형식을 나타냅니다.
verificationData를 (0x00 || rpIdHash || clientDataHash || credentialId || publicKeyU2F)의 연결 값으로 둡니다([FIDO-U2F-Message-Formats]의 제4.3절 참조).
제2단계에서 사용한 해시 함수로 SHA-256을 사용하여 [SEC1] 제4.1.4절에 따라 verificationData와 certificate public key를 사용하여 sig를 검증합니다.
선택적으로 x5c를 검사하고 외부에서 제공된 지식을 참조하여 attStmt가 기본 또는 AttCA 증명을 전달하는지 결정합니다.
성공하면 증명 유형 기본, AttCA 또는 불확실성, 그리고 증명 신뢰 경로 x5c를 나타내는 구현별 값을 반환합니다.

8.7. 없음 증명문 형식

없음 증명문 형식은 WebAuthn 신뢰 당사자가 증명 정보를 수신하지 않겠다고 지정할 때 인증자가 제공한 모든 증명문을 대체하는 데 사용됩니다. § 5.4.7 증명 전달 기본 설정 열거형 (열거형 AttestationConveyancePreference)을 참조하십시오.

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

증명문 형식 식별자

none

지원되는 증명 유형

없음

구문

없음 증명문의 구문은 다음과 같이 정의됩니다.

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

emptyMap = {}

서명 절차

위에 정의된 고정 증명문을 반환합니다.

검증 절차

증명 유형 없음과 비어 있는 증명 신뢰 경로를 나타내는 구현별 값을 반환합니다.

8.8. Apple 익명 증명문 형식

이 증명문 형식은 WebAuthn을 지원하는 특정 유형의 Apple 기기에서 Apple만 사용합니다.

증명문 형식 식별자

apple

지원되는 증명 유형

익명화 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와 같은지 검증합니다.
성공하면 증명 유형 익명화 CA와 증명 신뢰 경로 x5c를 나타내는 구현별 값을 반환합니다.

8.9. 복합 증명문 형식

"compound" 증명문 형식은 하나의 절차에서 여러 개의 독립적인 증명문을 전달하는 데 사용됩니다.

증명문 형식 식별자

compound

지원되는 증명 유형

모두. § 6.5.3 증명 유형을 참조하십시오.

구문

복합 증명문의 구문은 다음과 같이 정의됩니다.

$$attStmtType //= (
                      fmt: "compound",
                      attStmt: [2* nonCompoundAttStmt]
                  )

nonCompoundAttStmt = { $$attStmtType } .within { fmt: text .ne "compound", * any => any }

서명 절차

해당 없음

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같습니다.

attStmt의 각 subStmt에 대해 반복하여, 증명문 형식 식별자 subStmt.fmt에 대응하는 검증 절차를 검증 절차 입력 subStmt, authenticatorData 및 clientDataHash와 함께 평가합니다.

하나 이상의 subStmt 검증이 실패하면 신뢰 당사자 정책에 따라 적절한 결과를 결정합니다.
신뢰 당사자 정책에서 정한 충분한 수의 attStmt 항목이 성공적으로 검증되면 성공한 검증 절차의 출력 조합을 나타내는 구현별 값을 반환합니다.

9. WebAuthn 확장

§ 5 웹 인증 API에 정의된 공개 키 자격 증명을 생성하고 인증 어설션을 요청하고 생성하는 메커니즘은 특정 사용 사례에 맞게 확장할 수 있습니다. 각 사례는 등록 확장 및/또는 인증 확장을 정의하여 처리합니다.

모든 확장은 클라이언트 확장이며, 이는 확장이 클라이언트와의 통신 및 클라이언트의 처리를 수반한다는 의미입니다. 클라이언트 확장은 다음 단계와 데이터를 정의합니다.

등록 확장을 위한 navigator.credentials.create() 확장 요청 매개변수 및 응답 값.
인증 확장을 위한 navigator.credentials.get() 확장 요청 매개변수 및 응답 값.
등록 확장과 인증 확장을 위한 클라이언트 확장 처리.

공개 키 자격 증명을 생성하거나 인증 어설션을 요청할 때 WebAuthn 신뢰 당사자는 확장 집합의 사용을 요청할 수 있습니다. 이러한 확장은 클라이언트 및/또는 WebAuthn 인증자가 지원하는 경우 요청된 작업 중에 호출됩니다. 신뢰 당사자는 각 확장에 대한 클라이언트 확장 입력을 get() 호출 (인증 확장의 경우) 또는 create() 호출(등록 확장의 경우)에서 클라이언트로 전송합니다. 클라이언트는 클라이언트 확장 처리를 클라이언트 플랫폼이 지원하는 각 확장에 대해 수행하고, 각 확장에서 지정한 대로 확장 식별자와 클라이언트 확장 출력 값을 포함하여 클라이언트 데이터를 보강합니다.

확장은 인증자 확장일 수도 있으며, 이는 확장이 인증자와의 통신 및 인증자의 처리를 수반한다는 의미입니다. 인증자 확장은 다음 단계와 데이터를 정의합니다.

등록 확장을 위한 authenticatorMakeCredential 확장 요청 매개변수 및 응답 값.
인증 확장을 위한 authenticatorGetAssertion 확장 요청 매개변수 및 응답 값.
등록 확장과 인증 확장을 위한 인증자 확장 처리.

인증자 확장의 경우 클라이언트 확장 처리의 일부로 클라이언트는 각 확장에 대한 CBOR 인증자 확장 입력 값도 생성하며 (종종 해당 클라이언트 확장 입력 값을 기반으로 함), 이를 create() 호출(등록 확장의 경우) 또는 get() 호출(인증 확장의 경우)에서 인증자에 전달합니다. 이러한 인증자 확장 입력 값은 CBOR로 표현되고 이름-값 쌍으로 전달되며, 확장 식별자가 이름이고 해당 인증자 확장 입력이 값입니다. 인증자는 다시 자신이 지원하는 확장에 대해 추가 처리를 수행하고 확장에서 지정한 대로 각각에 대한 CBOR 인증자 확장 출력을 반환합니다. 인증자 확장 출력은 서명된 인증자 데이터의 일부로 반환되므로 인증자 확장은 출력 자체가 인증자 데이터에 의존하는 경우 등을 위해 서명되지 않은 확장 출력을 지정할 수도 있습니다. 인증자 확장을 위한 클라이언트 확장 처리의 일부는 인증자 확장 출력과 서명되지 않은 확장 출력을 클라이언트 확장 출력을 생성하는 입력으로 사용하는 것입니다.

모든 WebAuthn 확장은 클라이언트와 인증자 모두에게 선택 사항입니다. 따라서 신뢰 당사자가 요청한 모든 확장은 클라이언트 브라우저나 OS에서 무시되어 인증자에 전혀 전달되지 않을 수도 있고 인증자가 무시할 수도 있습니다. 확장을 무시하는 것은 WebAuthn API 처리에서 실패로 간주되지 않으므로 신뢰 당사자가 API 호출에 확장을 포함할 때는 이러한 확장의 일부 또는 전부가 무시되는 경우를 처리할 준비가 되어 있어야 합니다.

모든 WebAuthn 확장은 클라이언트 또는 인증자가 이를 지원하지 않더라도 사용자의 보안이나 개인정보 보호가 위험해지지 않는 방식으로 정의되어야 합니다. 예를 들어 확장에 클라이언트 처리가 필요하다면 JSON에서 CBOR로 클라이언트 확장 입력을 단순히 변환하는 순진한 패스스루가 의미상 유효하지 않은 인증자 확장 입력 값을 생성하도록 보장하여 인증자가 해당 확장을 무시하게 만드는 방식으로 정의할 수 있습니다. 모든 확장은 선택 사항이므로 이는 API 작업에서 기능적 실패를 일으키지 않습니다.

[RFC8809]에서 설정한 IANA "WebAuthn 확장 식별자" 레지스트리 [IANA-WebAuthn-Registries]에서 등록된 WebAuthn 확장의 최신 목록을 확인할 수 있습니다.

9.1. 확장 식별자

확장은 확장 작성자가 선택한 문자열인 확장 식별자로 식별됩니다.

확장 식별자는 [RFC8809]에서 설정한 IANA "WebAuthn 확장 식별자" 레지스트리 [IANA-WebAuthn-Registries]에 등록하는 것이 좋습니다. 등록된 모든 확장 식별자는 당연히 서로 고유합니다.

등록되지 않은 확장 식별자는 예를 들어 myCompany_extension처럼 정의 주체를 포함하여 전역적으로 고유하도록 해야 합니다.

모든 확장 식별자는 최대 32옥텟 길이여야 하며 백슬래시와 큰따옴표를 제외한 인쇄 가능한 USASCII 문자로만 구성되어야 합니다. 즉, [RFC5234]에 정의된 VCHAR에서 %x22와 %x5c를 제외한 문자입니다. 구현은 WebAuthn 확장 식별자를 대소문자를 구분하여 일치시켜야 합니다.

여러 버전이 존재할 수 있는 확장은 식별자에 버전을 포함하도록 주의해야 합니다. 결과적으로 서로 다른 버전은 서로 다른 확장으로 취급됩니다. 예: myCompany_extension_01

§ 10 정의된 확장에서는 추가 확장 집합과 해당 식별자를 정의합니다. 등록된 WebAuthn 확장 식별자의 최신 목록은 [RFC8809]에서 설정한 IANA "WebAuthn 확장 식별자" 레지스트리 [IANA-WebAuthn-Registries]를 참조하십시오.

9.2. 확장 정의

확장 정의는 확장 식별자, get() 또는 create() 호출을 통해 전송할 클라이언트 확장 입력 인수, 클라이언트 확장 처리 규칙 및 클라이언트 확장 출력 값을 지정해야 합니다. 확장이 인증자와 통신하는 경우(즉, 인증자 확장인 경우) authenticatorGetAssertion 또는 authenticatorMakeCredential 호출을 통해 전송되는 CBOR 인증자 확장 입력 인수, 인증자 확장 처리 규칙 및 CBOR 인증자 확장 출력 값도 지정해야 합니다. 확장은 서명되지 않은 확장 출력을 지정할 수 있습니다.

클라이언트가 처리하는 모든 클라이언트 확장은 WebAuthn 신뢰 당사자가 해당 확장이 클라이언트에서 처리되었음을 알 수 있도록 클라이언트 확장 출력 값을 반환해야 합니다. 마찬가지로 인증자 처리가 필요한 모든 확장은 신뢰 당사자가 해당 확장이 인증자에서 처리되었음을 알 수 있도록 인증자 확장 출력을 반환해야 합니다. 확장이 그 외의 결과 값을 필요로 하지 않는다면 JSON Boolean 클라이언트 확장 출력 결과를 반환하도록 정의하고, 확장이 이해되고 처리되었음을 나타내기 위해 true로 설정하는 것이 좋습니다. 마찬가지로 그 외의 결과 값을 필요로 하지 않는 인증자 확장은 값을 반환해야 하며 CBOR Boolean 인증자 확장 출력 결과를 반환하고, 확장이 이해되고 처리되었음을 나타내기 위해 true로 설정하는 것이 좋습니다.

9.3. 요청 매개변수 확장

확장은 하나 또는 두 개의 요청 인수를 정의합니다. JSON으로 인코딩할 수 있는 값인 클라이언트 확장 입력은 get() 또는 create() 호출에서 WebAuthn 신뢰 당사자로부터 클라이언트로 전달되며, CBOR 인증자 확장 입력은 이러한 호출 처리 중 인증자 확장을 위해 클라이언트에서 인증자로 전달됩니다.

신뢰 당사자는 extensions 옵션에 항목을 포함하여 확장 사용을 요청하는 동시에 해당 클라이언트 확장 입력을 설정하고 이를 create() 또는 get() 호출에 전달합니다. 항목의 키는 확장 식별자이고 값은 클라이언트 확장 입력입니다.

참고: 다른 문서에서는 확장 입력이 항상 확장 식별자를 항목 키로 사용하지 않는 확장을 지정하기도 했습니다. 위 규칙은 새 확장에도 계속 적용됩니다.

var assertionPromise = navigator.credentials.get({
    publicKey: {
        // 간결성을 위해 다른 멤버는 생략합니다
        extensions: {
            // "webauthnExample_foobar" 확장을 식별하는 "항목 키",
            // 그 값은 두 개의 입력 매개변수를 가진 맵입니다:
            "webauthnExample_foobar": {
              foo: 42,
              bar: "barfoo"
            }
        }
    }
});

확장 정의는 해당 클라이언트 확장 입력의 유효한 값을 지정해야 합니다. 클라이언트는 유효하지 않은 클라이언트 확장 입력을 가진 확장을 무시해야 합니다. 확장이 신뢰 당사자로부터 어떤 매개변수도 필요로 하지 않는다면, 신뢰 당사자가 확장을 요청했음을 나타내기 위해 true로 설정되는 Boolean 클라이언트 인수를 받도록 정의하는 것이 좋습니다.

클라이언트 처리에만 영향을 미치는 확장은 인증자 확장 입력을 지정할 필요가 없습니다. 인증자 처리가 있는 확장은 클라이언트 확장 입력에서 인증자 확장 입력을 계산하는 방법을 지정해야 하며, 확장 식별자를 항목 키로 사용하여 $$extensionInput 및 $$extensionOutput 그룹 소켓에 추가 선택지를 정의함으로써 CDDL 유형 AuthenticationExtensionsAuthenticatorInputs 및 AuthenticationExtensionsAuthenticatorOutputs 에 대한 확장을 정의해야 합니다. 입력 매개변수가 필요하지 않아 true로 설정된 Boolean 클라이언트 확장 입력 값을 받도록 정의된 확장은 인증자 확장 입력도 상수 Boolean 값 true(CBOR 메이저 유형 7, 값 21)로 정의하는 것이 좋습니다.

다음 예는 식별자 webauthnExample_foobar를 가진 확장이 부호 없는 정수를 인증자 확장 입력으로 받고 최소 하나의 바이트 문자열로 이루어진 배열을 인증자 확장 출력으로 반환하도록 정의합니다.

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

일부 인증자는 Bluetooth Low-Energy 또는 NFC와 같은 저대역폭 링크로 통신하므로 확장은 가능한 한 작은 인증자 인수를 정의하도록 해야 합니다.

9.4. 클라이언트 확장 처리

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

마찬가지로 클라이언트 확장 출력은 getClientExtensionResults()의 결과에서 확장 식별자를 키로 하고 각 확장의 클라이언트 확장 출력 값을 값으로 하는 딕셔너리로 표현됩니다. 클라이언트 확장 입력과 마찬가지로 클라이언트 확장 출력은 JSON으로 인코딩할 수 있는 값입니다. 무시된 확장에 대해서는 어떤 값도 반환해서는 안 됩니다.

인증자 처리가 필요한 확장은 클라이언트 확장 입력을 사용하여 CBOR 인증자 확장 입력을 결정하는 절차와 CBOR 인증자 확장 출력 및 사용되는 경우 서명되지 않은 확장 출력을 사용하여 클라이언트 확장 출력을 결정하는 절차를 정의해야 합니다.

9.5. 인증자 확장 처리

처리되는 각 인증자 확장의 CBOR 인증자 확장 입력 값은 authenticatorMakeCredential 및 authenticatorGetAssertion 작업의 extensions 매개변수에 포함됩니다. extensions 매개변수는 각 키가 확장 식별자이고 해당 값이 그 확장의 인증자 확장 입력인 CBOR 맵입니다.

마찬가지로 확장 출력은 인증자 데이터의 extensions 부분에 표현됩니다. 인증자 데이터의 extensions 부분은 각 키가 확장 식별자이고 해당 값이 그 확장의 인증자 확장 출력인 CBOR 맵입니다.

서명되지 않은 확장 출력은 인증자 데이터와 별도로 표현되고 인증자가 동일한 확장 식별자를 키로 하는 별도 맵으로 반환합니다. 이 맵에는 서명되지 않은 출력을 사용하는 인증자 확장에 대한 항목만 포함됩니다. 서명되지 않은 출력은 확장이 인증자 데이터에 대한 서명을 출력하는 경우(그렇지 않으면 서명이 자기 자신에 서명해야 하므로 불가능함) 또는 일부 확장 출력을 신뢰 당사자에게 보내지 않아야 하는 경우 유용합니다.

참고: [FIDO-CTAP]에서 서명되지 않은 확장 출력은 authenticatorMakeCredential과 authenticatorGetAssertion 모두에서 unsignedExtensionOutputs라는 최상위 필드에 CBOR 맵으로 반환됩니다.

지원되는 각 확장에 대해 해당 확장의 인증자 확장 처리 규칙을 사용하여 인증자 확장 입력 및 가능하면 다른 입력으로부터 인증자 확장 출력과 사용되는 경우 서명되지 않은 확장 출력을 생성합니다. 무시된 확장에 대해서는 어떤 값도 반환해서는 안 됩니다.

10. 정의된 확장

이 절과 그 하위 절에서는 [RFC8809]에서 설정한 IANA "WebAuthn 확장 식별자" 레지스트리 [IANA-WebAuthn-Registries]에 등록할 추가 확장 집합을 정의합니다. 광범위한 상호 운용성을 목표로 하는 사용자 에이전트는 이를 구현할 수 있습니다.

10.1. 클라이언트 확장

이 절에서는 클라이언트 확장에만 해당하는 확장을 정의합니다.

10.1.1. FIDO AppID 확장 (appid)

이 확장을 사용하면 기존 FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI]를 사용해 이전에 자격 증명을 등록한 WebAuthn 신뢰 당사자가 어설션을 요청할 수 있습니다. FIDO API는 신뢰 당사자를 위한 대체 식별자인 AppID [FIDO-APPID]를 사용하며, 이러한 API를 사용하여 생성된 모든 자격 증명은 해당 식별자로 범위가 지정됩니다. 이 확장이 없으면 RP ID로 범위를 지정하기 위해 다시 등록해야 합니다.

appid 확장 입력을 설정하는 것 외에도, 이 확장을 사용하려면 사용자가 등록된 U2F 자격 증명을 사용하여 인증할 수 있도록 신뢰 당사자가 몇 가지 추가 처리를 수행해야 합니다.

get() 메서드의 allowCredentials 옵션에 원하는 U2F 자격 증명을 나열합니다.
- type 멤버를 public-key로 설정합니다.
- id 멤버를 원하는 자격 증명의 각 U2F 키 핸들로 설정합니다. U2F 키 핸들은 일반적으로 base64url 인코딩을 사용하지만 id에서 사용할 때는 바이너리 형식으로 디코딩해야 합니다.
allowCredentials에는 WebAuthn 자격 증명 ID와 U2F 키 핸들이 혼합되어 포함될 수 있으며, 이 확장을 통해 appid를 지정해도 사용자가 rpId에 지정된 RP ID로 범위가 지정된 WebAuthn 등록 자격 증명을 사용하는 것을 막지 않습니다.
어설션을 검증할 때 rpIdHash가 RP ID 대신 AppID의 해시일 수도 있음을 예상합니다.

이 확장은 FIDO 호환 자격 증명을 생성할 수 있게 하지 않습니다. 따라서 WebAuthn으로 생성된 자격 증명은 FIDO JavaScript API와 하위 호환되지 않습니다.

참고: appid는 신뢰 당사자가 기존 FIDO API에서 이전에 사용한 AppID로 설정해야 합니다. 이는 신뢰 당사자의 WebAuthn RP ID를 AppID 형식으로 변환한 결과와 같지 않을 수 있습니다. 예를 들어 이전에 사용한 AppID가 "https://accounts.example.com"이었지만 현재 사용하는 RP ID는 "example.com"일 수 있습니다.

확장 식별자

appid

작업 적용 범위

인증

클라이언트 확장 입력

FIDO AppID를 지정하는 단일 DOMString.

partial dictionary AuthenticationExtensionsClientInputs {
  DOMString appid;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
  DOMString appid;
};

클라이언트 확장 처리

호출자의 오리진을 호출 애플리케이션의 FacetID를 결정하는 FIDO 알고리즘에 전달한 결과를 facetId로 둡니다.
appId를 확장 입력으로 둡니다.
facetId와 appId를 호출자의 FacetID가 AppID에 대해 승인되었는지 결정하는 FIDO 알고리즘에 전달합니다. 해당 알고리즘이 appId를 거부하면 "SecurityError" DOMException을 반환합니다.
allowCredentialDescriptorList를 구성할 때, U2F 인증자가 자격 증명을 적용할 수 없다고 나타내는 경우(즉, SW_WRONG_DATA를 반환하는 경우) 클라이언트는 U2F 애플리케이션 매개변수를 appId의 SHA-256 해시로 설정하여 다시 시도해야 합니다. 이 결과 적용 가능한 자격 증명이 있으면 클라이언트는 해당 자격 증명을 allowCredentialDescriptorList에 포함해야 합니다. 그러면 appId의 값이 authenticatorGetAssertion의 rpId 매개변수를 대체합니다.
output을 Boolean 값 false로 둡니다.
assertionCreationData를 생성할 때, 어설션이 RP ID의 SHA-256 해시 대신 appId의 SHA-256 해시로 설정된 U2F 애플리케이션 매개변수를 사용하는 U2F 인증자에 의해 생성되었다면 output을 true로 설정합니다.

참고: 실제로 여러 구현은 호출자의 FacetID가 AppID에 대해 승인되었는지 결정하는 알고리즘의 4단계 이후를 구현하지 않습니다. 대신 3단계에서 호스트 비교를 완화하여 동일 사이트의 호스트를 허용합니다.

클라이언트 확장 출력

output의 값을 반환합니다. true이면 AppID가 사용되었으므로 어설션을 검증할 때 신뢰 당사자는 rpIdHash가 RP ID가 아니라 AppID의 해시일 것으로 예상해야 합니다.

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appid;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
  boolean appid;
};

인증자 확장 입력

없음.

인증자 확장 처리

없음.

인증자 확장 출력

없음.

10.1.2. FIDO AppID 제외 확장 (appidExclude)

이 등록 확장을 사용하면 WebAuthn 신뢰 당사자가 기존 FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI]로 생성된 지정 자격 증명을 포함하는 인증자를 제외할 수 있습니다.

FIDO U2F JavaScript API에서 전환하는 동안 신뢰 당사자는 기존 자격 증명이 이미 등록된 사용자 집단을 보유할 수 있습니다. appid 확장을 사용하면 로그인 흐름을 원활하게 전환할 수 있지만, 등록 흐름을 전환할 때는 excludeCredentials 필드의 내용이 WebAuthn 자격 증명으로 간주되므로 기존 자격 증명이 있는 인증자를 제외하는 데 효과적이지 않습니다. 이 확장은 클라이언트 플랫폼이 excludeCredentials의 내용을 WebAuthn 및 기존 FIDO 자격 증명 모두로 고려하도록 지시합니다. U2F 키 핸들은 일반적으로 base64url 인코딩을 사용하지만 excludeCredentials에서 사용할 때는 바이너리 형식으로 디코딩해야 한다는 점에 유의하십시오.

확장 식별자

appidExclude

작업 적용 범위

등록

클라이언트 확장 입력

FIDO AppID를 지정하는 단일 DOMString.

partial dictionary AuthenticationExtensionsClientInputs {
  DOMString appidExclude;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
  DOMString appidExclude;
};

클라이언트 확장 처리

새 자격 증명을 생성할 때:

RP ID를 설정한 직후 다음 단계를 수행합니다.
1. 호출자의 오리진을 FIDO 알고리즘 호출 애플리케이션의 FacetID 결정에 전달한 결과를 facetId로 둡니다.
2. appId를 확장 입력 appidExclude의 값으로 둡니다.
3. facetId와 appId를 FIDO 알고리즘 호출자의 FacetID가 AppID에 대해 승인되었는지 결정에 전달합니다. 후자의 알고리즘이 appId를 거부하면 "SecurityError" DOMException을 반환하고 새 자격 증명 생성 알고리즘과 이 단계들을 종료합니다.
  
  참고: 실제로 여러 구현은 호출자의 FacetID가 AppID에 대해 승인되었는지 결정하는 알고리즘의 4단계 이후를 구현하지 않습니다. 대신 3단계에서 호스트 비교를 완화하여 동일 사이트의 호스트를 허용합니다.
4. 그렇지 않으면 정상 처리를 계속합니다.
authenticatorMakeCredential을 호출하기 직전에 다음 단계를 수행합니다.
1. authenticator가 U2F 프로토콜 [FIDO-U2F-Message-Formats]을 지원하면 excludeCredentialDescriptorList의 각 자격 증명 설명자 C에 대해 반복합니다.
  1. 다음 값으로 "다섯 부분"을 설정한 U2F_AUTHENTICATE 메시지를 authenticator에 보내 C가 authenticator에서 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 형태일 수도 있고, authenticator에서 사용자 동의를 요청하고 이를 받으면 인증자가 InvalidStateError를 반환한 것처럼 처리할 수도 있습니다. 사용자 동의 요청은 위와 동일하게 authenticator에 다른 U2F_AUTHENTICATE 메시지를 보내되 control byte를 0x03 ("enforce-user-presence-and-sign")으로 설정하고 응답을 무시하여 수행할 수 있습니다.
2. 정상 처리를 계속합니다.

클라이언트 확장 출력

확장이 처리되었음을 신뢰 당사자에게 나타내기 위해 true 값을 반환합니다.

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appidExclude;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
  boolean appidExclude;
};

인증자 확장 입력

없음.

인증자 확장 처리

없음.

인증자 확장 출력

없음.

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

이 클라이언트 등록 확장은 등록 절차의 결과로 공개 키 자격 증명 소스를 생성할 때 클라이언트가 알고 있는 특정 자격 증명 속성을 요청한 WebAuthn 신뢰 당사자에게 보고하기 쉽게 합니다.

현재 하나의 자격 증명 속성이 정의되어 있습니다. 바로 클라이언트 측에서 검색 가능한 자격 증명 속성입니다.

확장 식별자

credProps

작업 적용 범위

등록

클라이언트 확장 입력

이 확장을 신뢰 당사자가 요청했음을 나타내는 Boolean 값 true.

partial dictionary AuthenticationExtensionsClientInputs {
    boolean credProps;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
    boolean credProps;
};

클라이언트 확장 처리

rk를 authenticatorMakeCredential 작업의 호출에서 사용된 requireResidentKey 매개변수의 값으로 설정합니다.

클라이언트 확장 출력

clientExtensionResults["credProps"]["rk"]를 설정하여 authenticatorMakeCredential 작업의 호출에서 사용된 requireResidentKey 매개변수의 값으로 설정합니다.

dictionary CredentialPropertiesOutput {
    boolean rk;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    CredentialPropertiesOutput credProps;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
    CredentialPropertiesOutput credProps;
};

rk, 유형은 boolean

추상적으로 클라이언트 측에서 검색 가능한 자격 증명 속성 또는 상주 키 자격 증명 속성이라고 하는 이 선택적 속성은 등록 절차의 결과로 반환된 PublicKeyCredential이 클라이언트 측에서 검색 가능한 자격 증명인지 나타내는 Boolean 값입니다. rk가 true이면 자격 증명은 검색 가능한 자격 증명입니다. rk가 false이면 자격 증명은 서버 측 자격 증명입니다. rk가 존재하지 않으면 자격 증명이 검색 가능한 자격 증명인지 서버 측 자격 증명인지 알 수 없습니다.

참고: 일부 인증자는 클라이언트 플랫폼에서 요청하지 않아도 검색 가능한 자격 증명을 생성합니다. 이 때문에 클라이언트 플랫폼은 rk를 false로 설정할 수 있다는 확신이 없으므로 해당 속성을 생략해야 할 수 있습니다. 신뢰 당사자는 credProps 확장이 지원된다면 클라이언트 플랫폼이 rk 속성을 채우기 위해 노력할 것으로 가정해야 합니다. 따라서 rk가 없으면 생성된 자격 증명은 검색 불가능한 자격 증명일 가능성이 가장 높음을 나타냅니다.

인증자 확장 입력

없음.

인증자 확장 처리

없음.

인증자 확장 출력

없음.

10.1.4. 의사 난수 함수 확장 (prf)

이 클라이언트 등록 확장 및 인증 확장을 사용하면 신뢰 당사자가 자격 증명과 연결된 의사 난수 함수(PRF)의 출력을 평가할 수 있습니다. 이 확장에서 제공하는 PRF는 임의 길이의 BufferSource를 32바이트 BufferSource로 매핑합니다.

동기 부여 예로 PRF 출력은 사용자 데이터를 암호화하는 대칭 키로 사용할 수 있습니다. 이렇게 암호화된 데이터는 연결된 자격 증명에서 어설션을 얻을 수 없다면 접근할 수 없습니다. 아래 규정을 사용하여 하나의 어설션 작업에서 두 입력에 대해 PRF를 평가하면 새 무작위 입력을 선택하고 새 출력으로 다시 암호화함으로써 어설션 중에 암호화 키를 주기적으로 교체할 수 있습니다. 평가 입력을 예측할 수 없다면 사용자 검증을 충족할 수 있고 인증자에 제한된 시간 동안 접근할 수 있는 공격자조차 올바른 PRF 입력도 알고 있지 않다면 암호화 키를 알아낼 수 없습니다.

이 확장은 [FIDO-CTAP] hmac-secret 확장을 기반으로 모델링되었지만 다른 수단으로도 구현할 수 있습니다. hmac-secret은 사용자 에이전트만 수행할 수 있는 방식으로 입력과 출력을 암호화해야 하고 WebAuthn 사용과 기반 플랫폼의 다른 사용 사이를 분리해야 하므로 별도의 클라이언트 확장입니다. 이 분리는 임의 입력에 대한 PRF 평가를 방지하기 위해 제공된 PRF 입력을 컨텍스트 문자열과 함께 해시하여 이루어집니다.

hmac-secret 확장은 자격 증명당 두 개의 PRF를 제공합니다. 하나는 사용자 검증이 수행되는 요청에 사용되고 다른 하나는 그 외의 모든 요청에 사용됩니다. 이 확장은 자격 증명당 하나의 PRF만 노출하며 hmac-secret 위에서 구현할 때 해당 PRF는 사용자 검증이 수행될 때 사용하는 PRF여야 합니다. 필요한 경우 이는 UserVerificationRequirement를 재정의합니다.

이 확장은 [FIDO-CTAP]을 사용하지 않는 인증자에도 구현할 수 있습니다. 이를 위한 클라이언트와 인증자 사이의 인터페이스 및 인증자의 PRF 구성은 추상적으로만 지정됩니다.

참고: hmac-secret 위에 구현하면 다른 경우에는 존재하지 않는 인증자 확장 출력이 생성됩니다. 이러한 출력은 암호화되어 신뢰 당사자가 사용할 수 없지만 인증자 데이터가 서명되므로 클라이언트가 삭제할 수도 없습니다.

확장 식별자

prf

작업 적용 범위

등록 및 인증

클라이언트 확장 입력

dictionary AuthenticationExtensionsPRFValues {
    required BufferSource first;
    BufferSource second;
};
dictionary AuthenticationExtensionsPRFValuesJSON {
    required Base64URLString first;
    Base64URLString second;
};

dictionary AuthenticationExtensionsPRFInputs {
    AuthenticationExtensionsPRFValues eval;
    record<DOMString, AuthenticationExtensionsPRFValues> evalByCredential;
};
dictionary AuthenticationExtensionsPRFInputsJSON {
    AuthenticationExtensionsPRFValuesJSON eval;
    record<DOMString, AuthenticationExtensionsPRFValuesJSON> evalByCredential;
};

partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsPRFInputs prf;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
    AuthenticationExtensionsPRFInputsJSON prf;
};

eval, 유형은 AuthenticationExtensionsPRFValues: PRF를 평가할 하나 또는 두 개의 입력입니다. 모든 인증자가 자격 증명 생성 중 PRF 평가를 지원하는 것은 아니므로 출력이 제공될 수도 있고 제공되지 않을 수도 있습니다. 제공되지 않으면 출력을 얻으려면 어설션이 필요합니다.
evalByCredential, 유형은 record<DOMString, AuthenticationExtensionsPRFValues>: base64url로 인코딩된 자격 증명 ID를 해당 자격 증명에 대해 평가할 PRF 입력에 매핑하는 레코드입니다. allowCredentials가 비어 있지 않은 어설션 중에만 적용됩니다.

클라이언트 확장 처리 (등록)

evalByCredential이 존재하면 이름이 “NotSupportedError”인 DOMException을 반환합니다.
eval이 존재하면:
- salt1을 SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || eval.first)의 값으로 둡니다.
- eval.second가 존재하면 salt2를 SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || eval.second)의 값으로 둡니다.
인증자가 CTAP2 hmac-secret 확장 [FIDO-CTAP]을 지원하면:
1. 인증자 확장 입력에서 hmac-secret을 true로 설정합니다.
2. salt1이 정의되어 있고 향후 [FIDO-CTAP] 확장에서 생성 시점의 PRF 평가를 허용한다면 salt1 및 정의된 경우 salt2 값을 사용하여 hmac-secret 입력을 적절히 구성합니다.
3. enabled를 인증자 확장 출력의 hmac-secret 값으로 설정합니다. 존재하지 않으면 enabled를 false로 설정합니다.
4. results를 존재하는 경우 복호화된 PRF 결과로 설정합니다.
인증자가 CTAP2 hmac-secret 확장 [FIDO-CTAP]을 지원하지 않지만 아래에 정의된 추상 인증자 처리와 호환되는 다른 구현을 지원하면:
1. enabled를 true로 설정합니다.
2. salt1이 정의되어 있으면 지정되지 않은 메커니즘을 사용하여 salt1 및 정의된 경우 salt2를 그 순서대로 PRF 입력으로 인증자에 전달합니다.
3. 지정되지 않은 메커니즘을 사용하여 인증자에서 PRF 출력을 수신합니다. 존재하는 경우 평가 결과를 results에 설정합니다.

클라이언트 확장 처리 (인증)

evalByCredential이 비어 있지 않지만 allowCredentials가 비어 있으면 이름이 “NotSupportedError”인 DOMException을 반환합니다.
evalByCredential의 어떤 키라도 빈 문자열이거나 유효한 base64url 인코딩이 아니거나 base64url 디코딩을 수행한 후 allowCredentials의 어떤 요소의 id와도 같지 않으면 이름이 “SyntaxError”인 DOMException을 반환합니다.
prf 확장 출력을 빈 딕셔너리로 초기화합니다.
ev를 null로 두고 적용 가능한 PRF 입력을 찾습니다.
1. evalByCredential이 존재하고 반환될 자격 증명 ID의 base64url 인코딩을 키로 하는 항목을 포함한다면 ev를 해당 항목의 값으로 둡니다.
2. ev가 null이고 eval이 존재하면 ev를 eval의 값으로 둡니다.
ev가 null이 아니면:
1. salt1을 SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || ev.first)의 값으로 둡니다.
2. ev.second가 존재하면 salt2를 SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || ev.second)의 값으로 둡니다.
3. 인증자가 CTAP2 hmac-secret 확장 [FIDO-CTAP]을 지원하면:
  1. 해당 과정에서 salt1 및 설정된 경우 salt2 값을 동일한 이름의 매개변수로 사용하여 인증자에 hmac-secret 확장을 전송합니다.
  2. 확장 결과를 복호화하고 존재하는 경우 PRF 결과를 results에 설정합니다.
4. 인증자가 CTAP2 hmac-secret 확장 [FIDO-CTAP]을 지원하지 않지만 아래에 정의된 추상 인증자 처리와 호환되는 다른 구현을 지원하면:
  1. 지정되지 않은 메커니즘을 사용하여 salt1 및 정의된 경우 salt2를 그 순서대로 PRF 입력으로 인증자에 전달합니다.
  2. 지정되지 않은 메커니즘을 사용하여 인증자에서 PRF 출력을 AuthenticationExtensionsPRFValues 값 results로 수신합니다. results를 results로 설정합니다.

인증자 확장 입력 / 출력

이 확장은 인증자 구현을 추상화하여 [FIDO-CTAP] hmac-secret 확장 또는 클라이언트와 인증자 간 통신을 위한 지정되지 않은 인터페이스를 사용합니다. 따라서 다음 요구사항을 제외하면 입력과 출력을 위한 CBOR 인터페이스를 지정하지 않습니다.

인증자 확장 출력에는 평문 PRF 출력을 포함해서는 안 됩니다.

참고: 이는 인증자 데이터가 서명되므로 PublicKeyCredential을 신뢰 당사자 서버에 보내야 하는 경우 인증자 확장 출력을 생략할 수 없기 때문입니다. 이는 PRF 출력을 사용하여 암호화 키를 파생하는 것처럼 PRF 출력을 클라이언트 측에서만 비공개로 유지해야 하는 사용 사례에 중요합니다.

인증자 확장 처리

[FIDO-CTAP] hmac-secret 확장을 지원하는 인증자는 해당 확장에 정의된 대로 인증자 처리를 구현합니다.

[FIDO-CTAP] hmac-secret 확장을 지원하지 않는 인증자는 대신 다음 추상 절차를 구현할 수 있습니다.

PRF를 현재 자격 증명과 연결된 의사 난수 함수로 두거나 초기화되지 않았다면 연결을 초기화합니다.

PRF를 출력 길이가 정확히 32바이트이며 최소 2²⁵⁶개의 이러한 함수 집합에서 균등하게 무작위로 선택된 의사 난수 함수로 둡니다. PRF 선택은 사용자 검증 상태와 독립적이어야 합니다. 선택된 PRF는 이 확장을 구현하는 것 이외의 목적으로 사용하지 않는 것이 좋습니다. PRF를 현재 자격 증명의 수명 동안 해당 자격 증명과 연결합니다.
지정되지 않은 메커니즘을 사용하여 클라이언트로부터 PRF 입력 salt1 및 선택적으로 salt2를 그 순서대로 수신합니다. 아무것도 수신하지 않으면 salt1과 salt2를 정의되지 않은 것으로 둡니다.
salt1이 정의되어 있으면:
1. results를 주어진 입력에서 PRF를 평가한 결과를 포함하는 AuthenticationExtensionsPRFValues 구조로 둡니다.
  - results.first를 PRF(salt1)로 설정합니다.
  - salt2가 정의되어 있으면 results.second를 PRF(salt2)로 설정합니다.
2. 지정되지 않은 메커니즘을 사용하여 results를 PRF 출력으로 클라이언트에 전달합니다.

클라이언트 확장 출력

dictionary AuthenticationExtensionsPRFOutputs {
    boolean enabled;
    AuthenticationExtensionsPRFValues results;
};
dictionary AuthenticationExtensionsPRFOutputsJSON {
    boolean enabled;
    AuthenticationExtensionsPRFValuesJSON results;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    AuthenticationExtensionsPRFOutputs prf;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
    AuthenticationExtensionsPRFOutputsJSON prf;
};

enabled, 유형은 boolean

생성된 자격 증명에서 PRF를 사용할 수 있는 경우에만 true입니다. 이는 등록 중에만 보고되며 인증의 경우에는 존재하지 않습니다.

results, 유형은 AuthenticationExtensionsPRFValues

eval 또는 evalByCredential에 주어진 입력에 대해 PRF를 평가한 결과입니다. 등록 중에는 출력을 사용할 수 없을 수도 있습니다. eval의 설명을 참조하십시오.

일부 사용 사례에서는 예를 들어 PRF 출력을 클라이언트 측에서만 사용할 암호화 키를 파생하는 데 사용하는 경우 PublicKeyCredential을 원격 서버로 보낼 때 이 results 출력을 생략해야 할 수 있습니다. 예를 들어 § 7 WebAuthn 신뢰 당사자 작업의 절차를 수행하는 경우입니다. 특히 PublicKeyCredential.toJSON()이 반환하는 RegistrationResponseJSON 및 AuthenticationResponseJSON은 존재하는 경우 이 results 출력을 포함한다는 점에 유의하십시오.

10.1.5. 대용량 blob 저장소 확장 (largeBlob)

이 클라이언트 등록 확장 및 인증 확장을 사용하면 신뢰 당사자가 자격 증명과 연결된 불투명 데이터를 저장할 수 있습니다. 인증자는 소량의 데이터만 저장할 수 있고 대부분의 신뢰 당사자는 사용자에 대해 임의 양의 상태를 저장할 수 있는 온라인 서비스이므로 이는 특정 경우에만 유용합니다. 예를 들어 신뢰 당사자는 중앙 집중식 인증 서비스를 운영하는 대신 인증서를 발급하고자 할 수 있습니다.

참고: 신뢰 당사자는 공간이 제한된 기기에 기록할 때 불투명 데이터가 압축될 것으로 가정할 수 있으므로 직접 압축할 필요가 없습니다.

인증서 시스템은 자격 증명의 공개 키에 서명해야 하고 이 공개 키는 생성 후에만 사용할 수 있으므로 이 확장은 등록 컨텍스트에서 blob을 기록하는 기능을 추가하지 않습니다. 그러나 신뢰 당사자는 나중에 인증 확장을 사용하고자 한다면 자격 증명을 생성할 때 등록 확장을 사용하는 것이 좋습니다.

인증서는 일반적인 인증자의 저장 용량에 비해 크기가 크므로 사용자 에이전트는 이 제한된 리소스를 할당하고 악용을 방지하도록 사용자를 가장 잘 안내하기 위해 어떤 표시와 확인이 적절한지 고려해야 합니다.

참고: 상호 운용성을 위해 [FIDO-CTAP]을 사용하는 인증자에 대용량 blob을 저장하는 사용자 에이전트는 해당 명세에 자세히 설명된 자격 증명별 대용량 blob 저장 규정을 사용할 것으로 예상됩니다.

참고: [FIDO-CTAP]을 교차 플랫폼 전송 프로토콜로 사용하는 로밍 인증자는 이 대용량 Blob 확장을 검색 가능한 자격 증명에 대해서만 지원하며, authenticatorSelection.residentKey가 preferred 또는 required로 설정되지 않으면 오류를 반환할 수 있습니다. 그러나 [FIDO-CTAP]을 사용하지 않는 인증자는 반드시 이 확장을 검색 가능한 자격 증명으로 제한하지 않습니다.

확장 식별자

largeBlob

작업 적용 범위

등록 및 인증

클라이언트 확장 입력

partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsLargeBlobInputs largeBlob;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
    AuthenticationExtensionsLargeBlobInputsJSON largeBlob;
};

enum LargeBlobSupport {
  "required",
  "preferred",
};

dictionary AuthenticationExtensionsLargeBlobInputs {
    DOMString support;
    boolean read;
    BufferSource write;
};
dictionary AuthenticationExtensionsLargeBlobInputsJSON {
    DOMString support;
    boolean read;
    Base64URLString write;
};

support, 유형은 DOMString: LargeBlobSupport의 값 중 하나를 취하는 DOMString입니다. (§ 2.1.1 DOMString 유형으로서의 열거형 참조.) 등록 중에만 유효합니다.
read, 유형은 boolean: 신뢰 당사자가 어설션된 자격 증명과 연결되어 이전에 기록된 blob을 가져오고자 함을 나타내는 Boolean입니다. 인증 중에만 유효합니다.
write, 유형은 BufferSource: 신뢰 당사자가 기존 자격 증명과 함께 저장하려는 불투명 바이트 문자열입니다. 인증 중에만 유효합니다.

클라이언트 확장 처리 (등록)

read 또는 write가 존재하면:
1. 이름이 “NotSupportedError”인 DOMException을 반환합니다.
support가 존재하고 값이 required이면:
1. supported를 true로 설정합니다.
  
  참고: 이는 대용량 blob을 저장할 수 있는 인증자를 사용할 수 있게 될 것을 예상한 것입니다. [[Create]](origin, options, sameOriginWithAncestors)의 12단계 확장 처리 중에 발생합니다. 만족스러운 인증자를 사용할 수 없게 되면 AuthenticationExtensionsLargeBlobOutputs는 폐기됩니다.
2. 후보 인증자를 사용할 수 있게 되면 ([[Create]](origin, options, sameOriginWithAncestors)의 22단계) 어떤 options도 평가하기 전에 후보 인증자가 대용량 blob을 저장할 수 없다면 계속합니다(즉, 후보 인증자를 무시합니다).
그렇지 않으면(즉, support가 없거나 값이 preferred이면):
1. 인증자가 선택되고 선택된 인증자가 대용량 blob을 지원하면 supported를 true로 설정하고, 그렇지 않으면 false로 설정합니다.

클라이언트 확장 처리 (인증)

support가 존재하면:
1. 이름이 “NotSupportedError”인 DOMException을 반환합니다.
read와 write가 모두 존재하면:
1. 이름이 “NotSupportedError”인 DOMException을 반환합니다.
read가 존재하고 값이 true이면:
1. 클라이언트 확장 출력 largeBlob을 초기화합니다.
2. 어떤 인증자라도 성공을 나타내면([[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)에서), 어설션된 자격 증명과 연결된 모든 largeBlob 데이터를 읽으려고 시도합니다.
3. 성공하면 blob을 그 결과로 설정합니다.
  
  참고: 읽기에 성공하지 못하면 largeBlob은 AuthenticationExtensionsClientOutputs에 존재하지만 blob 멤버는 존재하지 않습니다.
write가 존재하면:
1. allowCredentials에 정확히 하나의 요소가 포함되지 않으면:
  1. 이름이 “NotSupportedError”인 DOMException을 반환합니다.
2. 어설션 작업이 성공하면 write의 내용을 지정된 자격 증명과 연결하여 인증자에 저장하려고 시도합니다.
3. 성공하면 written을 true로, 그렇지 않으면 false로 설정합니다.

클라이언트 확장 출력

partial dictionary AuthenticationExtensionsClientOutputs {
    AuthenticationExtensionsLargeBlobOutputs largeBlob;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
    AuthenticationExtensionsLargeBlobOutputsJSON largeBlob;
};

dictionary AuthenticationExtensionsLargeBlobOutputs {
    boolean supported;
    ArrayBuffer blob;
    boolean written;
};
dictionary AuthenticationExtensionsLargeBlobOutputsJSON {
    boolean supported;
    Base64URLString blob;
    boolean written;
};

supported, 유형은 boolean: 생성된 자격 증명이 대용량 blob 저장을 지원하는 경우에만 true입니다. 등록 출력에만 존재합니다.
blob, 유형은 ArrayBuffer: rawId로 식별되는 자격 증명과 연결되었던 불투명 바이트 문자열입니다. read가 true였을 때만 유효합니다.
written, 유형은 boolean: write의 내용이 지정된 자격 증명과 연결되어 인증자에 성공적으로 저장되었음을 나타내는 Boolean입니다.

인증자 확장 처리

이 확장은 사용자 에이전트가 대용량 blob을 인증자에 저장하거나 인증자에서 가져오도록 지시합니다. 따라서 신뢰 당사자를 위한 직접적인 인증자 상호 작용을 지정하지 않습니다.

10.1.6. 원격 클라이언트 데이터 JSON 확장 (remoteClientDataJSON)

원격 데스크톱 웹 클라이언트를 사용하면 사용자가 로컬 클라이언트(웹) 애플리케이션에서 원격 호스트의 (네이티브) 데스크톱 환경과 상호 작용할 수 있습니다.

이 등록 확장 및 인증 확장을 사용하면 사용자가 로컬 클라이언트 플랫폼에 연결된 WebAuthn 인증자를 사용하여 브라우저의 웹사이트나 원격 데스크톱 웹 클라이언트의 원격 호스트에서 실행되는 앱에 로그인할 수 있습니다.

이를 통해 웹 기반 원격 데스크톱 웹 클라이언트가 원격 WebAuthn 요청을 로컬에서 실행할 수 있습니다. 여기서 원격 데스크톱 웹 클라이언트는 원격 머신에 있는 RP를 대신하여 WebAuthn 요청을 호출하며 원격 머신의 호출 RP와는 다른 오리진을 가집니다.

이 확장은 사용 전에 오리진별 명시적 권한이 필요한 강력한 기능입니다. 사용자 에이전트는 요청 시점에 사용자에게 이 권한을 묻지 않는 것이 좋습니다. 대신 권한 부여는 기기 관리 정책(예: 관리되는 브라우저 프로필, 관리되는 브라우저 인스턴스 또는 특정 원격 데스크톱 웹 클라이언트 오리진을 열거하는 관리 기기) 또는 WebAuthn 클라이언트 설정에서 사용자의 명시적인 오리진별 동의를 통해 관리됩니다. 이 권한은 오리진별로 구성해야 하며 모든 오리진을 허용하는 기능을 제공해서는 안 됩니다.

권한

이 확장은 모두 "publickey-credentials-remote-client-data-json"이라는 이름으로 식별되는 강력한 기능([Permissions])과 정책 제어 기능([Permissions-Policy])을 정의합니다. 이 정책 제어 기능의 기본 허용 목록은 'none'입니다. 이 기능의 기본 권한 상태는 "denied"이며, 이는 확장을 기본적으로 사용할 수 없고 명시적으로 활성화해야 함을 의미합니다. 추가 측면이 정의되지 않았으므로 권한 설명자 유형은 기본적으로 PermissionDescriptor입니다.

원격 데스크톱 웹 클라이언트는 Permissions API를 통해 사용자 에이전트가 현재 오리진에서 이 확장을 허용하도록 구성되었는지 확인할 수 있습니다.

const status = await navigator.permissions.query({
    name: "publickey-credentials-remote-client-data-json"
});
if (status.state === "granted") {
    // 클라이언트가 remoteClientDataJSON 확장을 허용하도록 구성되었습니다. 원격 데스크톱 흐름을 계속합니다.
}

확장 식별자

remoteClientDataJSON

작업 적용 범위

등록 및 인증

클라이언트 확장 입력

partial dictionary AuthenticationExtensionsClientInputs {
    DOMString remoteClientDataJSON;
};
partial dictionary AuthenticationExtensionsClientInputsJSON {
    DOMString remoteClientDataJSON;
};

클라이언트 확장 처리 (등록)

새 자격 증명을 생성할 때 이 확장은 해당 알고리즘의 레이블 지정 지점에 다음 단계를 삽입합니다.

RP ID 설정을 다음 절차로 대체합니다.
1. "publickey-credentials-remote-client-data-json" 및 현재 설정 객체에 대해 현재 권한 상태 가져오기의 결과가 "granted"가 아니면:
  1. "NotAllowedError" DOMException을 throw합니다.
2. pkOptions.rp.id가 존재하지 않으면
  1. "NotAllowedError" DOMException을 throw합니다.
3. collectedClientData를 remoteClientDataJSON이 주어졌을 때 JSON 문자열을 Infra 값으로 파싱한 결과로 둡니다.
  1. 위 파싱 단계가 실패하면 "EncodingError" DOMException을 throw합니다.
4. remoteOrigin을 collectedClientData의 "origin" 키 값으로 둡니다.
5. pkOptions.rp.id가 remoteOrigin의 등록 가능한 도메인 접미사인지 또는 동일한지 여부를 확인하는 단계를 건너뜁니다.
  
  참고: 이는 로컬 클라이언트가 모든 RP ID 관련 오리진 검사를 원격 클라이언트에 위임한다는 의미입니다.
collectedClientData 구성 단계를 건너뜁니다.
1. collectedClientData는 RP ID를 설정할 때 주어진 remoteClientDataJSON에서 파싱되었습니다.
2. 사용자 에이전트는 collectedClientData의 내용을 추가, 제거 또는 수정해서는 안 됩니다. 그렇게 하면 원격 머신에서 계산한 clientDataJSON이 무효화되어 신뢰 당사자에서 서명이 일치하지 않게 됩니다.
클라이언트 데이터 직렬화 단계에서는 대신 clientDataJSON을 remoteClientDataJSON으로 설정합니다.
1. 사용자 에이전트는 여기서 clientDataJSON을 구성하기 위해 remoteClientDataJSON의 내용을 추가, 제거 또는 수정해서는 안 됩니다. 그렇게 하면 원격 머신에서 계산한 clientDataJSON이 무효화되어 신뢰 당사자에서 서명이 일치하지 않게 됩니다.

클라이언트 확장 처리 (인증)

인증 어설션을 생성할 때 이 확장은 해당 알고리즘의 레이블 지정 지점에 다음 단계를 삽입합니다.

RP ID 설정을 다음 절차로 대체합니다.
1. "publickey-credentials-remote-client-data-json" 및 현재 설정 객체에 대해 현재 권한 상태 가져오기의 결과가 "granted"가 아니면:
  1. "NotAllowedError" DOMException을 throw합니다.
2. pkOptions.rp.id가 존재하지 않으면
  1. "NotAllowedError" DOMException을 throw합니다.
3. collectedClientData를 remoteClientDataJSON이 주어졌을 때 JSON 문자열을 Infra 값으로 파싱한 결과로 둡니다.
  1. 위 파싱 단계가 실패하면 "EncodingError" DOMException을 throw합니다.
4. remoteOrigin을 collectedClientData의 "origin" 키 값으로 둡니다.
5. pkOptions.rp.id가 remoteOrigin의 등록 가능한 도메인 접미사인지 또는 동일한지 여부를 확인하는 단계를 건너뜁니다.
  
  참고: 이는 로컬 클라이언트가 모든 RP ID 관련 오리진 검사를 원격 클라이언트에 위임한다는 의미입니다.
collectedClientData 구성 단계를 건너뜁니다.
1. collectedClientData는 RP ID를 설정할 때 주어진 remoteClientDataJSON에서 파싱되었습니다.
2. 사용자 에이전트는 collectedClientData의 내용을 추가, 제거 또는 수정해서는 안 됩니다. 그렇게 하면 원격 머신에서 계산한 clientDataJSON이 무효화되어 신뢰 당사자에서 서명이 일치하지 않게 됩니다.
클라이언트 데이터 직렬화 단계에서는 대신 clientDataJSON을 remoteClientDataJSON으로 설정합니다.
1. 사용자 에이전트는 여기서 clientDataJSON을 구성하기 위해 remoteClientDataJSON의 내용을 추가, 제거 또는 수정해서는 안 됩니다. 그렇게 하면 원격 머신에서 계산한 clientDataJSON이 무효화되어 신뢰 당사자에서 서명이 일치하지 않게 됩니다.

인증자 확장 입력

없음

인증자 확장 처리

없음

인증자 확장 출력

없음

클라이언트 확장 출력

확장이 처리되었음을 신뢰 당사자에게 나타내기 위해 true 값을 반환합니다.

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean remoteClientDataJSON;
};
partial dictionary AuthenticationExtensionsClientOutputsJSON {
  boolean remoteClientDataJSON;
};

10.2. 인증자 확장

이 절에서는 클라이언트 확장이면서 인증자 확장이기도 한 확장을 정의합니다.

이 절은 현재 비어 있습니다.

11. 사용자 에이전트 자동화

사용자 에이전트 자동화 및 웹 애플리케이션 테스트를 위해 이 문서에서는 여러 [WebDriver] 확장 명령을 정의합니다.

11.1. WebAuthn WebDriver 확장 기능

아래에 정의된 확장 명령을 사용할 수 있음을 알리기 위해 새 확장 기능이 정의됩니다.

기능	키	값 유형	설명
가상 인증자 지원	`"webauthn:virtualAuthenticators"`	boolean	엔드포인트 노드가 모든 가상 인증자 명령을 지원하는지 나타냅니다.

기능을 검증할 때 "webauthn:virtualAuthenticators"를 value로 검증하는 확장별 하위 단계는 다음과 같습니다.

value가 boolean이 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
그렇지 않으면 deserialized를 value로 설정합니다.

기능을 일치시킬 때 "webauthn:virtualAuthenticators"를 value와 일치시키는 확장별 단계는 다음과 같습니다.

value가 true이고 엔드포인트 노드가 가상 인증자 명령을 하나도 지원하지 않으면 일치에 실패합니다.
그렇지 않으면 일치에 성공합니다.

11.1.1. 인증자 확장 기능

또한 이 명세에 정의된 모든 인증자 확장 (즉, 인증자 확장 처리를 정의하는 확장)에 대해 확장 기능도 정의됩니다.

기능	키	값 유형	설명
의사 난수 함수 확장 지원	`"webauthn:extension:prf"`	boolean	엔드포인트 노드 WebAuthn WebDriver 구현이 prf 확장을 지원하는지 나타냅니다.
대용량 Blob 저장소 확장 지원	`"webauthn:extension:largeBlob"`	boolean	엔드포인트 노드 WebAuthn WebDriver 구현이 largeBlob 확장을 지원하는지 나타냅니다.
credBlob 확장 지원	`"webauthn:extension:credBlob"`	boolean	엔드포인트 노드 WebAuthn WebDriver 구현이 [FIDO-CTAP]에 정의된 `credBlob` 확장을 지원하는지 나타냅니다.

기능을 검증할 때 인증자 확장 기능 key를 value로 검증하는 확장별 하위 단계는 다음과 같습니다.

value가 boolean이 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
그렇지 않으면 deserialized를 value로 설정합니다.

기능을 일치시킬 때 인증자 확장 기능 key를 value와 일치시키는 확장별 단계는 다음과 같습니다.

value가 true이고 엔드포인트 노드 WebAuthn WebDriver 구현이 key로 식별되는 인증자 확장을 지원하지 않으면 일치에 실패합니다.
그렇지 않으면 일치에 성공합니다.

정의된 인증자 확장을 구현하는 사용자 에이전트는 해당 인증자 확장 기능을 구현하는 것이 좋습니다.

11.2. 가상 인증자

이 WebDriver 확장 명령은 인증자 모델의 소프트웨어 구현인 가상 인증자를 생성하고 상호 작용합니다. 가상 인증자는 가상 인증자 데이터베이스에 저장됩니다. 저장된 각 가상 인증자는 다음 속성을 가집니다.

authenticatorId

[RFC3986] 부록 A에 정의된 unreserved 생성식의 문자 중 최대 48자로 만들어진 null이 아닌 문자열로, 가상 인증자를 고유하게 식별합니다.

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 배열에 존재하는 모든 인증자 확장을 지원해야 합니다. 자신의 extensions 배열에 존재하지 않는 어떤 인증자 확장도 지원해서는 안 됩니다.

defaultBackupEligibility

새로 생성되는 모든 공개 키 자격 증명 소스에 대한 백업 적격성 자격 증명 속성의 기본 상태를 결정합니다. 이 값은 이 가상 인증자로 authenticatorMakeCredential 작업을 수행할 때 BE 인증자 데이터 플래그에 반영되어야 합니다.

defaultBackupState

새로 생성되는 모든 공개 키 자격 증명 소스에 대한 백업 상태 자격 증명 속성의 기본 상태를 결정합니다. 이 값은 이 가상 인증자로 authenticatorMakeCredential 작업을 수행할 때 BS 인증자 데이터 플래그에 반영되어야 합니다.

11.3. 가상 인증자 추가

가상 인증자 추가 WebDriver 확장 명령은 소프트웨어 가상 인증자를 생성합니다. 다음과 같이 정의됩니다.

HTTP 메서드	URI 템플릿
POST	`/session/{session id}/webauthn/authenticator`

인증자 구성은 parameters로 원격 끝 단계에 전달되는 JSON 객체입니다. 다음 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`	문자열 배열	확장 식별자를 포함하는 배열	빈 배열
`defaultBackupEligibility`	boolean	`true`, `false`	`false`
`defaultBackupState`	boolean	`true`, `false`	`false`

원격 끝 단계는 다음과 같습니다.

parameters가 JSON 객체가 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.

참고: parameters는 인증자 구성 객체입니다.
authenticator를 새 가상 인증자로 둡니다.
parameters의 열거 가능한 각 자체 속성에 대해:
1. key를 해당 속성의 이름으로 둡니다.
2. value를 parameters에서 key라는 이름의 속성을 가져온 결과로 둡니다.
3. 인증자 구성에 key와 일치하는 key가 없으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
4. value가 해당 key의 유효한 값 중 하나가 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
5. authenticator에서 key 속성을 value로 설정합니다.
기본값이 정의된 인증자 구성의 각 속성에 대해:
1. key가 authenticator에 정의된 속성이 아니면 authenticator에서 key 속성을 default로 설정합니다.
인증자 구성의 각 속성에 대해:
1. key가 authenticator에 정의된 속성이 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
authenticator.extensions의 각 extension에 대해:
1. extension이 엔드포인트 노드 WebAuthn WebDriver 구현이 지원하는 확장 식별자가 아니면 WebDriver 오류를 WebDriver 오류 코드 지원되지 않는 작업과 함께 반환합니다.
유효하고 고유한 authenticatorId를 생성합니다.
authenticator에서 authenticatorId 속성을 authenticatorId로 설정합니다.
authenticator를 가상 인증자 데이터베이스에 저장합니다.
데이터 authenticatorId와 함께 성공을 반환합니다.

11.4. 가상 인증자 제거

가상 인증자 제거 WebDriver 확장 명령은 이전에 생성된 가상 인증자를 제거합니다. 다음과 같이 정의됩니다.

HTTP 메서드	URI 템플릿
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}`

원격 끝 단계는 다음과 같습니다.

authenticatorId가 가상 인증자 데이터베이스에 저장된 어떤 가상 인증자와도 일치하지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
authenticatorId로 식별되는 가상 인증자를 가상 인증자 데이터베이스에서 제거합니다.
성공을 반환합니다.

11.5. 자격 증명 추가

자격 증명 추가 WebDriver 확장 명령은 기존 가상 인증자에 공개 키 자격 증명 소스를 삽입합니다. 다음과 같이 정의됩니다.

HTTP 메서드	URI 템플릿
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credential`

자격 증명 매개변수는 parameters로 원격 끝 단계에 전달되는 JSON 객체입니다. 다음 key와 value 쌍을 포함합니다.

키	설명	값 유형
`credentialId`	Base64url 인코딩을 사용하여 인코딩된 자격 증명 ID.	string
`isResidentCredential`	`true`로 설정하면 클라이언트 측에서 검색 가능한 자격 증명이 생성됩니다. `false`로 설정하면 대신 서버 측 자격 증명이 생성됩니다.	boolean
`rpId`	자격 증명의 신뢰 당사자 ID 범위.	string
`privateKey`	[RFC5958]에 따라 단일 개인 키를 포함하고 Base64url 인코딩을 사용하여 인코딩된 비대칭 키 패키지.	string
`userHandle`	자격 증명과 연결된 userHandle을 Base64url 인코딩을 사용하여 인코딩한 값. 이 속성은 정의되지 않을 수 있습니다.	string
`signCount`	이 속성은 필수입니다. `0` 이상 `4294967295` 이하 범위의 32비트 부호 없는 정수 값이거나 `null`이어야 합니다. `signCount`가 부호 없는 정수 값이면 서명 카운터가 자격 증명과 연결되고 authenticatorGetAssertion 작업 중 증가합니다. `signCount`가 `null`이면 자격 증명과 연결되는 서명 카운터가 없습니다.	number 또는 null
`largeBlob`	자격 증명별 대용량 blob으로, 공개 키 자격 증명 소스와 연결되고 Base64url 인코딩을 사용하여 인코딩됩니다. 이 속성은 정의되지 않을 수 있습니다.	string
`backupEligibility`	공개 키 자격 증명 소스에 대해 시뮬레이션되는 백업 적격성. 설정되지 않으면 값은 가상 인증자의 `defaultBackupEligibility` 속성을 기본값으로 사용합니다. 시뮬레이션되는 백업 적격성은 이 공개 키 자격 증명 소스로 authenticatorGetAssertion 작업을 수행할 때 BE 인증자 데이터 플래그에 반영되어야 합니다.	boolean
`backupState`	공개 키 자격 증명 소스에 대해 시뮬레이션되는 백업 상태. 설정되지 않으면 값은 가상 인증자의 `defaultBackupState` 속성을 기본값으로 사용합니다. 시뮬레이션되는 백업 상태는 이 공개 키 자격 증명 소스로 authenticatorGetAssertion 작업을 수행할 때 BS 인증자 데이터 플래그에 반영되어야 합니다.	boolean
`userName`	자격 증명과 연결된 `user`의 `name`. 설정되지 않으면 값은 빈 문자열을 기본값으로 사용합니다.	string
`userDisplayName`	자격 증명과 연결된 `user`의 `displayName`. 설정되지 않으면 값은 빈 문자열을 기본값으로 사용합니다.	string

원격 끝 단계는 다음과 같습니다.

parameters가 JSON 객체가 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.

참고: parameters는 자격 증명 매개변수 객체입니다.
credentialId를 parameters의 credentialId 속성에 Base64url 인코딩 디코딩을 수행한 결과로 둡니다.
credentialId가 실패이면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
isResidentCredential을 parameters의 isResidentCredential 속성으로 둡니다.
isResidentCredential이 정의되지 않았으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
rpId를 parameters의 rpId 속성으로 둡니다.
rpId가 유효한 RP ID가 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
privateKey를 parameters의 privateKey 속성에 Base64url 인코딩 디코딩을 수행한 결과로 둡니다.
privateKey가 실패이면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
privateKey가 [RFC5958]에 따라 P-256 곡선의 단일 ECDSA 개인 키를 포함하는 올바르게 인코딩된 비대칭 키 패키지가 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
parameters의 userHandle 속성이 정의되어 있으면:
1. userHandle을 parameters의 userHandle 속성에 Base64url 인코딩 디코딩을 수행한 결과로 둡니다.
2. userHandle이 실패이면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
그렇지 않으면:
1. isResidentCredential이 true이면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
2. userHandle을 null로 둡니다.
authenticatorId가 가상 인증자 데이터베이스에 저장된 어떤 가상 인증자와도 일치하지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
authenticator를 authenticatorId와 일치하는 가상 인증자로 둡니다.
isResidentCredential이 true이고 authenticator의 hasResidentKey 속성이 false이면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
authenticator가 largeBlob 확장을 지원하고 parameters의 largeBlob 기능이 정의되어 있으면:
1. largeBlob을 parameters의 largeBlob 속성에 Base64url 인코딩 디코딩을 수행한 결과로 둡니다.
2. largeBlob이 실패이면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
그렇지 않으면:
1. largeBlob을 null로 둡니다.
backupEligibility를 parameters의 backupEligibility 속성으로 둡니다.
backupEligibility이 정의되지 않았으면 backupEligibility을 authenticator의 defaultBackupEligibility 값으로 설정합니다.
backupState를 parameters의 backupState 속성으로 둡니다.
backupState가 정의되지 않았으면 backupState를 authenticator의 defaultBackupState 값으로 설정합니다.
userName을 parameters의 userName 속성으로 둡니다.
userName이 정의되지 않았으면 userName을 빈 문자열로 설정합니다.
userDisplayName을 parameters의 userDisplayName 속성으로 둡니다.
userDisplayName이 정의되지 않았으면 userDisplayName을 빈 문자열로 설정합니다.
credential을 isResidentCredential이 true이면 새 클라이언트 측에서 검색 가능한 공개 키 자격 증명 소스로, 그렇지 않으면 다음 항목을 가진 새 서버 측 공개 키 자격 증명 소스로 둡니다.

type

public-key

id

credentialId

privateKey

privateKey

rpId

rpId

userHandle

userHandle

otherUI

userName과 userDisplayName으로 구성합니다.
credential의 백업 적격성 자격 증명 속성을 backupEligibility로 설정합니다.
credential의 백업 상태 자격 증명 속성을 backupState로 설정합니다.
signCount를 parameters의 signCount 속성으로 둡니다.
signCount가 정의되지 않았으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
signCount가 0 이상 4294967295 이하 범위의 32비트 부호 없는 정수 값으로 설정되어 있으면 시작 값이 signCount와 같은 서명 카운터 counter를 credential과 연결합니다.
그렇지 않고 signCount가 null이면 credential과 서명 카운터를 연결하지 않습니다.
그렇지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
largeBlob이 null이 아니면 credential과 연결된 자격 증명별 대용량 blob을 largeBlob으로 설정합니다.
credential과 counter를 authenticator의 데이터베이스에 저장합니다.
성공을 반환합니다.

11.6. 자격 증명 가져오기

자격 증명 가져오기 WebDriver 확장 명령은 가상 인증자에 저장된 모든 공개 키 자격 증명 소스에 대해 하나의 자격 증명 매개변수 객체를 반환합니다. 이들이 자격 증명 추가를 사용하여 저장되었는지 또는 navigator.credentials.create()을 사용하여 저장되었는지는 관계없습니다. 다음과 같이 정의됩니다.

HTTP 메서드	URI 템플릿
GET	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

원격 끝 단계는 다음과 같습니다.

authenticatorId가 가상 인증자 데이터베이스에 저장된 어떤 가상 인증자와도 일치하지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
credentialsArray를 빈 배열로 둡니다.
authenticatorId로 식별되는 인증자가 관리하는 각 공개 키 자격 증명 소스 credential에 대해 이에 대응하는 자격 증명 매개변수 객체를 구성하고 credentialsArray에 추가합니다.
credentialsArray를 포함하는 데이터와 함께 성공을 반환합니다.

11.7. 자격 증명 제거

자격 증명 제거 WebDriver 확장 명령은 가상 인증자에 저장된 공개 키 자격 증명 소스를 제거합니다. 다음과 같이 정의됩니다.

HTTP 메서드	URI 템플릿
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials/{credentialId}`

원격 끝 단계는 다음과 같습니다.

authenticatorId가 가상 인증자 데이터베이스에 저장된 어떤 가상 인증자와도 일치하지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
authenticator를 authenticatorId로 식별되는 가상 인증자로 둡니다.
credentialId가 authenticator가 관리하는 어떤 공개 키 자격 증명 소스와도 일치하지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
authenticator가 관리하며 credentialId로 식별되는 공개 키 자격 증명 소스를 제거합니다.
성공을 반환합니다.

11.8. 모든 자격 증명 제거

모든 자격 증명 제거 WebDriver 확장 명령은 가상 인증자에 저장된 모든 공개 키 자격 증명 소스를 제거합니다. 다음과 같이 정의됩니다.

HTTP 메서드	URI 템플릿
DELETE	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

원격 끝 단계는 다음과 같습니다.

authenticatorId가 가상 인증자 데이터베이스에 저장된 어떤 가상 인증자와도 일치하지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
authenticatorId로 식별되는 가상 인증자가 관리하는 모든 공개 키 자격 증명 소스를 제거합니다.
성공을 반환합니다.

11.9. 사용자 검증됨 설정

사용자 검증됨 설정 확장 명령은 가상 인증자의 isUserVerified 속성을 설정합니다. 다음과 같이 정의됩니다.

HTTP 메서드	URI 템플릿
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/uv`

사용자 검증됨 설정 매개변수는 parameters로 원격 끝 단계에 전달되는 JSON 객체입니다. 다음 key와 value 쌍을 포함합니다.

키	설명	값 유형
`isUserVerified`	가상 인증자에서 수행되는 사용자 검증의 결과를 결정합니다. `true`로 설정하면 사용자 검증은 항상 성공합니다. `false`로 설정하면 실패합니다.	boolean

원격 끝 단계는 다음과 같습니다.

parameters가 JSON 객체가 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.

참고: parameters는 사용자 검증됨 설정 매개변수 객체입니다.
authenticatorId가 가상 인증자 데이터베이스에 저장된 어떤 가상 인증자와도 일치하지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
isUserVerified가 parameters의 정의된 속성이 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
authenticator를 authenticatorId로 식별되는 가상 인증자로 둡니다.
authenticator의 isUserVerified 속성을 parameters의 isUserVerified 속성으로 설정합니다.
성공을 반환합니다.

11.10. 자격 증명 속성 설정

자격 증명 속성 설정 확장 명령을 사용하면 가상 인증자의 공개 키 자격 증명 소스에 있는 여러 자격 증명 속성을 설정할 수 있습니다. 다음과 같이 정의됩니다.

HTTP 메서드	URI 템플릿
POST	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials/{credentialId}/props`

자격 증명 속성 설정 매개변수는 parameters로 원격 끝 단계에 전달되는 JSON 객체입니다. 다음 key와 value 쌍을 포함합니다.

키	설명	값 유형
`backupEligibility`	백업 적격성 자격 증명 속성.	boolean
`backupState`	백업 상태 자격 증명 속성.	boolean
`signCount`	이 속성은 선택 사항입니다. 정의된 경우 `0` 이상 `4294967295` 이하 범위의 32비트 부호 없는 정수 값이거나 `null`이어야 합니다. `signCount`가 부호 없는 정수 값이면 자격 증명의 서명 카운터가 `signCount`로 업데이트됩니다. `signCount`가 `null`이면 자격 증명과 연결된 기존 서명 카운터가 제거됩니다.	number 또는 null

원격 끝 단계는 다음과 같습니다.

parameters가 JSON 객체가 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.

참고: parameters는 자격 증명 속성 설정 매개변수 객체입니다.
authenticatorId가 가상 인증자 데이터베이스에 저장된 어떤 가상 인증자와도 일치하지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
credential을 credentialId와 일치하며 authenticator가 관리하는 공개 키 자격 증명 소스로 둡니다.
credential이 비어 있으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
backupEligibility를 parameters의 backupEligibility 속성으로 둡니다.
backupEligibility이 정의되어 있으면 credential의 백업 적격성 자격 증명 속성을 backupEligibility 값으로 설정합니다.

참고: 일반적으로 backupEligibility 속성은 공개 키 자격 증명 소스에서 영구적입니다. 자격 증명 속성 설정은 테스트와 디버깅 목적으로 이를 변경할 수 있게 합니다.
backupState를 parameters의 backupState 속성으로 둡니다.
backupState가 정의되어 있으면 credential의 백업 상태 자격 증명 속성을 backupState 값으로 설정합니다.
signCount를 parameters의 signCount 속성으로 둡니다.
signCount가 정의되어 있으면:
1. signCount가 0 이상 4294967295 이하 범위의 32비트 부호 없는 정수 값으로 설정되어 있으면 credential의 기존 서명 카운터를 signCount 값으로 설정합니다. credential에 서명 카운터가 없으면 하나를 credential과 연결하고 signCount 값으로 설정합니다.
2. 그렇지 않고 signCount가 null이면 credential에 설정된 모든 서명 카운터를 제거합니다.
3. 그렇지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환합니다.
성공을 반환합니다.

12. IANA 고려사항

12.1. WebAuthn 증명문 형식 식별자 등록 업데이트

이 절에서는 § 8 정의된 증명문 형식에 정의되고, 원래 [WebAuthn-1]에서 등록된 아래의 증명문 형식을 [RFC8809]에서 설정한 IANA "WebAuthn 증명문 형식 식별자" 레지스트리 [IANA-WebAuthn-Registries]에서 이 명세를 가리키도록 업데이트합니다.

WebAuthn 증명문 형식 식별자: packed
설명: "packed" 증명문 형식은 증명을 위한 WebAuthn 최적화 형식입니다. 매우 간결하면서도 확장 가능한 인코딩 방식을 사용합니다. 이 형식은 제한된 리소스(예: 보안 요소)를 가진 인증자에서 구현할 수 있습니다.
명세 문서: 이 명세의 § 8.2 Packed 증명문 형식
WebAuthn 증명문 형식 식별자: tpm
설명: TPM 증명문 형식은 rawData 및 서명 필드가 다르게 계산되지만 packed 증명문 형식과 동일한 형식으로 증명문을 반환합니다.
명세 문서: 이 명세의 § 8.3 TPM 증명문 형식
WebAuthn 증명문 형식 식별자: android-key
설명: "N" 이상 버전의 플랫폼 인증자는 이 독점적인 "하드웨어 증명"문을 제공할 수 있습니다.
명세 문서: 이 명세의 § 8.4 Android 키 증명문 형식
WebAuthn 증명문 형식 식별자: android-safetynet
설명: Android 기반 플랫폼 인증자는 Android SafetyNet API를 기반으로 하는 증명문을 생성할 수 있습니다.
명세 문서: 이 명세의 § 8.5 Android SafetyNet 증명문 형식
WebAuthn 증명문 형식 식별자: fido-u2f
설명: FIDO U2F 인증자와 함께 사용됩니다.
명세 문서: 이 명세의 § 8.6 FIDO U2F 증명문 형식

12.2. WebAuthn 증명문 형식 식별자 등록

이 절에서는 § 8 정의된 증명문 형식에서 새로 정의된 아래의 증명문 형식을 [RFC8809]에서 설정한 IANA "WebAuthn 증명문 형식 식별자" 레지스트리 [IANA-WebAuthn-Registries]에 등록합니다.

WebAuthn 증명문 형식 식별자: apple
설명: Apple 기기의 플랫폼 인증자와 함께 사용됩니다.
명세 문서: 이 명세의 § 8.8 Apple 익명 증명문 형식
WebAuthn 증명문 형식 식별자: none
설명: WebAuthn 신뢰 당사자가 증명 정보를 수신하지 않겠다고 나타낼 때 인증자가 제공한 모든 증명문을 대체하는 데 사용됩니다.
명세 문서: 이 명세의 § 8.7 없음 증명문 형식

12.3. WebAuthn 확장 식별자 등록 업데이트

이 절에서는 § 10 정의된 확장에 정의되고 원래 [WebAuthn-1]에서 등록된 아래의 확장 식별자 값을 [RFC8809]에서 설정한 IANA "WebAuthn 확장 식별자" 레지스트리 [IANA-WebAuthn-Registries]에서 이 명세를 가리키도록 업데이트합니다.

WebAuthn 확장 식별자: appid
설명: 이 인증 확장을 사용하면 기존 FIDO JavaScript API를 사용하여 자격 증명을 등록한 WebAuthn 신뢰 당사자가 어설션을 요청할 수 있습니다.
명세 문서: 이 명세의 § 10.1.1 FIDO AppID 확장 (appid)

12.4. WebAuthn 확장 식별자 등록

이 절에서는 § 10 정의된 확장에서 새로 정의된 아래의 확장 식별자 값을 [RFC8809]에서 설정한 IANA "WebAuthn 확장 식별자" 레지스트리 [IANA-WebAuthn-Registries]에 등록합니다.

WebAuthn 확장 식별자: appidExclude
설명: 이 등록 확장을 사용하면 WebAuthn 신뢰 당사자가 기존 FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI]로 생성된 지정 자격 증명을 포함하는 인증자를 제외할 수 있습니다.
명세 문서: 이 명세의 § 10.1.2 FIDO AppID 제외 확장 (appidExclude)
WebAuthn 확장 식별자: credProps
설명: 이 클라이언트 등록 확장을 사용하면 클라이언트가 결정한 새로 생성된 자격 증명의 속성을 호출한 WebAuthn 신뢰 당사자의 웹 애플리케이션에 보고할 수 있습니다.
명세 문서: 이 명세의 § 10.1.3 자격 증명 속성 확장 (credProps)
WebAuthn 확장 식별자: largeBlob
설명: 이 클라이언트 등록 확장 및 인증 확장을 사용하면 신뢰 당사자가 자격 증명과 연결된 불투명 데이터를 저장할 수 있습니다.
명세 문서: 이 명세의 § 10.1.5 대용량 blob 저장소 확장 (largeBlob)

12.5. Well-Known URI 등록

이 절에서는 다음 well-known URI를 IANA "Well-Known URI" 레지스트리 [IANA-Well-Known-URIs]에 등록합니다.

URI 접미사: webauthn
참조: 이 명세의 § 5.11.1 관련 오리진 검증
상태: 영구
변경 관리자: W3C Web Authentication Working Group (public-webauthn@w3.org)
관련 정보: (없음)

13. 보안 고려사항

이 명세는 Web API와 암호학적 피어 엔터티 인증 프로토콜을 정의합니다. 웹 인증 API를 사용하면 웹 개발자(즉, "작성자")가 자신의 등록 및 인증 절차에서 웹 인증 프로토콜을 사용할 수 있습니다. 웹 인증 프로토콜 엔드포인트를 구성하는 엔터티는 사용자가 제어하는 WebAuthn 인증자와 신뢰 당사자의 웹 애플리케이션을 호스팅하는 WebAuthn 신뢰 당사자의 컴퓨팅 환경입니다. 이 모델에서 사용자 에이전트는 WebAuthn 클라이언트와 함께 인증자와 신뢰 당사자 사이의 중개자를 구성합니다. 또한 인증자는 자신의 출처에 관해 신뢰 당사자에게 증명할 수 있습니다.

현재 이 명세에는 상세한 보안 고려사항이 포함되어 있지 않습니다. 그러나 [FIDOSecRef] 문서는 전반적으로 이 명세에 적용할 수 있는 보안 분석을 제공합니다. 또한 [FIDOAuthnrSecReqs] 문서 모음은 인증자의 보안 특성에 관한 유용한 정보를 제공합니다.

아래 하위 절은 현재의 웹 인증 관련 보안 고려사항을 구성합니다. 대상 독자별로 나뉘며, 일반적인 보안 고려사항은 이 절의 직접적인 하위 절로 제공되고, 인증자, 클라이언트 및 신뢰 당사자 구현자를 위한 보안 고려사항은 각각의 하위 절로 묶여 있습니다.

13.1. 자격 증명 ID는 서명되지 않음

인증 어설션과 함께 제공되는 자격 증명 ID는 서명되지 않습니다. 이는 문제가 되지 않습니다. 인증자가 잘못된 자격 증명 ID를 반환하거나 공격자가 자격 증명 ID를 가로채 조작하더라도 WebAuthn 신뢰 당사자가 반환된 서명된 인증자 데이터 (즉, 어설션)를 검증할 올바른 자격 증명 공개 키를 조회하지 못할 뿐이며, 따라서 상호 작용은 오류로 끝납니다.

13.2. 클라이언트와 인증자 사이의 물리적 근접성

WebAuthn 인증자 모델에서는 일반적으로 로밍 인증자가 클라이언트와 물리적으로 가깝고 직접 통신한다고 가정합니다. 이 구성에는 몇 가지 중요한 장점이 있습니다.

클라이언트와 인증자 사이의 물리적 근접성을 보장하는 것은 소유한 것 인증 요소의 핵심적인 강점입니다. 예를 들어 로밍 인증자가 USB 또는 Bluetooth를 통해서만 통신할 수 있다면, 이러한 전송 방식의 제한된 범위로 인해 악의적인 행위자가 인증자와 상호 작용하려면 물리적으로 해당 범위 안에 있어야 합니다. 원격으로 호출할 수 있는 인증자의 경우에는 반드시 그렇지는 않습니다. 인증자가 사용자 존재를 검증하더라도 사용자는 원격으로 시작된 악의적인 요청을 승인하도록 속을 수 있습니다.

클라이언트와 인증자 사이의 직접 통신은 클라이언트가 자격 증명의 범위 제한을 적용할 수 있음을 의미합니다. 반대로 클라이언트와 인증자 사이의 통신이 제3자에 의해 중개되면, 클라이언트는 범위 제한을 적용하고 인증자에 대한 접근을 제어하도록 제3자를 신뢰해야 합니다. 이 둘 중 하나라도 실패하면 악의적인 신뢰 당사자가 다른 신뢰 당사자에 유효한 인증 어설션을 수신하거나, 악의적인 사용자가 다른 사용자의 인증 어설션에 접근할 수 있습니다.

인증자가 클라이언트와 물리적으로 가까이 있을 필요가 없거나, 클라이언트와 인증자가 직접 통신하지 않는 솔루션을 설계한다면, 설계자는 이것이 범위 제한의 적용과 인증자의 소유한 것 인증 요소로서의 강도에 어떤 영향을 주는지 고려해야 합니다.

13.3. 인증자를 위한 보안 고려사항

13.3.1. 증명 인증서 계층

증명 인증서에는 3계층 구조(즉, 증명 루트, 증명 발급 CA, 증명 인증서)가 권장됩니다. 또한 각 WebAuthn 인증자 기기 라인(즉, 모델)마다 별도의 발급 CA를 사용하여 특정 인증자 모델 버전의 문제를 격리하기 쉽게 하는 것이 권장됩니다.

증명 루트 인증서가 하나의 WebAuthn 인증자 기기 라인(즉, AAGUID) 전용이 아니라면 AAGUID를 증명 인증서 자체에 지정하여 인증자 데이터와 대조하여 검증할 수 있도록 하는 것이 좋습니다.

13.3.2. 증명 인증서 및 증명 인증서 CA 손상

증명 인증서 발급에 사용되는 중간 CA 또는 루트 CA가 손상되더라도 WebAuthn 인증자의 증명 키 쌍은 여전히 안전하지만 해당 인증서는 더 이상 신뢰할 수 없습니다. 자신의 인증자 모델의 증명 공개 키를 기록해 둔 WebAuthn 인증자 제조사는 새 중간 CA 또는 새 루트 CA에서 이러한 키에 대해 새 증명 인증서를 발급할 수 있습니다. 루트 CA가 변경되면 WebAuthn 신뢰 당사자는 그에 맞게 신뢰하는 루트 인증서를 업데이트해야 합니다.

WebAuthn 인증자의 증명 인증서는 해당 개인 키가 손상된 경우 발급 CA가 폐기해야 합니다. 노출이 펌웨어 결함으로 인해 발생했다면 WebAuthn 인증자 제조사는 펌웨어 업데이트를 배포하고 이미 제조된 WebAuthn 인증자에 새 증명 개인 키 및 인증서를 주입해야 할 수 있습니다. (이 작업이 이루어지는 절차는 이 명세의 범위를 벗어납니다.) WebAuthn 인증자 제조사에 이러한 기능이 없다면 신뢰 당사자가 영향을 받은 WebAuthn 인증자의 이후 증명문을 더 이상 신뢰하지 못할 수 있습니다.

§ 13.5.5 폐기된 증명 인증서의 신뢰 당사자 관련 보안 고려사항도 참조하십시오.

13.4. 클라이언트를 위한 보안 고려사항

13.4.1. remoteClientDataJSON 확장

remoteClientDataJSON 확장을 사용하면 원격 데스크톱 웹 클라이언트가 원격 신뢰 당사자를 대신하여 웹 인증 API 요청을 프록시할 수 있습니다. 이는 다음과 같은 방식으로 웹 인증 API의 신뢰 모델을 근본적으로 변경합니다.

오리진 대체: 사용자 에이전트는 현재 실행 컨텍스트에서 도출하는 대신 호출하는 원격 데스크톱 웹 클라이언트가 제공한 origin을 허용합니다. 따라서 이 권한을 부여하는 모든 사용자 에이전트는 호출자가 원격 신뢰 당사자의 오리진을 정확하고 정직하게 제공한다고 신뢰해야 합니다.
RP ID 검증: 관련 오리진과 플랫폼별 앱 배포 모델을 고려하여 오리진을 검증하는 데 필요한 모든 컨텍스트를 원격 클라이언트가 가지고 있으므로 RP ID 검증은 원격 클라이언트에 위임됩니다. 따라서 이 권한을 부여하는 모든 사용자 에이전트는 원격 클라이언트가 모든 오리진 검사에 대해 RP ID를 정확하고 정직하게 검증했다고 신뢰해야 합니다.
오리진별 구성 메커니즘 필요: 이 확장의 권한은 오리진별이므로 사용자 에이전트는 사용자 에이전트 정책(예: UA 설정 또는 엔터프라이즈 정책)을 통해 오리진별 구성 메커니즘만 제공해야 합니다.

이 확장을 허용하는 사용자 에이전트는 원격 데스크톱을 통해 프록시되는 WebAuthn 작업이 진행 중일 때 이를 사용자에게 명확하게 알려, 사용자가 자신의 인증자가 원격으로 호스팅되는 애플리케이션을 대신하여 사용되고 있음을 이해하도록 해야 합니다.

13.5. 신뢰 당사자를 위한 보안 고려사항

13.5.1. WebAuthn 신뢰 당사자를 위한 보안 이점

이 명세가 WebAuthn 신뢰 당사자에게 제공하는 주요 이점은 다음과 같습니다.

널리 호환되고 사용하기 쉬운 다중 요소 인증을 사용하여 사용자와 계정을 보호할 수 있습니다.
신뢰 당사자는 사용자에게 인증자 하드웨어를 제공할 필요가 없습니다. 대신 각 사용자는 독립적으로 적합한 인증자를 구하고 동일한 인증자를 임의 수의 신뢰 당사자와 함께 사용할 수 있습니다. 신뢰 당사자는 선택적으로 인증자가 반환한 증명문을 검사하여 인증자의 보안 속성에 대한 요구사항을 적용할 수 있습니다.
인증 절차는 중간자 공격에 강합니다. 등록 절차에 대해서는 아래의 § 13.5.4 증명의 한계를 참조하십시오.
신뢰 당사자는 코드 변경이 거의 또는 전혀 없이 PIN, 생체 인식 및/또는 향후 방식과 같은 여러 유형의 사용자 검증을 자동으로 지원할 수 있고, 각 사용자가 자신의 인증자 선택을 통해 선호하는 방식을 결정하도록 할 수 있습니다.
신뢰 당사자는 위의 이점을 얻기 위해 추가 비밀을 저장할 필요가 없습니다.

적합성 절에서 설명한 대로 신뢰 당사자는 위의 모든 보안 이점을 얻으려면 § 7 WebAuthn 신뢰 당사자 작업에 설명된 대로 동작해야 합니다. 그러나 이와 약간 다른 한 가지 주목할 만한 사용 사례가 아래의 § 13.5.4 증명의 한계에 설명되어 있습니다.

13.5.2. 임베디드 사용의 가시성 고려사항

§ 5.10 iframe 요소 내에서 웹 인증 사용에 설명된 것처럼 iframe 등의 임베디드 컨텍스트에서 WebAuthn을 단순하게 사용하면 사용자가 "클릭재킹"이라고도 하는 UI 위장 공격에 취약해질 수 있습니다. 이는 공격자가 신뢰 당사자가 의도한 UI 위에 자신의 UI를 겹쳐 놓고 사용자를 속여 신뢰 당사자에서 의도하지 않은 작업을 수행하도록 시도하는 것입니다. 예를 들어 이러한 기법을 사용하면 공격자가 사용자를 속여 물품을 구매하거나 송금하게 할 수 있습니다.

WebAuthn 전용 UI는 일반적으로 클라이언트 플랫폼에서 처리되므로 UI 위장에 취약하지 않지만, WebAuthn을 사용하는 임베디드 콘텐츠를 가진 신뢰 당사자는 자신의 콘텐츠 UI가 사용자에게 보이도록 하는 것이 중요할 가능성이 높습니다. 이를 위한 새롭게 등장하는 방법 중 하나는 실험적인 Intersection Observer v2의 isVisible 속성 상태를 관찰하는 것입니다. 예를 들어 임베디드 컨텍스트에서 실행되는 신뢰 당사자의 스크립트는 isVisble이 false로 설정된 것을 감지하면 선제적으로 팝업 창에 자신을 로드하여 콘텐츠가 가려지는 것을 피할 수 있습니다.

13.5.3. 암호학적 챌린지

암호학적 프로토콜로서 웹 인증은 재전송 공격을 방지하기 위해 무작위 챌린지에 의존합니다. 따라서 PublicKeyCredentialCreationOptions.challenge 및 PublicKeyCredentialRequestOptions.challenge의 값은 신뢰 당사자가 신뢰하는 환경(예: 서버 측)에서 무작위로 생성해야 하며, 클라이언트 응답에서 반환된 challenge 값은 생성된 값과 일치해야 합니다. 이는 클라이언트의 동작에 의존하지 않는 방식으로 수행해야 합니다. 예를 들어 신뢰 당사자는 작업이 완료될 때까지 챌린지를 임시로 저장하는 것이 좋습니다. 불일치를 허용하면 프로토콜의 보안이 손상됩니다.

챌린지는 WebAuthn 절차 시간 제한의 권장 범위 및 기본값 상한과 비슷한 기간 동안 유효해야 합니다.

재전송 공격을 방지하려면 챌린지에는 추측이 현실적으로 불가능하도록 충분한 엔트로피가 포함되어야 합니다. 따라서 챌린지는 최소 16바이트 길이인 것이 좋습니다.

13.5.4. 증명의 한계

이 절은 규범적이지 않습니다.

새 자격 증명을 등록할 때, 증명문이 존재한다면 WebAuthn 신뢰 당사자가 여러 인증자 특성에 대한 보장을 추론할 수 있게 할 수 있습니다. 예를 들어 인증자 모델이나 자격 증명 개인 키를 저장하고 보호하는 방식 등이 있습니다. 그러나 증명문 자체만으로는 신뢰 당사자가 증명 객체가 사용자가 의도한 인증자에서 생성되었고 중간자 공격자가 생성한 것이 아님을 검증할 방법을 제공하지 않는다는 점에 유의해야 합니다. 예를 들어 이러한 공격자는 신뢰 당사자 스크립트에 삽입된 악성 코드를 사용할 수 있습니다. 따라서 신뢰 당사자는 증명 객체를 중간자 공격으로부터 보호하기 위해 TLS 및 관련 기술과 같은 다른 수단에 의존해야 합니다.

등록 절차가 안전하게 완료되고 인증자가 자격 증명 개인 키의 기밀성을 유지한다는 가정하에, 해당 공개 키 자격 증명을 사용하는 이후의 인증 절차는 중간자 공격에 의한 변조에 강합니다.

위 논의는 모든 증명 유형에 적용됩니다. 모든 경우에 중간자 공격자는 증명문과 등록할 자격 증명 공개 키를 포함한 PublicKeyCredential 객체를 대체하고, 이후 동일한 신뢰 당사자에 범위가 지정되고 동일한 공격자를 통과하는 향후 인증 어설션을 변조할 수 있습니다.

이러한 공격은 잠재적으로 탐지할 수 있습니다. 신뢰 당사자가 사용자의 키가 아니라 공격자의 자격 증명 공개 키를 등록했으므로 공격자는 해당 신뢰 당사자와의 이후 모든 인증 절차를 변조해야 합니다. 변조되지 않은 절차는 실패하여 공격을 드러낼 수 있습니다.

자체 증명과 없음 이외의 증명 유형은 신뢰 당사자가 모델 지정과 같은 인증자 정보를 사용자에게 표시할 수 있으므로 이러한 공격의 난이도를 높일 수 있습니다. 따라서 공격자는 사용자의 인증자와 동일한 모델의 실제 인증자를 사용해야 할 수도 있고, 사용자가 신뢰 당사자가 자신이 예상한 것과 다른 인증자 모델을 보고한다는 점을 알아챌 수도 있습니다.

참고: 위에 설명된 모든 종류의 중간자 공격은 기존 암호 인증에 대한 중간자 공격보다 공격자가 수행하기 더 어렵습니다.

13.5.5. 폐기된 증명 인증서

폐기된 중간 증명 CA 인증서로 인해 증명 인증서 검증이 실패하고, 신뢰 당사자의 정책이 이러한 상황에서 등록/인증 요청을 거부하도록 요구한다면, 신뢰 당사자는 CA 손상 날짜 이후 동일한 중간 CA로 체인되는 증명 인증서를 사용하여 등록된 공개 키 자격 증명도 등록 해제하거나 "자체 증명"과 동등한 신뢰 수준으로 표시하는 것이 권장됩니다. 따라서 신뢰 당사자는 이러한 인증서가 폐기된 이후 등록이 수행된 경우 관련 공개 키 자격 증명을 등록 해제할 수 있도록 등록 중에 중간 증명 CA 인증서를 기억하는 것이 권장됩니다.

§ 13.3.2 증명 인증서 및 증명 인증서 CA 손상의 인증자 관련 보안 고려사항도 참조하십시오.

13.5.6. 자격 증명 손실 및 키 이동성

이 명세는 자격 증명 개인 키를 백업하거나 인증자 사이에서 공유하기 위한 프로토콜을 정의하지 않습니다. 일반적으로 자격 증명 개인 키는 이를 생성한 인증자를 절대 벗어나지 않을 것으로 예상됩니다. 따라서 일반적으로 인증자를 잃으면 잃어버린 인증자에 바인딩된 모든 자격 증명을 잃게 되며, 사용자가 신뢰 당사자에 등록한 자격 증명이 하나뿐이라면 계정에 접근하지 못할 수 있습니다. 웹 인증 API는 개인 키를 백업하거나 공유하는 대신 동일한 사용자에 대해 여러 자격 증명을 등록할 수 있게 합니다. 예를 들어 사용자는 자주 사용하는 클라이언트 기기에 플랫폼 자격 증명을 등록하고, 백업 용도 및 새롭거나 자주 사용하지 않는 클라이언트 기기에서 사용하기 위해 하나 이상의 로밍 자격 증명을 등록할 수 있습니다.

신뢰 당사자는 사용자가 동일한 사용자 계정에 여러 자격 증명을 등록할 수 있도록 허용하고 권장해야 합니다. 신뢰 당사자는 이러한 서로 다른 자격 증명이 서로 다른 인증자에 바인딩되도록 excludeCredentials 및 user.id 옵션을 사용해야 합니다.

13.5.7. 보호되지 않은 계정 탐지

이 절은 규범적이지 않습니다.

이 보안 고려사항은 첫 번째 인증 단계로 비어 있지 않은 allowCredentials 인수를 사용하여 인증 절차를 지원하는 신뢰 당사자에 적용됩니다. 예를 들어 서버 측 자격 증명을 사용하는 인증을 첫 번째 인증 단계로 사용하는 경우입니다.

이 경우 allowCredentials 인수는 어떤 사용자 계정에 WebAuthn 자격 증명이 등록되어 있고 어떤 계정에는 그렇지 않은지에 관한 정보를 유출할 위험이 있으며, 이는 계정 보호 강도를 나타내는 신호가 될 수 있습니다. 예를 들어 공격자가 사용자 이름만 제공하여 인증 절차를 시작할 수 있고, 신뢰 당사자가 일부 사용자 계정에는 비어 있지 않은 allowCredentials로 응답하고 다른 사용자 계정에는 실패 또는 암호 챌린지로 응답한다고 가정합니다. 그러면 공격자는 후자의 사용자 계정이 성공적인 인증을 위해 WebAuthn 어설션을 요구하지 않을 가능성이 높다고 결론 내리고, 상대적으로 약할 가능성이 있는 해당 계정에 공격을 집중할 수 있습니다.

이 문제는 § 14.6.2 사용자 이름 열거 및 § 14.6.3 자격 증명 ID를 통한 개인정보 유출에 설명된 문제와 유사하며 비슷한 방법으로 완화할 수 있습니다.

13.5.8. 코드 삽입 공격

신뢰 당사자의 공개 키 자격 증명의 범위 내 오리진에서 실행되는 모든 악성 코드는 WebAuthn이 제공할 수 있는 모든 보안 보장을 무효화할 가능성이 있습니다. WebAuthn 클라이언트는 보안 컨텍스트에서만 WebAuthn API를 노출하므로 가장 기본적인 공격은 완화되지만 신뢰 당사자가 추가 예방 조치와 함께 사용해야 합니다.

코드 삽입은 여러 방식으로 발생할 수 있습니다. 이 절에서는 가능성이 높은 몇 가지 시나리오를 지적하고 적절한 완화책을 제안하려 하지만 완전한 목록은 아닙니다.

신뢰 당사자가 포함한 제3자 스크립트에 의해 의도적으로 또는 제3자의 보안 취약점으로 인해 악성 코드가 삽입될 수 있습니다.

따라서 신뢰 당사자는 자신의 자격 증명의 범위 내 오리진에 포함되는 제3자 스크립트의 양을 제한해야 합니다.

신뢰 당사자는 자신의 오리진에서 실행될 수 있는 스크립트를 제한하기 위해 Content Security Policy [CSP2] 및/또는 당시 이용 가능한 기타 적절한 기술을 사용해야 합니다.
자격 증명 범위 규칙에 따라 RP ID의 하위 도메인에 악성 코드가 호스팅될 수 있습니다. 예를 들어 usercontent.example.org에 호스팅된 사용자 제출 코드는 RP ID example.org에 범위가 지정된 모든 자격 증명을 사용할 수 있습니다. 신뢰 당사자가 어설션을 검증할 때 하위 도메인 origin을 허용하면 악의적인 사용자가 이를 이용해 중간자 공격을 수행하여 유효한 인증 어설션을 얻고 공격 피해자를 가장할 수 있습니다.

따라서 신뢰 당사자는 기본적으로 어설션을 검증할 때 하위 도메인 origin을 허용하지 않아야 합니다. 신뢰 당사자가 하위 도메인 origin을 허용해야 한다면 신뢰 당사자는 자신의 공개 키 자격 증명의 범위 내 허용된 오리진의 어떤 하위 도메인에서도 신뢰할 수 없는 코드를 제공해서는 안 됩니다.

13.5.9. 자격 증명의 오리진 검증

자격 증명을 등록할 때와 어설션을 검증할 때, 신뢰 당사자는 클라이언트 데이터의 origin 멤버를 검증해야 합니다.

신뢰 당사자는 예상하지 않은 origin 값을 허용해서는 안 됩니다. 그렇게 하면 악성 웹사이트가 유효한 자격 증명을 얻을 수 있습니다. WebAuthn 자격 증명의 범위는 등록된 RP ID 외부의 도메인에서 사용되는 것을 방지하지만, 신뢰 당사자의 오리진 검증은 결함이 있는 인증자가 자격 증명 범위를 적용하지 못하는 경우 추가 보호 계층 역할을 합니다. 잠재적으로 악의적인 하위 도메인에 관한 논의는 § 13.5.8 코드 삽입 공격도 참조하십시오.

검증은 정확한 문자열 일치 또는 신뢰 당사자가 필요로 하는 다른 방법으로 수행할 수 있습니다. 예:

https://example.org에서만 제공되는 웹 애플리케이션은 origin이 정확히 https://example.org와 같도록 요구해야 합니다.

이는 가장 단순한 경우로, origin은 문자열 https:// 뒤에 RP ID가 이어지는 형태일 것으로 예상됩니다.
소수의 도메인에서 제공되는 웹 애플리케이션은 origin이 허용된 오리진 목록의 어떤 요소와 정확히 같도록 요구할 수 있습니다. 예를 들면 ["https://example.org", "https://login.example.org"] 목록입니다.
관련 오리진 요청을 사용하는 웹 애플리케이션도 origin이 허용된 오리진 목록의 어떤 요소와 정확히 같도록 요구할 수 있습니다. 예를 들면 ["https://example.co.uk", "https://example.de", "https://myexamplerewards.com"] 목록입니다. 이 목록은 일반적으로 RP ID의 well-known URI에 나열된 오리진과 일치합니다. § 5.11 관련 오리진 간 웹 인증 사용을 참조하십시오.
자주 변경되는 많은 도메인 집합에서 제공되는 웹 애플리케이션은 origin을 구조적으로 파싱하고 URL 스킴이 https이며 authority가 RP ID와 같거나 그 하위 도메인이 되도록 요구할 수 있습니다. 예를 들어 example.org 또는 example.org의 모든 하위 도메인).

참고: § 13.5.8 코드 삽입 공격에서 RP ID의 모든 하위 도메인을 허용할 때의 위험에 관한 논의를 참조하십시오.
동반 네이티브 애플리케이션이 있는 웹 애플리케이션은 origin이 네이티브 애플리케이션의 운영 체제 종속 식별자가 되도록 허용할 수 있습니다. 예를 들어 이러한 신뢰 당사자는 origin이 다음 목록의 어떤 요소와 정확히 같도록 요구할 수 있습니다. ["https://example.org", "example-os:appid:204ffa1a5af110ac483f131a1bef8a841a7adb0d8d135908bbd964ed05d2653b"].

클라이언트 데이터의 topOrigin 멤버를 검증할 때도 비슷한 고려사항이 적용됩니다. topOrigin이 존재하면 신뢰 당사자는 그 값이 예상된 값인지 검증해야 합니다. 이 검증은 정확한 문자열 일치 또는 신뢰 당사자가 필요로 하는 다른 방법으로 수행할 수 있습니다. 예:

교차 오리진 iframe에 임베드되기를 원하지 않는 웹 애플리케이션은 topOrigin이 origin과 정확히 같도록 요구할 수 있습니다.
소수의 도메인에서 교차 오리진 iframe에 임베드되기를 원하는 웹 애플리케이션은 topOrigin이 허용된 오리진 목록의 어떤 요소와 정확히 같도록 요구할 수 있습니다. 예를 들면 ["https://example-partner1.org", "https://login.partner2-example.org"] 목록입니다.
많은 도메인에서 교차 오리진 iframe에 임베드되기를 원하는 웹 애플리케이션은 topOrigin의 어떤 값이든 허용하거나 특정 절차에 대해 주어진 topOrigin 값이 허용되는지 결정하는 동적 절차를 사용할 수 있습니다.

14. 개인정보 보호 고려사항

[FIDO-Privacy-Principles]의 개인정보 보호 원칙도 이 명세에 적용됩니다.

이 절은 대상 독자별로 나뉩니다. 일반적인 개인정보 보호 고려사항은 이 절의 직접적인 하위 절로 구성되며, 인증자, 클라이언트 및 신뢰 당사자 구현자를 위한 개인정보 보호 고려사항은 각각 해당 하위 절로 묶여 있습니다.

14.1. 비익명화 방지 조치

이 절은 규범적이지 않습니다.

웹 인증 API 설계의 많은 측면은 개인정보 보호 문제를 고려하여 결정되었습니다. 이 명세에서 고려하는 주요 문제는 사용자의 개인 신원, 즉 한 사람을 식별하거나 서로 다른 신원이 동일한 사람에게 속한다고 연관시키는 것을 보호하는 것입니다. 웹 인증 API는 어떠한 형태의 전역 신원도 사용하거나 제공하지 않지만 잠재적으로 연관시킬 수 있는 다음 종류의 식별자가 사용됩니다.

사용자의 자격 증명 ID 및 자격 증명 공개 키.

이들은 WebAuthn 신뢰 당사자에 의해 등록되고, 이후 사용자가 해당 자격 증명 개인 키를 소유하고 있음을 증명하는 데 사용됩니다. 또한 클라이언트가 인증자와 통신하는 과정에서도 볼 수 있습니다.
각 신뢰 당사자에 특정된 사용자의 신원, 예를 들어 사용자 이름 및 사용자 핸들.

이러한 신원은 각 신뢰 당사자가 자신의 시스템에서 사용자를 식별하는 데 사용됩니다. 또한 클라이언트가 인증자와 통신하는 과정에서도 볼 수 있습니다.
사용자의 생체 특성, 예를 들어 지문이나 얼굴 인식 데이터 [ISOBiometricVocabulary].

이는 선택적으로 인증자가 사용자 검증을 수행하는 데 사용됩니다. 이 정보는 신뢰 당사자에게 공개되지 않지만 플랫폼 인증자의 경우 구현에 따라 클라이언트에서 볼 수 있을 수도 있습니다.
사용자의 인증자 모델, 예를 들어 제품 이름.

이는 등록 중 신뢰 당사자에게 제공되는 증명문에 노출됩니다. 또한 클라이언트가 인증자와 통신하는 과정에서도 볼 수 있습니다.
사용자의 인증자 식별 정보, 예를 들어 일련번호.

이는 클라이언트가 인증자와 통신할 수 있도록 하는 데 사용될 수 있지만 신뢰 당사자에게는 공개되지 않습니다.

위 정보 중 일부는 반드시 신뢰 당사자와 공유됩니다. 다음 절에서는 악의적인 신뢰 당사자가 이를 사용하여 사용자의 개인 신원을 알아내는 것을 방지하기 위해 취한 조치를 설명합니다.

14.2. 익명이며 범위가 지정되고 연관 불가능한 공개 키 자격 증명

이 절은 규범적이지 않습니다.

자격 증명 ID와 자격 증명 공개 키는 강력한 인증을 가능하게 하기 위해 반드시 WebAuthn 신뢰 당사자와 공유되지만 식별 가능성을 최소화하고 신뢰 당사자 간에 공유되지 않도록 설계되어 있습니다.

자격 증명 ID와 자격 증명 공개 키는 단독으로는 의미가 없습니다. 이들은 자격 증명 키 쌍만 식별하며 사용자를 직접 식별하지 않기 때문입니다.
각 공개 키 자격 증명은 특정 신뢰 당사자에 엄격하게 범위가 지정되며, 클라이언트는 그 존재가 다른 신뢰 당사자에게 공개되지 않도록 보장합니다. 따라서 악의적인 신뢰 당사자는 클라이언트에게 사용자의 다른 신원을 공개하도록 요청할 수 없습니다.
클라이언트는 또한 공개 키 자격 증명의 존재가 사용자 동의 없이 신뢰 당사자에게 공개되지 않도록 보장합니다. 이는 § 14.5.1 등록 절차 개인정보 보호 및 § 14.5.2 인증 절차 개인정보 보호에서 자세히 설명합니다. 따라서 악의적인 신뢰 당사자는 사용자가 공개 키 자격 증명을 등록해 사용할 수 있는 경우에도 조용히 사용자를 식별할 수 없습니다.
인증자는 서로 다른 공개 키 자격 증명의 자격 증명 ID와 자격 증명 공개 키가 동일한 사용자에게 속한다고 연관될 수 없도록 보장합니다. 따라서 악의적인 신뢰 당사자 두 곳은 의도적으로 재사용된 사용자 이름이나 이메일 주소와 같은 추가 정보 없이는 자신들의 시스템 간에서 사용자를 연관시킬 수 없습니다.
인증자는 자신의 증명 인증서가 단일 인증자나 소규모 인증자 집단을 식별할 정도로 고유하지 않도록 보장합니다. 자세한 내용은 § 14.4.1 증명 개인정보 보호에서 설명합니다. 따라서 악의적인 신뢰 당사자 두 곳은 개별 인증자를 추적하여 자신들의 시스템 간에서 사용자를 연관시킬 수 없습니다.

또한 클라이언트 측에서 검색 가능한 공개 키 자격 증명 소스에는 선택적으로 신뢰 당사자가 지정한 사용자 핸들이 포함될 수 있습니다. 그러면 자격 증명을 사용자를 식별하고 인증하는 데 모두 사용할 수 있습니다. 이는 개인정보 보호를 중시하는 신뢰 당사자가 기존 사용자 이름 없이 사용자 계정을 만들 수 있게 하여 신뢰 당사자 간의 연관 불가능성을 더욱 향상시킬 수 있음을 의미합니다.

14.3. 인증자 로컬 생체 인식

생체 인식 인증자는 생체 인식을 인증자 내부에서 수행합니다. 다만 플랫폼 인증자의 경우 생체 데이터가 구현에 따라 클라이언트에서도 보일 수 있습니다. 생체 데이터는 WebAuthn 신뢰 당사자에게 공개되지 않으며, 공개 키 자격 증명의 생성 및 등록 또는 이를 사용한 인증을 승인하는 사용자 검증을 로컬에서 수행하는 데만 사용됩니다. 따라서 악의적인 신뢰 당사자는 생체 데이터를 통해 사용자의 개인 신원을 알아낼 수 없으며, 신뢰 당사자에서 보안 침해가 발생해도 생체 데이터가 노출되어 공격자가 다른 신뢰 당사자에서 로그인을 위조하는 데 사용될 수 없습니다.

신뢰 당사자가 생체 인식을 요구하는 경우, 이는 생체 인식 인증자가 로컬에서 사용자 검증을 수행한 다음, 생체 데이터 자체를 신뢰 당사자에게 공개하는 대신 서명된 어설션 응답의 플래그 UV를 설정하여 결과를 나타냅니다.

14.4. 인증자를 위한 개인정보 보호 고려사항

14.4.1. 증명 개인정보 보호

증명 인증서와 증명 키 쌍은 사용자를 추적하거나 동일한 사용자의 여러 온라인 신원을 서로 연결하는 데 사용될 수 있습니다. 이는 다음을 포함한 여러 방법으로 완화할 수 있습니다.

WebAuthn 인증자 제조사는 동일한 배치의 인증자가 동일한 증명 인증서(기본 증명 또는 배치 증명이라고 함)를 공유하도록 인증자를 배치 단위로 출하할 수 있습니다. 이는 개인 키가 손상되었을 때 특정 증명 인증서를 폐기할 수 없게 되는 위험을 감수하는 대신 사용자를 익명화합니다. 그러면 인증자 제조사는 이러한 배치가 의미 있는 익명화를 제공할 만큼 충분히 크도록 보장하는 동시에 증명 개인 키가 손상될 경우 영향을 받는 사용자 수를 제한하기 위해 배치 크기를 가능한 한 작게 유지하는 것이 좋습니다.

[UAFProtocol]은 충분히 큰 집단을 만들기 위해 최소 100,000개의 인증자 기기가 동일한 증명 인증서를 공유하도록 요구합니다. 이는 적절한 배치 크기에 대한 지침으로 활용할 수 있습니다.
WebAuthn 인증자는 익명화 CA 방식에서 설명한 것처럼 자격 증명마다 서로 다른 증명 키 쌍(및 관련 인증서)을 동적으로 생성할 수 있습니다. 예를 들어 인증자는 주 증명 개인 키(및 인증서)와 함께 출하되고, 클라우드에서 운영되는 익명화 CA와 결합하여 자격 증명별 증명 키 쌍 및 증명 인증서를 동적으로 생성할 수 있습니다.

참고: 이 명세 외부의 여러 곳에서는 여기에서 익명화 CA라고 부르는 것을 가리키는 데 "Privacy CA"라는 용어를 사용합니다. Trusted Computing Group(TCG)도 "Privacy CA"라는 용어를 현재 TCG가 증명 CA(ACA) [TCG-CMCProfile-AIKCertEnroll]라고 부르는 것을 가리키는 데 사용했기 때문에, 이 명세의 특정 문맥에서 혼동을 줄이기 위해 여기서는 익명화 CA라는 용어를 사용합니다.

14.4.2. 인증자에 저장된 개인 식별 정보의 개인정보 보호

인증자는 이 명세에서 정의된 것 외의 추가 정보를 클라이언트에 제공할 수 있습니다. 예를 들어 사용자가 자격 증명 중 어떤 것을 인증 절차에 사용할지 선택할 수 있는 풍부한 UI를 클라이언트가 제공하도록 하기 위해서입니다. 인증자가 그렇게 하기로 선택한 경우, 성공적인 사용자 검증이 수행되지 않았다면 개인 식별 정보를 노출해서는 안 됩니다. 인증자가 둘 이상의 사용자를 동시에 등록한 상태에서 사용자 검증을 지원한다면, 인증자는 현재 검증된 사용자 이외의 사용자의 개인 식별 정보를 노출해서는 안 됩니다. 따라서 사용자 검증 기능이 없는 인증자는 개인 식별 정보를 저장해서는 안 됩니다.

이 논의의 목적상 PublicKeyCredentialUserEntity의 id 멤버로 전달되는 사용자 핸들은 개인 식별 정보로 간주되지 않습니다. § 14.6.1 사용자 핸들 내용을 참조하십시오.

이러한 권장사항은 인증자에 물리적으로 접근할 수 있는 공격자가 인증자에 등록된 사용자에 대한 개인 식별 정보를 추출하는 것을 방지하기 위한 것입니다.

14.5. 클라이언트를 위한 개인정보 보호 고려사항

14.5.1. 등록 절차 개인정보 보호

동의 없이 사용자가 식별되지 않도록 보호하려면 [[Create]](origin, options, sameOriginWithAncestors) 메서드 구현은 다음 경우를 악의적인 WebAuthn 신뢰 당사자가 구별할 수 있게 하는 정보를 유출하지 않도록 주의해야 합니다. 여기서 "제외됨"은 신뢰 당사자가 excludeCredentials에 나열한 자격 증명 중 하나 이상이 인증자에 바인딩되어 있음을 의미합니다.

인증자가 존재하지 않습니다.
하나 이상의 인증자가 존재하고, 존재하는 인증자 중 하나 이상이 제외됩니다.

위 경우를 구별할 수 있다면, 악의적인 신뢰 당사자가 어떤 자격 증명을 사용할 수 있는지 탐색하여 사용자를 식별할 수 있는 정보가 유출됩니다. 예를 들어 클라이언트가 제외된 인증자를 사용할 수 있게 되는 즉시 실패 응답을 반환하면 이러한 정보 유출이 발생합니다. 이 경우, 특히 제외된 인증자가 플랫폼 인증자라면 신뢰 당사자는 사용자가 현실적으로 직접 취소할 수 있기 전에 절차가 취소된 것을 감지하고 따라서 excludeCredentials 매개변수에 나열된 자격 증명 중 하나 이상을 사용자가 사용할 수 있다고 결론 내릴 수 있습니다.

그러나 구별 가능한 오류가 반환되기 전에 사용자가 새 자격 증명을 생성하는 데 동의했다면 위 문제는 우려할 사항이 아닙니다. 이 경우 사용자가 유출될 정보를 공유하려는 의도를 확인했기 때문입니다.

14.5.2. 인증 절차 개인정보 보호

동의 없이 사용자가 식별되지 않도록 보호하려면 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 메서드 구현은 다음 경우를 악의적인 WebAuthn 신뢰 당사자가 구별할 수 있게 하는 정보를 유출하지 않도록 주의해야 합니다. 여기서 "지정됨"은 신뢰 당사자가 allowCredentials에 해당 자격 증명을 나열했음을 의미합니다.

지정된 자격 증명을 사용할 수 없습니다.
지정된 자격 증명을 사용할 수 있지만, 사용자가 이를 사용하는 데 동의하지 않습니다.

위 경우를 구별할 수 있다면 악의적인 신뢰 당사자가 어떤 자격 증명을 사용할 수 있는지 탐색하여 사용자를 식별할 수 있는 정보가 유출됩니다. 예를 들어 클라이언트가 지정된 자격 증명을 포함하는 인증자를 찾은 후에만 인증 절차를 취소하거나 계속하기 위한 지침과 컨트롤을 표시하면 이러한 정보 유출이 발생할 수 있습니다. 이 경우 신뢰 당사자가 이러한 클라이언트 동작을 알고 있다면 신뢰 당사자는 절차가 시간 제한 때문이 아니라 사용자에 의해 취소되었음을 감지하고, 따라서 allowCredentials 매개변수에 나열된 자격 증명 중 하나 이상을 사용자가 사용할 수 있다고 결론 내릴 수 있습니다.

이 문제는 지정된 자격 증명을 사용할 수 있는지 여부와 관계없이 사용자가 언제든지 인증 절차를 취소할 수 있는 컨트롤을 표시하여 해결할 수 있습니다.

14.5.3. 운영 체제 계정 간 개인정보 보호

다중 사용자 운영 체제가 있는 클라이언트 기기에 플랫폼 인증자가 포함되어 있는 경우, 플랫폼 인증자와 클라이언트 기기는 모든 플랫폼 자격 증명의 존재가 해당 플랫폼 자격 증명을 만든 운영 체제 사용자에게만 공개되도록 함께 동작하는 것이 좋습니다.

14.5.4. 클라이언트 기능 공개

getClientCapabilities 메서드는 WebAuthn 신뢰 당사자가 클라이언트 및/또는 사용자와 함께 성공할 가능성이 높은 등록 및 인증 환경을 구성하는 데 도움을 줍니다.

WebAuthn 클라이언트가 특정 기능을 지원하거나 지원하지 않는다는 사실은 핑거프린팅 위험을 초래할 수 있습니다. 이 위험을 줄이려면 클라이언트는 false 값을 반환하기보다 반환되는 레코드에서 키를 생략하는 방식을 선호하는 것이 좋습니다. 키를 생략하면 (§ 5.1.7 클라이언트 기능의 가용성 - PublicKeyCredential의 getClientCapabilities() 메서드에서 설명한 것처럼) 기능이 지원되지 않는다고 명시적으로 확인하는 것보다 핑거프린팅 표면이 줄어듭니다. 클라이언트 구현은 클라이언트 정책 및/또는 사용자 동의에 따라 기능 공개를 제한할 수도 있습니다.

14.5.5. WebAuthn 자격 증명의 교차 오리진 사용

WebAuthn 등록 또는 인증 절차가 관련 오리진 요청을 사용하거나 교차 오리진 iframe 내에서 호출되는 경우처럼 교차 오리진 컨텍스트에서 수행되면, 누가 공개 키 자격 증명에 접근하거나 생성을 요청하는지에 관해 사용자가 혼동할 위험이 있습니다.

관련 오리진 요청과 같이 호출하는 오리진과 RP ID가 서로 다른 경우, WebAuthn 클라이언트와 클라이언트 플랫폼은 자격 증명 및 인증자 선택 인터페이스에서 다음 두 항목을 모두 표시하여 사용자에게 명확한 컨텍스트를 제공하도록 보장하는 것이 좋습니다.

호출자의 오리진: navigator.credentials를 호출하는 완전히 활성 상태인 문서의 오리진
신뢰 당사자 ID: 자격 증명이 원래 생성되었거나 생성될 RP ID

예를 들어 RP ID가 exampleA.com이고 호출 오리진이 https://otherExampleB.com인 경우 WebAuthn 클라이언트 및/또는 클라이언트 플랫폼은 사용자에게 다음과 같이 표시할 수 있습니다. "exampleA.com용 패스키를 사용하여 otherExampleB.com에 로그인하시겠습니까?"

WebAuthn이 iframe에서 호출되는 경우 WebAuthn 클라이언트 및/또는 클라이언트 플랫폼은 자격 증명 및 인증자 선택 인터페이스가 사용자에게 경고를 제공하고 iframe이 포함된 페이지의 최상위 오리진에 관한 추가 컨텍스트도 제공하도록 보장하는 것이 좋습니다. 이는 호출자의 오리진과 다를 수 있기 때문입니다. 절차가 성공하면 최상위 오리진과 호출 오리진 모두 각자의 사이트에서 사용자의 신원을 연관시킬 수 있습니다.

예를 들어 RP ID가 examplepay.com이고 호출 오리진이 https://examplepay.com, 최상위 오리진이 https://example.com인 경우 WebAuthn 클라이언트 및/또는 클라이언트 플랫폼은 사용자에게 다음과 같이 표시할 수 있습니다. "패스키를 사용하여 examplepay.com에 로그인하시겠습니까? Example.com은 사용자가 examplepay.com에 로그인하고 있음을 알게 됩니다."

14.6. 신뢰 당사자를 위한 개인정보 보호 고려사항

14.6.1. 사용자 핸들 내용

§ 14.4.2 인증자에 저장된 개인 식별 정보의 개인정보 보호에서 사용자 핸들은 개인 식별 정보로 간주되지 않으며, 인증자는 먼저 사용자 검증을 수행하지 않고도 사용자 핸들을 공개할 수 있으므로, 신뢰 당사자는 이메일 주소나 사용자 이름과 같은 개인 식별 정보를 사용자 핸들에 포함해서는 안 됩니다. 여기에는 개인 식별 정보의 해시 값도 포함됩니다. 다만 해시 함수가 신뢰 당사자에 비공개인 솔트 값으로 솔트 처리된 경우는 예외입니다. 해싱만으로는 추측 가능한 입력 값을 탐색하는 것을 막을 수 없기 때문입니다. 사용자 핸들은 64바이트의 무작위 값으로 하고 이 값을 사용자 계정에 저장하는 것이 권장됩니다.

14.6.2. 사용자 이름 열거

등록 또는 인증 절차를 시작할 때 WebAuthn 신뢰 당사자가 등록된 사용자에 대한 민감한 정보를 유출할 위험이 있습니다. 예를 들어 신뢰 당사자가 이메일 주소를 사용자 이름으로 사용하고 공격자가 "alex.mueller@example.com"에 대해 인증 절차를 시작하려 했을 때 신뢰 당사자가 실패로 응답하지만, 이후 "j.doe@example.com"에 대해서는 인증 절차를 성공적으로 시작한다면 공격자는 "j.doe@example.com"은 등록되어 있고 "alex.mueller@example.com"은 등록되어 있지 않다고 결론 내릴 수 있습니다. 따라서 신뢰 당사자는 "j.doe@example.com"이 이 신뢰 당사자에 사용자 계정을 가지고 있다는 잠재적으로 민감한 정보를 유출한 것입니다.

다음은 이러한 공격으로 인한 정보 유출을 완화하거나 방지하기 위해 신뢰 당사자가 구현할 수 있는 규범적이지 않고 완전하지 않은 조치 목록입니다.

등록 절차의 경우:
- 신뢰 당사자가 사용자를 식별하기 위해 신뢰 당사자별 사용자 이름을 사용하는 경우:
  - 등록 절차를 시작할 때 문법적으로 유효한 이메일 주소인 사용자 이름은 등록하지 못하도록 합니다.
    
    참고: 이 제안의 이유는 이 경우 사용자가 이미 등록된 사용자 이름을 등록하려 하면 신뢰 당사자가 등록 절차를 실패시키는 것 외에는 선택지가 없을 가능성이 높고, 따라서 정보 유출을 피할 수 없을 수 있기 때문입니다. 이메일 주소를 사용자 이름으로 허용하지 않으면 사용자가 이 신뢰 당사자와 다른 신뢰 당사자에서 동일한 사용자 이름을 사용할 가능성이 낮아지므로 유출의 영향을 완화할 수 있습니다.
- 신뢰 당사자가 사용자를 식별하기 위해 이메일 주소를 사용하는 경우:
  - 등록 절차를 시작할 때 이메일 주소가 입력된 후 사용자 상호 작용을 중단하고 예측할 수 없는 일회용 코드와 이를 사용하여 절차를 계속하는 방법에 대한 지침을 포함한 메시지를 해당 주소로 보냅니다. 전송된 이메일의 내용이나 해당 이메일 주소가 이미 등록되어 있는지 여부와 관계없이 웹 인터페이스에서는 동일한 메시지를 사용자에게 표시합니다.
    
    참고: 이 제안은 예를 들어 주민등록번호나 신용카드 번호처럼 외부적으로 의미 있는 다른 식별자에도 유사하게 적용할 수 있습니다. 단, 예를 들어 일반 우편 주소와 같은 유사한 대역 외 연락 정보를 제공하는 경우에 해당합니다.
인증 절차의 경우:
- 인증 절차를 시작할 때 제공된 사용자 이름과 일치하는 사용자 계정이 없다면, 그럴듯한 가상 값으로 채운 문법적으로 유효한 PublicKeyCredentialRequestOptions 객체를 사용하여 navigator.credentials.get()을 호출해 절차를 계속합니다.
  
  이 접근 방식은 allowCredentials를 통한 정보 유출을 완화하는 데도 사용할 수 있습니다. § 13.5.7 보호되지 않은 계정 탐지 및 § 14.6.3 자격 증명 ID를 통한 개인정보 유출을 참조하십시오.
  
  참고: 사용자 이름은 로그인 양식, 세션 쿠키 등 다양한 신뢰 당사자별 방식으로 "제공"될 수 있습니다.
  
  참고: 반환되는 가상 값이 실제 값과 눈에 띄게 다르면 영리한 공격자가 이를 구별하여 실제 계정의 존재 여부를 검사할 수 있습니다. 눈에 띄게 다른 값의 예로는 모든 사용자 이름 입력에 대해 값이 항상 동일하거나, 동일한 사용자 이름 입력으로 반복 시도할 때 값이 서로 다른 경우가 있습니다. 따라서 예를 들어 allowCredentials 멤버를 사용자 이름에서 결정적으로 파생한 의사 무작위 값으로 채울 수 있습니다.
- 인증자에서 받은 AuthenticatorAssertionResponse 응답을 검증할 때 서명이 유효하지 않아 검증에 실패한 경우와 해당 사용자 또는 자격 증명이 등록되어 있지 않아 실패한 경우를 구별할 수 없도록 합니다.
- 다단계 인증 절차를 수행합니다. 예를 들어 사용자 이름과 암호 또는 세션 쿠키를 먼저 제공한 뒤, 후속 단계로 WebAuthn 절차를 시작합니다. 이렇게 하면 사용자 이름 열거 문제가 WebAuthn 단계에서 그보다 앞선 인증 단계로 이동하며, 그 단계에서 해결하기 더 쉬울 수 있습니다.

14.6.3. 자격 증명 ID를 통한 개인정보 유출

이 절은 규범적이지 않습니다.

이 개인정보 보호 고려사항은 첫 번째 인증 단계에서 비어 있지 않은 allowCredentials 인수를 사용하는 인증 절차를 지원하는 신뢰 당사자에 적용됩니다. 예를 들어 서버 측 자격 증명을 사용하는 인증을 첫 번째 인증 단계로 사용하는 경우입니다.

이 경우 allowCredentials 인수는 인증되지 않은 호출자에게 사용자의 자격 증명 ID를 노출하므로 개인 식별 정보가 유출될 위험이 있습니다. 자격 증명 ID는 신뢰 당사자 간에 연관될 수 없도록 설계되었지만, 자격 증명 ID의 길이는 어떤 유형의 인증자가 이를 생성했는지에 대한 단서가 될 수 있습니다. 사용자는 여러 신뢰 당사자에서 동일한 사용자 이름과 동일한 인증자 집합을 사용할 가능성이 높으므로 allowCredentials에 포함된 자격 증명 ID의 개수와 길이는 사용자의 익명성을 해제하는 전역 연관 핸들로 사용될 수 있습니다. 사용자의 자격 증명 ID를 알고 있으면 사용자의 인증자 중 하나에 잠시 물리적으로 접근하는 것만으로도 사용자의 신원에 대한 추측을 확인할 수 있습니다.

이러한 정보 유출을 방지하기 위해 신뢰 당사자는 예를 들어 다음을 수행할 수 있습니다.

WebAuthn 인증 절차를 시작하고 사용자의 자격 증명 ID를 노출하기 전에 사용자 이름 및 암호 인증이나 세션 쿠키 인증과 같은 별도의 인증 단계를 수행합니다.
클라이언트 측에서 검색 가능한 자격 증명을 사용하여 allowCredentials 인수가 필요하지 않도록 합니다.

위의 방지 조치를 사용할 수 없다면, 즉 사용자 이름만 제공된 상태에서 allowCredentials를 노출해야 한다면 신뢰 당사자는 § 14.6.2 사용자 이름 열거에서 설명한 것과 동일하게 가상의 자격 증명 ID를 반환하는 방식을 사용하여 개인정보 유출을 완화할 수 있습니다.

자격 증명 ID가 인식되지 않았다고 알릴 때 WebAuthn 신뢰 당사자는 인증되지 않은 호출자에게 자격 증명 ID를 노출하지 않도록 signalAllAcceptedCredentials(options) 메서드 대신 signalUnknownCredential(options) 메서드를 사용하는 것이 좋습니다.

15. 접근성 고려사항

사용자 검증 기능이 있는 인증자는 로밍형이든 플랫폼형이든 사용자에게 두 가지 이상의 사용자 검증 방법을 제공하는 것이 좋습니다. 예를 들어 지문 감지와 PIN 입력을 모두 제공할 수 있습니다. 이를 통해 선택한 방식이 어떤 이유로 작동하지 않을 경우 다른 사용자 검증 수단으로 대체할 수 있습니다. 로밍 인증자의 경우 인증자와 플랫폼이 함께 작동하여 PIN 입력과 같은 사용자 검증 방법을 제공할 수 있다는 점에 유의하십시오 [FIDO-CTAP].

신뢰 당사자는 등록 시 사용자가 향후 승인 제스처를 올바르게 완료할 수 있도록 수단을 제공하는 것이 좋습니다. 여기에는 인증자에 이름을 지정하거나 기기와 연결할 그림을 선택하거나 자유 형식의 텍스트 지침 (예: 자신을 위한 알림)을 입력하는 방법 등이 포함될 수 있습니다.

15.1. 절차 시간 제한의 권장 범위

절차 중 시간에 의존하는 것, 예를 들어 등록 절차(timeout 참조) 또는 인증 절차(timeout 참조)는 [WCAG21]의 지침 2.2 충분한 시간을 따르는 것이 좋습니다. 클라이언트 플랫폼이 신뢰 당사자가 제공한 시간 제한이 앞서 언급한 [WCAG21] 지침을 적절히 따르지 않는다고 판단하면 클라이언트 플랫폼은 그에 맞게 시간 제한을 조정할 수 있습니다.

WebAuthn 절차 시간 제한의 권장 범위 및 기본값은 다음과 같습니다.

권장 범위: 300000밀리초에서 600000밀리초.
권장 기본값: 300000밀리초(5분).

16. 테스트 벡터

이 절은 규범적이지 않습니다.

이 절에서는 구현을 검증하는 데 사용할 수 있는 예제 값을 나열합니다.

예제는 동일한 자격 증명으로 수행한 등록 및 인증 절차 쌍을 의사 코드로 제공하며 바이트 문자열 리터럴과 주석은 CDDL [RFC8610] 표기법을 사용합니다. 예제는 완전하지 않으며 WebAuthn 확장을 포함하지 않습니다.

예제는 일부 중간 값을 포함하여 입력에서 출력으로 이어지는 흐름으로 구성되어 있습니다. 등록 예제에서는 신뢰 당사자가 challenge 입력을 정의하고, 클라이언트가 clientDataJSON 출력을 생성하며 인증자가 attestationObject 출력을 생성합니다. 인증 예제에서는 신뢰 당사자가 challenge 입력을 정의하고, 클라이언트가 clientDataJSON 출력을 생성하며 인증자가 authenticatorData 및 signature 출력을 생성합니다. 암호학적으로 관련이 없는 다른 입력과 출력은 포함하지 않습니다.

인증자 구현자는 유사하게 구성된 attestationObject, authenticatorData 및 signature 출력을 생성하는지 확인할 수 있습니다. 클라이언트 구현자는 유사하게 구성된 clientDataJSON 출력을 생성하는지 확인할 수 있습니다. 신뢰 당사자 구현자는 동일한 challenge 입력이 주어졌을 때 등록 출력을 성공적으로 검증할 수 있는지, 그리고 동일한 challenge 입력과 관련 등록 예제의 자격 증명 공개 키 및 자격 증명 ID가 주어졌을 때 인증 출력을 성공적으로 검증할 수 있는지 확인할 수 있습니다.

모든 예제는 RP ID example.org, origin https://example.org 및 해당하는 경우 topOrigin https://example.com을 사용합니다. 달리 명시하지 않는 한 예제에는 증명 없음이 포함됩니다. clientDataJSON, attestationObject, 증명 인증서와 같은 복합 객체에는 의사 코드에서 명시적으로 언급되지 않은 추가적인, 일반적으로 상수인 데이터가 포함될 수 있습니다.

모든 무작위 값은 CDDL에서 'WebAuthn test vectors'로 표기되거나 이와 동등하게 h'576562417574686e207465737420766563746f7273'로 표기되는 기본 입력 키 자료로부터 HKDF-SHA-256 [RFC5869]을 사용하여 결정적으로 생성됩니다. ECDSA 서명은 결정적 nonce [RFC6979]를 사용합니다. 예제의 RSA 키는 p ≥ 1024를 만족하는 가장 작은 두 메르센 소수 2^p - 1로 구성됩니다.

다음 사항에 유의하십시오.

예제에는 재현성을 위해 자격 증명 개인 키 및 증명 개인 키가 포함되지만, 일반적으로 이들은 클라이언트 또는 신뢰 당사자와 공유되지 않습니다.
각 예제에서 서로 다른 AAGUID를 사용하지만, 주어진 인증자에 대해서는 일반적으로 AAGUID가 일정합니다.

참고: CTAP2 [FIDO-CTAP]를 구현하는 인증자는 이 명세에 정의된 것과 다른 키를 사용하여 증명 객체를 반환합니다. 이 예제는 WebAuthn 신뢰 당사자가 예상하는 증명 객체 형식을 나타내므로, CTAP2에서 생성된 증명 객체는 이 예제와 비트 단위로 동일해지도록 키를 변환해야 합니다.

16.1. 증명 신뢰 루트 인증서

증명을 포함하는 모든 예제는 아래에 attestation_ca_cert로 주어진 증명 신뢰 루트 인증서를 사용하며, X.509 DER [RFC5280]로 인코딩됩니다.

attestation_ca_key = h'7809337f05740a96a78eedf9e9280499dcc8f2aa129616049ec1dccfe103eb2a'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='Attestation CA', L=32)
attestation_ca_serial_number = h'ed7f905d8bd0b414d1784913170a90b6'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='Attestation CA', L=16)
attestation_ca_cert = h'30820207308201ada003020102021100ed7f905d8bd0b414d1784913170a90b6300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a3062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d030107034200043269300e5ff7b699015f70cf80a8763bf705bc2e2af0c1b39cff718b7c35880ca30f319078d91b03389a006fdfc8a1dcd84edfa07d30aa13474a248a0dab5baaa3423040300f0603551d130101ff040530030101ff300e0603551d0f0101ff040403020106301d0603551d0e0416041445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d04030203480030450220483063b6bb08dcc83da33a02c11d2f42203176893554d138c614a36908724cc8022100f5ef2c912d4500b3e2f5b591d0622491e9f220dfd1f9734ec484bb7e90887663'

16.2. 증명 없는 ES256 자격 증명

등록:

challenge = h'00c30fb78531c464d2b6771dab8d7b603c01162f2fa486bea70f283ae556e130'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='none.ES256', L=32)

credential_private_key = h'6e68e7a58484a3264f66b77f5d6dc5bc36a47085b615c9727ab334e8c369c2ee'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='none.ES256', L=32)
client_data_gen_flags = h'f9'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='none.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'06441e0e375c4c1ad70620302532c4e5' = b64'BkQeDjdcTBrXBiAwJTLE5Q'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='none.ES256', L=16)
aaguid = h'8446ccb9ab1db374750b2367ff6f3a1f'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='none.ES256', L=16)
credential_id = h'f91f391db4c9b2fde0ea70189cba3fb63f579ba6122b33ad94ff3ec330084be4'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='none.ES256', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'ba'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='none.ES256', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22414d4d507434557878475453746e63647134313759447742466938767049612d7077386f4f755657345441222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20426b5165446a646354427258426941774a544c453551227d'
attestationObject = h'a363666d74646e6f6e656761747453746d74a068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b559000000008446ccb9ab1db374750b2367ff6f3a1f0020f91f391db4c9b2fde0ea70189cba3fb63f579ba6122b33ad94ff3ec330084be4a5010203262001215820afefa16f97ca9b2d23eb86ccb64098d20db90856062eb249c33a9b672f26df61225820930a56b87a2fca66334b03458abf879717c12cc68ed73290af2e2664796b9220'

인증:

challenge = h'39c0e7521417ba54d43e8dc95174f423dee9bf3cd804ff6d65c857c9abf4d408'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='none.ES256', L=32)

client_data_gen_flags = h'4a'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='none.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'38'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='none.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a224f63446e55685158756c5455506f334a5558543049393770767a7a59425039745a63685879617630314167222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3046022100f50a4e2e4409249c4a853ba361282f09841df4dd4547a13a87780218deffcd380221008480ac0f0b93538174f575bf11a1dd5d78c6e486013f937295ea13653e331e87'

16.3. 자체 증명이 있는 ES256 자격 증명

등록:

challenge = h'7869c2b772d4b58eba9378cf8f29e26cf935aa77df0da89fa99c0bdc0a76f7e5'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed-self.ES256', L=32)

credential_private_key = h'b4bbfa5d68e1693b6ef5a19a0e60ef7ee2cbcac81f7fec7006ac3a21e0c5116a'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed-self.ES256', L=32)
client_data_gen_flags = h'db'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed-self.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'53d8535ef284d944643276ffd3160756' = b64'U9hTXvKE2URkMnb_0xYHVg'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed-self.ES256', L=16)
aaguid = h'df850e09db6afbdfab51697791506cfc'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed-self.ES256', L=16)
credential_id = h'455ef34e2043a87db3d4afeb39bbcb6cc32df9347c789a865ecdca129cbef58c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed-self.ES256', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'fd'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed-self.ES256', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a2265476e4374334c55745936366b336a506a796e6962506b31716e666644616966715a774c33417032392d55222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a205539685458764b453255526b4d6e625f307859485667227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a263616c672663736967584630440220067a20754ab925005dbf378097c92120031581c73228d1fb4f5b881bcd7da98302207fc7b147558c7c0eba3af18bd9d121fa3d3a26d17fe3f220272178f473b6006d68617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b55d00000000df850e09db6afbdfab51697791506cfc0020455ef34e2043a87db3d4afeb39bbcb6cc32df9347c789a865ecdca129cbef58ca5010203262001215820eb151c8176b225cc651559fecf07af450fd85802046656b34c18f6cf193843c5225820927b8aa427a2be1b8834d233a2d34f61f13bfd44119c325d5896e183fee484f2'

인증:

challenge = h'4478a10b1352348dd160c1353b0d469b5db19eb91c27f7dfa6fed39fe26af20b'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed-self.ES256', L=32)

client_data_gen_flags = h'1f'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed-self.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'8136f9debcfa121496a265c6ce2982d5' = b64'gTb53rz6EhSWomXGzimC1Q'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed-self.ES256', L=16)
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'a1'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed-self.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a225248696843784e534e493352594d45314f7731476d3132786e726b634a5f6666707637546e2d4a71386773222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a206754623533727a36456853576f6d58477a696d433151227d'
signature = h'304402203310b9431903c401f1be2bdc8d23a4007682dbbddcf846994947b7f465daf84002204e94dd00047b316061b3b99772b7efd95994a83ef584b3b6b825ea3550251b66'

16.4. clientDataJSON에 "crossOrigin": true가 있는 ES256 자격 증명

등록:

challenge = h'3be5aacd03537142472340ab5969f240f1d87716e20b6807ac230655fa4b3b49'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='none.ES256.crossOrigin', L=32)

credential_private_key = h'96c940e769bd9f1237c119f144fa61a4d56af0b3289685ae2bef7fb89620623d'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='none.ES256.crossOrigin', L=32)
client_data_gen_flags = h'71'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='none.ES256.crossOrigin', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'cd9aae12d0d1f435aaa56e6d0564c5ba' = b64'zZquEtDR9DWqpW5tBWTFug'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='none.ES256.crossOrigin', L=16)
aaguid = h'883f4f6014f19c09d87aa38123be48d0'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='none.ES256.crossOrigin', L=16)
credential_id = h'6e1050c0d2ca2f07c755cb2c66a74c64fa43065c18f938354d9915db2bd5ce57'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='none.ES256.crossOrigin', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'27'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='none.ES256.crossOrigin', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a224f2d57717a514e5463554a484930437257576e7951504859647862694332674872434d475666704c4f306b222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a747275652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a207a5a7175457444523944577170573574425754467567227d'
attestationObject = h'a363666d74646e6f6e656761747453746d74a068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54500000000883f4f6014f19c09d87aa38123be48d000206e1050c0d2ca2f07c755cb2c66a74c64fa43065c18f938354d9915db2bd5ce57a501020326200121582022200a473f90b11078851550d03b4e44a2279f8c4eca27b3153dedfe03e4e97d225820cbd0be95e746ad6f5a8191be11756e4c0420e72f65b466d39bc56b8b123a9c6e'

인증:

challenge = h'876aa517ba83fdee65fcffdbca4c84eeae5d54f8041a1fc85c991e5bbb273137'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='none.ES256.crossOrigin', L=32)

client_data_gen_flags = h'57'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='none.ES256.crossOrigin', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'f76a5c4d50f401bcbeab876d9a3e9e7e' = b64'92pcTVD0Aby-q4dtmj6efg'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='none.ES256.crossOrigin', L=16)
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'0c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='none.ES256.crossOrigin', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50500000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a226832716c463771445f65356c5f505f62796b7945377135645650674547685f49584a6b655737736e4d5463222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a747275652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a2039327063545644304162792d713464746d6a36656667227d'
signature = h'3046022100eb12fcf23b12764c0f122e22371fab92e283879fd798f38ee1841c951b6e40e7022100c76237ff9db77b3c56f30837cda6a09acfa2e915544e609c0733b1184036d1cf'

16.5. clientDataJSON에 "topOrigin"이 있는 ES256 자격 증명

등록:

challenge = h'4e1f4c6198699e33c14f192153f49d7e0e8e3577d5ac416c5f3adc92a41f27e5'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='none.ES256.topOrigin', L=32)

credential_private_key = h'a2d6de40ab974b80d8c1ef78c6d4300097754f7e016afe7f8ea0ad9798b0d420'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='none.ES256.topOrigin', L=32)
client_data_gen_flags = h'54'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='none.ES256.topOrigin', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
aaguid = h'97586fd09799a76401c200455099ef2a'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='none.ES256.topOrigin', L=16)
credential_id = h'b8ad59b996047ab18e2ceb57206c362da57458793481f4a8ebf101c7ca7cc0f1'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='none.ES256.topOrigin', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'a0'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='none.ES256.topOrigin', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a225468394d595a68706e6a504254786b68555f53646667364f4e58665672454673587a72636b7151664a2d55222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a747275652c22746f704f726967696e223a2268747470733a2f2f6578616d706c652e636f6d227d'
attestationObject = h'a363666d74646e6f6e656761747453746d74a068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b5410000000097586fd09799a76401c200455099ef2a0020b8ad59b996047ab18e2ceb57206c362da57458793481f4a8ebf101c7ca7cc0f1a5010203262001215820a1c47c1d82da4ebe82cd72207102b380670701993bc35398ae2e5726427fe01d22582086c1080d82987028c7f54ecb1b01185de243b359294a0ed210cd47480f0adc88'

인증:

challenge = h'd54a5c8ca4b62a8e3bb321e3b2bc73856f85a10150db2939ac195739eb1ea066'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='none.ES256.topOrigin', L=32)

client_data_gen_flags = h'77'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='none.ES256.topOrigin', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'52216824c5514070c0156162e2fc54a5' = b64'UiFoJMVRQHDAFWFi4vxUpQ'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='none.ES256.topOrigin', L=16)
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'9f'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='none.ES256.topOrigin', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50500000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22315570636a4b53324b6f34377379486a7372787a68572d466f51465132796b3572426c584f6573656f4759222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a747275652c22746f704f726967696e223a2268747470733a2f2f6578616d706c652e636f6d222c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a205569466f4a4d56525148444146574669347678557051227d'
signature = h'3045022100b5a70c81780d5fcc9a4f2ae9caae99058f8accaf58b91fb59329646c28ac6ffc022012e101c165db3c8e9957f0c54dd6ca9b56bc3bd2f280bd2faa6c1d02c6e5c171'

16.6. 매우 긴 자격 증명 ID가 있는 ES256 자격 증명

등록:

challenge = h'1113c7265ccf5e65124282fa1d7819a7a14cb8539aa4cdbec7487e5f35d8ec6c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='none.ES256.long-credential-id', L=32)

credential_private_key = h'6fd2149bb5f1597fe549b138794bde61893b2dc32ca316de65f04808dac211dc'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='none.ES256.long-credential-id', L=32)
client_data_gen_flags = h'90'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='none.ES256.long-credential-id', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
aaguid = h'8f3360c2cd1b0ac14ffe0795c5d2638e'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='none.ES256.long-credential-id', L=16)
credential_id = h'3a761a4e1674ad6c4305869435c0eee9c286172c229bb91b48b4ada140c0863417031305cce5b4a27a88d7fe728a5f5a627de771b4b40e77f187980c124f9fe832d7136010436a056cce716680587d23187cf1fc2c62ae86fc3e508ee9617ffc74fbc10488ec16ec5e9096328669a898709b655e549738c666c1ae6281dc3b5f733c251d3eefb76ee70a3805ca91bcc18e49c8dc7f63ebcb486ba8c3d6ab52b88ff72c6a5bb47c32f3ee8683a3ddc8abf60870448ec8a21b5bdcb183c7dead870255575a6df96eb1b6a2a1019780cba9e4887b17ff1164bbbcc10eb0d86ed75984cd3fa3419103024507dfd9ce8f92c56af7914cb0bb50b87ba82a312bb7dcd93028dbdcd6adb266979667158335171e3682d37755701edbf9d872846a291d49e57ef09da1ec637f5052ed2aa7407f7e61827468e94b461844f4c67be5fa9c6055a566f8fdfc29d4bf78a9ff275f552cc68ba543fa3962eea36fd1ea8453764577d021d0a181efc1f6100ab2e4110039e21ee16970bda7432b6134492155afc126295b3a2eccd12c66a68e340969e995e3e8c9c476e395cfc21203414110779474f1c9797406637dbe414f132519d3bf0ce4f01734ef0e1a12c3ad604ff15d766b1624db6a5a7ccbff7bc35c9908df94aba277e0af48f04ff3d16381c47e5a37ed3988a67a3b1ecaa926336b33391fff04128f869991c9fabd905b6fe3ceef5f8b630ec1c5d2636d5b1961ad5ca5004170f6f5e482792aad989b0287fe91e5c479403397152f1fa56aa79b156eb47e6c8ea3eb175c34cfb38ad8e772874639b1023d4d01395c94e55831671cc022aa6fa1e02a02c2e4abc776f6960e51f83b71a8c0f207b6a347573977812c9aa5480b0011aa739bd4b76c18c000cc4757cceccb920f007c40c00e37e5ab21476cd9f6054a8fffb55a108f5c706e2cea2049d81fd321ff47d2a5761b0800955ab1d4f4889f55a84e2601c684f17a4ade7453ea49591d0b59c8d9a765052f62219cf6ef4a5dd9539f0617d6ebbebce7c000455475d18449e25c49ef9a1e3efe18c09082ebe2058d7c347defaa92f0664553b805c7d76bbfce5f330aca220ac90a789380fc479ea0d8793205813cca590a912f699ad52f991a1bc0a503c3ec4b2a696719e3c26591a87127f7305cc7e72f4c8e39355ebb06a5b1042990f38710ee7aa612ee4374bb82e878585a70a96c2a6b47f101a4ff154be4fd76a3167577a5cc54d9167c154c69ac35485e44cc898b719e1be3cc9c0fb5624b8f8a0dae10947a41bf848b6c1bb33d1006ec077d7e286e3f2a7b4843716390119449fe2721e81a5ed2333d331c7120765da58fadae73c19d9a8c4509cf8ac1e9d98b799a5274509069739b5823f3fb496663820033426988eefca53e580e0f9e0dfe0992fc2e53a97e053639f98577058f995bdbd41cefdb'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='none.ES256.long-credential-id', L=1023)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'69'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='none.ES256.long-credential-id', L=1)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22455250484a6c7a50586d5553516f4c364858675a7036464d75464f61704d322d7830682d587a5859374777222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d74646e6f6e656761747453746d74a0686175746844617461590483bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b549000000008f3360c2cd1b0ac14ffe0795c5d2638e03ff3a761a4e1674ad6c4305869435c0eee9c286172c229bb91b48b4ada140c0863417031305cce5b4a27a88d7fe728a5f5a627de771b4b40e77f187980c124f9fe832d7136010436a056cce716680587d23187cf1fc2c62ae86fc3e508ee9617ffc74fbc10488ec16ec5e9096328669a898709b655e549738c666c1ae6281dc3b5f733c251d3eefb76ee70a3805ca91bcc18e49c8dc7f63ebcb486ba8c3d6ab52b88ff72c6a5bb47c32f3ee8683a3ddc8abf60870448ec8a21b5bdcb183c7dead870255575a6df96eb1b6a2a1019780cba9e4887b17ff1164bbbcc10eb0d86ed75984cd3fa3419103024507dfd9ce8f92c56af7914cb0bb50b87ba82a312bb7dcd93028dbdcd6adb266979667158335171e3682d37755701edbf9d872846a291d49e57ef09da1ec637f5052ed2aa7407f7e61827468e94b461844f4c67be5fa9c6055a566f8fdfc29d4bf78a9ff275f552cc68ba543fa3962eea36fd1ea8453764577d021d0a181efc1f6100ab2e4110039e21ee16970bda7432b6134492155afc126295b3a2eccd12c66a68e340969e995e3e8c9c476e395cfc21203414110779474f1c9797406637dbe414f132519d3bf0ce4f01734ef0e1a12c3ad604ff15d766b1624db6a5a7ccbff7bc35c9908df94aba277e0af48f04ff3d16381c47e5a37ed3988a67a3b1ecaa926336b33391fff04128f869991c9fabd905b6fe3ceef5f8b630ec1c5d2636d5b1961ad5ca5004170f6f5e482792aad989b0287fe91e5c479403397152f1fa56aa79b156eb47e6c8ea3eb175c34cfb38ad8e772874639b1023d4d01395c94e55831671cc022aa6fa1e02a02c2e4abc776f6960e51f83b71a8c0f207b6a347573977812c9aa5480b0011aa739bd4b76c18c000cc4757cceccb920f007c40c00e37e5ab21476cd9f6054a8fffb55a108f5c706e2cea2049d81fd321ff47d2a5761b0800955ab1d4f4889f55a84e2601c684f17a4ade7453ea49591d0b59c8d9a765052f62219cf6ef4a5dd9539f0617d6ebbebce7c000455475d18449e25c49ef9a1e3efe18c09082ebe2058d7c347defaa92f0664553b805c7d76bbfce5f330aca220ac90a789380fc479ea0d8793205813cca590a912f699ad52f991a1bc0a503c3ec4b2a696719e3c26591a87127f7305cc7e72f4c8e39355ebb06a5b1042990f38710ee7aa612ee4374bb82e878585a70a96c2a6b47f101a4ff154be4fd76a3167577a5cc54d9167c154c69ac35485e44cc898b719e1be3cc9c0fb5624b8f8a0dae10947a41bf848b6c1bb33d1006ec077d7e286e3f2a7b4843716390119449fe2721e81a5ed2333d331c7120765da58fadae73c19d9a8c4509cf8ac1e9d98b799a5274509069739b5823f3fb496663820033426988eefca53e580e0f9e0dfe0992fc2e53a97e053639f98577058f995bdbd41cefdba50102032620012158203b8176b7504489cc593046d7988abb7905a742de6ac2cdc748a873c663e90cb12258201436d5edc9a75f23999eef9d5950a5c2455514ee1014084720f841a06b828a11'

인증:

challenge = h'ef1deba56dce48f674a447ccf63b9599258ce87648e5c396f2ef0ca1da460e3b'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='none.ES256.long-credential-id', L=32)

client_data_gen_flags = h'80'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='none.ES256.long-credential-id', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'e5'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='none.ES256.long-credential-id', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22377833727057334f53505a307045664d396a75566d53574d36485a4935634f573875384d6f647047446a73222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'304502203ecef83fb12a0cae7841055f9f87103a99fd14b424194bbf06c4623d3ee6e3fd022100d2ace346db262b1374a6b70faa51f518a42ddca13a4125ce6f5052a75bac9fb6'

16.7. ES256 자격 증명을 사용한 Packed 증명

등록:

challenge = h'c1184a5fddf8045e13dc47f54b61f5a656b666b59018f16d870e9256e9952012'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.ES256', L=32)

credential_private_key = h'36ed7bea2357cefa8c4ec7e134f3312d2e6ca3058519d0bcb4c1424272010432'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.ES256', L=32)
client_data_gen_flags = h'8d'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'f5af1b3588ca0a05ab05753e7c29756a' = b64'9a8bNYjKCgWrBXU-fCl1ag'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.ES256', L=16)
aaguid = h'876ca4f52071c3e9b25509ef2cdf7ed6'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.ES256', L=16)
credential_id = h'c9a6f5b3462d02873fea0c56862234f99f081728084e511bb7760201a89054a5'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.ES256', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'4f'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.ES256', L=1)
attestation_private_key = h'ec2804b222552b4b277d1f58f8c4343c0b0b0db5474eb55365c89d66a2bc96be'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.ES256', L=32)
attestation_cert_serial_number = h'88c220f83c8ef1feafe94deae45faad0'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a227752684b58393334424634543345663153324831706c61325a725751475046746877365356756d56494249222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20396138624e596a4b436757724258552d66436c316167227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c6726637369675847304502203f19ec4b229f46ab8c45eff29b904ff10c0390dc40bf1216f04a78f4ceba3425022100fe7041a32759aff05a0f9f26c70a999c7a284451ba89234a1d3483c25e21925b637835638159022530820221308201c8a00302010202110088c220f83c8ef1feafe94deae45faad0300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004a91ba4389409dd38a428141940ca8feb1ac0d7b4350558104a3777a49322f3798440f378b3398ab2d3bb7bf91322c92eb23556f59ad0a836fec4c7663b0e4dc3a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414a589ba72d060842ab11f74fb246bdedab16f9b9b301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d040302034700304402201726b9d85ecd8a5ed51163722ca3a20886fd9b242a0aa0453d442116075defd502207ef471e530ac87961a88a7f0d0c17b091ffc6b9238d30f79f635b417be5910e768617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54d00000000876ca4f52071c3e9b25509ef2cdf7ed60020c9a6f5b3462d02873fea0c56862234f99f081728084e511bb7760201a89054a5a50102032620012158201cf27f25da591208a4239c2e324f104f585525479a29edeedd830f48e77aeae522582059e4b7da6c0106e206ce390c93ab98a15a5ec3887e57f0cc2bece803b920c423'

인증:

challenge = h'b1106fa46a57bef1781511c0557dc898a03413d5f0f17d244630c194c7e1adb5'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.ES256', L=32)

client_data_gen_flags = h'75'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'019330c8cc486c3f3eba0b85369eabf1' = b64'AZMwyMxIbD8-uguFNp6r8Q'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.ES256', L=16)
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'46'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0c', info='packed.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a2273524276704770587676463446524841565833496d4b4130453958773858306b526a44426c4d6668726255222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20415a4d77794d78496244382d756775464e7036723851227d'
signature = h'30450220694969d3ee928de6f02ef23a9c644d7d779916451734a94b432542f498a1ebe90221008b0819c824218a97152cd099c55bfb1477b29d900a49a64018314f9bfccda163'

16.8. ES384 자격 증명을 사용한 Packed 증명

등록:

challenge = h'567b030b3e186bc1d169dd45b79f9e0d86f1fd63474da3eade5bdb8db379a0c3'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.ES384', L=32)

credential_private_key = h'271e37d309c558c0f35222b37abba7500377d68e179e4c74b0cb558551b2e5276b47b90a317ca8ebbe1a12c93c2d5dd9'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.ES384', L=48)
client_data_gen_flags = h'32'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.ES384', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
aaguid = h'e950dcda3bdae1d087cda380a897848b'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.ES384', L=16)
credential_id = h'953ae2dd9f28b1a1d5802c83e1f65833bb9769a08de82d812bc27c13fc6f06a9'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.ES384', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'db'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.ES384', L=1)
attestation_private_key = h'8d979fbb6e49c4eeb5925a2bca0fcdb023d3fb90bcadce8391da9da4ed2aee9a'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.ES384', L=32)
attestation_cert_serial_number = h'3d0a5588bb87ebb1d4cee4a1807c1b7c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.ES384', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22566e7344437a3459613848526164314674352d65445962785f574e4854615071336c76626a624e356f4d4d222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758473045022100c56ecc970b7843833e0f461fde26233f61eb395161d481558c08b9c6ed61675b022029f5e05033705cd0f9b0a07e149468ec308a4f84906409efdceb1da20a7518d6637835638159022530820221308201c7a00302010202103d0a5588bb87ebb1d4cee4a1807c1b7c300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d0301070342000417e5cc91d676d370e36aa7de40c25aacb45a3845f13d2932088ece2270b9b431241c219c22d0c256c9438ade00f2c05e62f8ef906b9b997ae9f3c460c2db66f5a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414c7c8dd95382a2230e4c0dd3664338fa908169a9c301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020348003045022054068cc9ae038937b7c468c307edb9c6927ffdeb6a20070c483eb40330f99f10022100cf41953919c3c04693d6b1f42a613753f204e70e85fc6e9b17036170b83596e068617574684461746158c5bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b55900000000e950dcda3bdae1d087cda380a897848b0020953ae2dd9f28b1a1d5802c83e1f65833bb9769a08de82d812bc27c13fc6f06a9a5010203382220022158304866bd8b01da789e9eb806e5eab05ae5a638542296ab057a2f1bbce9b58f8a08b9171390b58a37ac7fffc2c5f45857da2258302a0b024c7f4b72072a1f96bd30a7261aae9571dd39870eb29e55c0941c6b08e89629a1ea1216aa64ce57c2807bf3901a'

인증:

challenge = h'ff41c3d25dbd8966fb61e28ef5e47041e137ed268520412d76202ba0ad2d1453'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.ES384', L=32)

client_data_gen_flags = h'0c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.ES384', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'af'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.ES384', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a225f304844306c32396957623759654b4f39655277516545333753614649454574646941726f4b307446464d222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3065023100e4efbb46745ed00e67c4d51ab2bacab2af62ffa8b7c5fecec6d7d9bf2582275034a713a3dd731685eee81adfaf6aa63f0230161655353f07e018a3c2539f8de7c8c4cf88d4c32d2be29fe4e76fa096ecc9458bbfe0895d57129ab324130e6f0692db'

16.9. ES512 자격 증명을 사용한 Packed 증명

등록:

challenge = h'4ee220cd92b07e11451cb4c201c5755bd879848e492a9b12d79135c62764dc2fd28ead4808cafe5ad1de8fa9e08d4a8eeafea4dfb333877b02bc503f475d3b0c1394a7683baaf4f2477829f7b8cf750948985558748c073068396fcfdcd3f245bf2038e6bb38d7532768aad13be8c118f727722e7426139041e9caca503884c5'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.ES512', L=128)

credential_private_key = h'f11120594f6a4944ac3ba59adbbc5b85016895b649f4cc949a610f4b48be47b318850bacb105f747647bba8852b6b8e52a0b3679f1bbbdfe18c99409bcb644fa45'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.ES512', L=65)
client_data_gen_flags = h'6d'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.ES512', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'a37a958ce2f6b535a6e06c64cc8fd082' = b64'o3qVjOL2tTWm4GxkzI_Qgg'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.ES512', L=16)
aaguid = h'39d8ce6a3cf61025775083a738e5c254'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.ES512', L=16)
credential_id = h'd17d5af7e3f37c56622a67c8462c9e1c6336dfccb8b61d359dc47378dba58ce4'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.ES512', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'cf'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.ES512', L=1)
attestation_private_key = h'ffbc89d5f75994f52dc5e7538ee269402d26995d40c16fb713473e34fca98be4'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.ES512', L=32)
attestation_cert_serial_number = h'8a128b7ebe52b993835779e6d9b81355'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.ES512', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22547549677a5a4b7766684646484c544341635631573968356849354a4b707353313545317869646b33435f536a713149434d722d577448656a366e676a55714f3676366b33374d7a683373437646415f5231303744424f5570326737717654795233677039376a5064516c496d465659644977484d47673562385f63305f4a46767941343572733431314d6e614b72524f2d6a424750636e636935304a684f5151656e4b796c4134684d55222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a206f3371566a4f4c327454576d3447786b7a495f516767227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758473045022100ce158f6c04aa5c14c0dd3e1103cf93664896fb5c337a66dbd7dba31546ff0d41022071cbcd0d3b8e218a6d05374e0ef8031329d25059002ac1603d02d5fd8a0a29cb637835638159022730820223308201c8a0030201020211008a128b7ebe52b993835779e6d9b81355300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004940b68885291536e2f7c60c05acfb252e7eebcf4304425dd93ab7b1962f20492bf18dc0f12862599e81fb764ac92151f9a78fcbb35d7a26c8c52949b18133c06a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604143ffad863abcd3dc5717b8a252189f41af97e7f31301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100832c8b64c4f0188bd32e1bec63e13301cdc03165d3ef840d1f3dabb9a5719f83022100add57a9d5bedec98f29222dfc97ea795d055ee13a02a153d02be9ce00aedeb9168617574684461746158e9bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54d0000000039d8ce6a3cf61025775083a738e5c2540020d17d5af7e3f37c56622a67c8462c9e1c6336dfccb8b61d359dc47378dba58ce4a5010203382320032158420083240a2c3ad21a3dc0a6daa3d8bc05a46d7cd9825ba010ae2a22686c2d6d663d7d5f678987fb1e767542e63dc197ae915e25f8ee284651af29066910a2cc083f50225842017337df47ab5cce5d716ef8caffa97a3012689b1f326ea6c43a1ba9596c72f71f0122390143552b42be772b4c35ffb961220c743b486a601ea4cb6d5412f5b078d3'

인증:

challenge = h'08d3190c6dcb3d4f0cb659a0333bf5ea124ddf36a0cd33d5204b0d7a22a8cc26f2e4f169d200285c77b3fb22e0f1c7f49a87d4be2d25e92d797808ddaaa9b5715efd3a6ada9339d3052a687dbc5d2f8c871b0451e0691f57ad138541b7b72e7aa8933729ec1c664bf2e4dedae1616d08ecefa80a2a53b103663ce5a881048829'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.ES512', L=128)

client_data_gen_flags = h'ac'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.ES512', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'52'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.ES512', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22434e4d5a4447334c5055384d746c6d674d7a763136684a4e337a61677a5450564945734e65694b6f7a436279355046703067416f5848657a2d794c67386366306d6f66557669306c3653313565416a6471716d31635637394f6d72616b7a6e544253706f666278644c3479484777525234476b66563630546855473374793536714a4d334b6577635a6b7679354e376134574674434f7a7671416f71553745445a6a7a6c7149454569436b222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3081870242009bda02fe384e77bcb9fb42b07c395b7a53ec9d9616dd0308ab8495c2141c8364c7d16e212a4a4fb8e3987ff6c99eafd64d8484fd28c3fc7968f658a9033d1bb1b802416383e9f3ee20c691b66620299fef36bea2df4d39c92b2ead92f58e7b79ab0d9864d2ebf3b0dcc66ea13234492ccee6e9d421db43c959bcb94c162dc9494136c9f6'

16.10. RS256 자격 증명을 사용한 Packed 증명

등록:

challenge = h'bea8f0770009bd57f2c0df6fea9f743a27e4b61bbe923c862c7aad7a9fc8e4a6'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.RS256', L=32)

; p >= 1024인 가장 작은 두 메르센 소수 2^p - 1
private_key_p = 2^1279 - 1 = h'7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
private_key_q = 2^2203 - 1 = h'07ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
client_data_gen_flags = h'1c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.RS256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
aaguid = h'428f8878298b9862a36ad8c7527bfef2'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.RS256', L=16)
credential_id = h'992a18acc83f67533600c1138a4b4c4bd236de13629cf025ed17cb00b00b74df'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.RS256', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'7e'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.RS256', L=1)
attestation_private_key = h'08a1322d5aa5b5b40cd67c2cc30b038e7921d7888c84c342d50d79f0c5fc3464'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.RS256', L=32)
attestation_cert_serial_number = h'1f6fb7a5ece81b45896b983a995da5f3'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.RS256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a2276716a776477414a76566679774e3976367039304f69666b7468752d6b6a79474c48717465705f49354b59222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c672663736967584730450221008b8c5c6ea8c142c032e0be69e1353d44461c5c9109941cdda951b976eb95b6b302204d52f406c19e254b3ff9589bd18070fb055ac8db12fdd0a6734bea9d7168e900637835638159022630820222308201c7a00302010202101f6fb7a5ece81b45896b983a995da5f3300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004b7b36b7542a11120b443c794d0c99fdc25a06b76586413d81e086163ef6fe147a557afc34e2861d9057d6d465d4705a0310550bdeeb5f35ee35b9425ab859981a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414fb37b647bccfb9e54d989eaaacc1633868703fb3301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100b86bc129d92afca7d9869a39f70f139a305b4073a39eb654d81424bed5757d91022100cf9f7c60cab7c4a7d3e7f0020f281a93d4fd0a9f95121b989f56932a68885fba68617574684461746159021bbfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b55d00000000428f8878298b9862a36ad8c7527bfef20020992a18acc83f67533600c1138a4b4c4bd236de13629cf025ed17cb00b00b74dfa4010303390100205901b403fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012143010001'

인증:

challenge = h'295f59f5fa8fe62c5aca9e27626c78c8da376ae6d8cd2dd29aebad601e1bc4c5'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.RS256', L=32)

client_data_gen_flags = h'0e'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.RS256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'ba'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.RS256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a224b56395a39667150356978617970346e596d7834794e6f33617562597a5333536d75757459423462784d55222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'01063d52d7c39b4d432fc7063c5d93e582bdcb16889cd71f888d67d880ea730a428498d3bc8e1ee11f2b1ecbe6c292b118c55ffaaddefa8cad0a54dd137c51f1eec673f1bb6c4d1789d6826a222b22d0f585fc901fdc933212e579d199b89d672aa44891333e6a1355536025e82b25590256c3538229b55737083b2f6b9377e49e2472f11952f79fdd0da180b5ffd901b4049a8f081bb40711bef76c62aed943571f2d0575304cb549d68d8892f95086a30f93716aee818f8dc06e96c0d5e0ed4cfa9fd8773d90464b68cf140f7986666ff9c9e3302acd0535d60d769f465e2ab57ef8aabc89fccfef7ba32a64154a8b3d26be2298f470b8cc5377dbe3dfd4b0b45f8f01e63bde6cfc76b62771f9b70aa27cf40152cad93aa5acd784fd4b90f676e2ea828d0bf2400aebbaae4153e5838f537f88b6228346782a93a899be66ec77de45b3efcf311da6321c92e6b0cd11bfe653bf3e98cee8e341f02d67dbb6f9c98d9e8178090cfb5b70fbc6d541599ac794ae2f1d4de1286ec8de8c2daf7b1d15c8438e90d924df5c19045220a4c8438c1b979bbe016cf3d0eeec23c3999d4882cc645b776de930756612cdc6dd398160ff02a6'

16.11. Ed25519 자격 증명을 사용한 Packed 증명

등록:

challenge = h'a8abf9dabdc6b0df63466b39bda9e8a34a34e185337a59f1c579990676d3b3bd'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.EdDSA', L=32)

private_key = h'971f38c0f73aaf0c5a614eb5e26430ae1ea0ed13e4f425d96e9662349340b0b3'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.EdDSA', L=32)
client_data_gen_flags = h'bd'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.EdDSA', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'07f0d3e60ed90fffbd3932d85f922f11' = b64'B_DT5g7ZD_-9OTLYX5IvEQ'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.EdDSA', L=16)
aaguid = h'd5aa33581e8ca478e20fe713f5d32ff2'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.EdDSA', L=16)
credential_id = h'ce9f840ed96599580cd140fbc7bb3230633f50f61041aff73308ae71caa8a2bd'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.EdDSA', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'32'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.EdDSA', L=1)
attestation_private_key = h'fbe7f950684f23afd045072a8b287ad29528707c662672850ac69733ffe0db85'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.EdDSA', L=32)
attestation_cert_serial_number = h'b2cfc9ea33c8643b0e1a760463eaf164'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.EdDSA', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22714b763532723347734e396a526d733576616e6f6f306f303459557a656c6e7878586d5a426e6254733730222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20425f44543567375a445f2d394f544c59583549764551227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758483046022100d83f60bd80269537583218858aefb03ac57d45fa06e42feaae332d187f62da9f022100a02bd3cb6f7e1d283c93bad1f3f4b5a4c0494463da7fdbf256949116754d1f17637835638159022730820223308201c8a003020102021100b2cfc9ea33c8643b0e1a760463eaf164300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004dd2b7a564b73b8c0b81c4c62e521925c4d1198ec9f583dbf1eebe364b65cd9c29a9bdf346aaa81fb6b9507e5249a52fdaf8e39e26b0b7dc45992a7e233b70f70a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604140ae27546bc7eccb1b4b597bd354f0c0b1f1f8f8e301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100a0d434ecb5fc3bfd7da5f41904517ad2836249f561bd834ba7a438a8ab7a4ce8022100fac845bb7a02513b58e9f319654dbe49b0f02b95835bac568c71f8a18cdde9ab6861757468446174615881bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54100000000d5aa33581e8ca478e20fe713f5d32ff20020ce9f840ed96599580cd140fbc7bb3230633f50f61041aff73308ae71caa8a2bda401010327200621582044e06ddd331c36a8dc667bab52bcae63486c916aa5e339e6acebaa84934bf832'

인증:

challenge = h'895957e01c633a698348a2d8a31a54b7db27e8c1c43b2080d79ae2190267bfd2'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.EdDSA', L=32)

client_data_gen_flags = h'8c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.EdDSA', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'ab'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.EdDSA', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50100000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a2269566c583442786a4f6d6d44534b4c596f7870557439736e364d48454f7943413135726947514a6e763949222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'f5c59c7e46c34f6f8cc197101ddf9934fa2595f68eb1913a637e8419eb9ba4cfdfc48f85393bc0d40b011f0d6fecb097d6607525713223a0dc0d453993dae00b'

16.12. Ed448 자격 증명을 사용한 Packed 증명

등록:

challenge = h'2578d0801b5a005b5451e540121788cb01949e187b91db13f58755403efbf337'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.Ed448', L=32)

private_key = h'ed479eecf63bd89e3898434798bb3c417bfc8284f6f011958bc0e78edbf6a2a640c0e358b1b1452a1f3782c400dabb4134192dee3031869a45'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.Ed448', L=57)
client_data_gen_flags = h'e3'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.Ed448', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'050a80de27875521cc4c3316c06da42b' = b64'BQqA3ieHVSHMTDMWwG2kKw'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.Ed448', L=16)
aaguid = h'41c913aeda925fe02273322e34c2ae67'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.Ed448', L=16)
credential_id = h'224fcde324e6b075ede55098a24b9ddce5f5a7c71d23703efd528a38f8a5f33c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.Ed448', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'3b'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.Ed448', L=1)
attestation_private_key = h'd90faf5cc3f7853456b09124dd870250347f9c9ff66dba363aecd9194c665715'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.Ed448', L=32)
attestation_cert_serial_number = h'cff4228697d6e5ac47480b2390677f05'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.Ed448', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a224a586a5167427461414674555565564145686549797747556e6868376b6473543959645651443737387a63222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a2042517141336965485653484d54444d577747326b4b77227d'
attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758473045022100c5430b6b53f6b8fd1e5fa46ae7ebb8f9e9ae0d10ebc748e876e2d979b39b1382022008c5cda8af174f2d3c050d5d14eec0721031364cb12924a06633d4924c6bcad3637835638159022730820223308201c8a003020102021100cff4228697d6e5ac47480b2390677f05300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004b85aaf790c824037cfe9fc56ab8d7ce6fbfaff2e3fe7c8d745734c3c6e3c6ce880d505ccdb1e2c3738680e6f49f475e4d8d0b6c29060e6e0d7a6392fb69094cea360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414fa8f81c2dcc0e194ae5034c7e79dcf6d9d8593e2301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100e761f54215ad92f27c2c14b9eea3e39e8c22429e833ecba5be918987aa72e0e6022100d5a714df479c238586b7d9e6684ea84991087038b0fef6a29b57b66b74df05fd686175746844617461589bbfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b5590000000041c913aeda925fe02273322e34c2ae670020224fcde324e6b075ede55098a24b9ddce5f5a7c71d23703efd528a38f8a5f33ca4010103383420072158398051ef4f94670b5abf17da2e9558ba6eba94eb8704363915b4d666de287ad329de9f1f075211aba602dc6e7a5e52b15a8ee1c984a9f8887380'

인증:

challenge = h'1a942f401d8d8e36fe888c35c22b718217802fc6685bf139c47b311408128693'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.Ed448', L=32)

client_data_gen_flags = h'2d'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.Ed448', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'5ca1e381b5e009e01760db2eb632316f' = b64'XKHjgbXgCeAXYNsutjIxbw'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.Ed448', L=16)
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'fc'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0c', info='packed.Ed448', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22477051765142324e6a6a622d6949773177697478676865414c385a6f575f4535784873784641675368704d222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20584b486a6762586743654158594e7375746a49786277227d'
signature = h'071db921430e13ca1a607eedb96cbd30fd63946a06e731217cad6fd82ba3b930d482308a2c101752a2518cff70918d4a20f29bd2eda4f45a80bba6c4ad85b10fb721b1849725b7dbef315d5fb101c6dab890b06d94a8b52a74b5848f68e6152af24867b7555d2b22b8955cbff5c87de73b00'

16.13. ES256 자격 증명을 사용한 TPM 증명

등록:

challenge = h'cfc82cdf1ceee876120aa88f0364f0910193460cfb97a317b2fe090694f9a299'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='tpm.ES256', L=32)

credential_private_key = h'80c60805e564f6d33e7abdff9d32e3db09a6219fe378a268d23107191b18e39f'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='tpm.ES256', L=32)
client_data_gen_flags = h'84'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='tpm.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
aaguid = h'4b92a377fc5f6107c4c85c190adbfd99'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='tpm.ES256', L=16)
credential_id = h'ec27bec7521c894bbb821105ea3724c90e770cf1fa354157ef18d0f18f78bea9'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='tpm.ES256', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'af'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='tpm.ES256', L=1)
attestation_private_key = h'6210f09e0ce7593e851a880a4bdde2d2192afeac46104abce1a890a5a71cf0c6'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='tpm.ES256', L=32)
attestation_cert_serial_number = h'311fc42da0ab10c43a9b1bf3a75e34e2'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='tpm.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a227a38677333787a753648595343716950413254776b51475452677a376c364d587376344a427054356f706b222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d746374706d6761747453746d74a663616c67266373696758463044022066e5826a652091030fd444e33c3eca2bc6dc548cf3045013addb38aa6457a21002203f3a5c95c9e707d0e555041bcc8698ee4ebc04e26cc8bae459705471789851766376657263322e30637835638159023a30820236308201dca0030201020210311fc42da0ab10c43a9b1bf3a75e34e2300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a30003059301306072a8648ce3d020106082a8648ce3d03010703420004c54e3f109094f60d7699b7db5d838569ffd1f3e1c9e897cd9eb40063f9402e3e9937e936cf1fcd5eb743ff443c97ab2edcd7c8e0e6cf6cfd413b8ab19fffa769a381d33081d0300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604145f546cb6973d4981e80fcdc7463859f5879680e4301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e30100603551d250409300706056781050803305e0603551d110101ff04543052a450304e314c3014060567810502010c0b69643a30303030303030303014060567810502030c0b69643a3030303030303030301e060567810502020c15576562417574686e207465737420766563746f7273300a06082a8648ce3d0403020348003045022063c9a2797b8066f1db34dd609f1ab6695607e7a98e9ff8090a68853c9a9fc949022100a55831a39f5b8a2aa9a68837829cabf43fea2a5cea4859ae851cac78e6ac3e97677075624172656158560023000b0004000000000010001000030010002041202698c9d9753fb4bb3f27cd09fe6b8afdb76438ee2ae54d7c9dade10d864b0020d8735115cdb330a63ea1d6e43d5000f4bd56f99bce83ee1d73301fc270116d076863657274496e666f5869ff544347801700000020277d0e05579dd013215a62273f7f3a3e7e191ead2654a3036d75a5a3ee37a6b0000000000000000011111111222222223300000000000000000022000b9c42d8aad5939331b9af3711af179f17123178098c9a7d0ca89fcd1fc800f3c7000068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54d000000004b92a377fc5f6107c4c85c190adbfd990020ec27bec7521c894bbb821105ea3724c90e770cf1fa354157ef18d0f18f78bea9a501020326200121582041202698c9d9753fb4bb3f27cd09fe6b8afdb76438ee2ae54d7c9dade10d864b225820d8735115cdb330a63ea1d6e43d5000f4bd56f99bce83ee1d73301fc270116d07'

인증:

challenge = h'00093b66c21d5b5e89f7a07082118907ea3e502d343b314b8c5a54d62db202fb'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='tpm.ES256', L=32)

client_data_gen_flags = h'86'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='tpm.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'87'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='tpm.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50d00000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a2241416b375a7349645731364a393642776768474a422d6f2d554330304f7a464c6a46705531693279417673222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3045022060dc76b1607ec716c6e5eba8d056695ed6bc47b2e3d7a729c34e759e3ab66aa0022100d010a9e8fddcb64c439dfdca628ddb33cf245d567d157d9f66f942601bed9b38'

16.14. ES256 자격 증명을 사용한 Android 키 증명

등록:

challenge = h'3de1f0b7365dccde3ff0cbf25e26ffa7baff87ef106c80fc865dc402d9960050'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='android-key.ES256', L=32)

credential_private_key = h'd4328d911acb0ebcc42aad29b29ffb55d5bc31d8af7ca9a16703d56c21abc7b4'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='android-key.ES256', L=32)
client_data_gen_flags = h'73'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='android-key.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'555d5c42e476a8b33f6a63dfa07ccbd2' = b64'VV1cQuR2qLM_amPfoHzL0g'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='android-key.ES256', L=16)
aaguid = h'ade9705e1ce7085b899a540d02199bf8'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='android-key.ES256', L=16)
credential_id = h'0a4729519788b6ed8a2d772b494e186244d8c798c052960dbc8c10c915176795'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='android-key.ES256', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'1e'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='android-key.ES256', L=1)
attestation_cert_serial_number = h'1ff91f76b63f44812f998b250b0286bf'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='android-key.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a2250654877747a5a647a4e345f384d76795869625f7037725f682d385162494438686c334541746d57414641222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a205656316351755232714c4d5f616d50666f487a4c3067227d'
attestationObject = h'a363666d746b616e64726f69642d6b65796761747453746d74a363616c67266373696758483046022100e95512982aa3f216cff2e87c8ec57057b8529f674eaabeccaa27fd03d8779f19022100afb6bf459da4a826f00d01fc6b60712ff31dc4eb331619c8f874bb17e4314e94637835638159027c308202783082021ea00302010202101ff91f76b63f44812f998b250b0286bf300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d0301070342000499169657036d089a2a9821a7d0063d341f1a4613389359636efab5f3cbf1accfdd91c55543176ea99b644406dd1dd63774b6af65ac759e06ff40b1c8ab02df6ba381b63081b3300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604141ac81e50641e8d1339ab9f7eb25f0cd5aac054b0301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e3053060a2b06010401d679020111044530430202012c0a01000201000a01000420b435028d7b6a8f83bb461d41c19b053a9d3cdb30351a4f374cd4cde8dbefb60604003000300ea1053103020102bf853e03020100300a06082a8648ce3d040302034800304502201354f9149996f6e1830852da629b86d37c10da0ffe17471c67d48765ed83f63b02210086db5746944cecdfce071d9e041072ceac3d1c504382f205676e9a1f02d7632568617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b55d00000000ade9705e1ce7085b899a540d02199bf800200a4729519788b6ed8a2d772b494e186244d8c798c052960dbc8c10c915176795a501020326200121582099169657036d089a2a9821a7d0063d341f1a4613389359636efab5f3cbf1accf225820dd91c55543176ea99b644406dd1dd63774b6af65ac759e06ff40b1c8ab02df6b'

인증:

challenge = h'e4ee05ca9dbced74116540f24ed9adc62aae8507560522844ffa7eea14f7af86'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='android-key.ES256', L=32)

client_data_gen_flags = h'43'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='android-key.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'ab127107eff182bc3230beb5f1dad29c' = b64'qxJxB-_xgrwyML618drSnA'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='android-key.ES256', L=16)
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'4a'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='android-key.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22354f344679703238375851525a55447954746d74786971756851645742534b45545f702d36685433723459222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a2071784a78422d5f78677277794d4c3631386472536e41227d'
signature = h'3045022100a2b5e37da43ceb63566f6e2817c6cbef261073d0cadfd213ff6229bd33ddea6c02203d77eb3202fc92b9b5bb843ef082c7766f8c7f23194c92708ff2f3d1de765a8f'

16.15. ES256 자격 증명을 사용한 Apple 익명 증명

등록:

challenge = h'f7f688213852007775009cf8c096fda89d60b9a9fb5a50dd81dd9898af5a0609'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='apple.ES256', L=32)

credential_private_key = h'de987bd9d43eeb44728ce0b14df11209dff931fb56b5b1948de4c0da1144ded0'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='apple.ES256', L=32)
client_data_gen_flags = h'5f'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='apple.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
extraData_random = h'4e32cf9e939a5d052b14d71b1f6b5364' = b64'TjLPnpOaXQUrFNcbH2tTZA'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='apple.ES256', L=16)
aaguid = h'748210a20076616a733b2114336fc384'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='apple.ES256', L=16)
credential_id = h'9c4a5886af9283d9be3e9ec55978dedfdce2e3b365cab193ae850c16238fafb8'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='apple.ES256', L=32)
; auth_data_UV_BE_BS는 인증자 데이터 플래그의 UV, BE 및 BS 비트를 결정하지만, BS는 BE가 설정된 경우에만 설정됨
auth_data_UV_BE_BS = h'2a'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='apple.ES256', L=1)
attestation_cert_serial_number = h'394275613d5310b81a29ce90f48b61c1'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='apple.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22395f61494954685341486431414a7a34774a6239714a316775616e37576c4464676432596d4b396142676b222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20546a4c506e704f6158515572464e6362483274545a41227d'
attestationObject = h'a363666d74656170706c656761747453746d74a1637835638159025c30820258308201fea0030201020210394275613d5310b81a29ce90f48b61c1300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d030107034200048a3d5b1b4c543a706bf6e4b00afedb3c930b690dd286934fe2911f779cc7761af728e1aa3b0ff66692192daa776b83ddf8e3340d2d9a0eabdfc324eb3e2f136ca38196308193300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e0416041412f1ce6c0ae39b403bfc9200317bc183a4e4d766301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e303306092a864886f76364080204263024a1220420d7a86e7233fb843eb0eeb407d8b76ff7e4f82d218cf5dbb461d752073f5cb29a300a06082a8648ce3d0403020348003045022070f5c2ede3000e9dae358d412b26a4acbf18f4cdeb80f5b13fcd564d090c39ec022100f672e2c3dbe117c9b1490b3c660abf5dcd74398187082dacb58b6744de4aca6068617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54900000000748210a20076616a733b2114336fc38400209c4a5886af9283d9be3e9ec55978dedfdce2e3b365cab193ae850c16238fafb8a50102032620012158208a3d5b1b4c543a706bf6e4b00afedb3c930b690dd286934fe2911f779cc7761a225820f728e1aa3b0ff66692192daa776b83ddf8e3340d2d9a0eabdfc324eb3e2f136c'

인증:

challenge = h'd3eb2964641e26fed023403a72dde093b19c4ba9008c3f9dd83fcfd347a66d05'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='apple.ES256', L=32)

client_data_gen_flags = h'c2'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='apple.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'e2'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='apple.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50900000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22302d73705a4751654a76375149304136637433676b37476353366b416a442d6432445f503030656d625155222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'3046022100ee35db795ce28044e1f8231d68b3d79a9882f7415aa35c1b5ac74d24251073c8022100dcc65691650a412d0ceef843710c09827acf26c7845bddac07eec95863e7fc4c'

16.16. ES256 자격 증명을 사용한 FIDO U2F 증명

등록:

challenge = h'e074372990b9caa507a227dfc67b003780c45325380d1a90c20f81ed7d080c06'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='fido-u2f.ES256', L=32)

credential_private_key = h'51bd002938fa10b83683ac2a2032d0a7338c7f65a90228cfd1f61b81ec7288d0'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='fido-u2f.ES256', L=32)
client_data_gen_flags = h'00'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='fido-u2f.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
aaguid = h'afb3c2efc054df425013d5c88e79c3c1'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='fido-u2f.ES256', L=16)
credential_id = h'a4ba6e2d2cfec43648d7d25c5ed5659bc18f2b781538527ebd492de03256bdf4'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='fido-u2f.ES256', L=32)
attestation_private_key = h'66fda477a2a99d14c5edd7c1041a297ba5f3375108b1d032b79429f42349ce33'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='fido-u2f.ES256', L=32)
attestation_cert_serial_number = h'04f66dc6542ea7719dea416d325a2401'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='fido-u2f.ES256', L=16)

clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22344851334b5a4335797155486f696666786e73414e344445557955344452715177672d4237583049444159222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
attestationObject = h'a363666d74686669646f2d7532666761747453746d74a26373696758473045022100f41887a20063bb26867cb9751978accea5b81791a68f4f4dd6ea1fb6a5c086c302204e5e00aa3895777e6608f1f375f95450045da3da57a0e4fd451df35a31d2d98a637835638159022530820221308201c7a003020102021004f66dc6542ea7719dea416d325a2401300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d0301070342000456fffa7093dede46aefeefb6e520c7ccc78967636e2f92582ba71455f64e93932dff3be4e0d4ef68e3e3b73aa087e26a0a0a30b02dc2aa2309db4c3a2fc936dea360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414420822eb1908b5cd3911017fbcad4641c05e05a3301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d040302034800304502200d0b777f0a0b181ad2830275acc3150fd6092430bcd034fd77beb7bdf8c2d546022100d4864edd95daa3927080855df199f1717299b24a5eecefbd017455a9b934d8f668617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54100000000afb3c2efc054df425013d5c88e79c3c10020a4ba6e2d2cfec43648d7d25c5ed5659bc18f2b781538527ebd492de03256bdf4a5010203262001215820b0d62de6b30f86f0bac7a9016951391c2e31849e2e64661cbd2b13cd7d5508ad225820503b0bda2a357a9a4b34475a28e65b660b4898a9e3e9bbf0820d43494297edd0'

인증:

challenge = h'f90c612981d84f599438de1a500f76926e92cc84bef8e02c6e23553f00485435'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='fido-u2f.ES256', L=32)

client_data_gen_flags = h'2c'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='fido-u2f.ES256', L=1)
; client_data_gen_flags의 비트 0x01이 1인 경우에만 extraData가 clientDataJSON에 추가됨
; auth_data_UV_BS는 인증자 데이터 플래그의 UV 및 BS 비트를 설정하지만, BS는 등록에서 BE가 설정된 경우에만 설정됨
auth_data_UV_BS = h'd1'   ; 다음으로 파생됨: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='fido-u2f.ES256', L=1)

authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50100000000'
clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a222d5178684b59485954316d554f4e3461554139326b6d36537a49532d2d4f417362694e5650774249564455222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
signature = h'304402206172459958fea907b7292b92f555034bfd884895f287a76200c1ba287239137002204727b166147e26a21bbc2921d192ebfed569b79438538e5c128b5e28e6926dd7'

16.17. WebAuthn 확장용 테스트 벡터

이 절에서는 WebAuthn 확장의 예제 값을 나열합니다.

16.17.1. 의사 난수 함수 확장(prf)

이 절에서는 의사 난수 함수(prf) 확장의 예제 값을 나열합니다.

prf 확장은 CTAP2 hmac-secret 확장 [FIDO-CTAP]과 통합되므로, 예제는 두 절로 나뉩니다. WebAuthn 클라이언트 및 WebAuthn 신뢰 당사자와 관련된 WebAuthn prf 확장의 예제 입력 및 출력, 그리고 WebAuthn 클라이언트 및 WebAuthn 인증자와 관련된 WebAuthn prf 확장과 CTAP2 hmac-secret 확장 간의 예제 매핑입니다.

16.17.1.1. 웹 인증 API

다음 예제는 WebAuthn 클라이언트의 prf 확장 구현 및 WebAuthn 신뢰 당사자의 사용을 테스트하는 데 사용할 수 있습니다. 예제는 완전하지 않습니다.

enabled 출력은 등록 절차 중에는 항상 존재하고 인증 절차 중에는 존재하지 않습니다.

// 확장 입력 예:
{ prf: {} }

// navigator.credentials.create()의 클라이언트 확장 출력 예:
{ prf: { enabled: true } }
{ prf: { enabled: false } }

// navigator.credentials.get()의 클라이언트 확장 출력 예:
{ prf: {} }

results 출력은 eval 또는 evalByCredential 입력이 있는 경우 등록 절차 또는 인증 절차 중에 존재할 수 있습니다.

// 확장 입력 예:
{ prf: { eval: { first: new Uint8Array([1, 2, 3, 4]) } } }

// navigator.credentials.create()의 클라이언트 확장 출력 예:
{ prf: { enabled: true } }
{ prf: { enabled: false } }
{ prf: { enabled: true, results: { first: ArrayBuffer } } }

// navigator.credentials.get()의 클라이언트 확장 출력 예:
{ prf: {} }
{ prf: { results: { first: ArrayBuffer } } }

results.second 출력은 results 출력이 존재하고 선택한 PRF 입력에 second 입력이 있었던 경우에만 존재합니다.

// 확장 입력 예:
{
  prf: {
    eval: {
      first: new Uint8Array([1, 2, 3, 4]),
      second: new Uint8Array([5, 6, 7, 8]),
    },
    evalByCredential: {
      "e02eZ9lPp0UdkF4vGRO4-NxlhWBkL1FCmsmb1tTfRyE": {
        first: new Uint8Array([9, 10, 11, 12]),
      }
    }
  }
}

// 자격 증명 "e02eZ9lP..."가 사용된 경우 navigator.credentials.get()의 클라이언트 확장 출력 예:
{ prf: { results: { first: ArrayBuffer } } }

// 다른 자격 증명이 사용된 경우 navigator.credentials.get()의 클라이언트 확장 출력 예:
{ prf: {} }
{ prf: { results: { first: ArrayBuffer, second: ArrayBuffer } } }

first 및 second 출력은 어떤 BufferSource 유형이든 될 수 있습니다. 동일한 first 및 second 입력은 동일한 first 및 second 출력을 생성합니다.

// 확장 입력 예:
{
  prf: {
    evalByCredential: {
      "e02eZ9lPp0UdkF4vGRO4-NxlhWBkL1FCmsmb1tTfRyE": {
        first: new Uint8Array([9, 10, 11, 12]),
        second: new Uint8Array([9, 10, 11, 12])
      }
    }
  }
}

// navigator.credentials.get()의 클라이언트 확장 출력 예:
{
  prf: {
    results: {
      first: new Uint8Array([0xc4, 0x17, 0x2e, 0x98, 0x2e, 0x90, 0x97, 0xc3, 0x9a, 0x6c, 0x0c, 0xb7, 0x20, 0xcb, 0x37, 0x5b, 0x92, 0xe3, 0xfc, 0xad, 0x15, 0x4a, 0x63, 0xe4, 0x3a, 0x93, 0xf1, 0x09, 0x6b, 0x1e, 0x19, 0x73]),
      second: new Uint32Array([0x982e17c4, 0xc397902e, 0xb70c6c9a, 0x5b37cb20, 0xadfce392, 0xe4634a15, 0x09f1933a, 0x73191e6b]),
    }
  }
}

이 절에서 사용된 의사 난수 값은 다음과 같이 생성되었습니다.

"e02eZ9lPp0UdkF4vGRO4-NxlhWBkL1FCmsmb1tTfRyE" = Base64Url(SHA-256(UTF-8("WebAuthn PRF test vectors") || 0x00))
h'c4172e982e9097c39a6c0cb720cb375b92e3fcad154a63e43a93f1096b1e1973' = SHA-256(UTF-8("WebAuthn PRF test vectors") || 0x01)

16.17.1.2. CTAP2 `hmac-secret` 확장

다음 예제는 prf 확장이 [FIDO-CTAP] hmac-secret 확장을 사용하는 방법에 관한 WebAuthn 클라이언트 구현을 테스트하는 데 사용할 수 있습니다. 예제는 CDDL [RFC8610] 표기법으로 제공됩니다. 예제는 완전하지 않습니다.

다음 공유 정의는 이후의 모든 예제에서 사용됩니다.

; 주어진 입력 매개변수:
platform_key_agreement_private_key = 0x0971bc7fb1be48270adcd3d9a5fc15d5fb0f335b3071ff36a54c007fa6c76514
authenticator_key_agreement_public_key = {
    1: 2,
    3: -25,
    -1: 1,
    -2: h'a30522c2de402b561965c3cf949a1cab020c6f6ea36fcf7e911ac1a0f1515300',
    -3: h'9961a929abdb2f42e6566771887d41484d889e735e3248518a53112d2b915f00',
}
authenticator_cred_random = h'437e065e723a98b2f08f39d8baf7c53ecb3c363c5e5104bdaaf5d5ca2e028154'

first 및 second 입력은 예제에서 각각 prf_eval_first 및 prf_eval_second로 매핑됩니다. 예제의 prf_results_first 및 prf_results_second 값은 각각 results.first 및 results.second 출력으로 매핑됩니다.

PIN 프로토콜 2를 사용하는 단일 입력 경우:

; 신뢰 당사자의 입력:
prf_eval_first = h'576562417574686e20505246207465737420766563746f727302'

; 클라이언트 계산:
shared_secret = h'0c63083de8170101d38bcf8bd72309568ddb4550867e23404b35d85712f7c20d8bc911ee23c06034cbc14290b9669bec07739053c5a416e313ef905c79955876'
salt1 = h'527413ebb48293772df30f031c5ac4650c7de14bf9498671ae163447b6a772b3'
salt_enc = h'23dde5e3462daf36559b85c4ac5f9656aa9bfd81c1dc2bf8533c8b9f3882854786b4f500e25b4e3d81f7fc7c74236229'

; 인증자 계산:
output1 = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'
output_enc = h'3bfaa48f7952330d63e35ff8cd5bca48d2a12823828915749287256ab146272f9fb437bf65691243c3f504bd7ea6d5e6'

; 클라이언트 복호화:
prf_results_first = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'

PIN 프로토콜 2를 사용하는 두 입력 경우:

; 신뢰 당사자의 입력:
prf_eval_first = h'576562417574686e20505246207465737420766563746f727302'
prf_eval_second = h'576562417574686e20505246207465737420766563746f727303'

; 클라이언트 계산:
shared_secret = h'0c63083de8170101d38bcf8bd72309568ddb4550867e23404b35d85712f7c20d8bc911ee23c06034cbc14290b9669bec07739053c5a416e313ef905c79955876'
salt1 = h'527413ebb48293772df30f031c5ac4650c7de14bf9498671ae163447b6a772b3'
salt2 = h'd68ac03329a10ee5e0ec834492bb9a96a0e547baf563bf78ccbe8789b22e776b'
salt_enc = h'd9f4236403e0fe843a8e4e5be764d120904c198ad6e77b089876a3391961f183b0008b4ca66b91cd72aa35b6151ff981f6e5649f3c040e6615ad7dd8ae96ef23b229a5c97c3f0dcd8605eee166ce163a'

; 인증자 계산:
output1 = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'
output2 = h'a62a8773b19cda90d7ed4ef72a80a804320dbd3997e2f663805ad1fd3293d50b'
output_enc = h'90ee52f739043bc17b3488a74306d7801debb5b61f18662c648a25b5b5678ede482cdaff99a537a44f064fcb10ce6e04dfd27619dc96a0daff8507e499296b1eecf0981f7c8518b277a7a3018f5ec6fb'

; 클라이언트 복호화:
prf_results_first = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'
prf_results_second = h'a62a8773b19cda90d7ed4ef72a80a804320dbd3997e2f663805ad1fd3293d50b'

PIN 프로토콜 1을 사용하는 단일 입력 경우:

; 신뢰 당사자의 입력:
prf_eval_first = h'576562417574686e20505246207465737420766563746f727302'

; 클라이언트 계산:
shared_secret = h'23e5ed7157c25892b77732fb9c8a107e3518800db2af4142f9f4adfacb771d39'
salt1 = h'527413ebb48293772df30f031c5ac4650c7de14bf9498671ae163447b6a772b3'
salt_enc = h'ab8c878bb05d04700f077ed91845ec9c503c925cb12b327ddbeb4243c397f913'

; 인증자 계산:
output1 = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'
output_enc = h'15d4e4f3f04109b492b575c1b38c28585b6719cf8d61304215108d939f37ccfb'

; 클라이언트 복호화:
prf_results_first = h'3c33e07d202c3b029cc21f1722767021bf27d595933b3d2b6a1b9d5dddc77fae'

이 절에서 사용된 입력과 의사 난수 값은 다음과 같이 생성되었습니다.

seed = UTF-8("WebAuthn PRF test vectors")
prf_eval_first = seed || 0x02
prf_eval_second = seed || 0x03
platform_key_agreement_private_key = SHA-256(seed || 0x04)
authenticator_key_agreement_public_key = P256-Public-Key(sk) 여기서 sk = SHA-256(seed || 0x05)
authenticator_cred_random = SHA-256(seed || 0x06)
PIN 프로토콜 2를 사용하는 단일 입력 salt_enc의 iv: 잘린 SHA-256(seed || 0x07)
PIN 프로토콜 2를 사용하는 두 입력 salt_enc의 iv: 잘린 SHA-256(seed || 0x08)
PIN 프로토콜 2를 사용하는 단일 입력 output_enc의 iv: 잘린 SHA-256(seed || 0x09)
PIN 프로토콜 2를 사용하는 두 입력 output_enc의 iv: 잘린 SHA-256(seed || 0x0a)

17. 감사의 말

이 명세를 검토하고 기여해 주신 다음 분들께 감사드립니다: Yuriy Ackermann, James Barclay, Richard Barnes, Dominic Battré, Julien Cayzac, Domenic Denicola, Rahul Ghosh, Brad Hill, Nidhi Jaju, Jing Jin, Wally Jones, Ian Kilpatrick, Axel Nennker, Zack Newman, Yoshikazu Nojima, Kimberly Paulhamus, Adam Powers, Yaron Sheffer, Anne van Kesteren, Johan Verrept, 그리고 Boris Zbarsky.

전체 등록 및 인증 흐름 다이어그램 (그림 1 및 그림 2)을 만든 Adam Powers에게 감사드립니다.

웹 인증 워킹 그룹 공동 의장으로 기여한 Anthony Nadalin, John Fontana, 그리고 Richard Barnes에게 감사드립니다.

또한 W3C 팀 담당자로 기여한 Simone Onofri, Philippe Le Hégaret, Wendy Seltzer, Samuel Weiler, 그리고 Harry Halpin에게 감사드립니다.

18. 개정 이력

이 절은 규범적이지 않습니다.

이 절에서는 시간 경과에 따라 이 명세에 이루어진 주요 변경 사항을 요약합니다.

18.1. 웹 인증 레벨 3 [webauthn-3-20260825] 이후 변경 사항

18.1.1. 실질적 변경 사항

웹 인증 API 및 그 동작 방식에 다음 변경 사항이 적용되었습니다.

변경 사항:

prf 확장의 인증자 확장 출력에 평문 PRF 출력이 포함되지 않도록 요구했습니다.
가상 인증자의 자격 증명 추가 및 자격 증명 속성 설정 명령에 서명 카운터를 생성, 업데이트 또는 제거할 수 있는 기능을 포함하여 명시적인 signCount 처리를 추가했습니다.

새 기능:

원격 데스크톱 WebAuthn 작업을 위한 remoteClientDataJSON 등록 및 인증 확장을 추가했습니다. 여기에는 기본적으로 거부되는 강력한 기능, 정책 제어 기능이며 기본 허용 목록이 'none'인 기능, 그리고 클라이언트를 위한 보안 고려사항이 포함됩니다. § 10.1.6 원격 클라이언트 데이터 JSON 확장 (remoteClientDataJSON), § 5.9 Permissions Policy 통합, § 13.4.1 remoteClientDataJSON 확장.

18.1.2. 편집상 변경 사항

문서의 명확성, 가독성, 탐색성 및 유사한 측면을 개선하기 위해 다음 변경 사항이 적용되었습니다.

자격 증명 생성 및 인증 알고리즘에서 remoteClientDataJSON 확장이 사용하는 클라이언트 데이터 구성 및 직렬화 단계에 명시적인 앵커를 추가했습니다.
사용자 검증됨 설정 가상 인증자 명령을 위한 JSON 사용자 검증됨 설정 매개변수 객체를 정의했습니다.

18.2. 웹 인증 레벨 2 [webauthn-2-20210408] 이후 변경 사항

18.2.1. 실질적 변경 사항

웹 인증 API 및 그 동작 방식에 다음 변경 사항이 적용되었습니다.

변경 사항:

시간 제한 지침 업데이트: § 15.1 절차 시간 제한의 권장 범위
uvm 확장은 더 이상 포함되지 않습니다. 대신 L2 [webauthn-2-20210408]를 참조하십시오.
attestation 기본 설정이 none인 경우 증명된 자격 증명 데이터의 aaguid가 더 이상 0으로 설정되지 않습니다. § 5.1.3 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드
ESP256(-9), ESP384(-51) 및 ESP512(-52) 공개 키가 압축되지 않은 형식을 사용하도록 요구사항을 추가했습니다. § 5.8.5 암호화 알고리즘 식별자(typedef COSEAlgorithmIdentifier)
§ 5.6 AbortSignal을 사용한 작업 중단에서 문서가 포커스를 잃을 때 중단하라는 권장사항을 제거했습니다.

사용 중단 예정:

등록 매개변수 publicKey.rp.name: § 5.4.1 공개 키 엔터티 설명(dictionary PublicKeyCredentialEntity)
§ 8.5 Android SafetyNet 증명문 형식
tokenBinding이 [RESERVED]로 변경되었습니다.
필드 내 언어 및 방향 메타데이터는 더 이상 권장되지 않습니다.
- § 6.4.2 언어 및 방향 인코딩
- publicKey.rp.name
- publicKey.user.name
- publicKey.user.displayName
COSEAlgorithmIdentifier 값 -9, -51, -52 및 -19를 pubKeyCredParams에서 사용하지 말라는 권장사항을 추가했습니다.

새 기능:

새 JSON (역)직렬화 메서드:
교차 오리진 iframe에서의 생성 작업:
- § 5.1.3 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드
- § 5.10 iframe 요소 내에서 웹 인증 사용
create의 조건부 중재: § 5.1.3 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드
get의 조건부 중재: § 5.1.4 기존 자격 증명을 사용하여 어설션 만들기
§ 5.1.7 클라이언트 기능의 가용성 - PublicKeyCredential의 getClientCapabilities() 메서드
- § 14.5.4 클라이언트 기능 공개
§ 5.8.4 인증자 전송 열거형(enum AuthenticatorTransport)에 새 열거형 값 hybrid를 추가했습니다.
§ 5.1.10 인증자에 자격 증명 변경 알리기 - PublicKeyCredential의 signal 메서드
새 클라이언트 데이터 속성 topOrigin: § 5.8.1 WebAuthn 서명에 사용되는 클라이언트 데이터(dictionary CollectedClientData)
§ 5.8.8 사용자 에이전트 힌트 열거형(enum PublicKeyCredentialHint)
§ 5.11 관련 오리진 간 웹 인증 사용
인증자 데이터 플래그 BE 및 BS 할당:
§ 8.9 복합 증명문 형식
§ 10.1.4 의사 난수 함수 확장(prf)
등록 매개변수 publicKey.attestationFormats: § 5.4 자격 증명 생성 옵션(dictionary PublicKeyCredentialCreationOptions)

18.2.2. 편집상 변경 사항

문서의 명확성, 가독성, 탐색성 및 유사한 측면을 개선하기 위해 다음 변경 사항이 적용되었습니다.

§ 1.2 사용 사례를 배포 환경의 발전을 반영하도록 업데이트했습니다.
신뢰 당사자가 어떤 데이터를 저장해야 하는지, 그리고 그 데이터가 등록 및 인증 절차 간에 어떻게 관련되는지를 명확히 하기 위해 자격 증명 레코드 개념을 도입했습니다.
오류 조건 명확화:
- § 5.1.3.1 생성 요청 예외
- § 5.1.4.3 가져오기 요청 예외
§ 6.4 문자열 처리를 § 6.4.1.1 클라이언트에 의한 문자열 자르기 및 § 6.4.1.2 인증자에 의한 문자열 자르기 하위 절로 나누어 책임 분담을 명확히 했습니다.
§ 16 테스트 벡터를 추가했습니다.
"참고" 블록 밖으로 규범적 문구를 이동했습니다.
웹 인증: 공개 키 자격 증명에 접근하기 위한 API - 레벨 3 § sctn-isUserVerifyingPlatformAuthenticatorAvailable 및 웹 인증: 공개 키 자격 증명에 접근하기 위한 API - 레벨 3 § sctn-getClientCapabilities에서 Permissions Policy에 관한 오래된 참고를 제거했습니다.
웹 인증: 공개 키 자격 증명에 접근하기 위한 API - 레벨 3 § sctn-sample-registration의 예제 코드에 알고리즘 -8(EdDSA)을 추가했습니다.

웹 인증:공개 키 자격 증명에 접근하기 위한 API레벨 4

초록

이 문서의 상태

1. 소개

1.1. 명세 로드맵

1.2. 사용 사례

1.2.1. 다중 기기 자격 증명을 사용하는 소비자

1.2.1.1. 등록

1.2.1.2. 인증

1.2.2. 단일 기기 자격 증명을 사용하는 조직 구성원

1.2.2.1. 등록

1.2.2.2. 인증

1.2.3. 기타 사용 사례 및 구성

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.3.1. 생성 요청 예외

5.1.4. 기존 자격 증명을 사용하여 어설션 생성

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

5.1.4.2. 인증자에 자격 증명 요청 발행

5.1.4.3. 가져오기 요청 예외

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

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

5.1.7. 클라이언트 기능의 사용 가능 여부 - PublicKeyCredential의 getClientCapabilities() 메서드

5.1.8. 등록 절차 옵션 역직렬화 - PublicKeyCredential의 parseCreationOptionsFromJSON() 메서드

5.1.9. 인증 절차 옵션 역직렬화 - PublicKeyCredential의 parseRequestOptionsFromJSON() 메서드

5.1.10. 인증자에 자격 증명 변경 신호 전달 - PublicKeyCredential의 신호 메서드

5.1.10.1. 비동기 RP ID 검증 알고리즘

5.1.10.2. signalUnknownCredential(options)

5.1.10.3. signalAllAcceptedCredentials(options)

5.1.10.4. signalCurrentUserDetails(options)

5.2. 인증자 응답 (인터페이스 AuthenticatorResponse)

5.2.1. 공개 키 자격 증명에 대한 정보 (인터페이스 AuthenticatorAttestationResponse)

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

5.2.2. 웹 인증 어설션 (인터페이스 AuthenticatorAssertionResponse)

5.3. 자격 증명 생성 매개변수 (딕셔너리 PublicKeyCredentialParameters)

5.4. 자격 증명 생성 옵션 (딕셔너리 PublicKeyCredentialCreationOptions)

5.4.1. 공개 키 엔터티 설명 (딕셔너리 PublicKeyCredentialEntity)

5.4.2. 자격 증명 생성을 위한 신뢰 당사자 매개변수 (딕셔너리 PublicKeyCredentialRpEntity)

5.4.3. 자격 증명 생성을 위한 사용자 계정 매개변수 (딕셔너리 PublicKeyCredentialUserEntity)

5.4.4. 인증자 선택 기준 (딕셔너리 AuthenticatorSelectionCriteria)

5.4.5. 인증자 연결 방식 열거형 (열거형 AuthenticatorAttachment)

5.4.6. 상주 키 요구사항 열거형 (열거형 ResidentKeyRequirement)

5.4.7. 증명 전달 기본 설정 열거형 (열거형 AttestationConveyancePreference)

5.5. 어설션 생성 옵션 (딕셔너리 PublicKeyCredentialRequestOptions)

5.6. AbortSignal을 사용하여 작업 중단

5.7. WebAuthn 확장 입력 및 출력

5.7.1. 인증 확장 클라이언트 입력 (딕셔너리 AuthenticationExtensionsClientInputs)

5.7.2. 인증 확장 클라이언트 출력 (딕셔너리 AuthenticationExtensionsClientOutputs)

5.7.3. 인증 확장 인증자 입력 (CDDL 유형 AuthenticationExtensionsAuthenticatorInputs)

5.7.4. 인증 확장 인증자 출력 (CDDL 유형 AuthenticationExtensionsAuthenticatorOutputs)

5.8. 지원 데이터 구조

5.8.1. WebAuthn 서명에 사용되는 클라이언트 데이터 (딕셔너리 CollectedClientData)

5.8.1.1. 직렬화

5.8.1.2. 제한된 검증 알고리즘

5.8.1.3. 향후 개발

5.8.2. 자격 증명 유형 열거형 (열거형 PublicKeyCredentialType)

5.8.3. 자격 증명 설명자 (딕셔너리 PublicKeyCredentialDescriptor)

5.8.4. 인증자 전송 열거형 (열거형 AuthenticatorTransport)

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

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

5.8.7. 클라이언트 기능 열거형 (열거형 ClientCapability)

웹 인증:
공개 키 자격 증명에 접근하기 위한 API
레벨 4

5.1. `PublicKeyCredential` 인터페이스

5.1.1. `CredentialCreationOptions` 딕셔너리 확장

5.1.2. `CredentialRequestOptions` 딕셔너리 확장

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

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

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

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

5.1.7. 클라이언트 기능의 사용 가능 여부 - PublicKeyCredential의 `getClientCapabilities()` 메서드

5.1.8. 등록 절차 옵션 역직렬화 - PublicKeyCredential의 `parseCreationOptionsFromJSON()` 메서드

5.1.9. 인증 절차 옵션 역직렬화 - PublicKeyCredential의 `parseRequestOptionsFromJSON()` 메서드

5.1.10.2. `signalUnknownCredential(options)`

5.1.10.3. `signalAllAcceptedCredentials(options)`

5.1.10.4. `signalCurrentUserDetails(options)`

5.2. 인증자 응답 (인터페이스 `AuthenticatorResponse`)

5.2.1. 공개 키 자격 증명에 대한 정보 (인터페이스 `AuthenticatorAttestationResponse`)

5.2.2. 웹 인증 어설션 (인터페이스 `AuthenticatorAssertionResponse`)

5.3. 자격 증명 생성 매개변수 (딕셔너리 `PublicKeyCredentialParameters`)

5.4. 자격 증명 생성 옵션 (딕셔너리 `PublicKeyCredentialCreationOptions`)

5.4.1. 공개 키 엔터티 설명 (딕셔너리 `PublicKeyCredentialEntity`)

5.4.2. 자격 증명 생성을 위한 신뢰 당사자 매개변수 (딕셔너리 `PublicKeyCredentialRpEntity`)

5.4.3. 자격 증명 생성을 위한 사용자 계정 매개변수 (딕셔너리 `PublicKeyCredentialUserEntity`)

5.4.4. 인증자 선택 기준 (딕셔너리 `AuthenticatorSelectionCriteria`)

5.4.5. 인증자 연결 방식 열거형 (열거형 `AuthenticatorAttachment`)

5.4.6. 상주 키 요구사항 열거형 (열거형 `ResidentKeyRequirement`)

5.4.7. 증명 전달 기본 설정 열거형 (열거형 `AttestationConveyancePreference`)

5.5. 어설션 생성 옵션 (딕셔너리 `PublicKeyCredentialRequestOptions`)

5.6. `AbortSignal`을 사용하여 작업 중단

5.7.1. 인증 확장 클라이언트 입력 (딕셔너리 `AuthenticationExtensionsClientInputs`)

5.7.2. 인증 확장 클라이언트 출력 (딕셔너리 `AuthenticationExtensionsClientOutputs`)

5.7.3. 인증 확장 인증자 입력 (CDDL 유형 `AuthenticationExtensionsAuthenticatorInputs`)

5.7.4. 인증 확장 인증자 출력 (CDDL 유형 `AuthenticationExtensionsAuthenticatorOutputs`)

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

5.8.2. 자격 증명 유형 열거형 (열거형 `PublicKeyCredentialType`)

5.8.3. 자격 증명 설명자 (딕셔너리 `PublicKeyCredentialDescriptor`)

5.8.4. 인증자 전송 열거형 (열거형 `AuthenticatorTransport`)

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

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

5.8.7. 클라이언트 기능 열거형 (열거형 `ClientCapability`)

5.8.8. 사용자 에이전트 힌트 열거형 (열거형 `PublicKeyCredentialHint`)

5.10. `iframe` 요소 내에서 웹 인증 사용

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