웹 인증: 공개 키 자격 증명에 접근하기 위한 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), Bluetooth 저전력(BLE) 또는 근거리 무선 통신(NFC) 등의 전송 방식을 통해 접근할 수 있다.

1.1. 명세 로드맵

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

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

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

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

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

1.2. 사용 사례

아래의 사용 사례 시나리오는 매우 다른 두 유형의 인증기 사용을 보여 주고 추가 시나리오의 개요도 제시한다. 예제 코드를 포함한 추가 시나리오는 뒤의 § 1.3 API 사용 예시 시나리오에서 제시한다.

1.2.1. 등록

휴대전화에서:
- 사용자가 브라우저에서 example.com으로 이동한 후 지금까지 사용하던 방법 (비밀번호와 같은 레거시 방법일 수 있음)을 사용하여 기존 계정에 로그인하거나 새 계정을 생성한다.
- 휴대전화에 "이 장치를 example.com에 등록하시겠습니까?"라는 메시지가 표시된다.
- 사용자가 동의한다.
- 휴대전화에서 사용자에게 이전에 구성한 승인 제스처(PIN, 생체 인식 등)를 요구하며, 사용자는 이를 제공한다.
- 웹사이트에 "등록이 완료되었습니다."라는 메시지가 표시된다.

1.2.2. 인증

노트북 또는 데스크톱에서:
- 사용자가 Bluetooth를 통해 휴대전화를 노트북 또는 데스크톱과 페어링한다.
- 사용자가 브라우저에서 example.com으로 이동하여 로그인을 시작한다.
- 브라우저에 "휴대전화에서 이 작업을 완료하십시오."라는 메시지가 표시된다.
그다음 휴대전화에서:
- 사용자에게 "example.com에 로그인"이라는 별도의 프롬프트 또는 알림이 표시된다.
- 사용자가 이 프롬프트/알림을 선택한다.
- 사용자에게 example.com의 ID 목록(예: "Mohamed로 로그인 / 张三으로 로그인")이 표시된다.
- 사용자가 ID를 선택하고 승인 제스처(PIN, 생체 인식 등)를 요구받은 후 이를 제공한다.
이제 다시 노트북에서:
- 웹 페이지에 선택한 사용자가 로그인했음이 표시되고 로그인된 페이지로 이동한다.

1.2.3. 새 장치 등록

이 사용 사례 시나리오는 신뢰 당사자가 로밍 인증기(예: USB 보안 키 장치)와 플랫폼 인증기(예: 내장 지문 센서)를 함께 활용하여 사용자가 다음을 보유하도록 할 수 있는 방법을 보여 준다.

처음 사용하는 클라이언트 장치(예: 노트북, 데스크톱) 또는 플랫폼 인증기가 없는 클라이언트 장치에서 인증하는 데 사용하는 "기본" 로밍 인증기, 그리고
플랫폼 인증기가 있는 클라이언트 장치에서 번거로움 없이 강력하게 재인증하는 수단.

참고: 하나의 계정에 여러 인증기를 등록하는 이 접근 방식은 계정 복구 사용 사례에도 유용하다.

먼저 플랫폼 인증기가 없는 데스크톱 컴퓨터에서:
- 사용자가 브라우저에서 example.com으로 이동한 후 지금까지 사용하던 방법 (비밀번호와 같은 레거시 방법일 수 있음)을 사용하여 기존 계정에 로그인하거나 새 계정을 생성한다.
- 사용자가 계정 보안 설정으로 이동하여 "보안 키 등록"을 선택한다.
- 웹사이트에서 USB 보안 키 장치를 연결하라는 메시지가 표시되며 사용자는 이를 연결한다.
- USB 보안 키가 깜박여 버튼을 눌러야 함을 알리며 사용자는 버튼을 누른다.
- 웹사이트에 "등록이 완료되었습니다."라는 메시지가 표시된다.
참고: 이 컴퓨터에는 플랫폼 인증기가 없으므로 웹사이트는 사용자가 웹사이트와 상호작용할 때마다 또는 가끔 USB 보안 키를 제시하도록 요구할 수 있다. 이는 웹사이트의 재량에 따른다.
나중에 플랫폼 인증기가 있는 노트북에서:
- 사용자가 브라우저에서 example.com으로 이동하여 로그인을 시작한다.
- 웹사이트에서 USB 보안 키를 연결하라는 메시지가 표시된다.
- 사용자가 이전에 등록한 USB 보안 키를 연결하고 버튼을 누른다.
- 웹사이트에 사용자가 로그인했음이 표시되고 로그인된 페이지로 이동한다.
- 웹사이트에 "이 컴퓨터를 example.com에 등록하시겠습니까?"라는 메시지가 표시된다.
- 사용자가 동의한다.
- 노트북에서 사용자에게 이전에 구성한 승인 제스처(PIN, 생체 인식 등)를 요구하며 사용자는 이를 제공한다.
- 웹사이트에 "등록이 완료되었습니다."라는 메시지가 표시된다.
- 사용자가 로그아웃한다.
나중에 다시 노트북에서:
- 사용자가 브라우저에서 example.com으로 이동하여 로그인을 시작한다.
- 웹사이트에 "컴퓨터의 안내에 따라 로그인을 완료하십시오."라는 메시지가 표시된다.
- 노트북에서 사용자에게 승인 제스처(PIN, 생체 인식 등)를 요구하며 사용자는 이를 제공한다.
- 웹사이트에 사용자가 로그인했음이 표시되고 로그인된 페이지로 이동한다.

1.2.4. 기타 사용 사례 및 구성

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

사용자가 노트북에서 example.com으로 이동한 후 휴대전화에 자격 증명을 생성하고 등록하는 흐름의 안내를 받는다.
사용자가 USB 또는 USB+NFC/BLE 연결 옵션을 갖춘 "토큰"과 같은 별도의 로밍 인증기를 구한 후, 노트북이나 휴대전화의 브라우저에서 example.com을 열고 토큰에 자격 증명을 생성하고 등록하는 흐름의 안내를 받는다.
신뢰 당사자가 결제 또는 기타 금융 거래와 같은 단일 거래를 승인하기 위해 사용자의 승인 제스처를 요구한다.

1.3. API 사용 예시 시나리오

이 절은 규범적이지 않다.

이 절에서는 공개 키 자격 증명의 수명 주기에서 발생하는 몇 가지 이벤트와 이 API를 사용하는 해당 예제 코드를 살펴본다. 이는 예시 흐름이며 API 사용 방법의 범위를 제한하지 않는다.

앞 절과 마찬가지로 이 흐름은 자체 디스플레이가 있는 1차 요소 로밍 인증기를 사용하는 사례에 초점을 맞춘다. 이러한 인증기의 한 예는 스마트 폰이다. 클라이언트 플랫폼이 구현한다면 이 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",
  },

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

  authenticatorSelection: {
    // 가능한 경우 UV를 사용한다. 이 값은 기본값이기도 하다.
    userVerification: "preferred"
  },

  timeout: 360000,  // 6분
  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"}
  ],

  // excludeCredentials 검사가 U2F에 등록된 자격 증명과 하위 호환되도록 한다.
  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) {
            // 신뢰 당사자별 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: 120000,  // 2분
  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: 120000,  // 2분
  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 == "AbortError") {
            // 자격 증명이 생성되지 않았음을 사용자에게 알린다.
            // 키가 생성되지 않았음을 서버에 알린다.
        }
    });

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

1.3.5. 사용 중단

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

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

1.4. 플랫폼별 구현 지침

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

2. 적합성

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

2.1. 사용자 에이전트

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

적합한 사용자 에이전트는 "Web IDL" 명세에 설명된 대로 이 명세의 IDL 조각에 대한 적합한 구현이어야 한다. [WebIDL]

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

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

2.2. 인증기

WebAuthn 인증기는 § 6 WebAuthn 인증기 모델에서 정의한 작업을 제공해야 하며, 해당 작업은 그곳에 설명된 대로 동작해야 한다. 이는 적합한 사용자 에이전트가 인증기를 사용할 수 있도록 하는 기능 및 보안 요구 사항의 집합이다.

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

2.2.1. FIDO U2F와의 하위 호환성

인증기가 § 8.6 FIDO U2F 증명문 형식만 지원하는 경우에는 사용자 핸들을 저장할 방법이 없으므로 반환되는 userHandle은 항상 null이다.

2.3. WebAuthn 신뢰 당사자

WebAuthn 신뢰 당사자가 이 명세에서 제공하는 모든 보안 이점을 얻으려면 § 7 WebAuthn 신뢰 당사자 작업에 설명된 대로 동작해야 한다. 이에 대한 자세한 설명은 § 13.4.1 WebAuthn 신뢰 당사자의 보안 이점을 참조한다.

2.4. 모든 적합성 클래스

위 적합성 클래스의 구성원이 수행하는 모든 CBOR 인코딩은 반드시 CTAP2 정규 CBOR 인코딩 형식을 사용해야 한다. 위 적합성 클래스의 모든 디코더는 CTAP2 정규 CBOR 인코딩 형식으로 올바르게 인코딩되지 않은 CBOR을 거부하고, 중복된 맵 키가 있는 메시지도 거부하는 것이 좋다.

3. 의존성

이 명세는 아래와 참조를 통해 정의된 용어에 나열된 여러 기반 명세에 의존한다.

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

이 문서에서 사용하는 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 및 "OPTIONAL"은 [RFC2119]에 설명된 대로 해석해야 한다.

4. 용어

증명

일반적으로 증명은 증언하거나 확인하거나 인증하는 역할을 하는 진술이다. 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 인증기는 로밍 인증기, 클라이언트 장치에 통합된 전용 하드웨어 하위 시스템, 또는 클라이언트나 클라이언트 장치의 소프트웨어 구성 요소일 수 있다.

일반적으로 인증기에는 사용자가 한 명뿐이라고 가정한다. 여러 자연인이 하나의 인증기에 대한 접근 권한을 공유하면 해당 인증기의 컨텍스트에서는 이들이 동일한 사용자를 나타내는 것으로 간주한다. 인증기 구현이 분리된 구획에서 여러 사용자를 지원하면 각 구획은 다른 사용자의 자격 증명에 접근할 수 없는 한 명의 사용자가 있는 별도의 인증기로 간주한다.

승인 제스처

승인 제스처는 등록이나 인증과 같은 세레모니의 일부로 사용자가 인증기와 수행하는 물리적 상호작용이다. 사용자는 이러한 승인 제스처를 수행하여 세레모니의 진행에 동의한다(즉, 승인한다). 사용하는 인증기가 이를 지원하면 사용자 검증이 포함될 수 있으며, 그렇지 않으면 간단한 사용자 존재 여부 검사가 포함될 수 있다.

생체 인식

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

생체 인증기

생체 인식을 구현하는 모든 인증기.

바인딩된 자격 증명

공개 키 자격 증명 소스 또는 공개 키 자격 증명은 해당 관리 인증기에 바인딩된다. 이는 관리 인증기만 자신에게 바인딩된 공개 키 자격 증명 소스의 어서션을 생성할 수 있다는 의미이다.

세레모니

세레모니 [Ceremony] 개념은 컴퓨터 노드와 함께 사람 노드를 포함하고 사용자 인터페이스, 사람 간 통신 및 데이터를 전달하는 물리적 객체의 이동을 포함하는 통신 링크를 갖도록 네트워크 프로토콜의 개념을 확장한 것이다. 프로토콜에서 대역 외인 것은 세레모니에서 대역 내이다. 이 명세에서는 등록과 인증이 세레모니이며, 승인 제스처는 이러한 세레모니의 구성 요소인 경우가 많다.

클라이언트

WebAuthn 클라이언트

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

WebAuthn 클라이언트는 WebAuthn 클라이언트 장치에서 실행되며 이 장치와는 별개이다.

클라이언트 장치

WebAuthn 클라이언트 장치

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

WebAuthn 클라이언트 장치와 클라이언트의 차이점은 다음과 같다.

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

클라이언트 장치와 클라이언트가 함께 클라이언트 플랫폼을 구성한다.

클라이언트 플랫폼

클라이언트 장치와 클라이언트가 함께 클라이언트 플랫폼을 구성한다. 하나의 하드웨어 장치는 서로 다른 운영 체제 및/또는 클라이언트를 실행함으로써 시간에 따라 여러 개별 클라이언트 플랫폼의 일부가 될 수 있다.

클라이언트 측

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

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

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

검색 가능한 자격 증명

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

[사용 중단됨] 상주 키

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

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

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

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

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

적합한 사용자 에이전트

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

자격 증명 ID

공개 키 자격 증명 소스와 해당 인증 어서션을 식별하는 확률적으로 고유한 바이트 시퀀스이다.

자격 증명 ID는 인증기가 다음 두 형식 중 하나로 생성한다.

100비트 이상의 엔트로피를 포함하는 16바이트 이상의 값, 또는
자격 증명 ID와 변경 가능한 항목을 제외한 공개 키 자격 증명 소스를 해당 관리 인증기만 복호화할 수 있도록 암호화한 값. 이 형식을 사용하면 신뢰 당사자가 필요한 상태를 저장하므로 인증기를 거의 무상태로 만들 수 있다.

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

신뢰 당사자는 이 두 자격 증명 ID 형식을 구분할 필요가 없다.

자격 증명 키 쌍

자격 증명 비공개 키

자격 증명 공개 키

사용자 공개 키

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

자격 증명 공개 키는 자격 증명 키 쌍의 공개 키 부분이다. 자격 증명 공개 키는 등록 세레모니 중 신뢰 당사자에게 반환된다.

자격 증명 비공개 키는 자격 증명 키 쌍의 비공개 키 부분이다. 자격 증명 비공개 키는 특정 인증기, 즉 해당 관리 인증기에 바인딩되며 인증기 소유자를 포함한 다른 누구에게도 절대 노출되지 않아야 한다.

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

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

자격 증명 속성

자격 증명 속성은 공개 키 자격 증명 소스가 클라이언트 측 검색 가능한 자격 증명인지 서버 측 자격 증명인지와 같은 특성이다.

사람 친화성

사람 친화적인 식별자는 무작위로 생성된 비트 시퀀스와 같은 식별자와 달리 일반적인 사용자가 기억하고 재현할 수 있도록 고안된 식별자이다 [EduPersonObjectClassSpec].

검색 불가능한 자격 증명

클라이언트 측에서 검색할 수 없으므로 navigator.credentials.get()을 호출할 때 allowCredentials에 자격 증명 ID를 제공해야 하는 자격 증명이다. 서버 측 자격 증명도 참조한다.

공개 키 자격 증명 소스

자격 증명 소스([CREDENTIAL-MANAGEMENT-1])로, 인증기가 인증 어서션을 생성하는 데 사용한다. 공개 키 자격 증명 소스는 다음 항목으로 구성된 구조체이다.

type: 값은 PublicKeyCredentialType이며, 기본값은 public-key이다.
id: 자격 증명 ID.
privateKey: 자격 증명 비공개 키.
rpId: 이 신뢰 당사자 식별자는 신뢰 당사자를 나타내며, 이 공개 키 자격 증명 소스는 해당 당사자로 범위가 지정된다.
userHandle: 이 공개 키 자격 증명 소스가 생성될 때 연결된 사용자 핸들. 이 항목에는 null을 사용할 수 있다.
otherUI: 인증기가 자신의 UI에 정보를 제공하는 데 사용하는 선택적인 기타 정보. 예를 들어 사용자의 displayName이 포함될 수 있다. otherUI는 변경 가능한 항목이며, otherUI가 업데이트되지 못하도록 공개 키 자격 증명 소스에 바인딩해서는 안 된다.

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

공개 키 자격 증명

일반적으로 자격 증명은 한 엔터티가 자신을 다른 엔터티에 인증하기 위해 제시하는 데이터이다 [RFC4949]. 공개 키 자격 증명이라는 용어는 다음 중 하나를 의미한다. 공개 키 자격 증명 소스, 공개 키 자격 증명 소스에 해당하며 증명되었을 수 있는 자격 증명 공개 키, 또는 인증 어서션. 일반적으로 어느 것을 의미하는지는 컨텍스트에 따라 결정된다.

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

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

등록 시 인증기는 비대칭 키 쌍을 생성한 후 비공개 키 부분과 신뢰 당사자가 제공한 정보를 공개 키 자격 증명 소스에 저장한다. 공개 키 부분은 신뢰 당사자에게 반환되며, 신뢰 당사자는 이를 현재 사용자의 계정과 함께 저장한다. 이후에는 해당 신뢰 당사자만 자신의 RP ID로 식별되어 get() 메서드를 통해 인증 세레모니에서 공개 키 자격 증명을 사용할 수 있다. 신뢰 당사자는 저장된 자격 증명 공개 키 사본을 사용하여 결과로 생성된 인증 어서션을 검증한다.

속도 제한

인증기가 일정 기간 내에 연속으로 실패한 인증 시도 횟수를 제한하여 무차별 대입 공격에 대한 제어를 구현하는 프로세스로, 스로틀링이라고도 한다. 한도에 도달하면 인증기는 연속된 시도마다 기하급수적으로 증가하는 지연을 적용하거나, 현재 인증 방식을 비활성화하고 사용할 수 있는 경우 다른 인증 요소를 제공하는 것이 좋다. 속도 제한은 흔히 사용자 검증의 한 측면으로 구현된다.

등록

등록 세레모니

사용자, 신뢰 당사자 및 하나 이상의 인증기를 포함한 사용자의 클라이언트가 협력하여 공개 키 자격 증명을 생성하고 사용자의 신뢰 당사자 계정과 연결하는 세레모니이다. 여기에는 사용자 존재 여부 검사 또는 사용자 검증의 사용이 포함된다. 등록 세레모니가 성공하면 인증 세레모니를 통해 사용자를 인증할 수 있다.

WebAuthn 등록 세레모니는 § 7.1 새 자격 증명 등록에서 정의되며, 신뢰 당사자가 publicKey 인수를 사용하여 navigator.credentials.create()을 호출하면 시작된다. 소개 개요는 § 5 웹 인증 API를 참조하고 구현 예제는 § 1.3.1 등록을 참조한다.

신뢰 당사자

WebAuthn 신뢰 당사자를 참조한다.

신뢰 당사자 식별자

RP ID

WebAuthn API 컨텍스트에서 신뢰 당사자 식별자는 특정 등록 또는 인증 세레모니가 대신 수행되는 WebAuthn 신뢰 당사자를 식별하는 유효한 도메인 문자열이다. 공개 키 자격 증명은 자신을 등록한 동일한 엔터티 (RP ID로 식별됨)에서의 인증에만 사용할 수 있다.

기본적으로 WebAuthn 작업의 RP ID는 호출자 출처의 유효 도메인으로 설정된다. 호출자가 지정한 RP ID 값이 호출자 출처의 유효 도메인과 동일하거나 그 도메인의 등록 가능한 도메인 접미사이면 호출자가 이 기본값을 재정의할 수 있다. § 5.1.3 새 자격 증명 생성 - PublicKeyCredential의 [[Create]](origin, options, sameOriginWithAncestors) 메서드 및 § 5.1.4 기존 자격 증명을 사용하여 어서션 생성 - PublicKeyCredential의 [[Get]](options) 메서드도 참조한다.

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

RP ID는 출처의 유효 도메인과 동일하거나 해당 출처 유효 도메인의 등록 가능한 도메인 접미사여야 한다.
출처의 스킴은 https여야 한다.
출처의 포트에는 제한이 없다.

예를 들어 출처가 https://login.example.com:1337인 신뢰 당사자의 경우 다음 RP ID가 유효하다. login.example.com (기본값) 및 example.com. 그러나 m.login.example.com과 com은 유효하지 않다.

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

출처 값에 대한 이러한 제한은 WebAuthn 클라이언트에 적용된다.

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

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

서버 측 자격 증명

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

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

서버 측 공개 키 자격 증명 소스, 줄여서 서버 측 자격 증명은 신뢰 당사자가 navigator.credentials.get()의 allowCredentials 인수에 자신의 자격 증명 ID를 제공한 인증 세레모니에서만 사용할 수 있는 공개 키 자격 증명 소스이다. 이는 신뢰 당사자가 자격 증명의 저장과 검색을 관리하고, navigator.credentials.get() 호출에 제공할 자격 증명 ID를 검색하려면 먼저 사용자를 식별할 수 있어야 한다는 의미이다.

서버 측 자격 증명에는 공개 키 자격 증명 소스의 클라이언트 측 저장이 필요하지 않다. 이와 대조적으로 클라이언트 측 검색 가능한 자격 증명은 navigator.credentials.get() 호출에 사용자의 자격 증명 ID를 제공하기 위해 사용자를 먼저 식별할 필요가 없다.

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

사용자 존재 여부 검사

사용자 존재 테스트는 간단한 형태의 승인 동작이자 기술적 절차로, 사용자가 일반적으로 인증기를 단순히 터치하여 상호 작용하며(다른 방식도 존재할 수 있음), 그 결과로 부울 값을 생성한다. 이는 사용자 검증에 해당하지 않는다는 점에 유의한다. 정의상 사용자 존재 테스트는 생체 인식을 수행할 수 없고, 비밀번호나 PIN과 같은 공유 비밀의 제시도 수반하지 않기 때문이다.

사용자 동의

사용자 동의는 사용자가 요청받은 내용에 동의한다는 의미이며, 프롬프트를 읽고 이해하는 것을 포함한다. 승인 제스처는 사용자 동의를 나타내는 데 흔히 사용되는 세레모니 구성 요소이다.

사용자 핸들

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

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

사용자 검증

인증기가 authenticatorMakeCredential 및 authenticatorGetAssertion 작업의 호출을 로컬에서 승인하는 기술적 프로세스이다. 사용자 검증은 터치와 PIN 코드의 조합, 비밀번호 입력 또는 생체 인식(예: 지문 제시)과 같은 다양한 승인 제스처 방식으로 시작될 수 있다 [ISOBiometricVocabulary]. 그 목적은 개별 사용자를 구분하는 것이다.

사용자 검증은 신뢰 당사자에게 사용자의 구체적인 식별 정보를 제공하지는 않는다. 그러나 해당 자격 증명을 사용하여 사용자 검증을 포함한 세레모니를 두 번 이상 수행한 경우, 모든 세레모니를 수행한 사용자가 동일한 사용자였음을 나타낸다. 다만 여러 자연인이 동일한 인증기에 대한 접근 권한을 공유하면 동일한 사용자가 항상 동일한 자연인을 의미하지는 않을 수 있다.

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

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

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

사용자 검증 절차는 무차별 대입 공격으로부터 보호하기 위해 속도 제한을 구현할 수 있다.

사용자 존재

UP

사용자 존재 여부 검사가 성공적으로 완료되면 사용자가 "존재한다"고 한다.

검증된 사용자

UV

사용자 검증 프로세스가 성공적으로 완료되면 사용자가 "검증되었다"고 한다.

WebAuthn 신뢰 당사자

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

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

참고: 신뢰 당사자라는 용어는 다른 컨텍스트(예: X.509 및 OAuth)에서도 자주 사용되지만 한 컨텍스트에서 신뢰 당사자로 동작하는 엔터티가 다른 컨텍스트에서도 반드시 신뢰 당사자인 것은 아니다. 이 명세에서는 WebAuthn 신뢰 당사자라는 용어를 흔히 단순히 신뢰 당사자로 줄여 부르며 WebAuthn 컨텍스트의 신뢰 당사자를 명시적으로 가리킨다. 구체적인 인스턴스에서는 WebAuthn 컨텍스트가 OAuth 기반 컨텍스트와 같은 더 광범위한 전체 컨텍스트에 포함될 수 있다는 점에 유의한다.

5. 웹 인증 API

이 절에서는 공개 키 자격 증명을 생성하고 사용하는 API를 규범적으로 명시한다. 기본 개념은 자격 증명이 사용자에게 속하며 관리 주체인 WebAuthn 인증기를 WebAuthn 신뢰 당사자가 클라이언트 플랫폼을 통해 사용한다는 것이다. 신뢰 당사자 스크립트는 (사용자의 동의를 얻어) 브라우저에 신뢰 당사자가 나중에 사용할 새 자격 증명을 생성하도록 요청할 수 있다. 아래의 그림 을 참조한다.

스크립트는 기존 자격 증명을 사용하여 인증 작업을 수행할 권한을 사용자에게 요청할 수도 있다. 아래의 그림 을 참조한다.

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

인증기는 위의 스크립트 인터페이스 외에도 관리용 사용자 인터페이스를 구현하거나 이를 구현하는 클라이언트 소프트웨어와 함께 제공될 수 있다. 이러한 인터페이스는 예를 들어 인증기를 초기 상태로 재설정하거나 인증기의 현재 상태를 검사하는 데 사용될 수 있다. 즉, 이러한 인터페이스는 방문 기록, 저장된 비밀번호 및 쿠키와 같은 사용자 상태를 관리하기 위해 브라우저가 제공하는 사용자 인터페이스와 유사하다. 자격 증명 삭제와 같은 인증기 관리 작업은 이러한 사용자 인터페이스가 담당하는 것으로 간주되며 스크립트에 노출되는 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

현재 모든 엔진에서 지원된다.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge(레거시)18IE없음

Android용 Firefox60+iOS Safari13.3+Android용 Chrome70+Android WebView70+Samsung Internet없음Opera Mobile없음

PublicKeyCredential 인터페이스는 Credential [CREDENTIAL-MANAGEMENT-1]을 상속하며, 새 자격 증명을 생성하거나 새 어서션을 요청할 때 호출자에게 반환되는 특성을 포함한다.

PublicKeyCredential/getClientExtensionResults

현재 모든 엔진에서 지원된다.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge(레거시)18IE없음

Android용 Firefox60+iOS Safari13.3+Android용 Chrome70+Android WebView70+Samsung Internet없음Opera Mobile없음

PublicKeyCredential/rawId

현재 모든 엔진에서 지원된다.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge(레거시)18IE없음

Android용 Firefox60+iOS Safari13.3+Android용 Chrome70+Android WebView70+Samsung Internet없음Opera Mobile없음

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

id

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

rawId

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

PublicKeyCredential/response 현재 모든 엔진에서 지원된다. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge(레거시)18IE없음 Android용 Firefox60+iOS Safari13.3+Android용 Chrome70+Android WebView70+Samsung Internet없음Opera Mobile없음 response, 유형은 AuthenticatorResponse, 읽기 전용

이 속성에는 인증기가 공개 키 자격 증명을 생성하거나 인증 어서션을 생성하라는 클라이언트의 요청에 보낸 응답이 들어 있다. PublicKeyCredential이 create()에 대한 응답으로 생성된 경우, 이 속성의 값은 AuthenticatorAttestationResponse이다. 그렇지 않으면 PublicKeyCredential은 get()에 대한 응답으로 생성된 것이며, 이 속성의 값은 AuthenticatorAssertionResponse이다.

getClientExtensionResults()

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

[[type]]

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

참고: 이는 Credential에서 상속된 type 속성 getter에 반영된다.

[[discovery]]

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

[[identifier]]

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

참고: 이 API는 식별자가 인증기에서 키 하나를 고유하게 선택하기에 충분해야 한다는 점 외에는 식별자의 형식이나 길이를 제한하지 않는다. 예를 들어 내장 저장소가 없는 인증기는 인증기에 내장된 대칭 키로 래핑된 자격 증명 개인 키를 포함하는 식별자를 생성할 수 있다.

[[clientExtensionsResults]]

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

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

5.1.1. `CredentialCreationOptions` 사전 확장

navigator.credentials.create()을 통한 등록을 지원하기 위해 이 문서는 CredentialCreationOptions 사전을 다음과 같이 확장한다.

partial dictionary CredentialCreationOptions {
    PublicKeyCredentialCreationOptions      publicKey;
};

5.1.2. `CredentialRequestOptions` 사전 확장

navigator.credentials.get()을 통한 어서션 획득을 지원하기 위해 이 문서는 CredentialRequestOptions 사전을 다음과 같이 확장한다.

partial dictionary CredentialRequestOptions {
    PublicKeyCredentialRequestOptions      publicKey;
};

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

PublicKeyCredential의 인터페이스 객체가

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

내부 메서드를 구현한 것은 [CREDENTIAL-MANAGEMENT-1]에 따라 WebAuthn 신뢰 당사자 스크립트가 navigator.credentials.create()를 호출하여 새로운 공개 키 자격 증명 소스의 생성을 요청할 수 있게 하며, 그 소스는 바인딩을 통해 인증기에 연결된다. 이 navigator.credentials.create() 작업은 AbortController를 활용하여 중단할 수 있다. 자세한 지침은 DOM §3.3 API에서 AbortController 및 AbortSignal 객체 사용하기를 참조한다.

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

origin

이 인수는 관련 설정 객체의 출처이며, 호출하는 create() 구현이 이를 결정한다.

options

이 인수는 CredentialCreationOptions 객체이며, 그 options.publicKey 멤버에는 생성할 공개 키 자격 증명에 필요한 특성을 지정하는 PublicKeyCredentialCreationOptions 객체가 들어 있다.

sameOriginWithAncestors

이 인수는 호출자의 환경 설정 객체가 상위 요소들과 동일 출처인 경우에만 true인 부울 값이다. 호출자가 교차 출처인 경우에는 false이다.

참고: 이 내부 메서드의 호출은 [CREDENTIAL-MANAGEMENT-1] 계층에서 평가되는 권한 정책이 이를 허용했음을 나타낸다. § 5.9 권한 정책 통합을 참조한다.

참고: 이 알고리즘은 동기식이다. Promise의 이행/거부는 navigator.credentials.create()가 처리한다.

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

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

단언: options.publicKey 가 존재한다.
sameOriginWithAncestors가 false이면 "NotAllowedError" DOMException을 반환한다.

참고: 이 "sameOriginWithAncestors" 제한은 이슈 #1336에서 제기된 추적 문제를 해결하기 위한 것이다. 이 제한은 이 명세의 향후 버전에서 개정될 수 있다.
options를 options.publicKey의 값으로 둔다.
options의 timeout 멤버가 존재하면 그 값이 클라이언트가 정의한 합리적인 범위 안에 있는지 확인하고, 그렇지 않으면 해당 범위 안에서 가장 가까운 값으로 보정한다. 타이머 lifetimeTimer를 이 보정된 값으로 설정한다. options의 timeout 멤버가 존재하지 않으면 lifetimeTimer를 클라이언트별 기본값으로 설정한다.

options의 timeout 멤버에 권장되는 범위와 기본값은 다음과 같다. 다음 options.authenticatorSelection.userVerification의 경우

discouraged로 설정됨

권장 범위: 30000밀리초에서 180000밀리초.

권장 기본값: 120000밀리초(2분).

required 또는 preferred로 설정됨

권장 범위: 30000밀리초에서 600000밀리초.

권장 기본값: 300000밀리초(5분).

참고: 사용자 에이전트는 특별한 요구가 있는 사용자의 시간 초과와 관련하여 인지 지침을 고려하는 것이 좋다.
options.user.id의 길이가 1바이트에서 64바이트 사이(양 끝 포함)가 아니면 TypeError를 반환한다.
callerOrigin을 origin으로 둔다. callerOrigin이 불투명 출처이면 이름이 "NotAllowedError"인 DOMException을 반환하고 이 알고리즘을 종료한다.
effectiveDomain을 callerOrigin의 유효 도메인으로 둔다. 유효 도메인이 유효한 도메인이 아니면 이름이 "SecurityError"인 DOMException을 반환하고 이 알고리즘을 종료한다.

참고: 유효 도메인은 호스트로 해석될 수 있으며, 호스트는 도메인, IPv4 주소, IPv6 주소, 불투명 호스트 또는 빈 호스트 등 여러 방식으로 표현될 수 있다. 여기서는 호스트의 도메인 형식만 허용된다. 이는 단순화를 위한 것이며 PKI 기반 보안과 함께 직접 IP 주소 식별을 사용할 때 발생하는 여러 문제를 고려한 것이기도 하다.
options.rp.id가

존재함

options.rp.id가 effectiveDomain의 등록 가능한 도메인 접미사가 아니고 그와 같지도 않으면, 이름이 "SecurityError"인 DOMException을 반환하고 이 알고리즘을 종료한다.

존재하지 않음

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

참고: options.rp.id는 호출자의 RP ID를 나타낸다. 호출자가 create()를 호출할 때 options.rp.id를 명시적으로 설정하지 않는 한 RP ID의 기본값은 호출자 출처의 유효 도메인이다.
credTypesAndPubKeyAlgs를 PublicKeyCredentialType과 COSEAlgorithmIdentifier의 쌍을 항목으로 갖는 새로운 목록으로 둔다.
options.pubKeyCredParams의 크기가
0임
다음 PublicKeyCredentialType과 COSEAlgorithmIdentifier 값의 쌍을 credTypesAndPubKeyAlgs에 추가한다.
- public-key 및 -7("ES256").
- public-key 및 -257("RS256").
0이 아님
options.pubKeyCredParams의 각 current에 대해 반복한다.
1. current.type에 이 구현이 지원하는 PublicKeyCredentialType이 포함되어 있지 않으면 계속한다.
2. alg를 current.alg로 둔다.
3. current.type과 alg의 쌍을 credTypesAndPubKeyAlgs에 추가한다.
credTypesAndPubKeyAlgs가 비어 있으면, 이름이 "NotSupportedError"인 DOMException을 반환하고 이 알고리즘을 종료한다.
clientExtensions를 새로운 맵으로, authenticatorExtensions를 새로운 맵으로 둔다.
options의 extensions 멤버가 존재하면 options.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

options.challenge의 base64url 인코딩.

origin

callerOrigin의 직렬화.

crossOrigin

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

tokenBinding

클라이언트와 callerOrigin 사이의 토큰 바인딩 상태와, 사용할 수 있는 경우 callerOrigin에 연결된 토큰 바인딩 ID.
clientDataJSON을 collectedClientData에서 생성한 클라이언트 데이터의 JSON 호환 직렬화로 둔다.
clientDataHash를 clientDataJSON이 나타내는 직렬화된 클라이언트 데이터의 해시로 둔다.
options.signal이 존재하고 그 중단됨 플래그가 true로 설정되어 있으면, 이름이 "AbortError"인 DOMException을 반환하고 이 알고리즘을 종료한다.
issuedRequests를 새로운 순서 있는 집합으로 둔다.
authenticators는 임의의 시점마다 집합인 값을 나타내며, 각 항목은 해당 시점에 이 클라이언트 플랫폼에서 현재 사용할 수 있는 인증기를 식별하는 클라이언트 플랫폼별 핸들이다.

참고: 인증기가 "사용 가능"한 것으로 간주되는 조건은 의도적으로 지정하지 않았다. 이는 다양한 메커니즘을 통해 인증기를 핫 플러그하거나(예: USB를 통해) 클라이언트가 검색하거나(예: NFC 또는 Bluetooth를 통해), 클라이언트에 영구적으로 내장할 수 있는 방식을 나타내기 위한 것이다.
lifetimeTimer를 시작한다.
lifetimeTimer가 만료되지 않은 동안, lifetimeTimer와 authenticators에 있는 각 authenticator의 상태 및 응답에 따라 다음 작업을 수행한다.
lifetimeTimer가 만료되면,

issuedRequests의 각 authenticator에 authenticatorCancel 작업을 호출하고 authenticator를 issuedRequests에서 제거한다.

사용자가 사용자 에이전트 사용자 인터페이스의 처리 취소 옵션을 실행하면,

issuedRequests의 각 authenticator에 authenticatorCancel 작업을 호출하고 authenticator를 issuedRequests에서 제거한다. 이름이 "NotAllowedError"인 DOMException을 반환한다.

options.signal이 존재하고 그 중단됨 플래그가 true로 설정되어 있으면,

issuedRequests의 각 authenticator에 authenticatorCancel 작업을 호출하고 authenticator를 issuedRequests에서 제거한다. 그런 다음 이름이 "AbortError"인 DOMException을 반환하고 이 알고리즘을 종료한다.

이 클라이언트 장치에서 authenticator를 사용할 수 있게 되면,
참고: 여기에는 lifetimeTimer를 시작할 때 이미 authenticator를 사용할 수 있었던 경우도 포함된다.
1. 이제 이 authenticator가 후보 인증기이다.
2. options.authenticatorSelection이 존재하면 다음을 수행한다.
  1. options.authenticatorSelection.authenticatorAttachment가 존재하고 그 값이 authenticator의 인증기 부착 방식과 같지 않으면 계속한다.
  2. options.authenticatorSelection.residentKey가
    
    존재하며 required로 설정됨
    
    authenticator가 클라이언트 측 검색 가능 공개 키 자격 증명 소스를 저장할 수 없으면 계속한다.
    
    존재하며 preferred 또는 discouraged로 설정됨
    
    효과 없음.
    
    존재하지 않음
    
    options.authenticatorSelection.requireResidentKey가 true로 설정되어 있고 authenticator가 클라이언트 측 검색 가능 공개 키 자격 증명 소스를 저장할 수 없으면 계속한다.
  3. options.authenticatorSelection.userVerification이 required로 설정되어 있고 authenticator가 사용자 검증을 수행할 수 없으면 계속한다.
3. requireResidentKey를 다음과 같은 부울 값인 자격 증명 생성을 위한 유효 상주 키 요구사항으로 둔다.
  
  options.authenticatorSelection.residentKey가
  
  존재하며 required로 설정됨
  
  requireResidentKey를 true로 둔다.
  
  존재하며 preferred로 설정됨
  
  authenticator가
  
  클라이언트 측 자격 증명 저장 방식을 지원함
  
  requireResidentKey를 true로 둔다.
  
  클라이언트 측 자격 증명 저장 방식을 지원하지 않거나 클라이언트가 인증기의 기능을 판단할 수 없음
  
  requireResidentKey를 false로 둔다.
  
  존재하며 discouraged로 설정됨
  
  requireResidentKey를 false로 둔다.
  
  존재하지 않음
  
  requireResidentKey를 options.authenticatorSelection.requireResidentKey의 값으로 둔다.
4. userVerification을 다음과 같은 부울 값인 자격 증명 생성을 위한 유효 사용자 검증 요구사항으로 둔다. options.authenticatorSelection.userVerification이
  
  required로 설정됨
  
  userVerification을 true로 둔다.
  
  preferred로 설정됨
  
  authenticator가
  
  사용자 검증을 수행할 수 있음
  
  userVerification을 true로 둔다.
  
  사용자 검증을 수행할 수 없음
  
  userVerification을 false로 둔다.
  
  discouraged로 설정됨
  
  userVerification을 false로 둔다.
5. enterpriseAttestationPossible을 다음과 같은 부울 값으로 둔다. options.attestation이
  
  enterprise로 설정됨
  
  사용자 에이전트가 options.rp.id에 대해 엔터프라이즈 증명을 지원하려는 경우 enterpriseAttestationPossible을 true로 둔다 (위의 8단계 참조). 그렇지 않으면 false로 둔다.
  
  그 밖의 경우
  
  enterpriseAttestationPossible을 false로 둔다.
6. excludeCredentialDescriptorList를 새로운 목록으로 둔다.
7. options.excludeCredentials의 각 자격 증명 설명자 C에 대해 반복한다.
  1. C.transports가 비어 있지 않고, authenticator가 C.transports에 언급되지 않은 전송 수단으로 연결되어 있으면 클라이언트는 계속할 수 있다.
    
    참고: 클라이언트가 계속하기로 선택한 경우, C.transports의 전송 수단 힌트가 정확하지 않으면 같은 인증기에 바인딩된 여러 자격 증명이 의도치 않게 등록될 수 있다. 예를 들어 소프트웨어 업그레이드로 새로운 연결 옵션이 추가되면 저장된 전송 수단 힌트가 부정확해질 수 있다.
  2. 그렇지 않으면 C를 excludeCredentialDescriptorList에 추가한다.
  3. clientDataHash, options.rp, options.user, requireResidentKey, userVerification, credTypesAndPubKeyAlgs, excludeCredentialDescriptorList, enterpriseAttestationPossible, authenticatorExtensions를 매개변수로 사용하여 authenticator에서 authenticatorMakeCredential 작업을 호출한다.
8. 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을 반환하고 이 알고리즘을 종료한다.
참고: 이 오류 상태는 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
  
  options.attestation의 값을 값으로 갖는다.
  
  clientExtensionResults
  
  확장 식별자 → 클라이언트 확장 출력 항목을 포함하는 AuthenticationExtensionsClientOutputs 객체를 값으로 갖는다. 이 항목들은 options.extensions의 각 클라이언트 확장에 대해 각 확장의 클라이언트 확장 처리 알고리즘을 실행하여 클라이언트 확장 출력을 생성함으로써 만들어진다.
3. constructCredentialAlg를 전역 객체 global을 받으며 다음 단계를 수행하는 알고리즘으로 둔다.
  1. credentialCreationData.attestationConveyancePreferenceOption의 값이 다음과 같으면
    
    "none"
    
    잠재적으로 개인을 고유하게 식별할 수 있는 정보를 같은 정보의 비식별 버전으로 대체한다.
    
    증명된 자격 증명 데이터의 AAGUID가 16개의 0 바이트이고, credentialCreationData.attestationObjectResult.fmt가 "packed"이며, credentialCreationData.attestationObjectResult에 "x5c"가 없으면 자체 증명이 사용 중이므로 추가 작업이 필요하지 않다.
    
    그렇지 않으면
    
    증명된 자격 증명 데이터의 AAGUID를 16개의 0 바이트로 대체한다.
    
    credentialCreationData.attestationObjectResult.fmt의 값을 "none"으로 설정하고, credentialCreationData.attestationObjectResult.attStmt의 값을 빈 CBOR 맵으로 설정한다. (§ 8.7 없음 증명 구문 형식 및 § 6.5.4 증명 객체 생성 참조).
    
    "indirect"
    
    클라이언트는 AAGUID와 증명 구문을 같은 데이터의 개인정보 보호에 더 유리하거나 더 쉽게 검증할 수 있는 버전으로 대체할 수 있다(예: 익명화 CA 사용).
    
    "direct" 또는 "enterprise"
    
    인증기의 AAGUID와 증명 구문을 변경하지 않고 신뢰 당사자에게 전달한다.
  2. attestationObject를 credentialCreationData.attestationObjectResult의 값에 해당하는 바이트를 포함하고 global의 %ArrayBuffer%를 사용해 생성한 새로운 ArrayBuffer로 둔다.
  3. id를 attestationObject.authData.attestedCredentialData.credentialId로 둔다.
  4. pubKeyCred를 global과 연결되고 다음 필드를 갖는 새로운 PublicKeyCredential 객체로 둔다.
    
    [[identifier]]
    
    id
    
    response
    
    global과 연결되고 다음 필드를 갖는 새로운 AuthenticatorAttestationResponse 객체.
    
    clientDataJSON
    
    credentialCreationData.clientDataJSONResult의 바이트를 포함하고 global의 %ArrayBuffer%를 사용해 생성한 새로운 ArrayBuffer.
    
    attestationObject
    
    attestationObject
    
    [[transports]]
    
    authenticator가 지원한다고 여겨지는, 사전식 순서로 정렬된 0개 이상의 고유한 DOMString 시퀀스. 값은 AuthenticatorTransport의 멤버인 것이 좋지만 클라이언트 플랫폼은 반드시 알 수 없는 값을 무시해야 한다.
    
    사용자 에이전트가 이 정보를 공개하기를 원하지 않으면 개인정보 보호를 위해 설계된 임의의 시퀀스로 대체할 수 있다. 이 시퀀스는 여전히 유효해야 한다. 즉, 사전식으로 정렬되고 중복이 없어야 한다. 예를 들어 빈 시퀀스를 사용할 수 있다. 어느 쪽이든 이 경우 사용자 에이전트는 신뢰 당사자의 동작이 최적이 아닐 수 있다는 위험을 감수한다.
    
    사용자 에이전트에 전송 수단 정보가 없으면 이 필드를 빈 시퀀스로 설정하는 것이 좋다.
    
    참고: 사용자 에이전트가 특정 인증기에서 지원하는 전송 수단을 발견하는 방법은 이 명세의 범위를 벗어나지만, 증명 인증서의 정보(예: [FIDO-Transports-Ext]), CTAP2 같은 인증기 프로토콜에서 전달된 메타데이터 또는 플랫폼 인증기에 관한 특별한 지식이 포함될 수 있다.
    
    [[clientExtensionsResults]]
    
    credentialCreationData.clientExtensionResults의 바이트를 포함하고 global의 %ArrayBuffer%를 사용해 생성한 새로운 ArrayBuffer.
  5. pubKeyCred를 반환한다.
4. issuedRequests에 남아 있는 각 authenticator에서 authenticatorCancel 작업을 호출하고 해당 항목을 issuedRequests에서 제거한다.
5. constructCredentialAlg를 반환하고 이 알고리즘을 종료한다.
이름이 "NotAllowedError"인 DOMException을 반환한다. 사용자를 동의 없이 식별할 수 있는 정보의 유출을 방지하기 위해 이 단계는 lifetimeTimer가 만료되기 전에 절대로 실행해서는 안 된다. 자세한 내용은 § 14.5.1 등록 세리머니 개인정보 보호를 참조한다.

위 과정 중에 사용자 에이전트는 인증기를 선택하고 승인하는 과정을 안내하는 UI를 사용자에게 표시하는 것이 좋다.

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

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

get() 구현 [CREDENTIAL-MANAGEMENT-1]은 PublicKeyCredential.[[CollectFromCredentialStore]]()을 호출하여 사용자 개입 없이 사용할 수 있어야 하는 모든 자격 증명을 수집한다(대략 이 명세의 승인 동작에 해당함). 이러한 자격 증명을 정확히 하나 찾지 못하면 사용자가 자격 증명 소스를 선택하도록 PublicKeyCredential.[[DiscoverFromExternalSource]]()을 호출한다.

이 명세에서는 모든 자격 증명을 생성할 때 승인 동작을 요구하므로, PublicKeyCredential.[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 내부 메서드는 빈 집합을 반환하는 Credential.[[CollectFromCredentialStore]]()의 기본 동작을 상속한다.

이 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인 부울 값이다. 호출자가 교차 출처인 경우에는 false이다.

참고: 이 내부 메서드의 호출은 [CREDENTIAL-MANAGEMENT-1] 계층에서 평가되는 권한 정책이 이를 허용했음을 나타낸다. § 5.9 권한 정책 통합을 참조한다.

참고: 이 알고리즘은 동기식이다. Promise의 이행/거부는 navigator.credentials.get()이 처리한다.

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

단언: options.publicKey 가 존재한다.
options를 options.publicKey의 값으로 둔다.
options의 timeout 멤버가 존재하면 그 값이 클라이언트가 정의한 합리적인 범위 안에 있는지 확인하고, 그렇지 않으면 해당 범위 안에서 가장 가까운 값으로 보정한다. 타이머 lifetimeTimer를 이 보정된 값으로 설정한다. options의 timeout 멤버가 존재하지 않으면 lifetimeTimer를 클라이언트별 기본값으로 설정한다.

options의 timeout 멤버에 권장되는 범위와 기본값은 다음과 같다. 다음 options.userVerification의 경우

discouraged로 설정됨

권장 범위: 30000밀리초에서 180000밀리초.

권장 기본값: 120000밀리초(2분).

required 또는 preferred로 설정됨

권장 범위: 30000밀리초에서 600000밀리초.

권장 기본값: 300000밀리초(5분).

참고: 사용자 에이전트는 특별한 요구가 있는 사용자의 시간 초과와 관련하여 인지 지침을 고려하는 것이 좋다.
callerOrigin을 origin으로 둔다. callerOrigin이 불투명 출처이면 이름이 "NotAllowedError"인 DOMException을 반환하고 이 알고리즘을 종료한다.
effectiveDomain을 callerOrigin의 유효 도메인으로 둔다. 유효 도메인이 유효한 도메인이 아니면 이름이 "SecurityError"인 DOMException을 반환하고 이 알고리즘을 종료한다.

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

type

문자열 "webauthn.get".

challenge

options.challenge의 base64url 인코딩

origin

callerOrigin의 직렬화.

crossOrigin

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

tokenBinding

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

참고: 인증기가 "사용 가능"한 것으로 간주되는 조건은 의도적으로 지정하지 않았다. 이는 다양한 메커니즘을 통해 인증기를 핫 플러그하거나(예: USB를 통해) 클라이언트가 검색하거나(예: NFC 또는 Bluetooth를 통해), 클라이언트에 영구적으로 내장할 수 있는 방식을 나타내기 위한 것이다.
lifetimeTimer를 시작한다.
lifetimeTimer가 만료되지 않은 동안, lifetimeTimer와 authenticators에 있는 각 authenticator의 상태 및 응답에 따라 다음 작업을 수행한다.
lifetimeTimer가 만료되면,

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

사용자가 사용자 에이전트 사용자 인터페이스의 처리 취소 옵션을 실행하면,

issuedRequests의 각 authenticator에서 authenticatorCancel 작업을 호출하고, authenticator를 issuedRequests에서 제거한다. DOMException을 반환한다. 그 이름은 "NotAllowedError"이다.

signal 멤버가 존재하고 중단됨 플래그가 true로 설정되어 있으면,

issuedRequests의 각 authenticator에서 authenticatorCancel 작업을 호출하고, authenticator를 issuedRequests에서 제거한다. 그런 다음 DOMException을 반환한다. 그 이름은 "AbortError"이며 이 알고리즘을 종료한다.

issuedRequests가 비어 있고, options.allowCredentials가 비어 있지 않으며, 그 안의 어떤 공개 키 자격 증명에도 사용할 수 있는 authenticator가 생기지 않을 경우,

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

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

authenticator가 이 클라이언트 장치에서 사용할 수 있게 되면,
참고: 여기에는 lifetimeTimer를 시작할 때 authenticator를 이미 사용할 수 있었던 경우도 포함된다.
1. options.userVerification이 required로 설정되어 있고 authenticator가 사용자 검증을 수행할 수 없으면 계속한다.
2. userVerification을 어서션에 적용되는 유효 사용자 검증 요구사항으로 둔다. 이는 다음과 같은 부울 값이다. options.userVerification이
  
  required로 설정됨
  
  userVerification을 true로 둔다.
  
  preferred로 설정됨
  
  authenticator가
  
  사용자 검증을 수행할 수 있음
  
  userVerification을 true로 둔다.
  
  사용자 검증을 수행할 수 없음
  
  userVerification을 false로 둔다.
  
  discouraged로 설정됨
  
  userVerification을 false로 둔다.
3. options.allowCredentials가
  비어 있지 않음
  
  allowCredentialDescriptorList를 새로운 목록으로 둔다.
  
  클라이언트 플랫폼별 절차를 실행하여 options.allowCredentials에서 설명하는 공개 키 자격 증명 가운데 어느 것이 이 authenticator에 바인딩되어 있는지 판단한다. 이 판단에는 rpId, options.allowCredentials.id 및 options.allowCredentials.type과의 일치 여부를 사용한다. allowCredentialDescriptorList를 이 필터링된 목록으로 설정한다.
  
  allowCredentialDescriptorList가 비어 있으면 계속한다.
  
  distinctTransports를 새로운 순서 있는 집합으로 둔다.
  
  allowCredentialDescriptorList에 값이 정확히 하나 있으면 savedCredentialIds[authenticator]를 allowCredentialDescriptorList[0].id의 값으로 설정한다(자세한 내용은 여기와 § 6.3.3 authenticatorGetAssertion 작업을 참조한다).
  
  allowCredentialDescriptorList의 각 자격 증명 설명자 C에 대해 C.transports의 각 값이 있으면 distinctTransports에 추가한다.
  
  참고: 이 과정에서는 transports의 고유한 값만 distinctTransports에 모인다 (이 인증기에 해당). 이는 순서 있는 집합의 특성 때문이다.
  
  distinctTransports가
  
  비어 있지 않음
  
  클라이언트는 distinctTransports에서 transport 값 하나를 선택한다. 이때 authenticator와 함께 사용할 적절한 전송 수단에 관한 로컬 구성 정보를 선택 과정에 반영할 수 있다.
  
  그런 다음 transport를 사용하여 authenticatorGetAssertion 작업을 authenticator에서 호출한다. 매개변수는 rpId, clientDataHash, allowCredentialDescriptorList, userVerification 및 authenticatorExtensions이다.
  
  비어 있음
  
  authenticator와 함께 사용할 적절한 전송 수단에 관한 로컬 구성 정보를 사용하여 authenticatorGetAssertion 작업을 authenticator에서 호출한다. 매개변수는 rpId, clientDataHash, allowCredentialDescriptorList, userVerification 및 authenticatorExtensions이다.
  
  비어 있음
  
  authenticator와 함께 사용할 적절한 전송 수단에 관한 로컬 구성 정보를 사용하여 authenticatorGetAssertion 작업을 authenticator에서 호출한다. 매개변수는 rpId, clientDataHash, userVerification 및 authenticatorExtensions이다.
  
  참고: 이 경우 신뢰 당사자는 허용 가능한 자격 증명 설명자 목록을 제공하지 않았다. 따라서 인증기는 자신이 보유한 자격 증명 가운데 범위가 지정된 자격 증명을 사용하도록 요청받는다. 범위의 대상은 rpId로 식별되는 신뢰 당사자이다.
4. 추가: 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의 값을 자격 증명 ID의 바이트로 설정한다. 이 ID는 성공한 authenticatorGetAssertion 작업에서 반환된 것이며, § 6.3.3 authenticatorGetAssertion 작업에 정의되어 있다.
  
  clientDataJSONResult
  
  clientDataJSON의 바이트를 값으로 갖는다.
  
  authenticatorDataResult
  
  인증기 데이터의 바이트를 값으로 갖는다. 이 데이터는 인증기가 반환한 것이다.
  
  signatureResult
  
  인증기가 반환한 서명 값의 바이트를 값으로 갖는다.
  
  userHandleResult
  
  인증기가 사용자 핸들을 반환했으면 userHandleResult의 값을 반환된 사용자 핸들의 바이트로 설정한다. 그렇지 않으면 userHandleResult의 값을 null로 설정한다.
  
  clientExtensionResults
  
  AuthenticationExtensionsClientOutputs 객체를 값으로 갖는다. 이 객체에는 확장 식별자 → 클라이언트 확장 출력 항목이 포함된다. 이 항목은 각 확장의 클라이언트 확장 처리 알고리즘을 실행하여 클라이언트 확장 출력을 생성함으로써 만들어진다. 대상은 options.extensions의 각 클라이언트 확장이다.
3. constructAssertionAlg를 전역 객체 global을 받는 알고리즘으로 둔다. 그 단계는 다음과 같다.
  1. pubKeyCred를 새로운 PublicKeyCredential 객체로 둔다. 이 객체는 global과 연결되며 필드는 다음과 같다.
    
    [[identifier]]
    
    새 ArrayBuffer. global의 %ArrayBuffer%를 사용해 생성하며, assertionCreationData.credentialIdResult의 바이트를 포함한다.
    
    response
    
    새 AuthenticatorAssertionResponse 객체. global과 연결되며 필드는 다음과 같다.
    
    clientDataJSON
    
    새 ArrayBuffer. global의 %ArrayBuffer%를 사용해 생성하며, assertionCreationData.clientDataJSONResult의 바이트를 포함한다.
    
    authenticatorData
    
    새 ArrayBuffer. global의 %ArrayBuffer%를 사용해 생성하며, assertionCreationData.authenticatorDataResult의 바이트를 포함한다.
    
    signature
    
    새 ArrayBuffer. global의 %ArrayBuffer%를 사용해 생성하며, assertionCreationData.signatureResult의 바이트를 포함한다.
    
    userHandle
    
    assertionCreationData.userHandleResult가 null이면 이 필드를 null로 설정한다. 그렇지 않으면 이 필드를 새 ArrayBuffer로 설정한다. 이는 global의 %ArrayBuffer%를 사용해 생성하며, assertionCreationData.userHandleResult의 바이트를 포함한다.
    
    [[clientExtensionsResults]]
    
    새 ArrayBuffer. global의 %ArrayBuffer%를 사용해 생성하며, assertionCreationData.clientExtensionResults의 바이트를 포함한다.
  2. pubKeyCred를 반환한다.
4. issuedRequests에 남아 있는 각 authenticator에서 authenticatorCancel 작업을 호출하고 issuedRequests에서 제거한다.
5. constructAssertionAlg를 반환하고 이 알고리즘을 종료한다.
DOMException을 반환한다. 그 이름은 "NotAllowedError"이다. 사용자를 동의 없이 식별할 수 있는 정보의 유출을 방지하기 위해 이 단계는 lifetimeTimer가 만료되기 전에 절대로 실행해서는 안 된다. 자세한 내용은 § 14.5.2 인증 세리머니 개인정보 보호를 참조한다.

위 과정 중에 사용자 에이전트는 작업을 완료할 인증기를 선택하고 승인하는 과정을 안내하는 UI를 사용자에게 표시하는 것이 좋다.

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

[[Store]](credential, sameOriginWithAncestors) 메서드는 웹 인증의 PublicKeyCredential 유형에서 지원되지 않으므로 항상 오류를 반환한다.

참고: 이 알고리즘은 동기식이다. Promise의 이행/거부는 navigator.credentials.store()가 처리한다.

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

credential: 이 인수는 PublicKeyCredential 객체이다.
sameOriginWithAncestors: 이 인수는 호출자의 환경 설정 객체가 상위 요소들과 동일 출처인 경우에만 true인 부울 값이다.

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

DOMException을 반환한다. 그 이름은 "NotSupportedError"이며 이 알고리즘을 종료한다.

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

[[preventSilentAccess]](credential, sameOriginWithAncestors) 메서드를 호출해도 승인 동작을 요구하는 인증기에는 아무런 영향이 없지만, 해당 플래그를 설정하면 사용자 개입 없이 작동할 수 있는 인증기가 제외될 수 있다.

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

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

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

이 메서드는 인수를 받지 않으며 부울 값을 반환한다.

PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable

현재 모든 엔진에서 지원됩니다.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge (레거시)18IE없음

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

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

참고: 브라우징 컨텍스트에서 이 메서드를 호출할 때 웹 인증 API가 사용이 허용됨 알고리즘, 즉 권한 정책에 따라 "비활성화"되어 있으면 이름이 "NotAllowedError"인 DOMException으로 프로미스가 거부된다. § 5.9 권한 정책 통합도 참조한다.

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

AuthenticatorResponse

현재 모든 엔진에서 지원됩니다.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge (레거시)18IE없음

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

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

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

AuthenticatorResponse/clientDataJSON 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (레거시)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음 clientDataJSON, 형식: ArrayBuffer, 읽기 전용: 이 속성에는 JSON 호환 직렬화 형식의 클라이언트 데이터가 들어 있다. 그 해시는 클라이언트가 create() 또는 get()을 호출할 때 인증기로 전달된다. 즉, 클라이언트 데이터 자체는 인증기로 전송되지 않는다.

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

AuthenticatorAttestationResponse

현재 모든 엔진에서 지원됩니다.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge (레거시)18IE없음

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

AuthenticatorAttestationResponse 인터페이스는 새로운 공개 키 자격 증명 생성에 대한 클라이언트의 요청에 보낸 인증기의 응답을 나타낸다. 이 응답에는 나중에 사용할 때 식별할 수 있는 새 자격 증명에 관한 정보와, 등록 과정에서 자격 증명의 특성을 평가할 때 WebAuthn 신뢰 당사자가 사용할 수 있는 메타데이터가 들어 있다.

AuthenticatorAttestationResponse/getTransports

현재 어떤 엔진에서도 지원되지 않습니다.

Firefox없음Safari없음Chrome없음

Opera없음Edge없음

Edge (레거시)없음IE없음

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

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

clientDataJSON: AuthenticatorResponse에서 상속된 이 속성에는 이 자격 증명을 생성하기 위해 클라이언트가 인증기에 전달한 클라이언트 데이터의 JSON 호환 직렬화가 들어 있다(§ 6.5 증명 참조). 직렬화된 클라이언트 데이터의 해시가 이 직렬화를 대상으로 계산되었으므로 정확한 JSON 직렬화는 반드시 보존해야 한다.
AuthenticatorAttestationResponse/attestationObject 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (레거시)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet10.0+Opera Mobile없음 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의 멤버인 것이 좋지만 신뢰 당사자는 반드시 알 수 없는 값을 무시해야 한다.

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

[[Create]](origin, options, sameOriginWithAncestors) 메서드의 모든 사용자는 향후 인증 어서션을 검증하기 위해 반환된 자격 증명 공개 키를 파싱하여 저장해야 한다. 그러나 자격 증명 공개 키는 [RFC8152](COSE) 형식이며, AuthenticatorAttestationResponse.attestationObject가 전달한 증명 객체 안의 인증기 데이터 안의 attestedCredentialData 안의 credentialPublicKey 멤버에 들어 있다. 증명을 사용하려는 신뢰 당사자는 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이 아닌 값을 반환할 수 있어야 한다.

-7(ES256). 여기서 kty는 2(압축되지 않은 점 사용)이고 crv는 1(P-256)이다.
-257(RS256).
-8(EdDSA). 여기서 crv는 6(Ed25519)이다.

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

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

참고: getPublicKey() 및 getAuthenticatorData()은 이 명세의 레벨 2에서야 추가되었다. 신뢰 당사자는 이 함수들을 사용하기 전에 'getPublicKey' in AuthenticatorAttestationResponse.prototype의 값을 테스트하여 기능 감지를 수행하는 것이 좋다. 이 함수의 존재를 요구하는 신뢰 당사자는 이전 사용자 에이전트와 상호 운용되지 않을 수 있다.

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

AuthenticatorAssertionResponse

현재 모든 엔진에서 지원됩니다.

Firefox60+Safari13+Chrome67+

Opera없음Edge79+

Edge (레거시)18IE없음

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

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

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

clientDataJSON: AuthenticatorResponse에서 상속된 이 속성에는 이 어서션을 생성하기 위해 클라이언트가 인증기에 전달한 클라이언트 데이터의 JSON 호환 직렬화가 들어 있다(§ 5.8.1 WebAuthn 서명에 사용되는 클라이언트 데이터(사전 CollectedClientData) 참조). 직렬화된 클라이언트 데이터의 해시가 이 직렬화를 대상으로 계산되었으므로 정확한 JSON 직렬화는 반드시 보존해야 한다.
AuthenticatorAssertionResponse/authenticatorData 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (레거시)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음 authenticatorData, 형식: ArrayBuffer, 읽기 전용: 이 속성에는 인증기가 반환한 인증기 데이터가 들어 있다. § 6.1 인증기 데이터를 참조한다.
AuthenticatorAssertionResponse/signature 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (레거시)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음 signature, 형식: ArrayBuffer, 읽기 전용: 이 속성에는 인증기가 반환한 원시 서명이 들어 있다. § 6.3.3 authenticatorGetAssertion 작업을 참조한다.
AuthenticatorAssertionResponse/userHandle 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera없음Edge79+ Edge (레거시)18IE없음 Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet없음Opera Mobile없음 userHandle, 형식: ArrayBuffer, 읽기 전용, null 허용: 이 속성에는 인증기가 반환한 사용자 핸들이 들어 있으며, 인증기가 사용자 핸들을 반환하지 않았으면 null이다. § 6.3.3 authenticatorGetAssertion 작업을 참조한다.

5.3. 자격 증명 생성 매개변수(사전 `PublicKeyCredentialParameters`)

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

이 사전은 새 자격 증명을 생성할 때 추가 매개변수를 제공하는 데 사용된다.

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

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

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

PublicKeyCredentialCreationOptions

현재 모든 엔진에서 지원됩니다.

Firefox60+Safari13+Chrome67+

Opera54+Edge79+

Edge (레거시)없음IE없음

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

dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp;
    required PublicKeyCredentialUserEntity       user;

```
required BufferSource                             challenge;
required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;

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

};

PublicKeyCredentialCreationOptions/rp 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ rp, 형식: PublicKeyCredentialRpEntity

이 멤버에는 요청을 담당하는 신뢰 당사자에 관한 데이터가 들어 있다.

값의 name 멤버는 필수이다. 자세한 내용은 § 5.4.1 공개 키 엔터티 설명(사전 PublicKeyCredentialEntity)을 참조한다.

값의 id 멤버는 자격 증명의 범위를 지정할 RP ID를 지정한다. 생략하면 그 값은 CredentialsContainer 객체의 관련 설정 객체의 출처의 유효 도메인이 된다. 자세한 내용은 § 5.4.2 자격 증명 생성을 위한 신뢰 당사자 매개변수(사전 PublicKeyCredentialRpEntity)를 참조한다.

PublicKeyCredentialCreationOptions/user 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ user, 형식: PublicKeyCredentialUserEntity

이 멤버에는 신뢰 당사자가 증명을 요청하는 사용자 계정에 관한 데이터가 들어 있다.

값의 name, displayName 및 id 멤버는 필수이다. 자세한 내용은 § 5.4.1 공개 키 엔터티 설명(사전 PublicKeyCredentialEntity) 및 § 5.4.3 자격 증명 생성을 위한 사용자 계정 매개변수 (사전 PublicKeyCredentialUserEntity)를 참조한다.

PublicKeyCredentialCreationOptions/challenge 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ challenge, 형식: BufferSource

이 멤버에는 새로 생성되는 자격 증명의 증명 객체를 생성할 때 사용할 챌린지가 들어 있다. § 13.4.3 암호학적 챌린지 보안 고려 사항을 참조한다.

PublicKeyCredentialCreationOptions/pubKeyCredParams 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ pubKeyCredParams, 형식: sequence PublicKeyCredentialParameters

이 멤버에는 생성할 자격 증명에 필요한 특성에 관한 정보가 들어 있다. 시퀀스는 가장 선호하는 것부터 가장 덜 선호하는 것까지 정렬된다. 클라이언트는 가능한 한 가장 선호되는 자격 증명을 생성하기 위해 최선을 다한다.

PublicKeyCredentialCreationOptions/timeout 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ timeout, 형식: unsigned long

이 멤버는 호출자가 호출 완료를 기다릴 의사가 있는 시간을 밀리초 단위로 지정한다. 이는 힌트로 취급되며 클라이언트가 재정의할 수 있다.

PublicKeyCredentialCreationOptions/excludeCredentials 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ excludeCredentials, 형식: sequencePublicKeyCredentialDescriptor, 기본값: []

이 멤버는 하나의 인증기에서 동일한 계정에 여러 자격 증명이 생성되는 것을 제한하려는 신뢰 당사자가 사용한다. 새 자격 증명이 이 매개변수에 열거된 자격 증명 중 하나도 포함하는 인증기에 생성될 경우 클라이언트는 오류를 반환하도록 요청받는다.

PublicKeyCredentialCreationOptions/authenticatorSelection 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ authenticatorSelection, 형식: AuthenticatorSelectionCriteria

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

PublicKeyCredentialCreationOptions/attestation 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ attestation, 형식: DOMString, 기본값: "none"

이 멤버는 신뢰 당사자가 증명 전달에 대한 선호를 나타낼 때 사용한다. 값은 AttestationConveyancePreference의 멤버인 것이 좋다. 클라이언트 플랫폼은 반드시 알 수 없는 값을 무시하고, 알 수 없는 값은 멤버가 존재하지 않는 것처럼 처리해야 한다. 기본값은 "none"이다.

extensions, 형식: AuthenticationExtensionsClientInputs

이 멤버에는 클라이언트와 인증기에 추가 처리를 요청하는 추가 매개변수가 들어 있다. 예를 들어 호출자는 특정 기능을 갖춘 인증기만 자격 증명 생성에 사용하도록 요청하거나, 특정 정보를 증명 객체에 반환하도록 요청할 수 있다. 일부 확장은 § 9 WebAuthn 확장에서 정의한다. 등록된 WebAuthn 확장의 최신 목록은 [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." 또는 "ОАО Примертех"이다.
- 신뢰 당사자는 name 값을 설정하거나 사용자에게 표시할 때, PRECIS FreeformClass [RFC8264]의 Nickname Profile에 관해 [RFC8266] 제2.3절에 규정된 검사를 적용하는 것이 좋다.
- 이 문자열은 언어 및 방향 메타데이터를 포함할 수 있다. 신뢰 당사자는 이 정보를 제공하는 것을 고려하는 것이 좋다. 이 메타데이터의 인코딩 방법은 § 6.4.2 언어 및 방향 인코딩을 참조한다.
- 클라이언트는 name 값을 사용자에게 표시하거나 authenticatorMakeCredential 작업의 매개변수로 포함하기 전에, PRECIS FreeformClass [RFC8264]의 Nickname Profile에 관해 [RFC8266] 제2.3절에 규정된 검사를 적용하는 것이 좋다.
PublicKeyCredentialUserEntity에 상속된 경우 이는 사용자 계정에 대한 사람이 읽기 쉬운 식별자이다. 이는 표시 목적으로만, 즉 사용자가 displayName이 비슷한 사용자 계정들을 구별하도록 돕기 위한 것이다. 예를 들면 "alexm", "alex.mueller@example.com" 또는 "+14255551234"이다.
- 신뢰 당사자는 사용자가 이 값을 선택하도록 할 수 있다. 신뢰 당사자는 name 값을 설정하거나 사용자에게 표시할 때, PRECIS IdentifierClass [RFC8264]의 UsernameCasePreserved Profile에 관해 [RFC8265] 제3.4.3절에 규정된 검사를 적용하는 것이 좋다.
- 이 문자열은 언어 및 방향 메타데이터를 포함할 수 있다. 신뢰 당사자는 이 정보를 제공하는 것을 고려하는 것이 좋다. 이 메타데이터의 인코딩 방법은 § 6.4.2 언어 및 방향 인코딩을 참조한다.
- 클라이언트는 name 값을 사용자에게 표시하거나 authenticatorMakeCredential 작업의 매개변수로 포함하기 전에, PRECIS IdentifierClass [RFC8264]의 UsernameCasePreserved Profile에 관해 [RFC8265] 제3.4.3절에 규정된 검사를 적용하는 것이 좋다.

클라이언트, 클라이언트 플랫폼 또는 인증기가 name 값을 표시할 때에는 표시된 값 주위에 명확한 경계를 제공하는 UI 요소를 항상 사용해야 하며, 다른 요소로 넘치지 않도록 해야 한다 [css-overflow-3].

인증기가 값을 저장하는 경우, 인증기는 name 멤버의 값이 64바이트 이내에 들어가도록 자를 수 있다. 잘라내기 및 기타 고려 사항은 § 6.4.1 문자열 잘라내기를 참조한다.

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 멤버를 기준으로 내려야 하며, displayName 또는 name 멤버를 기준으로 내려서는 안 된다. [RFC8266] 제6.1절을 참조한다.

사용자 핸들은 사용자 이름이나 이메일 주소와 같이 사용자를 개인적으로 식별하는 정보를 절대로 포함해서는 안 된다. 자세한 내용은 § 14.6.1 사용자 핸들의 내용을 참조한다. 사용자 핸들은 절대로 비어 있어서는 안 되지만, null일 수는 있다.

참고: 일부 인증기는 항상 검색 가능한 자격 증명을 생성하므로, 검색 불가능한 자격 증명이라도 서로 다른 계정에서 사용자 핸들은 일정한 값이 아니어야 한다. 일정한 사용자 핸들을 사용하면 사용자가 그러한 인증기를 신뢰 당사자의 둘 이상의 계정에 사용할 수 없게 된다.

displayName, 유형은 DOMString

사용자 계정에 대한 사람이 읽기 쉬운 이름으로, 표시 목적으로만 사용된다. 예를 들면 "Alex Müller" 또는 "田中倫"이다. 신뢰 당사자는 사용자가 이 이름을 선택하도록 하는 것이 좋으며, 필요 이상으로 선택을 제한해서는 안 된다.

신뢰 당사자는 displayName 값을 설정하거나 사용자에게 표시할 때, PRECIS FreeformClass [RFC8264]의 Nickname Profile에 관해 [RFC8266] 제2.3절에 규정된 검사를 적용하는 것이 좋다.
이 문자열은 언어 및 방향 메타데이터를 포함할 수 있다. 신뢰 당사자는 이 정보를 제공하는 것을 고려하는 것이 좋다. 이 메타데이터의 인코딩 방법은 § 6.4.2 언어 및 방향 인코딩을 참조한다.
클라이언트는 displayName 값을 사용자에게 표시하거나 authenticatorMakeCredential 작업의 매개변수로 포함하기 전에, PRECIS FreeformClass [RFC8264]의 Nickname Profile에 관해 [RFC8266] 제2.3절에 규정된 검사를 적용하는 것이 좋다.

클라이언트, 클라이언트 플랫폼 또는 인증기가 displayName 값을 표시할 때에는 표시된 값 주위에 명확한 경계를 제공하는 UI 요소를 항상 사용해야 하며, 다른 요소로 넘치지 않도록 해야 한다 [css-overflow-3].

인증기는 displayName 멤버의 값에 대해 반드시 최소 64바이트 길이를 받아들이고 저장해야 한다. 인증기는 displayName 멤버의 값이 64바이트 이내에 들어가도록 자를 수 있다. 잘라내기 및 기타 고려 사항은 § 6.4.1 문자열 잘라내기를 참조한다.

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

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

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

authenticatorAttachment, 유형은 DOMString

이 멤버가 존재하는 경우 적격 인증기는 지정된 § 5.4.5 인증기 연결 열거형(enum AuthenticatorAttachment) 방식으로 연결된 인증기로만 필터링된다. 값은 AuthenticatorAttachment의 멤버인 것이 좋지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하고, 해당 값을 멤버가 존재하지 않는 것처럼 취급해야 한다.

residentKey, 유형은 DOMString

신뢰 당사자가 클라이언트 측 검색 가능한 자격 증명을 생성하고자 하는 정도를 지정한다. 역사적인 이유로 이름에는 폐기된 “resident” 용어가 유지되어 있다. 값은 ResidentKeyRequirement의 멤버인 것이 좋지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하고, 해당 값을 멤버가 존재하지 않는 것처럼 취급해야 한다. 값이 지정되지 않은 경우, requireResidentKey가 true이면 유효한 값은 required이고, false이거나 존재하지 않으면 discouraged이다.

residentKey의 값과 의미에 대한 설명은 ResidentKeyRequirement을 참조한다.

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

이 멤버는 WebAuthn Level 1과의 하위 호환성을 위해 유지되며, 역사적인 이유로 검색 가능한 자격 증명에 대한 이름에는 폐기된 “resident” 용어가 유지되어 있다. 신뢰 당사자는 residentKey가 required로 설정된 경우에만 이 멤버를 true로 설정하는 것이 좋다.

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

이 멤버는 create() 작업에서 사용자 검증에 관한 신뢰 당사자의 요구 사항을 설명한다. 적격 인증기는 이 요구 사항을 충족할 수 있는 인증기로만 필터링된다. 값은 UserVerificationRequirement의 멤버인 것이 좋지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하고, 해당 값을 멤버가 존재하지 않는 것처럼 취급해야 한다.

5.4.5. 인증기 연결 열거형(enum `AuthenticatorAttachment`)

이 열거형의 값은 인증기의 연결 양식을 설명한다. 신뢰 당사자는 자격 증명을 생성하기 위해 navigator.credentials.create()를 호출할 때 선호하는 인증기 연결 양식을 나타내기 위해 이를 사용한다.

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

참고: AuthenticatorAttachment 열거형은 의도적으로 참조되지 않는다. § 2.1.1 DOMString 유형으로서의 열거형을 참조한다.

platform: 이 값은 플랫폼 연결을 나타낸다.
cross-platform: 이 값은 교차 플랫폼 연결을 나타낸다.

참고: 인증기 연결 양식 선택 옵션은 [[Create]](origin, options, sameOriginWithAncestors) 작업에서만 사용할 수 있다. 신뢰 당사자는 예를 들어 사용자가 다른 클라이언트 기기에서 인증할 수 있도록 로밍 자격 증명을 보유하게 하거나, 특정 클라이언트 기기를 사용하여 더 쉽게 재인증할 수 있도록 플랫폼 자격 증명을 명시적으로 등록하기 위해 이 옵션을 사용할 수 있다. [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 작업에는 인증기 연결 양식 선택 옵션이 없으므로, 신뢰 당사자는 사용자가 등록한 모든 자격 증명을 받아들이는 것이 좋다. 그러면 클라이언트와 사용자는 그 시점에 사용할 수 있고 편리한 것을 사용한다.

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

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

참고: ResidentKeyRequirement 열거형은 의도적으로 참조되지 않는다. § 2.1.1 DOMString 유형으로서의 열거형을 참조한다.

이 열거형의 값은 클라이언트 측 검색 가능한 자격 증명(이전에는 상주 자격 증명 또는 상주 키라고 함)에 관한 신뢰 당사자의 요구 사항을 설명한다.

discouraged

이 값은 신뢰 당사자가 서버 측 자격 증명 생성을 선호하지만 클라이언트 측 검색 가능한 자격 증명도 받아들인다는 것을 나타낸다.

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

preferred

이 값은 신뢰 당사자가 클라이언트 측 검색 가능한 자격 증명 생성을 매우 선호하지만, 서버 측 자격 증명도 받아들인다는 것을 나타낸다. 예를 들어 사용자 에이전트는 이 경우 사용자 검증을 설정해야 클라이언트 측 검색 가능한 자격 증명을 생성할 수 있다면 사용자가 이를 설정하도록 안내하는 것이 좋다. 이는 userVerification 설정보다 우선한다.

required

이 값은 신뢰 당사자가 클라이언트 측 검색 가능한 자격 증명을 요구하며, 클라이언트 측 검색 가능한 자격 증명을 생성할 수 없는 경우 오류를 받을 준비가 되어 있음을 나타낸다.

참고: 신뢰 당사자는 options.authenticatorSelection.residentKey에 제공된 값을 고려하여 자격 증명 속성 확장의 반환 값을 검사함으로써 인증기가 클라이언트 측 검색 가능한 자격 증명을 생성했는지 여부에 관한 정보를 얻을 수 있다. 이는 options.authenticatorSelection.residentKey에 discouraged 또는 preferred 값을 사용할 때 유용하다. 그러한 경우에는 인증기가 클라이언트 측 검색 가능한 자격 증명과 서버 측 자격 증명 중 어느 것이든 생성할 수 있기 때문이다.

5.4.7. 증명 전달 선호도 열거형(enum `AttestationConveyancePreference`)

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

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

참고: AttestationConveyancePreference 열거형은 의도적으로 참조되지 않는다. § 2.1.1 DOMString 유형으로서의 열거형을 참조한다.

none

이 값은 신뢰 당사자가 인증기 증명에 관심이 없음을 나타낸다. 예를 들어 식별 정보를 신뢰 당사자에게 전달하기 위한 사용자 동의를 받아야 할 가능성을 피하거나, 증명 CA 또는 익명화 CA로의 왕복 통신을 줄이기 위한 것이다.

이는 기본값이다.

indirect

이 값은 신뢰 당사자가 검증 가능한 증명 구문을 생성하는 증명 전달을 선호하지만, 그러한 증명 구문을 얻는 방법은 클라이언트가 결정하도록 허용한다는 것을 나타낸다. 사용자의 개인정보를 보호하거나 이질적인 생태계에서 신뢰 당사자의 증명 검증을 지원하기 위해 클라이언트는 인증기가 생성한 증명 구문을 익명화 CA가 생성한 증명 구문으로 대체할 수 있다.

참고: 이 경우 신뢰 당사자가 검증 가능한 증명 구문을 얻는다는 보장은 없다. 예를 들어 인증기가 자체 증명을 사용하는 경우가 그렇다.

direct

이 값은 신뢰 당사자가 인증기에서 생성된 그대로의 증명 구문을 받기를 원함을 나타낸다.

enterprise

이 값은 신뢰 당사자가 고유한 식별 정보를 포함할 수 있는 증명 구문을 받기를 원함을 나타낸다. 이는 조직이 등록을 특정 인증기와 연결하고자 하는 기업 내부의 통제된 배포를 위한 것이다. 사용자 에이전트 또는 인증기의 구성이 요청된 RP ID에 대해 이를 허용하지 않는 한, 사용자 에이전트는 절대로 이러한 증명을 제공해서는 안 된다.

허용된 경우 사용자 에이전트는 기업 증명이 요청되었음을 인증기에 (호출 시점에) 알리고, 그 결과로 얻은 AAGUID와 증명 구문을 변경하지 않고 신뢰 당사자에게 전달하는 것이 좋다.

5.5. 어서션 생성을 위한 옵션(딕셔너리 `PublicKeyCredentialRequestOptions`)

PublicKeyCredentialRequestOptions

현재 모든 엔진에서 지원됩니다.

Firefox60+Safari13+Chrome67+

Opera54+Edge79+

Edge (레거시)없음IE없음

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

PublicKeyCredentialRequestOptions 딕셔너리는 어서션 생성에 필요한 데이터를 get()에 제공한다. challenge 멤버는 반드시 존재해야 하며, 그 밖의 멤버는 선택 사항이다.

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

PublicKeyCredentialRequestOptions/challenge 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ challenge, 유형은 BufferSource: 이 멤버는 선택된 인증기가 인증 어서션을 생성할 때 다른 데이터와 함께 서명하는 챌린지를 나타낸다. 보안 고려 사항인 § 13.4.3 암호학적 챌린지를 참조한다.
PublicKeyCredentialRequestOptions/timeout 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ timeout, 유형은 unsigned long: 이 선택적 멤버는 호출자가 호출의 완료를 기다릴 의사가 있는 시간을 밀리초 단위로 지정한다. 이 값은 힌트로 취급되며 클라이언트가 재정의할 수 있다.
PublicKeyCredentialRequestOptions/rpId 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ rpId, 유형은 USVString: 이 선택적 멤버는 호출자가 주장하는 신뢰 당사자 식별자를 지정한다. 생략하면 그 값은 CredentialsContainer 객체의 관련 설정 객체의 출처에 해당하는 유효 도메인이 된다.
PublicKeyCredentialRequestOptions/allowCredentials 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ allowCredentials, 유형은 sequence<PublicKeyCredentialDescriptor이며 기본값은 []: 이 선택적 멤버에는 호출자가 허용하는 공개 키 자격 증명을 나타내는 PublicKeyCredentialDescriptor 객체 목록이 호출자의 선호도가 높은 순서로 들어 있다. 목록의 첫 번째 항목이 가장 선호되는 자격 증명이며 이후 항목도 같은 방식으로 나열된다.
PublicKeyCredentialRequestOptions/userVerification 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ userVerification, 유형은 DOMString이며 기본값은 "preferred": 이 선택적 멤버는 get() 작업에서 사용자 검증에 관한 신뢰 당사자의 요구 사항을 설명한다. 값은 UserVerificationRequirement의 멤버인 것이 좋지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하고, 해당 값을 멤버가 존재하지 않는 것처럼 취급해야 한다. 적격 인증기는 이 요구 사항을 충족할 수 있는 인증기로만 필터링된다.
PublicKeyCredentialCreationOptions/extensions 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView없음Samsung Internet없음Opera Mobile48+ PublicKeyCredentialRequestOptions/extensions 현재 모든 엔진에서 지원됩니다. Firefox60+Safari13+Chrome67+ Opera54+Edge79+ Edge (레거시)없음IE없음 Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung Internet없음Opera Mobile48+ extensions, 유형은 AuthenticationExtensionsClientInputs: 이 선택적 멤버에는 클라이언트와 인증기에 추가 처리를 요청하는 추가 매개변수가 들어 있다. 예를 들어 사용자에게 트랜잭션 확인을 요청한다면 프롬프트 문자열을 확장에 포함할 수 있다.

5.6. `AbortSignal`을 사용한 작업 중단

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

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

가시성 및 포커스 상태에 따라 Window 객체에서 [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 작업을 계속해야 하는지가 결정된다. [Document와 연결된 Window 객체가 포커스를 잃으면, [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 작업을 중단하는 것이 좋다.

WHATWG HTML WG는 탐색 컨텍스트가 포커스를 얻거나 잃을 때 훅을 제공할지 논의하고 있다. 훅이 제공되면 위 단락은 해당 훅을 포함하도록 업데이트된다. 자세한 내용은 WHATWG HTML WG 이슈 #2711을 참조한다.

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;
    TokenBinding                 tokenBinding;
};

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

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

type, 유형은 DOMString

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

challenge, 유형은 DOMString

이 멤버에는 신뢰 당사자가 제공한 챌린지의 base64url 인코딩이 들어 있다. 보안 고려 사항인 § 13.4.3 암호학적 챌린지를 참조한다.

origin, 유형은 DOMString

이 멤버에는 클라이언트가 인증기에 제공한 요청자의 정규화된 전체 출처가 [RFC6454]에 정의된 구문으로 들어 있다.

crossOrigin, 유형은 boolean

이 멤버에는 sameOriginWithAncestors 인수 값의 역이 들어 있으며, 이 값은 내부 메서드에 전달되었다.

tokenBinding, 유형은 TokenBinding

이 선택적 멤버에는 토큰 바인딩 프로토콜 [TokenBinding]의 상태에 관한 정보가 들어 있으며, 이 프로토콜은 신뢰 당사자와 통신할 때 사용되었다. 이 멤버가 없으면 클라이언트가 토큰 바인딩을 지원하지 않음을 나타낸다.

status, 유형은 DOMString

이 멤버는 TokenBindingStatus의 멤버인 것이 좋지만, 클라이언트 플랫폼은 알 수 없는 값을 반드시 무시하고, 알 수 없는 값을 tokenBinding 멤버가 존재하지 않는 것처럼 취급해야 한다. 알려진 값인 경우 이 멤버는 다음 중 하나이다.

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

참고: TokenBindingStatus 열거형은 의도적으로 참조되지 않는다. § 2.1.1 DOMString 유형으로서의 열거형을 참조한다.

id, 유형은 DOMString

status가 present이면 이 멤버는 반드시 존재해야 하며, 토큰 바인딩 ID의 base64url 인코딩이어야 한다. 해당 토큰 바인딩 ID는 신뢰 당사자와 통신할 때 사용된 것이다.

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

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

클라이언트 데이터의 JSON 호환 직렬화: 이는 CollectedClientData 딕셔너리에 JSON 호환 직렬화 알고리즘을 수행한 결과이다.
직렬화된 클라이언트 데이터의 해시: 이는 클라이언트가 구성한 클라이언트 데이터의 JSON 호환 직렬화를 SHA-256으로 계산한 해시이다.

5.8.1.1. 직렬화

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

직렬화 알고리즘은 처음에는 비어 있는 부분 결과에 연속적인 바이트 문자열을 이어 붙여 완전한 결과를 얻는 방식으로 작동한다.

result를 빈 바이트 문자열이라고 하자.
0x7b2274797065223a({"type":)를 result에 추가한다.
CCDToString(type)을 result에 추가한다.
0x2c226368616c6c656e6765223a(,"challenge":)를 result에 추가한다.
CCDToString(challenge)를 result에 추가한다.
0x2c226f726967696e223a(,"origin":)를 result에 추가한다.
CCDToString(origin)을 result에 추가한다.
0x2c2263726f73734f726967696e223a(,"crossOrigin":)를 result에 추가한다.
crossOrigin이 존재하지 않거나 false인 경우:
1. 0x66616c7365(false)를 result에 추가한다.
그렇지 않은 경우:
1. 0x74727565(true)를 result에 추가한다.
CollectedClientData의 임시 복사본을 만들고 type, challenge, origin 및 crossOrigin 필드가 존재한다면 이를 제거한다.
임시 복사본에 남은 필드가 없는 경우:
1. 0x7d(})를 result에 추가한다.
그렇지 않은 경우:
1. 임시 복사본에 JSON을 바이트로 직렬화하기를 호출하여 바이트 문자열 remainder를 생성한다.
2. 0x2c(,)를 result에 추가한다.
3. remainder에서 맨 앞 바이트를 제거한다.
4. remainder를 result에 추가한다.
직렬화의 결과는 result의 값이다.

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

encoded를 빈 바이트 문자열이라고 하자.
0x22(")를 encoded에 추가한다.
주어진 객체에 ToString을 호출하여 문자열로 변환한다.
결과 문자열의 각 코드 포인트에 대해, 해당 코드 포인트가 다음 조건에 해당하는 경우:

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

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

U+0022임

0x5c22(")를 encoded에 추가한다.

U+005C임

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

그 밖의 경우

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

5.8.1.2. 제한된 검증 알고리즘

검증자가 완전한 JSON 파서를 지원할 수 없다면 다음 알고리즘을 사용하여 인코딩된 CollectedClientData를 검증할 수 있다.

알고리즘의 입력은 다음과 같다.
1. clientDataJSON, 즉 검증할 직렬화된 CollectedClientData를 포함하는 바이트 문자열 clientDataJSON.
2. 예상되는 type을 포함하는 문자열 type.
3. PublicKeyCredentialRequestOptions 또는 PublicKeyCredentialCreationOptions에 제공된 챌린지 바이트 문자열을 포함하는 바이트 문자열 challenge.
4. 사용자 에이전트에 요청을 발행한 예상 origin을 포함하는 문자열 origin.
5. 요청이 교차 출처 iframe 내에서 수행되었어야 하는 경우에만 true인 불리언 crossOrigin.
expected를 빈 바이트 문자열이라고 하자.
0x7b2274797065223a({"type":)를 expected에 추가한다.
CCDToString(type)을 expected에 추가한다.
0x2c226368616c6c656e6765223a(,"challenge":)를 expected에 추가한다.
challenge에 base64url 인코딩을 수행하여 문자열 challengeBase64를 생성한다.
CCDToString(challengeBase64)을 expected에 추가한다.
0x2c226f726967696e223a(,"origin":)를 expected에 추가한다.
CCDToString(origin)을 expected에 추가한다.
0x2c2263726f73734f726967696e223a(,"crossOrigin":)를 expected에 추가한다.
crossOrigin이 true인 경우:
1. 0x74727565(true)를 expected에 추가한다.
그렇지 않은 경우, 즉 crossOrigin이 false인 경우:
1. 0x66616c7365(false)를 expected에 추가한다.
expected가 clientDataJSON의 접두사가 아니면 검증은 실패한다.
clientDataJSON이 expected보다 적어도 한 바이트 더 길지 않으면 검증은 실패한다.
expected의 길이와 같은 오프셋에 있는 clientDataJSON의 바이트가 다음과 같은 경우:

0x7d임

검증에 성공한다.

0x2c임

검증에 성공한다.

그 밖의 경우

검증에 실패한다.

5.8.1.3. 향후 개발

제한된 검증 알고리즘과의 호환성을 유지하기 위해 이 명세의 향후 버전은 type, challenge, origin 또는 crossOrigin 필드를 CollectedClientData에서 제거해서는 안 된다. 또한 이러한 필드가 직렬화되는 순서를 변경하도록 직렬화 알고리즘을 변경해서도 안 된다.

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

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

enum PublicKeyCredentialType { "public-key"
};

참고: PublicKeyCredentialType 열거형은 의도적으로 참조되지 않는다. § 2.1.1 DOMString 유형으로서의 열거형을 참조한다.

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

현재는 "public-key"이라는 하나의 자격 증명 유형이 정의되어 있다.

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

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

이 딕셔너리에는 호출자가 공개 키 자격 증명을 create() 또는 get() 메서드의 입력 매개변수로 참조할 때 지정하는 속성이 들어 있다. 이는 후자의 메서드에서 반환되는 PublicKeyCredential 객체의 필드를 반영한다.

type, 유형은 DOMString

이 멤버에는 호출자가 참조하는 공개 키 자격 증명의 유형이 들어 있다. 값은 PublicKeyCredentialType의 멤버인 것이 좋지만, 클라이언트 플랫폼은 알 수 없는 type을 가진 모든 PublicKeyCredentialDescriptor를 반드시 무시해야 한다.

id, 유형은 BufferSource

이 멤버에는 호출자가 참조하는 공개 키 자격 증명의 자격 증명 ID가 들어 있다.

transports, 유형은 sequenceDOMString>

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

getTransports() 작업은 이 멤버에 적합한 값을 제공할 수 있다. 새 자격 증명을 등록할 때 신뢰 당사자는 getTransports()에서 반환된 값을 저장하는 것이 좋다. 해당 자격 증명에 대한 PublicKeyCredentialDescriptor를 생성할 때 신뢰 당사자는 저장된 값을 가져와 transports 멤버의 값으로 설정하는 것이 좋다.

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

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

참고: AuthenticatorTransport 열거형은 의도적으로 참조되지 않는다. § 2.1.1 DOMString 유형으로서의 열거형을 참조한다.

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

usb: 해당 인증기에 착탈식 USB를 통해 연결할 수 있음을 나타낸다.
nfc: 해당 인증기에 근거리 무선 통신(NFC)을 통해 연결할 수 있음을 나타낸다.
ble: 해당 인증기에 Bluetooth Smart(Bluetooth Low Energy / BLE)를 통해 연결할 수 있음을 나타낸다.
internal: 해당 인증기가 클라이언트 기기별 전송 방식을 사용하여 연결된다는 것, 즉 플랫폼 인증기임을 나타낸다. 이러한 인증기는 클라이언트 기기에서 분리할 수 없다.

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

typedef long COSEAlgorithmIdentifier;

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

COSE 알고리즘 레지스트리는 다른 매개변수가 COSE 키에서 지정하도록 어느 정도의 자유도를 남겨 둔다. 상호 운용성을 높이기 위해 이 명세는 자격 증명 공개 키에 관해 다음 사항을 추가로 보장한다.

알고리즘이 ES256(-7)인 키는 반드시 P-256(1)을 crv 매개변수로 지정해야 하며, 절대로 압축된 포인트 형식을 사용해서는 안 된다.
알고리즘이 ES384(-35)인 키는 반드시 P-384(2)를 crv 매개변수로 지정해야 하며, 절대로 압축된 포인트 형식을 사용해서는 안 된다.
알고리즘이 ES512(-36)인 키는 반드시 P-521(3)을 crv 매개변수로 지정해야 하며, 절대로 압축된 포인트 형식을 사용해서는 안 된다.
알고리즘이 EdDSA(-8)인 키는 반드시 Ed25519(6)를 crv 매개변수로 지정해야 한다. 이러한 키는 COSE에서 항상 압축된 형식을 사용한다.

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

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

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

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

참고: UserVerificationRequirement 열거형은 의도적으로 참조되지 않는다. § 2.1.1 DOMString 유형으로서의 열거형을 참조한다.

required: 이 값은 신뢰 당사자가 작업에 사용자 검증을 요구하며, 응답에 UV 플래그가 설정되어 있지 않으면 작업이 실패한다는 것을 나타낸다.
preferred: 이 값은 신뢰 당사자가 가능하다면 작업에 사용자 검증을 사용하는 것을 선호하지만, 응답에 UV 플래그가 설정되어 있지 않더라도 작업을 실패시키지는 않는다는 것을 나타낸다.
discouraged: 이 값은 신뢰 당사자가 작업 중 사용자 검증을 사용하기를 원하지 않음을 나타낸다. 예를 들면 사용자 상호작용 흐름의 방해를 최소화하기 위한 경우이다.

5.9. 권한 정책 통합

Headers/Feature-Policy/publickey-credentials-get

현재 하나의 엔진에서만 지원됩니다.

Firefox없음Safari없음Chrome84+

Opera없음Edge84+

Edge (레거시)없음IE없음

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

이 명세는 기능 식별자 토큰 "publickey-credentials-get"으로 식별되는 하나의 정책 제어 기능을 정의한다. 그 기본 허용 목록은 'self'이다. [Permissions-Policy]

Document의 권한 정책은 해당 문서의 콘텐츠가 성공적으로 호출하도록 허용되는지를 결정한다. 즉, navigator.credentials.get({publicKey:..., ...})를 통해 Web Authentication API를 호출하도록 허용되는지를 결정한다. 어떤 문서에서든 이 기능이 비활성화되면 문서의 어떤 콘텐츠도 앞서 언급한 메서드를 사용하도록 허용되지 않으며, 이를 시도하면 오류가 반환된다.

참고: 실제 권한 정책 평가는 [CREDENTIAL-MANAGEMENT-1]에 규정된 알고리즘이 수행한다. 이러한 정책 평가는 현재 설정 객체에 접근할 수 있을 때 수행되어야 하기 때문이다. [[Create]](origin, options, sameOriginWithAncestors) 및 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드는 병렬로 호출되므로 이러한 접근 권한이 없다. 이 호출은 [CREDENTIAL-MANAGEMENT-1]에 규정된 알고리즘이 수행한다.

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

Web Authentication API는 교차 출처 iframe에서 기본적으로 비활성화된다. 이 기본 정책을 재정의하고 교차 출처 iframe이 Web Authentication API의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 메서드를 호출하도록 허용됨을 나타내려면, allow 속성을 iframe 요소에 지정하고, publickey-credentials-get 기능 식별자 토큰을 allow 속성의 값에 포함한다.

내장된 컨텍스트에서 WebAuthn API를 사용하는 신뢰 당사자는 UI 위장과 가능한 완화 방법에 관한 § 13.4.2 내장 사용에 대한 가시성 고려 사항을 검토해야 한다.

6. WebAuthn 인증기 모델

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

클라이언트 플랫폼은 이 추상 모델을 원하는 방식으로 구현하고 노출할 수 있다. 그러나 해당 클라이언트 플랫폼이 지원하는 인증기를 대상으로 작동하는 클라이언트의 Web Authentication API 구현 동작은 반드시 § 5 Web Authentication API에 규정된 동작과 구별할 수 없어야 한다.

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

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

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

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

각 인증기는 자격 증명 맵, 즉 (rpId, [userHandle])에서 공개 키 자격 증명 소스로 대응되는 맵을 저장한다.

또한 각 인증기에는 인증기의 유형(예: 제조사와 모델)을 나타내는 128비트 식별자인 AAGUID가 있다. 제조업체는 실질적으로 동일하게 제조한 모든 인증기에서 AAGUID가 반드시 동일하고, 다른 모든 유형의 인증기에 대한 AAGUID와는 높은 확률로 다르도록 선택해야 한다. 이를 보장하기 위해 특정 인증기 유형의 AAGUID는 무작위로 생성하는 것이 좋다. 신뢰 당사자는 다른 출처의 정보를 사용하여 인증 수준이나 키 보호 강도 같은 인증기의 특정 속성을 AAGUID로 추론할 수 있다.

인증기의 주요 기능은 다양한 문맥 데이터에 바인딩된 WebAuthn 서명을 제공하는 것이다. 서명 요청이 서버에서 인증기로 전달될 때 스택의 여러 수준에서 이러한 데이터를 관찰하고 추가한다. 서버는 서명을 검증할 때 이러한 바인딩을 예상 값과 대조한다. 문맥적 바인딩은 두 가지로 나뉜다. 신뢰 당사자 또는 클라이언트가 추가한 것은 클라이언트 데이터라고 하며, 인증기가 추가한 것은 인증기 데이터라고 한다. 인증기는 클라이언트 데이터를 포함하여 서명하지만 그 내용 자체에는 관심을 두지 않는다. 인증기의 대역폭과 처리 요구 사항을 줄이기 위해 클라이언트는 클라이언트 데이터를 해시하고 그 결과만 인증기로 전송한다. 인증기는 직렬화된 클라이언트 데이터의 해시와 자체 인증기 데이터의 조합을 대상으로 서명한다.

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

서명 생성 방식은 클라이언트 기기와 인증기 사이의 연결이 대역폭 및/또는 지연 시간 측면에서 매우 제한적인 경우를 수용해야 한다. 그 예로 Bluetooth Low Energy와 근거리 무선 통신이 있다.
인증기에서 처리하는 데이터는 작고 저수준 코드에서 쉽게 해석할 수 있어야 한다. 특히 인증기가 JSON과 같은 고수준 인코딩을 파싱할 필요가 없어야 한다.
클라이언트와 인증기 모두 필요에 따라 문맥적 바인딩을 유연하게 추가할 수 있어야 한다.
이 설계는 도입과 구현을 돕기 위해 기존 인코딩 형식을 가능한 한 많이 재사용하는 것을 목표로 한다.

인증기는 서로 다른 두 가지 목적을 위해 암호화 서명을 생성한다.

증명 서명은 authenticatorMakeCredential 작업을 통해 새 공개 키 자격 증명을 생성할 때 만들어진다. 증명 서명은 인증기 및 자격 증명의 특정 속성에 대한 암호학적 증거를 제공한다. 예를 들어 증명 서명은 AAGUID로 나타낸 인증기 유형과 자격 증명 공개 키를 단언한다. 증명 서명은 원하는 증명 유형에 따라 선택되는 증명 개인 키로 서명된다. 증명에 대한 자세한 내용은 § 6.5 증명을 참조한다.
어서션 서명은 authenticatorGetAssertion 메서드를 호출할 때 생성된다. 이는 로그인이나 구매 완료 같은 특정 트랜잭션에 사용자가 동의했음을 인증기가 단언하는 것이다. 따라서 어서션 서명은 특정 자격 증명 개인 키를 보유한 인증기가 최선을 다해 판단한 결과, 이 트랜잭션을 요청하는 사용자가 해당 공개 키 자격 증명의 생성에 동의했던 사용자와 동일함을 단언한다. 또한 클라이언트 데이터라고 하는 추가 정보도 단언한다. 여기에는 사용자 동의가 제공된 수단이나 인증기가 사용자에게 표시한 프롬프트처럼 호출자에게 유용할 수 있는 정보가 포함된다. 어서션 서명 형식은 아래의 그림 4에 나와 있다.

WebAuthn 서명이라는 용어는 증명 서명과 어서션 서명을 모두 가리킨다. 이러한 서명의 형식과 생성 절차는 아래에 규정되어 있다.

6.1. 인증기 데이터

인증기 데이터 구조는 인증기가 만든 문맥적 바인딩을 인코딩한다. 이러한 바인딩은 인증기 자체에서 제어하며, 인증기의 보안 속성에 대한 WebAuthn 신뢰 당사자의 평가에서 신뢰를 얻는다. 한쪽 극단의 경우 인증기가 클라이언트에 내장되어 그 바인딩을 클라이언트 데이터보다 더 신뢰할 수 없을 수 있다. 다른 쪽 극단의 경우 인증기는 높은 보안 수준의 하드웨어와 소프트웨어를 갖추고 보안 채널을 통해 클라이언트에 연결되는 독립된 엔터티일 수 있다. 두 경우 모두 신뢰 당사자는 동일한 형식으로 인증기 데이터를 수신하고, 인증기에 관해 알고 있는 정보를 사용하여 신뢰 여부를 결정한다.

인증기 데이터에는 간결하면서도 확장 가능한 인코딩이 사용된다. 인증기는 클라이언트 플랫폼보다 훨씬 단순한 소프트웨어 스택을 사용하며 기능과 전력 요구 사항이 제한된 기기일 수 있으므로 이러한 인코딩이 바람직하다.

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

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

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

RP ID는 원래 자격 증명이 생성될 때 클라이언트로부터 수신되며, 어서션이 생성될 때 다시 수신된다. 그러나 이는 몇 가지 중요한 측면에서 다른 클라이언트 데이터와 다르다. 첫째, 클라이언트 데이터와 달리 자격 증명의 RP ID는 작업 간에 변경되지 않고 해당 자격 증명의 수명 동안 동일하게 유지된다. 둘째, authenticatorGetAssertion 작업 중 인증기가 이를 검증한다. 이때 요청된 자격 증명의 범위로 지정된 RP ID가 제공된 RP ID, 즉 클라이언트가 제공한 값과 정확히 일치하는지 확인한다.

인증기는 다음 단계에 따라 인증기 데이터 구조를 생성한다.

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

참고: 인증기가 사용자 존재 테스트와 사용자 검증을 모두 수행했다면, 두 과정이 하나의 승인 동작으로 결합된 경우에도 인증기는 UP 플래그와 UV 플래그를 모두 설정한다.
증명 서명의 경우 인증기는 반드시 AT 플래그를 설정하고 attestedCredentialData를 포함해야 한다. 어서션 서명의 경우 AT 플래그를 절대로 설정해서는 안 되며, attestedCredentialData를 절대로 포함해서는 안 된다.
인증기가 확장 데이터를 포함하지 않으면 반드시 ED 플래그를 0으로 설정해야 하며, 확장 데이터가 포함되면 1로 설정해야 한다.

그림 은 인증기 데이터 구조를 시각적으로 보여 준다.

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

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

6.1.1. 서명 카운터 고려 사항

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

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

서명 카운터 불일치를 탐지하더라도 현재 작업을 복제된 인증기가 수행했는지 원래 인증기가 수행했는지는 알 수 없다. 신뢰 당사자는 개별 상황, 즉 위험 허용 수준에 맞게 이 상황을 적절히 처리해야 한다.

인증기는 다음을 수행한다.

자격 증명별 서명 카운터를 구현하는 것이 좋다. 이렇게 하면 서명 카운터 값이 신뢰 당사자 간에 공유되어 사용자를 연관 짓는 핸들로 사용될 가능성을 방지한다. 인증기는 인증기별 전역 서명 카운터를 구현할 수 있지만, 이는 사용자 개인정보 보호 측면에서 덜 바람직하다.
서명 카운터 값이 하드웨어 장애 등의 이유로 우발적으로 감소하지 않도록 하는 것이 좋다.

6.1.2. FIDO U2F 서명 형식 호환성

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

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

6.2. 인증기 분류 체계

많은 사용 사례는 사용되는 인증기의 기능에 따라 달라진다. 이 절에서는 이러한 기능과 그중 가장 중요한 조합 및 해당 조합으로 구현할 수 있는 사용 사례에 관한 용어를 정의한다.

예:

특정 클라이언트 기기에서 처음 인증할 때에는 사용자가 해당 클라이언트 기기에 아직 플랫폼 자격 증명을 갖고 있지 않으므로 일반적으로 로밍 인증기가 필요하다.
같은 클라이언트 기기에서 이후 재인증할 때에는 플랫폼 인증기가 별도로 찾아야 할 수도 있는 기기가 아니라 클라이언트 기기에 직접 내장되어 있으므로 가장 편리할 가능성이 크다.
기존 사용자 이름과 비밀번호에 추가되는 두 번째 요소 인증에는 모든 인증기를 사용할 수 있다.
비밀번호 없는 다중 요소 인증에는 사용자 검증을 수행할 수 있는 인증기가 필요하며, 일부 경우에는 검색 가능한 자격 증명 지원 기능도 필요하다.
노트북 컴퓨터는 USB와 Bluetooth를 통한 로밍 인증기 연결을 지원할 수 있지만, 휴대전화는 NFC만 지원할 수 있다.

위의 예는 주요 인증기 유형 특성을 보여 준다.

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

이러한 특성은 서로 독립적이며 이론적으로는 어떤 방식으로도 조합할 수 있지만, 표 에는 특히 중요한 몇 가지 인증기 유형과 그 이름이 나와 있다.

인증기 유형	인증기 연결 양식	자격 증명 저장 양식	인증 요소 기능
두 번째 요소 플랫폼 인증기	플랫폼	둘 중 하나	단일 요소 지원
사용자 검증 플랫폼 인증기	플랫폼	둘 중 하나	다중 요소 지원
두 번째 요소 로밍 인증기	교차 플랫폼	서버 측 저장	단일 요소 지원
첫 번째 요소 로밍 인증기	교차 플랫폼	클라이언트 측 저장	다중 요소 지원

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

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

사용자 검증 플랫폼 인증기와 첫 번째 요소 로밍 인증기는 비밀번호 없는 다중 요소 인증을 가능하게 한다. 이 인증기들은 자격 증명 개인 키의 보유 증명에 더해 두 번째 인증 요소로서 사용자 검증을 지원한다. 이는 일반적으로 PIN 또는 생체 인식이다. 따라서 인증기는 두 종류의 인증 요소로 작동할 수 있으며, 그 결과 다중 요소 인증을 가능하게 하는 동시에 신뢰 당사자와 비밀번호를 공유할 필요를 없앤다.

표 에서 이름이 지정되지 않은 네 가지 조합은 뚜렷한 사용 사례가 상대적으로 적다.

자격 증명 저장 양식은 로밍 인증기보다 플랫폼 인증기에 덜 중요하다. 플랫폼 인증기를 사용하는 사용자는 일반적으로 세션 쿠키 등, 즉 앰비언트 자격 증명으로 식별할 수 있기 때문이다.
검색 가능한 자격 증명을 지원하지만 다중 요소를 지원하지 않는 로밍 인증기는 사용자 이름 없는 단일 요소 인증에 사용할 수 있다. 이 경우 사용자 핸들로 사용자를 자동 식별하고 자격 증명 개인 키의 보유를 유일한 인증 요소로 사용한다. 이는 일부 상황에서 유용할 수 있지만 사용자가 인증기 도난에 특히 취약해진다.
다중 요소를 지원하지만 검색 가능한 자격 증명을 지원하지 않는 로밍 인증기는 다중 요소 인증에 사용할 수 있지만, 먼저 사용자를 식별해야 하므로 개인 식별 정보가 유출될 위험이 있다. § 14.6.3 자격 증명 ID를 통한 개인정보 유출을 참조한다.

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

6.2.1. 인증기 연결 양식

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

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

일부 플랫폼 인증기는 컨텍스트에 따라 로밍 인증기로도 작동할 수 있다. 예를 들어 모바일 기기에 통합된 플랫폼 인증기는 Bluetooth를 통해 자신을 로밍 인증기로 제공할 수 있다. 이 경우 모바일 기기에서 실행되는 클라이언트는 인증기를 플랫폼 인증기로 인식하지만, 다른 클라이언트 기기에서 실행되고 Bluetooth를 통해 동일한 인증기와 통신하는 클라이언트는 이를 로밍 인증기로 인식한다.

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

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

6.2.2. 자격 증명 저장 양식

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

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

이렇게 하면 암호화된 자격 증명 개인 키를 인증기 대신 신뢰 당사자가 저장하므로 인증기는 자격 증명 개인 키에 대해 무제한 저장 용량을 가질 수 있다. 그러나 이 방식으로 저장한 자격 증명은 인증기가 사용하기 전에 신뢰 당사자로부터 가져와야 한다.

인증기가 이러한 저장 전략 중 어느 것을 지원하는지에 따라 인증기의 자격 증명 저장 양식은 다음과 같이 정의된다.

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

검색 가능한 자격 증명을 지원하는 인증기는 두 저장 전략을 모두 지원할 수 있다. 이 경우 인증기는 재량에 따라 서로 다른 자격 증명에 서로 다른 저장 전략을 사용할 수 있지만, residentKey 또는 requireResidentKey 옵션의 적용을 받는다. 이 옵션은 create()의 옵션이다.

6.2.3. 인증 요소 기능

인증 세리머니 중 신원을 증명하는 데 사용할 수 있는 인증 요소에는 크게 세 가지 부류, 즉 사용자가 가진 것, 사용자가 아는 것 및 사용자 자신인 것이 있다. 각각의 예로 물리적 키, 비밀번호 및 지문이 있다.

모든 WebAuthn 인증기는 사용자가 가진 것 부류에 속하지만, 사용자 검증을 지원하는 인증기는 한두 가지 추가 인증 요소로도 작동할 수 있다. 예를 들어 인증기가 PIN을 검증할 수 있다면 PIN은 사용자가 아는 것이며, 생체 인증기는 사용자 자신인 것을 검증할 수 있다. 따라서 사용자 검증을 지원하는 인증기는 다중 요소 지원 인증기이다. 반대로 다중 요소 지원 인증기가 아닌 인증기는 단일 요소 지원 인증기이다. 하나의 다중 요소 지원 인증기가 여러 사용자 검증 모드를 지원할 수도 있으며, 이는 세 종류의 인증 요소 모두로 작동할 수 있음을 의미한다.

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

6.3. 인증기 작업

WebAuthn 클라이언트는 인증기의 작업을 호출하려면 반드시 해당 인증기에 연결해야 한다. 이 연결은 인증기 세션을 정의한다. 인증기는 세션 간 격리를 유지해야 한다. 특정 시점에 하나의 세션만 존재하도록 허용하거나 더 복잡한 세션 관리를 제공하여 이를 수행할 수 있다.

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

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 작업

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

hash: 클라이언트가 제공한 직렬화된 클라이언트 데이터의 해시.
rpEntity: 신뢰 당사자의 PublicKeyCredentialRpEntity.
userEntity: 신뢰 당사자가 지정한 사용자 핸들을 포함하는 사용자 계정의 PublicKeyCredentialUserEntity.
requireResidentKey: 클라이언트가 결정한 불리언 값인 자격 증명 생성을 위한 유효 상주 키 요구 사항.
requireUserPresence: 상수 불리언 값 true. WebAuthn에서는 사용자 존재 테스트가 선택 사항이 아니지만, 이를 선택 사항으로 만들고자 할 수 있는 구현에 이 추상 인증기 모델을 간단히 적용할 수 있도록 의사 매개변수로 여기에 포함된다.
requireUserVerification: 클라이언트가 결정한 불리언 값인 자격 증명 생성을 위한 유효 사용자 검증 요구 사항.
credTypesAndPubKeyAlgs: 신뢰 당사자가 요청한 PublicKeyCredentialType과 공개 키 알고리즘(COSEAlgorithmIdentifier) 쌍의 시퀀스. 이 시퀀스는 가장 선호되는 항목부터 가장 덜 선호되는 항목 순으로 정렬된다. 인증기는 생성할 수 있는 가장 선호도 높은 자격 증명을 만들기 위해 최선을 다한다.
excludeCredentialDescriptorList: 신뢰 당사자가 제공한 PublicKeyCredentialDescriptor 객체의 선택적 목록. 인증기가 이 객체 중 하나라도 알고 있다면 새 자격 증명을 생성하지 않는 것이 좋다는 의도로 제공된다. excludeCredentialDescriptorList에는 알려진 자격 증명 목록이 들어 있다.
enterpriseAttestationPossible: 인증기가 개인을 식별하는 증명을 반환할 수 있음을 나타내는 불리언 값.
extensions: 신뢰 당사자가 요청한 확장이 있는 경우 이를 기반으로 클라이언트가 생성한, 확장 식별자를 해당 인증기 확장 입력에 대응시키는 CBOR 맵.

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

이 작업이 호출되면 인증기는 반드시 다음 절차를 수행해야 한다.

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

requireUserPresence가 true이면 승인 동작에는 반드시 사용자 존재 테스트가 포함되어야 한다.

사용자가 동의하지 않거나 사용자 검증에 실패하면, "NotAllowedError"에 해당하는 오류 코드를 반환하고 작업을 종료한다.
승인 동작이 완료되고 사용자 동의를 얻었으면 새 자격 증명 객체를 생성한다.
1. (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를 포함하는 증명된 자격 증명 데이터 바이트 배열이라고 하자.
authenticatorData를 § 6.1 인증기 데이터에 규정된 바이트 배열이라고 하자. 여기에는 attestedCredentialData가 attestedCredentialData로 포함되며, processedExtensions가 있다면 extensions로 포함된다.
인증기가 선택한 증명 구문 형식, authenticatorData 및 hash를 사용하고 enterpriseAttestationPossible의 값도 taking into account하여, § 6.5.4 증명 객체 생성하기에 규정된 절차로 새 자격 증명에 대한 증명 객체를 생성한다. 증명에 대한 자세한 내용은 § 6.5 증명을 참조한다.

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

6.3.3. authenticatorGetAssertion 작업

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

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

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

이 메서드가 호출되면 인증기는 반드시 다음 절차를 수행해야 한다.

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

requireUserVerification이 true이면 승인 동작에는 반드시 사용자 검증이 포함되어야 한다.

requireUserPresence가 true이면 승인 동작에는 반드시 사용자 존재 테스트가 포함되어야 한다.

사용자가 동의하지 않으면 "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
  
  참고: 반환된 userHandle 값은 null일 수 있다. userHandleResult를 참조한다.

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

6.3.4. authenticatorCancel 작업

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

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

현재 진행 중인 authenticatorMakeCredential 또는 authenticatorGetAssertion 작업이 없는 인증기 세션에서 호출하면 이 작업은 무시된다.

6.4. 문자열 처리

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

6.4.1. 문자열 잘라내기

API의 각 임의 문자열에는 인증기가 사용할 수 있는 자원이 제한적일 가능성에 대비한 조치가 마련된다. 문자열 값 잘라내기를 조치로 선택한 경우, 인증기는 문자열이 지정된 최소 지원 길이 이상의 길이에 들어가도록 자를 수 있다. 이러한 잘라내기에서는 UTF-8 시퀀스 경계 또는 문자소 클러스터 경계 [UTR29]도 존중하는 것이 좋다. 이는 허용되는 최대 잘라내기 범위를 정의하며, 인증기는 절대로 이보다 더 잘라서는 안 된다.

예를 들어 그림 의 문자열 길이는 65바이트이다. 64바이트로 자르는 경우 마지막 0x88 바이트는 공간상의 이유만으로 반드시 제거해야 한다. 그러면 불완전한 UTF-8 시퀀스가 남으므로 해당 시퀀스의 나머지도 제거할 수 있다. 그 결과 불완전한 문자소 클러스터가 남으므로 인증기는 해당 클러스터의 나머지도 제거할 수 있다.

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

준수 사용자 에이전트는 신뢰 당사자가 관찰하는 인증기 동작이 문자열 처리와 관련하여 이 명세를 준수하도록 보장할 책임이 있다. 예를 들어 인증기가 큰 문자열을 저장하도록 요청받았을 때 잘못 작동한다고 알려져 있다면, 사용자 에이전트는 신뢰 당사자의 관점에서 모델을 유지하기 위해 인증기를 대신하여 잘라내기를 수행하는 것이 좋다. 이를 수행하는 사용자 에이전트는 문자소 클러스터 경계에서 자르는 것이 좋다.

UTF-8 시퀀스만을 기준으로 자르면 문자소 클러스터가 잘릴 수 있다. 그러면 글리프를 완전히 제거하는 대신 문자소 클러스터가 다른 글리프로 렌더링되어 문자열의 의미가 바뀔 수 있다.

또한 바이트 경계만을 기준으로 자르면 사용자 에이전트가 알아야 할 다음과 같은 문제가 발생한다. 인증기가 [FIDO-CTAP]을 사용한다면 값의 유형이 CBOR 문자열이어서 유효한 UTF-8이어야 하므로, 인증기의 이후 메시지에 유효하지 않은 CBOR이 들어 있을 수 있다. 인증기가 문자 인코딩과 유니코드 문자 속성을 이해해야 하는 부담을 피하도록 이 문제를 처리하는 일은 사용자 에이전트에 맡겨진다. 따라서 인증기를 다룰 때 사용자 에이전트는 다음과 같이 하는 것이 좋다.

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

6.4.2. 언어 및 방향 인코딩

문자열을 컨텍스트에서 올바르게 표시하려면 그 언어와 기본 방향이 필요할 수 있다. 이 API의 문자열은 고정 기능 인증기에 기록된 다음 나중에 다시 읽혀 다른 플랫폼에 표시되어야 할 수 있다. 따라서 언어와 방향 메타데이터가 원자적으로 전송되도록 문자열 자체에 인코딩한다.

언어 및 방향 메타데이터를 허용한다고 문서화된 문자열에 이를 인코딩하려면, 문자열의 코드 포인트 뒤에 두 코드 포인트 시퀀스를 붙인다.

첫 번째 시퀀스는 코드 포인트 U+E0001 뒤에 언어 태그의 각 ASCII 값을 U+E0000만큼 올린 값을 붙여 언어 태그를 인코딩한다. 예를 들어 언어 태그 “en-US”는 코드 포인트 U+E0001, U+E0065, U+E006E, U+E002D, U+E0055, U+E0053이 된다.

두 번째 시퀀스는 U+200E(“LEFT-TO-RIGHT MARK”), U+200F(“RIGHT-TO-LEFT MARK”) 또는 U+E007F(“CANCEL TAG”) 중 하나인 단일 코드 포인트로 구성된다. 앞의 두 값은 방향성을 나타내는 데 사용할 수 있지만 올바른 결과를 얻는 데 필요한 경우에만 사용하는 것이 좋다. 예를 들면 LTR 강문자로 시작하는 RTL 문자열이다. U+E007F 값은 언어 태그의 끝을 방향과 무관하게 나타낸다.

따라서 문자열 “حبیب الرحمان”은 언어가 인코딩되었는지에 따라 서로 다른 두 가지 DOMString 값을 가질 수 있다. 이 예에서는 방향이 명확하므로 방향성 표식이 필요하지 않다.

꾸미지 않은 문자열: U+FEA2, U+FE92, U+FBFF, U+FE91, U+20, U+FE8E, U+FEDF, U+FEAE, U+FEA4, U+FEE3, U+FE8E, U+FEE7
언어 “ar-SA”를 인코딩한 문자열: U+FEA2, U+FE92, U+FBFF, U+FE91, U+20, U+FE8E, U+FEDF, U+FEAE, U+FEA4, U+FEE3, U+FE8E, U+FEE7, U+E0001, U+E0061, U+E0072, U+E002D, U+E0053, U+E0041, U+E007F

언어와 방향이 인코딩되었을 수 있는 문자열의 소비자는 잘라내기로 인해 언어 태그가 다르지만 여전히 유효한 언어로 잘릴 수 있음을 알아야 한다. 마지막 방향성 표식 또는 CANCEL TAG 코드 포인트는 잘라내기를 명확하게 나타낸다.

6.5. 증명

인증기는 가능하다면 어떤 형태로든 증명을 제공하는 것이 좋다. 인증기가 이를 제공하는 경우 기본 요구 사항은 인증기가 각 자격 증명 공개 키에 대해 WebAuthn 신뢰 당사자가 검증할 수 있는 증명 구문을 생성할 수 있어야 한다는 것이다. 일반적으로 이 증명 구문에는 증명된 자격 증명 공개 키와 챌린지를 대상으로 증명 개인 키로 생성한 서명 및 증명 공개 키의 출처 정보를 제공하는 인증서 또는 유사한 데이터가 포함된다. 이를 통해 신뢰 당사자가 신뢰 결정을 내릴 수 있다. 그러나 증명 키 쌍을 사용할 수 없다면 인증기는 해당 자격 증명 개인 키를 사용하여 자격 증명 공개 키의 자체 증명을 수행하거나, 증명 없음을 수행할 수 있다. 이 모든 정보는 새 공개 키 자격 증명이 생성될 때마다 인증기가 증명 객체라는 전체 형식으로 반환한다. 증명 객체와 인증기 데이터(증명된 자격 증명 데이터 포함) 및 증명 구문의 관계는 아래 그림 에 나와 있다.

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

포함된 인증기 데이터(증명된 자격 증명 데이터 포함) 및 증명 구문을 보여 주는 증명 객체 레이아웃.

이 그림은 packed 증명 구문 형식만 보여 준다. 여러 추가 증명 구문 형식은 § 8 정의된 증명 구문 형식에 정의되어 있다.

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

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

일반적으로 증명 구문 형식과 증명 유형 사이에는 단순한 대응 관계가 없다. 예를 들어 § 8.2 패킹된 증명 구문 형식에 정의된 "packed" 증명 구문 형식은 모든 증명 유형과 함께 사용할 수 있지만, 다른 형식과 유형은 적용 범위가 더 제한적이다.

증명의 개인정보 보호, 보안 및 작동 특성은 다음에 따라 달라진다.

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

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

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

증명된 자격 증명 데이터는 주어진 자격 증명에 대한 증명 객체를 생성할 때 인증기 데이터에 추가되는 가변 길이 바이트 배열이다. 그 형식은 표 에 나와 있다.

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

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

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

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

[RFC8152]의 제7절은 COSE_Key로 인코딩된 모든 키의 일반적인 프레임워크를 정의한다. 특정 알고리즘의 특정 키 유형은 아래에 언급된 대로 [RFC8152]의 다른 절과 기타 명세에 정의되어 있다.

다음은 P-256 곡선에서 ES256 서명 알고리즘(SHA-256을 사용하는 ECDSA, [RFC8152] 제8.1절 참조)과 함께 사용되는 EC2 형식([RFC8152] 제13.1절 참조)의 COSE_Key로 인코딩된 타원 곡선 공개 키의 예이다.

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

다음은 위의 타원 곡선 공개 키를 CTAP2 정규 CBOR 인코딩 형식으로 인코딩한 것이다. 명확성을 높이고 위의 CDDL [RFC8610] 표현과 일치시키기 위해 여기에 공백과 줄바꿈을 포함했다.

A5
   01  02

   03  26

   20  01

   21  58 20   65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d

   22  58 20   1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c

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

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

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

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

6.5.2. 증명 구문 형식

위에서 설명한 것처럼 증명 구문 형식은 일련의 맥락 바인딩에 대해 인증기가 생성한 암호화 서명을 나타내는 데이터 형식이다. 각 증명 구문 형식은 다음 템플릿을 사용하여 반드시 정의해야 한다.

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

처음으로 명시된 증명 구문 형식 목록은 § 8 정의된 증명 구문 형식에 있다.

6.5.3. 증명 유형

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

참고: 이 명세는 인증기가 사용하는 증명 유형을 명시적으로 표현하는 데이터 구조를 정의하지 않는다. 증명 구문 검증을 수행하는 신뢰 당사자—즉, navigator.credentials.create()를 호출할 때 none 이외의 증명 전달을 선택하고 수신한 증명 구문을 검증하는 신뢰 당사자—는 검증의 일부로 사용된 증명 유형을 결정한다. § 8 정의된 증명 구문 형식의 “검증 절차” 하위 절을 참조하라. § 14.4.1 증명 개인정보 보호도 참조하라. 이 절에 정의된 모든 증명 유형 중 자체와 없음을 제외한 유형에서는 신뢰 당사자의 검증 다음에 § 7.1 새 자격 증명 등록의 21단계에 따라 신뢰 경로를 허용 가능한 루트 인증서와 대조한다. 이러한 증명 유형을 구분하는 것은 주로 증명이 신뢰 당사자 정책에 따라 허용 가능한지 결정하는 수단으로 유용하다.

기본 증명 (기본)

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

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

자체 증명 (자체)

대리 기본 증명 [UAFProtocol]이라고도 하는 자체 증명의 경우 인증기에는 특정한 증명 키 쌍이 없다. 대신 자격 증명 개인 키를 사용하여 증명 서명을 생성한다. 증명 개인 키를 위한 의미 있는 보호 수단이 없는 인증기는 일반적으로 이 증명 유형을 사용한다.

증명 CA (AttCA)

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

참고: 이 개념은 일반적으로 여러 개의 증명 인증서를 생성한다. 가장 최근에 요청된 증명 인증서를 “활성”이라고 한다.

익명화 CA (AnonCA)

이 경우 인증기는 자격 증명별 증명 인증서를 동적으로 생성하는 익명화 CA를 사용한다. 따라서 자격 증명에 대해 신뢰 당사자에게 제시되는 증명 구문은 추적 목적으로 사용될 수 있는 정보와 같이 고유하게 식별 가능한 정보를 제공하지 않는다.

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

증명 구문 없음 (없음)

이 경우 사용할 수 있는 증명 정보가 없다. § 8.7 증명 구문 없음 형식도 참조하라.

6.5.4. 증명 객체 생성

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

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

인증기는 반드시 다음을 수행해야 한다.

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

이 알고리즘이 초기화한 변수로 채워진 다음 구문의 CBOR 맵으로 증명 객체를 반환한다.

    attObj = {
authData: bytes,
$$attStmtType
}

```
attStmtTemplate = (
                      fmt: text,
                      attStmt: { * tstr => any } ; Map is filled in by each concrete attStmtType
                  )

; Every attestation statement format must have the above fields
attStmtTemplate .within $$attStmtType
```

6.5.5. 패킹된 증명, FIDO U2F 증명 및 어서션 서명의 서명 형식

COSEAlgorithmIdentifier -7(ES256) 및 기타 ECDSA 기반 알고리즘의 경우 sig 값은 [RFC3279] 제2.2.3절에 정의된 ASN.1 DER Ecdsa-Sig-Value로 반드시 인코딩해야 한다.

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

참고: CTAP1/U2F 인증기가 이미 이 형식으로 서명 값을 생성하고 있으므로, 일관성을 위해 CTAP2 인증기도 같은 형식으로 서명 값을 생성한다.

새로 정의되는 증명 형식에서는 ASN.1 인코딩을 사용하지 않고, 대신 [RFC8152]와 [RFC8230]에 정의된 COSE 서명에서 사용하는 것과 같은 표현을 사용하여 서명을 내부 구조가 없는 동등한 고정 길이 바이트 배열로 나타내는 것이 권장된다.

아래 서명 형식 정의는 이 요구 사항을 충족하며, 여기에 명시적으로 언급되지 않은 다른 서명 알고리즘에 대해 동일한 형식을 도출하는 예로 사용된다.

COSEAlgorithmIdentifier -257(RS256)의 경우 sig는 [RFC8017] 제8.2.1절에 정의된 RSASSA-PKCS1-v1_5 서명 체계에서 SHA-256을 해시 함수로 사용하여 생성한 서명을 반드시 포함해야 한다. 이 서명은 ASN.1로 래핑되지 않는다.
COSEAlgorithmIdentifier -37(PS256)의 경우 sig는 [RFC8017] 제8.1.1절에 정의된 RSASSA-PSS 서명 체계에서 SHA-256을 해시 함수로 사용하여 생성한 서명을 반드시 포함해야 한다. 이 서명은 ASN.1로 래핑되지 않는다.

7. WebAuthn 신뢰 당사자 작업

등록 또는 인증 세레모니는 WebAuthn 신뢰 당사자가 각각 세레모니의 매개변수를 인코딩하는 PublicKeyCredentialCreationOptions 또는 PublicKeyCredentialRequestOptions 객체를 생성하면서 시작된다. 신뢰 당사자는 이 단계에서 민감한 정보가 유출되지 않도록 주의하는 것이 좋다. 자세한 내용은 § 14.6.2 사용자 이름 열거를 참조하라.

create() 또는 get()이 성공적으로 실행되면 신뢰 당사자의 스크립트는 클라이언트로부터 각각 AuthenticatorAttestationResponse 또는 AuthenticatorAssertionResponse 구조를 포함하는 PublicKeyCredential을 수신한다. 그런 다음 명세의 범위를 벗어나는 방법을 사용하여 이 구조의 내용을 신뢰 당사자 서버에 전달해야 한다. 이 절에서는 이러한 구조를 수신한 신뢰 당사자가 수행해야 하는 작업을 설명한다.

7.1. 새 자격 증명 등록

등록 세레모니를 수행하려면 신뢰 당사자는 반드시 다음과 같이 진행해야 한다.

options를 세레모니에 대한 신뢰 당사자의 요구에 맞게 구성된 새로운 PublicKeyCredentialCreationOptions 구조로 설정한다.
navigator.credentials.create()를 호출하고 options를 publicKey 옵션으로 전달한다. credential을 성공적으로 이행된 프로미스의 결과로 설정한다. 프로미스가 거부되면 사용자에게 표시되는 오류와 함께 세레모니를 중단하거나, 거부된 프로미스에서 사용할 수 있는 맥락으로 판단할 수 있는 방식에 따라 사용자 경험을 안내한다. 예를 들어 프로미스가 "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 값이 options.challenge의 base64url 인코딩과 같은지 검증한다.
C.origin 값이 신뢰 당사자의 출처와 일치하는지 검증한다.
C.tokenBinding.status 값이 어서션을 얻은 TLS 연결의 토큰 바인딩 상태와 일치하는지 검증한다. 해당 TLS 연결에서 토큰 바인딩을 사용했다면 C.tokenBinding.id가 연결의 토큰 바인딩 ID를 base64url 인코딩한 값과 일치하는지도 검증한다.
hash를 response.clientDataJSON에 SHA-256을 사용하여 해시를 계산한 결과로 설정한다.
AuthenticatorAttestationResponse 구조의 attestationObject 필드에 CBOR 디코딩을 수행하여 증명 구문 형식 fmt, 인증기 데이터 authData 및 증명 구문 attStmt를 얻는다.
authData의 rpIdHash가 신뢰 당사자가 예상하는 RP ID의 SHA-256 해시인지 검증한다.
authData의 플래그에 있는 사용자 존재 비트가 설정되어 있는지 검증한다.
이 등록에 사용자 검증이 필요한 경우 authData의 플래그에 있는 사용자 검증됨 비트가 설정되어 있는지 검증한다.
authData의 자격 증명 공개 키에 있는 "alg" 매개변수가 options.pubKeyCredParams의 항목 중 하나에 있는 alg 속성과 일치하는지 검증한다.
clientExtensionResults에 있는 클라이언트 확장 출력 값과 authData의 extensions에 있는 인증기 확장 출력 값이 예상과 같은지 검증한다. 이때 options.extensions에 제공된 클라이언트 확장 입력 값과, 요청되지 않은 확장, 즉 options.extensions의 일부로 지정되지 않은 확장에 관한 신뢰 당사자의 특정 정책을 고려한다. 일반적으로 “예상과 같다”의 의미는 신뢰 당사자와 사용 중인 확장에 따라 달라진다.

참고: 클라이언트 플랫폼은 추가 인증기 확장 또는 클라이언트 확장을 설정하는 로컬 정책을 시행할 수 있다. 이에 따라 원래 options.extensions의 일부로 지정되지 않은 값이 인증기 확장 출력 또는 클라이언트 확장 출력에 나타날 수 있다. 신뢰 당사자는 요청되지 않은 확장을 무시하거나 증명을 거부하는 방식 등으로 이러한 상황을 처리할 준비가 반드시 되어 있어야 한다. 신뢰 당사자는 로컬 정책과 사용 중인 확장에 따라 이러한 결정을 내릴 수 있다.

참고: 모든 확장은 클라이언트와 인증기 모두에 선택 사항이므로, 신뢰 당사자는 요청된 확장이 하나도 처리되지 않았거나 일부만 처리된 경우도 처리할 준비가 반드시 되어 있어야 한다.
fmt를 지원되는 WebAuthn 증명 구문 형식 식별자 값 집합과 USASCII 대소문자 구분 방식으로 일치시켜 증명 구문 형식을 결정한다. 등록된 WebAuthn 증명 구문 형식 식별자 값의 최신 목록은 [RFC8809]에 의해 수립된 IANA “WebAuthn 증명 구문 형식 식별자” 레지스트리 [IANA-WebAuthn-Registries]에서 관리한다.
attStmt, authData 및 hash가 주어졌을 때 증명 구문 형식 fmt의 검증 절차를 사용하여 attStmt가 유효한 증명 서명을 전달하는 올바른 증명 구문인지 검증한다.

참고: 각 증명 구문 형식은 자체 검증 절차를 지정한다. 처음 정의된 형식은 § 8 정의된 증명 구문 형식을, 최신 목록은 [IANA-WebAuthn-Registries]를 참조하라.
검증에 성공하면 신뢰할 수 있는 출처 또는 정책에서 해당 증명 유형 및 증명 구문 형식 fmt에 허용 가능한 신뢰 앵커, 즉 증명 루트 인증서 목록을 얻는다. 예를 들어 FIDO 메타데이터 서비스 [FIDOMetadataService]는 authData의 attestedCredentialData에 있는 aaguid를 사용하여 이러한 정보를 얻는 한 가지 방법을 제공한다.
다음과 같이 19단계의 검증 절차 출력을 사용하여 증명의 신뢰성을 평가한다.
- 증명 없음이 제공된 경우 없음 증명이 신뢰 당사자 정책에 따라 허용 가능한지 검증한다.
- 자체 증명을 사용한 경우 자체 증명이 신뢰 당사자 정책에 따라 허용 가능한지 검증한다.
- 그렇지 않으면 검증 절차에서 증명 신뢰 경로로 반환된 X.509 인증서를 사용하여 증명 공개 키가 허용 가능한 루트 인증서에 올바르게 연결되거나 그 자체가 허용 가능한 인증서인지 검증한다. 후자의 경우 그 인증서와 20단계에서 얻은 루트 인증서가 같을 수 있다.
credentialId가 아직 다른 사용자에게 등록되지 않았는지 확인한다. 이미 다른 사용자에게 등록된 자격 증명에 대해 등록을 요청한 경우 신뢰 당사자는 이 등록 세레모니를 실패시키는 것이 좋다. 또는 예를 들어 이전 등록을 삭제하면서 새 등록을 허용하도록 결정할 수 있다.
증명 구문 attStmt가 성공적으로 검증되고 신뢰할 수 있는 것으로 확인되면 새 자격 증명을 options.user에 표시된 계정에 등록한다.
- 신뢰 당사자의 시스템에 적합한 방식으로 사용자 계정을 authData.attestedCredentialData의 credentialId 및 credentialPublicKey와 연결한다.
- credentialId를 authData.signCount 값으로 초기화된 새로운 저장 서명 카운터 값과 연결한다.
다음도 수행하는 것이 권장된다.
- credentialId를 credential.response.getTransports()을 호출하여 반환된 전송 힌트와 연결한다. 이 값은 저장하기 전이나 후에 수정하지 않는 것이 좋다. 향후 get() 호출에서 allowCredentials 옵션의 transports를 채우는 데 이 값을 사용하는 것이 권장된다. 이는 클라이언트가 적합한 인증기를 찾는 방법을 파악하는 데 도움이 된다.
증명 구문 attStmt가 성공적으로 검증되었지만 위의 21단계에 따라 신뢰할 수 없는 경우 신뢰 당사자는 등록 세레모니를 실패시키는 것이 좋다.

참고: 그러나 정책에서 허용하는 경우 신뢰 당사자는 자격 증명 ID와 자격 증명 공개 키를 등록하되 해당 자격 증명을 자체 증명이 있는 자격 증명으로 취급할 수 있다(§ 6.5.3 증명 유형 참조). 이렇게 하는 경우 신뢰 당사자는 공개 키 자격 증명이 특정 인증기 모델에 의해 생성되었다는 암호학적 증거가 없다고 단언하는 것이다. 더 자세한 논의는 [FIDOSecRef]와 [UAFProtocol]을 참조하라.

증명 객체를 검증하려면 신뢰 당사자가 위의 20단계에서 허용 가능한 신뢰 앵커를 결정하는 신뢰할 수 있는 방법을 보유해야 한다. 또한 인증서를 사용하는 경우 신뢰 당사자는 중간 CA 인증서의 인증서 상태 정보에 반드시 접근할 수 있어야 한다. 클라이언트가 증명 정보에 증명 인증서 체인을 제공하지 않았다면 신뢰 당사자는 이 체인도 반드시 구성할 수 있어야 한다.

7.2. 인증 어서션 검증

인증 세레모니를 수행하려면 신뢰 당사자는 반드시 다음과 같이 진행해야 한다.

options를 세레모니에 대한 신뢰 당사자의 요구에 맞게 구성된 새로운 PublicKeyCredentialRequestOptions 구조로 설정한다.

options.allowCredentials가 존재하는 경우 각 항목의 transports 멤버는 해당 자격 증명을 등록할 때 credential.response.getTransports()이 반환한 값으로 설정하는 것이 좋다.
navigator.credentials.get()을 호출하고 options를 publicKey 옵션으로 전달한다. credential을 성공적으로 이행된 프로미스의 결과로 설정한다. 프로미스가 거부되면 사용자에게 표시되는 오류와 함께 세레모니를 중단하거나, 거부된 프로미스에서 사용할 수 있는 맥락으로 판단할 수 있는 방식에 따라 사용자 경험을 안내한다. 다양한 오류 맥락과 그러한 오류가 발생하는 상황에 관한 정보는 § 6.3.3 authenticatorGetAssertion 작업을 참조하라.
response를 credential.response로 설정한다. response가 AuthenticatorAssertionResponse의 인스턴스가 아니면 사용자에게 표시되는 오류와 함께 세레모니를 중단한다.
clientExtensionResults를 credential.getClientExtensionResults()을 호출한 결과로 설정한다.
options.allowCredentials가 비어 있지 않은 경우, credential.id가 options.allowCredentials에 나열된 공개 키 자격 증명 중 하나를 식별하는지 검증한다.
인증되는 사용자를 식별하고, 이 사용자가 credential.id로 식별되는 공개 키 자격 증명 소스 credentialSource의 소유자인지 검증한다.

예를 들어 사용자 이름이나 쿠키를 통해 인증 세레모니를 시작하기 전에 사용자를 식별한 경우,

식별된 사용자가 credentialSource의 소유자인지 검증한다. response.userHandle이 존재하는 경우 userHandle을 그 값으로 설정한다. userHandle도 같은 사용자에 매핑되는지 검증한다.

인증 세레모니를 시작하기 전에 사용자를 식별하지 않은 경우,

response.userHandle이 존재하고 이 값으로 식별되는 사용자가 credentialSource의 소유자인지 검증한다.
credential.id를 사용하여(사용 사례에 base64url 인코딩이 적합하지 않다면 credential.rawId를 사용하여) 해당 자격 증명 공개 키를 조회하고 credentialPublicKey를 그 자격 증명 공개 키로 설정한다.
cData, authData 및 sig가 각각 response의 clientDataJSON, authenticatorData 및 signature 값을 나타내도록 한다.
JSONtext를 cData 값에 UTF-8 디코딩을 실행한 결과로 설정한다.

참고: UTF-8 디코딩 알고리즘이 산출하는 결과와 동일한 결과를 산출하기만 하면 어떤 UTF-8 디코딩 구현을 사용해도 된다. 특히 선행 바이트 순서 표시(BOM)는 반드시 제거해야 한다.
C, 즉 서명에 사용되었다고 주장되는 클라이언트 데이터를 JSONtext에 구현별 JSON 파서를 실행한 결과로 설정한다.

참고: 이 알고리즘에서 요구하는 대로 C의 구성 요소를 참조할 수 있기만 하면 C는 어떠한 구현별 데이터 구조 표현이어도 된다.
C.type 값이 문자열 webauthn.get인지 검증한다.
C.challenge 값이 options.challenge의 base64url 인코딩과 같은지 검증한다.
C.origin 값이 신뢰 당사자의 출처와 일치하는지 검증한다.
C.tokenBinding.status 값이 증명을 얻은 TLS 연결의 토큰 바인딩 상태와 일치하는지 검증한다. 해당 TLS 연결에서 토큰 바인딩을 사용했다면 C.tokenBinding.id가 연결의 토큰 바인딩 ID를 base64url 인코딩한 값과 일치하는지도 검증한다.
authData의 rpIdHash가 신뢰 당사자가 예상하는 RP ID의 SHA-256 해시인지 검증한다.
참고: appid 확장을 사용하는 경우 이 단계에는 몇 가지 특수 논리가 필요하다. 자세한 내용은 § 10.1 FIDO AppID 확장(appid)을 참조하라.
authData의 플래그에 있는 사용자 존재 비트가 설정되어 있는지 검증한다.
이 어서션에 사용자 검증이 필요한 경우 authData의 플래그에 있는 사용자 검증됨 비트가 설정되어 있는지 검증한다.
clientExtensionResults에 있는 클라이언트 확장 출력 값과 authData의 extensions에 있는 인증기 확장 출력 값이 예상과 같은지 검증한다. 이때 options.extensions에 제공된 클라이언트 확장 입력 값과, 요청되지 않은 확장, 즉 options.extensions의 일부로 지정되지 않은 확장에 관한 신뢰 당사자의 특정 정책을 고려한다. 일반적으로 “예상과 같다”의 의미는 신뢰 당사자와 사용 중인 확장에 따라 달라진다.

참고: 클라이언트 플랫폼은 추가 인증기 확장 또는 클라이언트 확장을 설정하는 로컬 정책을 시행할 수 있다. 이에 따라 원래 options.extensions의 일부로 지정되지 않은 값이 인증기 확장 출력 또는 클라이언트 확장 출력에 나타날 수 있다. 신뢰 당사자는 요청되지 않은 확장을 무시하거나 어서션을 거부하는 방식 등으로 이러한 상황을 처리할 준비가 반드시 되어 있어야 한다. 신뢰 당사자는 로컬 정책과 사용 중인 확장에 따라 이러한 결정을 내릴 수 있다.

참고: 모든 확장은 클라이언트와 인증기 모두에 선택 사항이므로, 신뢰 당사자는 요청된 확장이 하나도 처리되지 않았거나 일부만 처리된 경우도 처리할 준비가 반드시 되어 있어야 한다.
hash를 cData에 SHA-256을 사용하여 해시를 계산한 결과로 설정한다.
credentialPublicKey를 사용하여 sig가 authData와 hash의 이진 연결에 대한 유효한 서명인지 검증한다.

참고: 이 검증 단계는 FIDO U2F 인증기가 생성한 서명과 호환된다. § 6.1.2 FIDO U2F 서명 형식 호환성을 참조하라.
storedSignCount를 credential.id와 연결된 저장 서명 카운터 값으로 설정한다. authData.signCount가 0이 아니거나 storedSignCount가 0이 아니면 다음 하위 단계를 실행한다.
- authData.signCount가 다음 중 하나인 경우:
  
  storedSignCount보다 큰 경우:
  storedSignCount를 authData.signCount 값으로 업데이트한다.
  storedSignCount보다 작거나 같은 경우:
  이는 인증기가 복제되었을 수 있다는 신호이다. 즉, 자격 증명 개인 키의 복사본이 두 개 이상 존재하며 병렬로 사용되고 있을 수 있다. 신뢰 당사자는 이 정보를 위험 점수 산정에 반영하는 것이 좋다. 이 경우 신뢰 당사자가 storedSignCount를 업데이트할지 여부 또는 인증 세레모니를 실패시킬지 여부는 신뢰 당사자별로 다르다.
위의 모든 단계가 성공하면 적절한 방식으로 인증 세레모니를 계속한다. 그렇지 않으면 인증 세레모니를 실패시킨다.

8. 정의된 증명 구문 형식

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

8.1. 증명 구문 형식 식별자

증명 구문 형식은 증명 구문 형식의 작성자가 선택한 문자열로 식별되며, 이 문자열을 증명 구문 형식 식별자라고 한다.

증명 구문 형식 식별자는 [RFC8809]에서 수립한 IANA “WebAuthn 증명 구문 형식 식별자” 레지스트리 [IANA-WebAuthn-Registries]에 등록하는 것이 좋다. 등록된 모든 증명 구문 형식 식별자는 당연히 서로 고유하다.

등록되지 않은 증명 구문 형식 식별자는 식별자의 고유성을 보장하기 위해 개발자가 등록한 도메인 이름을 사용하여 소문자 역방향 도메인 이름 명명법을 사용하는 것이 좋다. 모든 증명 구문 형식 식별자는 길이가 반드시 최대 32옥텟이어야 하며, 백슬래시와 큰따옴표를 제외한 인쇄 가능한 USASCII 문자로만 반드시 구성해야 한다. 즉, [RFC5234]에 정의된 VCHAR에서 %x22와 %x5c를 제외한 문자이다.

참고: 이는 도메인 이름을 기반으로 하는 증명 구문 형식 식별자가 반드시 LDH 레이블 [RFC5890]만 포함해야 한다는 뜻이다.

구현은 WebAuthn 증명 구문 형식 식별자를 반드시 대소문자를 구분하여 일치시켜야 한다.

여러 버전으로 존재할 수 있는 증명 구문 형식은 식별자에 버전을 포함하는 것이 좋다. 따라서 서로 다른 버전은 서로 다른 형식으로 취급된다. 예를 들어 § 8.2 패킹된 증명 구문 형식의 새 버전에는 packed2를 사용할 수 있다.

다음 절에서는 현재 정의되고 등록된 증명 구문 형식과 그 식별자 집합을 제시한다. 등록된 WebAuthn 확장의 최신 목록은 [RFC8809]에서 수립한 IANA “WebAuthn 증명 구문 형식 식별자” 레지스트리 [IANA-WebAuthn-Registries]에서 관리한다.

8.2. 패킹된 증명 구문 형식

이는 WebAuthn에 최적화된 증명 구문 형식이다. 매우 간결하면서도 확장 가능한 인코딩 방법을 사용한다. 리소스가 제한된 인증기(예: 보안 요소)에서도 구현할 수 있다.

증명 구문 형식 식별자

packed

지원되는 증명 유형

기본, 자체, AttCA

구문

패킹된 증명 구문의 구문은 다음 CDDL로 정의한다.

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

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

필드의 의미론은 다음과 같다.

alg: 증명 서명을 생성하는 데 사용된 알고리즘의 식별자를 포함하는 COSEAlgorithmIdentifier.
sig: 증명 서명을 포함하는 바이트 문자열.
x5c: 이 배열의 요소에는 attestnCert와 그 인증서 체인(있는 경우)이 포함되며 각각 X.509 형식으로 인코딩된다. 증명 인증서 attestnCert는 반드시 배열의 첫 번째 요소여야 한다.
attestnCert: X.509 형식으로 인코딩된 증명 인증서.

서명 절차

이 증명 구문 형식의 서명 절차는 어서션 서명을 생성하는 절차와 유사하다.

authenticatorData가 증명을 위한 인증기 데이터를 나타내도록 하고, clientDataHash가 직렬화된 클라이언트 데이터의 해시를 나타내도록 한다.
기본 또는 AttCA 증명을 사용하는 경우 인증기는 authenticatorData와 clientDataHash를 연결하고, 인증기별 메커니즘을 통해 선택한 증명 개인 키를 사용하여 그 결과에 서명함으로써 sig를 생성한다. x5c를 attestnCert와 그 뒤에 이어지는 관련 인증서 체인(있는 경우)으로 설정한다. alg를 증명 개인 키의 알고리즘으로 설정한다.
자체 증명을 사용하는 경우 인증기는 authenticatorData와 clientDataHash를 연결하고 자격 증명 개인 키를 사용하여 그 결과에 서명함으로써 sig를 생성한다. alg를 자격 증명 개인 키의 알고리즘으로 설정하고 다른 필드는 생략한다.

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같다.

attStmt가 위에 정의된 구문을 준수하는 유효한 CBOR인지 검증하고 CBOR 디코딩을 수행하여 포함된 필드를 추출한다.
x5c가 존재하는 경우:
- alg에 지정된 알고리즘과 attestnCert의 증명 공개 키를 사용하여 sig가 authenticatorData와 clientDataHash의 연결에 대한 유효한 서명인지 검증한다.
- attestnCert가 § 8.2.1 패킹된 증명 구문 인증서 요구 사항을 충족하는지 검증한다.
- 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와 자격 증명 공개 키를 사용하여 sig가 authenticatorData와 clientDataHash의 연결에 대한 유효한 서명인지 검증한다.
- 성공하면 증명 유형 자체와 비어 있는 증명 신뢰 경로를 나타내는 구현별 값을 반환한다.

8.2.1. 패킹된 증명 구문 인증서 요구 사항

증명 인증서에는 반드시 다음 필드/확장이 있어야 한다.

버전은 반드시 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으로 포함해야 한다. 이 확장은 절대로 중요 확장으로 표시해서는 안 된다.

X.509 확장은 값의 DER 인코딩을 OCTET STRING으로 인코딩한다는 점에 유의하라. 따라서 AAGUID가 유효하려면 반드시 두 개의 OCTET STRING으로 래핑해야 한다. 다음은 인코딩된 확장 구조의 예이다.
```
30 21                                     -- SEQUENCE
  06 0b 2b 06 01 04 01 82 e5 1c 01 01 04  -- 1.3.6.1.4.1.45724.1.1.4
  04 12                                   -- OCTET STRING
    04 10                                 -- OCTET STRING
      cd 8c 39 5c 26 ed ee de             -- AAGUID
      65 3b 00 79 7d 03 ca 3c
```
Basic Constraints 확장의 CA 구성 요소는 반드시 false로 설정해야 한다.
많은 증명 인증서의 상태를 인증기 메타데이터 서비스를 통해 확인할 수 있으므로 id-ad-ocsp 항목이 있는 Authority Information Access(AIA) 확장과 CRL Distribution Point 확장 [RFC5280]은 모두 선택 사항이다. 예를 들어 FIDO 메타데이터 서비스 [FIDOMetadataService]를 참조하라.

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 필드를 자격 증명 공개 키의 공개 영역으로, certInfo 필드를 같은 이름의 출력 매개변수로, sig 필드를 위 절차에서 얻은 서명으로 설정한다.

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같다.

attStmt가 위에 정의된 구문을 준수하는 유효한 CBOR인지 검증하고 CBOR 디코딩을 수행하여 포함된 필드를 추출한다.

pubArea의 parameters 및 unique 필드가 지정하는 공개 키가 authenticatorData의 attestedCredentialData에 있는 credentialPublicKey와 동일한지 검증한다.

authenticatorData와 clientDataHash를 연결하여 attToBeSigned를 구성한다.

certInfo가 유효한지 검증한다.

magic이 TPM_GENERATED_VALUE로 설정되어 있는지 검증한다.
type이 TPM_ST_ATTEST_CERTIFY로 설정되어 있는지 검증한다.
extraData가 "alg"에서 사용하는 해시 알고리즘으로 계산한 attToBeSigned의 해시로 설정되어 있는지 검증한다.
attested가 [TPMv2-Part2] 제10.12.3절에 지정된 TPMS_CERTIFY_INFO 구조를 포함하는지 검증한다. 이 구조의 name 필드는 [TPMv2-Part1] 제16절에 지정된 절차에 따라 pubArea의 nameAlg 필드에 있는 알고리즘을 사용하여 계산한 pubArea의 유효한 Name을 포함해야 한다.
x5c가 존재하는지 검증한다.
“표준 증명 구조” [TPMv2-Part1] 제31.2절의 나머지 필드, 즉 qualifiedSigner, clockInfo 및 firmwareVersion은 무시한다. 이러한 필드는 위험 엔진의 입력으로 사용할 수 있다.
alg에 지정된 알고리즘과 aikCert의 증명 공개 키를 사용하여 sig가 certInfo에 대한 유효한 서명인지 검증한다.
aikCert가 § 8.3.1 TPM 증명 구문 인증서 요구 사항을 충족하는지 검증한다.
aikCert가 OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid)인 확장을 포함하는 경우 이 확장의 값이 authenticatorData의 aaguid와 일치하는지 검증한다.
성공하면 증명 유형 AttCA와 증명 신뢰 경로 x5c를 나타내는 구현별 값을 반환한다.

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

TPM 증명 인증서에는 반드시 다음 필드/확장이 있어야 한다.

버전은 반드시 3으로 설정해야 한다.
Subject 필드는 반드시 비어 있도록 설정해야 한다.
Subject Alternative Name 확장은 반드시 [TPMv2-EK-Profile] 제3.2.9절에 정의된 대로 설정해야 한다.
Extended Key Usage 확장은 OID 2.23.133.8.3 ("joint-iso-itu-t(2) internationalorganizations(23) 133 tcg-kp(8) tcg-kp-AIKCertificate(3)")을 반드시 포함해야 한다.
Basic Constraints 확장의 CA 구성 요소는 반드시 false로 설정해야 한다.
많은 증명 인증서의 상태를 메타데이터 서비스를 통해 확인할 수 있으므로 id-ad-ocsp 항목이 있는 Authority Information Access(AIA) 확장과 CRL Distribution Point 확장 [RFC5280]은 모두 선택 사항이다. 예를 들어 FIDO 메타데이터 서비스 [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를 챌린지 값으로 제공하면서(예: setAttestationChallenge 사용) keyStore.getCertificateChain(myKeyUUID)을 호출하여 Android 키 증명을 요청한다. x5c를 반환된 값으로 설정한다.

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

검증 절차

검증 절차 입력 attStmt, authenticatorData 및 clientDataHash가 주어졌을 때 검증 절차는 다음과 같다.

attStmt가 위에 정의된 구문을 준수하는 유효한 CBOR인지 검증하고 CBOR 디코딩을 수행하여 포함된 필드를 추출한다.
alg에 지정된 알고리즘과 x5c의 첫 번째 인증서에 있는 공개 키를 사용하여 sig가 authenticatorData와 clientDataHash의 연결에 대한 유효한 서명인지 검증한다.
x5c의 첫 번째 인증서에 있는 공개 키가 authenticatorData의 attestedCredentialData에 있는 credentialPublicKey와 일치하는지 검증한다.
증명 인증서의 확장 데이터에 있는 attestationChallenge 필드가 clientDataHash와 동일한지 검증한다.
증명 인증서의 확장 데이터에서 적절한 승인 목록을 사용하여 다음을 검증한다.
- PublicKeyCredential은 반드시 범위가 지정되어야 하며 그 범위는 RP ID여야 하므로, AuthorizationList.allApplications 필드는 어느 승인 목록(softwareEnforced 또는 teeEnforced)에도 존재하지 않는다.
- 다음 항목에서는 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 서비스의 버전 번호.
response: SafetyNet API의 getJwsResult() 호출 결과를 UTF-8로 인코딩한 값. 이 값은 압축 직렬화 형식의 JWS [RFC7515] 객체이다(SafetyNet 온라인 문서 참조).

서명 절차

authenticatorData가 증명을 위한 인증기 데이터를 나타내도록 하고, clientDataHash가 직렬화된 클라이언트 데이터의 해시를 나타내도록 한다.

authenticatorData와 clientDataHash를 연결하고 연결된 문자열의 SHA-256 해시를 수행한 뒤 그 해시 결과가 attToBeSigned를 구성하도록 한다.

attToBeSigned를 nonce 값으로 제공하여 SafetyNet 증명을 요청한다. response를 그 결과로, ver를 인증기에서 실행 중인 Google Play 서비스의 버전으로 설정한다.

검증 절차

검증 절차 입력 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절에 지정된 등록 응답 메시지를 생성한다. 이때 애플리케이션 매개변수는 주어진 자격 증명의 범위로 지정된 RP ID의 SHA-256 해시로 설정하고, 챌린지 매개변수는 clientDataHash로 설정하며, 키 핸들 매개변수는 주어진 자격 증명의 자격 증명 ID로 설정한다. 이 등록 응답 메시지의 원시 서명 부분, 즉 사용자 공개 키, 키 핸들 및 증명 인증서를 제외한 부분을 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([RFC8152]의 제7절 참조)를 원시 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절 참조).
[SEC1] 제4.1.4절에 따라 verificationData와 certificate public key를 사용하여 sig를 검증한다. 이때 두 번째 단계에서 사용되는 해시 함수로 SHA-256을 사용한다.
선택적으로 x5c를 검사하고 외부에서 제공된 지식을 참조하여 attStmt가 기본 또는 AttCA 증명을 전달하는지 결정한다.
성공하면 증명 유형 기본, AttCA 또는 불확실성과 증명 신뢰 경로 x5c를 나타내는 구현별 값을 반환한다.

8.7. 증명 구문 없음 형식

증명 구문 없음 형식은 WebAuthn 신뢰 당사자가 증명 정보를 받지 않겠다고 나타내는 경우 인증기가 제공한 모든 증명 구문을 대체하는 데 사용한다. § 5.4.7 증명 전달 선호도 열거형(enum 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: X.509 형식으로 각각 인코딩된 credCert와 그 뒤에 이어지는 인증서 체인.
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를 나타내는 구현별 값을 반환한다.

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 호출에 확장을 포함하는 경우 해당 확장의 일부 또는 전부가 무시되는 상황을 처리할 준비가 반드시 되어 있어야 한다.

가능한 한 광범위한 확장을 지원하려는 클라이언트는 인식하지 못하는 확장을 인증기에 그대로 전달하도록 선택할 수 있으며, 이때 클라이언트 확장 입력을 CBOR로 인코딩하는 것만으로 인증기 확장 입력을 생성한다. 모든 WebAuthn 확장은 이러한 구현 선택이 사용자의 보안이나 개인정보를 위험하게 하지 않도록 반드시 정의해야 한다. 예를 들어 확장에 클라이언트 처리가 필요한 경우 이러한 단순 전달이 의미론적으로 유효하지 않은 인증기 확장 입력 값을 생성하도록 정의하여 인증기가 해당 확장을 무시하게 할 수 있다. 모든 확장은 선택 사항이므로 이로 인해 API 작업이 기능적으로 실패하지는 않는다. 마찬가지로 클라이언트는 CBOR 출력이 JSON에 존재하는 형식만 사용하는 경우, 이해하지 못하는 확장의 인증기 확장 출력 값을 JSON으로 인코딩하여 클라이언트 확장 출력 값을 생성하도록 선택할 수 있다.

클라이언트가 인식하지 못하는 확장을 그대로 전달하도록 선택하면 클라이언트 확장 입력의 JavaScript 값은 인증기 확장 입력의 CBOR 값으로 변환된다. JavaScript 값이 %ArrayBuffer%이면 CBOR 바이트 배열로 변환된다. JavaScript 값이 정수가 아닌 숫자이면 64비트 CBOR 부동 소수점 숫자로 변환된다. 그렇지 않고 JavaScript 형식이 JSON 형식에 대응하면 JSON 형식 값이 아닌 JavaScript 형식 값을 입력으로 처리한다는 점을 제외하고 [RFC8949] 제6.2절(JSON에서 CBOR로 변환)에 정의된 규칙을 사용하여 변환한다. 이러한 변환이 완료되면 결과 CBOR는 CTAP2 정규 CBOR 인코딩 형식을 사용하여 반드시 정규화해야 한다.

JavaScript 숫자 변환 규칙으로 인해 다음과 같은 결과가 발생한다는 점에 유의하라. 클라이언트가 인식하지 못하는 확장을 그대로 전달할 때 해당 확장이 부동 소수점 값을 사용한다면, 실제 클라이언트 지원 없이도 확장이 항상 작동하기를 인증기가 원할 경우 인증기는 그러한 값을 CBOR 정수로 수신할 준비가 되어 있어야 한다. 이러한 상황은 사용된 부동 소수점 값이 우연히 정수일 때 발생한다.

마찬가지로 클라이언트가 인식하지 못해 그대로 전달한 확장에서 출력을 수신하면 인증기 확장 출력의 CBOR 값은 클라이언트 확장 출력의 JavaScript 값으로 변환된다. CBOR 값이 바이트 문자열이면 base64url로 인코딩된 문자열이 아니라 JavaScript %ArrayBuffer%로 변환된다. 그렇지 않고 CBOR 형식이 JSON 형식에 대응하면 JSON 형식 값을 출력하는 대신 JavaScript 형식 값을 출력한다는 점을 제외하고 [RFC8949] 제6.1절(CBOR에서 JSON으로 변환)에 정의된 규칙을 사용하여 변환한다.

일부 클라이언트는 기능 플래그 아래에서 이 그대로 전달 기능을 구현하도록 선택할 수 있다는 점에 유의하라. 이 기능을 지원하면 혁신을 촉진할 수 있으며, 인증기는 새로운 확장을 실험하고 신뢰 당사자는 클라이언트에서 명시적으로 지원하기 전에도 해당 확장을 사용할 수 있다.

등록된 WebAuthn 확장의 최신 목록은 [RFC8809]에서 수립한 IANA “WebAuthn 확장 식별자” 레지스트리 [IANA-WebAuthn-Registries]에서 확인할 수 있다.

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 신뢰 당사자가 클라이언트에서 해당 확장이 적용되었음을 알 수 있도록 클라이언트 확장 출력 값을 반드시 반환해야 한다. 마찬가지로 인증기 처리가 필요한 모든 확장은 신뢰 당사자가 인증기에서 해당 확장이 적용되었음을 알 수 있도록 인증기 확장 출력을 반드시 반환해야 한다. 확장에 그 밖의 결과 값이 필요하지 않은 경우, 확장이 이해되고 처리되었음을 나타내기 위해 true로 설정된 JSON 불리언 클라이언트 확장 출력 결과를 반환하도록 정의하는 것이 좋다. 마찬가지로 그 밖의 결과 값이 필요하지 않은 모든 인증기 확장은 반드시 값을 반환해야 하며, 확장이 이해되고 처리되었음을 나타내기 위해 true로 설정된 CBOR 불리언 인증기 확장 출력 결과를 반환하는 것이 좋다.

9.3. 요청 매개변수 확장

확장은 하나 또는 두 개의 요청 인수를 정의한다. JSON으로 인코딩할 수 있는 값인 클라이언트 확장 입력은 get() 또는 create() 호출에서 WebAuthn 신뢰 당사자가 클라이언트로 전달한다. 한편 CBOR 인증기 확장 입력은 이러한 호출을 처리하는 동안 인증기 확장을 위해 클라이언트가 인증기로 전달한다.

신뢰 당사자는 create() 또는 get() 호출의 extensions 옵션에 항목을 포함함으로써 확장 사용을 요청하는 동시에 해당 클라이언트 확장 입력을 설정한다. 항목 키는 확장 식별자이고 값은 클라이언트 확장 입력이다.

참고: 다른 문서에서는 확장 입력이 항상 확장 식별자를 항목 키로 사용하지 않는 확장을 지정한 바 있다. 새 확장은 위 규칙을 따르는 것이 좋다.

var assertionPromise = navigator.credentials.get({
    publicKey: {
        // Other members omitted for brevity
        extensions: {
            // An "entry key" identifying the "webauthnExample_foobar" extension, 
            // whose value is a map with two input parameters:
            "webauthnExample_foobar": {
              foo: 42,
              bar: "barfoo"
            }
        }
    }
});

확장의 정의는 해당 클라이언트 확장 입력의 유효한 값을 반드시 지정해야 한다. 클라이언트는 유효하지 않은 클라이언트 확장 입력이 있는 확장을 무시하는 것이 좋다. 확장에 신뢰 당사자의 매개변수가 필요하지 않은 경우, 신뢰 당사자가 확장을 요청했음을 나타내도록 true로 설정된 불리언 클라이언트 인수를 받는 것으로 정의하는 것이 좋다.

클라이언트 처리에만 영향을 미치는 확장은 인증기 확장 입력을 지정하지 않아도 된다. 인증기 처리가 있는 확장은 클라이언트 확장 입력으로부터 인증기 확장 입력을 계산하는 방법을 반드시 지정해야 한다. 또한 확장 식별자를 항목 키로 사용하여 $$extensionInput 및 $$extensionOutput 그룹 소켓에 추가 선택 항목을 정의함으로써 CDDL 형식 AuthenticationExtensionsAuthenticatorInputs 및 AuthenticationExtensionsAuthenticatorOutputs의 확장을 반드시 정의해야 한다. 입력 매개변수가 필요하지 않아 true로 설정된 불리언 클라이언트 확장 입력 값을 받는 것으로 정의된 확장은 인증기 확장 입력도 상수 불리언 값 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 맵이다.

지원되는 각 확장에 대해 해당 확장의 인증기 확장 처리 규칙을 사용하여 인증기 확장 입력 및 필요한 경우 다른 입력으로부터 인증기 확장 출력을 생성한다. 무시된 확장에 대해서는 절대로 어떠한 값도 반환해서는 안 된다.

10. 정의된 확장

이 절에서는 [RFC8809]에서 수립한 IANA “WebAuthn 확장 식별자” 레지스트리 [IANA-WebAuthn-Registries]에 등록할 추가 확장 집합을 정의한다. 광범위한 상호운용성을 목표로 하는 사용자 에이전트는 이를 구현할 수 있다.

10.1. FIDO AppID 확장(appid)

이 확장을 사용하면 레거시 FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI]를 사용하여 이전에 자격 증명을 등록한 WebAuthn 신뢰 당사자가 어서션을 요청할 수 있다. FIDO API는 신뢰 당사자에 대해 AppID [FIDO-APPID]라는 대체 식별자를 사용하며, 해당 API로 생성된 모든 자격 증명에는 그 식별자로 범위가 지정된다. 이 확장이 없으면 해당 자격 증명을 RP ID로 범위를 지정하기 위해 다시 등록해야 한다.

appid 확장 입력을 설정하는 것 외에도, 사용자가 등록된 U2F 자격 증명을 사용하여 인증할 수 있게 하려면 이 확장을 사용할 때 신뢰 당사자가 다음과 같은 추가 처리를 수행해야 한다.

원하는 U2F 자격 증명을 get() 메서드의 allowCredentials 옵션에 나열한다.
- 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를 지정하는 단일 USVString.

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appid;
};

클라이언트 확장 처리

facetId를 호출자의 출처를 호출 애플리케이션의 FacetID를 결정하는 FIDO 알고리즘에 전달한 결과로 설정한다.
appId를 확장 입력으로 설정한다.
facetId와 appId를 호출자의 FacetID가 AppID에 대해 승인되었는지 결정하는 FIDO 알고리즘에 전달한다. 해당 알고리즘이 appId를 거부하면 "SecurityError" DOMException을 반환한다.
allowCredentialDescriptorList를 구성할 때 U2F 인증기가 자격 증명을 적용할 수 없다고 나타내면(즉, SW_WRONG_DATA를 반환하면) 클라이언트는 U2F 애플리케이션 매개변수를 appId의 SHA-256 해시로 설정하여 반드시 다시 시도해야 한다. 그 결과 적용 가능한 자격 증명이 발견되면 클라이언트는 해당 자격 증명을 allowCredentialDescriptorList에 반드시 포함해야 한다. 그러면 appId 값이 authenticatorGetAssertion의 rpId 매개변수를 대체한다.
output을 불리언 값 false로 설정한다.
assertionCreationData를 생성할 때 어서션이 RP ID의 SHA-256 해시 대신 appId의 SHA-256 해시로 설정된 U2F 애플리케이션 매개변수를 사용하여 U2F 인증기에서 생성되었다면 output을 true로 설정한다.

참고: 실제로 여러 구현은 호출자의 FacetID가 AppID에 대해 승인되었는지 결정하는 알고리즘의 네 번째 단계 이후를 구현하지 않는다. 대신 세 번째 단계에서 호스트 비교를 완화하여 동일 사이트의 호스트를 허용한다.

클라이언트 확장 출력

output 값을 반환한다. 이 값이 true이면 AppID가 사용된 것이므로 어서션을 검증할 때 신뢰 당사자는 rpIdHash가 RP ID가 아니라 AppID의 해시일 것으로 반드시 예상해야 한다.

partial dictionary AuthenticationExtensionsClientOutputs {
  boolean appid;
};

인증기 확장 입력

없음.

인증기 확장 처리

없음.

인증기 확장 출력

없음.

10.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를 지정하는 단일 USVString.

partial dictionary AuthenticationExtensionsClientInputs {
  USVString appidExclude;
};

클라이언트 확장 처리

새 자격 증명을 생성할 때:

RP ID를 설정한 직후 다음 단계를 수행한다.
1. facetId를 호출자의 출처를 호출 애플리케이션의 FacetID를 결정하는 FIDO 알고리즘에 전달한 결과로 설정한다.
2. appId를 확장 입력 appidExclude의 값으로 설정한다.
3. facetId와 appId를 호출자의 FacetID가 AppID에 대해 승인되었는지 결정하는 FIDO 알고리즘에 전달한다. 후자의 알고리즘이 appId를 거부하면 "SecurityError" DOMException을 반환하고 새 자격 증명 생성 알고리즘과 이러한 단계를 모두 종료한다.
  
  참고: 실제로 여러 구현은 호출자의 FacetID가 AppID에 대해 승인되었는지 결정하는 알고리즘의 네 번째 단계 이후를 구현하지 않는다. 대신 세 번째 단계에서 호스트 비교를 완화하여 동일 사이트의 호스트를 허용한다.
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;
};

인증기 확장 입력

없음.

인증기 확장 처리

없음.

인증기 확장 출력

없음.

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

이 확장을 사용하면 사용자 검증 방법을 사용할 수 있다.

확장 식별자

uvm

작업 적용 가능성

등록 및 인증

클라이언트 확장 입력

신뢰 당사자가 이 확장을 요청했음을 나타내는 불리언 값 true.

partial dictionary AuthenticationExtensionsClientInputs {
  boolean uvm;
};

클라이언트 확장 처리

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

클라이언트 확장 출력

인증기 확장 출력의 요소를 인코딩하는 숫자 3개짜리 배열들로 구성된 JSON 배열을 반환한다.

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

partial dictionary AuthenticationExtensionsClientOutputs {
  UvmEntries uvm;
};

인증기 확장 입력

CBOR(주 유형 7, 값 21)로 인코딩된 불리언 값 true.

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

인증기 확장 처리

인증기는 아래에 정의된 대로 사용자가 작업을 승인하는 데 사용한 방법을 나타내는 하나 이상의 사용자 검증 방법으로 인증기 확장 출력을 설정한다. 이 확장은 증명 객체와 어서션에 추가할 수 있다.

인증기 확장 출력

인증기는 아래에 정의된 CBOR 구문을 사용하여 단일 인증 인스턴스에 사용된 서로 다른 사용자 검증 방법(요소)을 최대 3개까지 보고할 수 있다.

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

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

각 uvmEntry 필드의 의미론은 다음과 같다.

userVerificationMethod: 인증기가 사용자를 검증하는 데 사용한 인증 방법/요소. 사용 가능한 값은 [FIDO-Registry]의 제3.1절 사용자 검증 방법에 정의되어 있다.
keyProtectionType: 인증기가 FIDO 등록 개인 키 자료를 보호하는 데 사용하는 방법. 사용 가능한 값은 [FIDO-Registry]의 제3.2절 키 보호 유형에 정의되어 있다.
matcherProtectionType: 인증기가 사용자 검증을 수행하는 매처를 보호하는 데 사용하는 방법. 사용 가능한 값은 [FIDO-Registry]의 제3.3절 매처 보호 유형에 정의되어 있다.

인증 인스턴스에서 3개보다 많은 요소를 사용할 수 있는 경우 인증기 공급업체는 서버와 가장 관련성이 높다고 판단한 요소 3개를 UVM에 포함하도록 반드시 선택해야 한다.

2개의 요소를 사용한 다중 요소 인증 인스턴스에 대한 하나의 UVM 확장을 포함하는 인증기 데이터의 예:

...                    -- RP ID hash (32 bytes)
81                     -- UP and ED set
00 00 00 01            -- (initial) signature counter
...                    -- all public key alg etc.
A1                     -- extension: CBOR map of one element
    63                 -- Key 1: CBOR text string of 3 bytes
        75 76 6d       -- "uvm" [=UTF-8 encoded=] string
    82                 -- Value 1: CBOR array of length 2 indicating two factor usage
        83              -- Item 1: CBOR array of length 3
            02           -- Subitem 1: CBOR integer for User Verification Method Fingerprint
            04           -- Subitem 2: CBOR short for Key Protection Type TEE
            02           -- Subitem 3: CBOR short for Matcher Protection Type TEE
        83              -- Item 2: CBOR array of length 3
            04           -- Subitem 1: CBOR integer for User Verification Method Passcode
            01           -- Subitem 2: CBOR short for Key Protection Type Software
            01           -- Subitem 3: CBOR short for Matcher Protection Type Software

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

이 클라이언트 등록 확장은 등록 세레모니의 결과로 공개 키 자격 증명 소스가 생성될 때 클라이언트가 알고 있는 특정 자격 증명 속성을 요청한 WebAuthn 신뢰 당사자에게 보고할 수 있게 한다.

현재 하나의 자격 증명 속성이 정의되어 있다. 바로 상주 키 자격 증명 속성, 즉 클라이언트 측 검색 가능 자격 증명 속성이다.

확장 식별자

credProps

작업 적용 가능성

등록

클라이언트 확장 입력

신뢰 당사자가 이 확장을 요청했음을 나타내는 불리언 값 true.

partial dictionary AuthenticationExtensionsClientInputs {
    boolean credProps;
};

클라이언트 확장 처리

출력으로 자격 증명 속성을 보고하는 것 외에는 없음.

클라이언트 확장 출력

설정 작업으로 clientExtensionResults["credProps"]["rk"]를 authenticatorMakeCredential 작업의 호출에 사용된 requireResidentKey 매개변수의 값으로 설정한다.

dictionary CredentialPropertiesOutput {
    boolean rk;
};

partial dictionary AuthenticationExtensionsClientOutputs {
    CredentialPropertiesOutput credProps;
};

rk, 형식은 boolean

추상적으로 상주 키 자격 증명 속성, 즉 클라이언트 측 검색 가능 자격 증명 속성이라고 하는 이 선택적 속성은 등록 세레모니의 결과로 반환된 PublicKeyCredential이 클라이언트 측 검색 가능 자격 증명인지 나타내는 불리언 값이다. rk가 true이면 자격 증명은 검색 가능 자격 증명이다. rk가 false이면 자격 증명은 서버 측 자격 증명이다. rk가 존재하지 않으면 자격 증명이 검색 가능 자격 증명인지 서버 측 자격 증명인지 알 수 없다.

참고: 일부 인증기는 클라이언트 플랫폼이 요청하지 않아도 검색 가능 자격 증명을 생성한다. 이 때문에 클라이언트 플랫폼은 값을 false로 설정할 수 있다는 보장이 부족하여 rk 속성을 생략해야 할 수 있다. 신뢰 당사자는 credProps 확장이 지원되는 경우 클라이언트 플랫폼이 rk 속성을 채우려고 노력할 것이라고 가정하는 것이 좋다. 따라서 rk가 없으면 생성된 자격 증명이 검색 불가능한 자격 증명일 가능성이 가장 높다는 뜻이다.

인증기 확장 입력

없음.

인증기 확장 처리

없음.

인증기 확장 출력

없음.

10.5. 대형 블롭 저장소 확장(largeBlob)

이 클라이언트 등록 확장 및 인증 확장을 사용하면 신뢰 당사자가 자격 증명과 연결된 불투명 데이터를 저장할 수 있다. 인증기는 소량의 데이터만 저장할 수 있고 대부분의 신뢰 당사자는 사용자를 위한 임의 분량의 상태를 저장할 수 있는 온라인 서비스이므로, 이는 특정 사례에서만 유용하다. 예를 들어 신뢰 당사자는 중앙 집중식 인증 서비스를 운영하는 대신 인증서를 발급하려 할 수 있다.

참고: 신뢰 당사자는 불투명 데이터를 공간이 제한된 기기에 기록할 때 압축한다고 가정할 수 있으므로 직접 압축할 필요가 없다.

인증서 시스템은 자격 증명의 공개 키에 서명해야 하고 해당 공개 키는 생성 후에만 사용할 수 있으므로, 이 확장은 등록 맥락에서 블롭을 기록하는 기능을 추가하지 않는다. 그러나 신뢰 당사자가 나중에 인증 확장을 사용하려는 경우 자격 증명을 생성할 때 등록 확장을 사용하는 것이 좋다.

인증서는 일반적인 인증기의 저장 용량에 비해 크므로 사용자 에이전트는 이 제한된 리소스를 할당하도록 사용자를 가장 적절하게 안내하고 악용을 방지하기 위해 어떤 표시와 확인이 적합한지 고려하는 것이 좋다.

참고: 상호운용을 위해 [FIDO-CTAP]을 사용하여 인증기에 대형 블롭을 저장하는 사용자 에이전트는 해당 명세에 자세히 설명된 자격 증명별 대형 블롭 저장 규정을 사용하는 것으로 예상된다.

확장 식별자

largeBlob

작업 적용 가능성

등록 및 인증

클라이언트 확장 입력

partial dictionary AuthenticationExtensionsClientInputs {
    AuthenticationExtensionsLargeBlobInputs largeBlob;
};

enum LargeBlobSupport {
  "required",
  "preferred",
};

dictionary AuthenticationExtensionsLargeBlobInputs {
    DOMString support;
    boolean read;
    BufferSource write;
};

support, 형식은 DOMString: LargeBlobSupport 값 중 하나를 받는 DOMString. (§ 2.1.1 DOMString 형식으로서의 열거형 참조.) 등록 중에만 유효하다.
read, 형식은 boolean: 신뢰 당사자가 어서션된 자격 증명과 연결되어 이전에 기록된 블롭을 가져오려 함을 나타내는 불리언. 인증 중에만 유효하다.
write, 형식은 BufferSource: 신뢰 당사자가 기존 자격 증명과 함께 저장하려는 불투명 바이트 문자열. 인증 중에만 유효하다.

클라이언트 확장 처리(등록)

read 또는 write가 존재하는 경우:
1. 이름이 “NotSupportedError”인 DOMException을 반환한다.
support가 존재하고 그 값이 required인 경우:
1. supported를 true로 설정한다.
  
  참고: 이는 대형 블롭을 저장할 수 있는 인증기를 사용할 수 있게 될 것을 예상한 것이다. [[Create]]() 11단계의 확장 처리 중에 발생한다. 적합한 인증기를 사용할 수 없게 되면 AuthenticationExtensionsLargeBlobOutputs는 폐기된다.
2. 후보 인증기를 사용할 수 있게 되면([[Create]]() 19단계), 어떤 options도 평가하기 전에 후보 인증기가 대형 블롭을 저장할 수 없는 경우 계속한다. 즉, 해당 후보 인증기를 무시한다.
그렇지 않은 경우, 즉 support가 없거나 값이 preferred인 경우:
1. 인증기가 선택되었고 선택된 인증기가 대형 블롭을 지원하면 supported를 true로 설정하고, 그렇지 않으면 false로 설정한다.

클라이언트 확장 처리(인증)

support가 존재하는 경우:
1. 이름이 “NotSupportedError”인 DOMException을 반환한다.
read와 write가 모두 존재하는 경우:
1. 이름이 “NotSupportedError”인 DOMException을 반환한다.
read가 존재하고 그 값이 true인 경우:
1. 클라이언트 확장 출력 largeBlob을 초기화한다.
2. 인증기가 성공을 나타내는 경우([[DiscoverFromExternalSource]]()에서) 어서션된 자격 증명과 연결된 largeBlob 데이터가 있으면 읽으려고 시도한다.
3. 성공하면 blob을 그 결과로 설정한다.
  
  참고: 읽기에 성공하지 못한 경우 largeBlob은 AuthenticationExtensionsClientOutputs에 존재하지만 blob 멤버는 존재하지 않는다.
write가 존재하는 경우:
1. allowCredentials가 정확히 하나의 요소를 포함하지 않는 경우:
  1. 이름이 “NotSupportedError”인 DOMException을 반환한다.
2. 어서션 작업이 성공하면 표시된 자격 증명과 연결하여 write의 내용을 인증기에 저장하려고 시도한다.
3. 성공하면 written을 true로, 그렇지 않으면 false로 설정한다.

클라이언트 확장 출력

partial dictionary AuthenticationExtensionsClientOutputs {
    AuthenticationExtensionsLargeBlobOutputs largeBlob;
};

dictionary AuthenticationExtensionsLargeBlobOutputs {
    boolean supported;
    ArrayBuffer blob;
    boolean written;
};

supported, 형식은 boolean: 생성된 자격 증명이 대형 블롭 저장을 지원하는 경우에만 true이다. 등록 출력에만 존재한다.
blob, 형식은 ArrayBuffer: rawId로 식별된 자격 증명과 연결되었던 불투명 바이트 문자열. read가 true였던 경우에만 유효하다.
written, 형식은 boolean: write의 내용이 지정된 자격 증명과 연결되어 인증기에 성공적으로 저장되었음을 나타내는 불리언.

인증기 확장 처리

이 확장은 사용자 에이전트가 대형 블롭을 인증기에 저장하거나 인증기에서 검색하도록 지시한다. 따라서 신뢰 당사자를 위한 인증기와의 직접적인 상호작용을 지정하지 않는다.

11. 사용자 에이전트 자동화

사용자 에이전트 자동화 및 웹 애플리케이션 테스트를 위해, 이 문서는 여러 [WebDriver] 확장 명령을 정의한다.

11.1. WebAuthn WebDriver 확장 기능

아래에 정의된 확장 명령의 사용 가능 여부를 알리기 위해 새로운 확장 기능을 정의한다.

기능	키	값 유형	설명
가상 인증기 지원	`"webauthn:virtualAuthenticators"`	불리언	엔드포인트 노드가 모든 가상 인증기 명령을 지원하는지를 나타낸다.

기능을 검증할 때, value를 사용하여 "webauthn:virtualAuthenticators"를 검증하는 확장별 하위 단계는 다음과 같다.

value가 불리언이 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
그렇지 않으면 deserialized를 value로 설정한다.

기능을 일치시킬 때, value를 사용하여 "webauthn:virtualAuthenticators"를 일치시키는 확장별 단계는 다음과 같다.

value가 true이고 엔드포인트 노드가 가상 인증기 명령을 하나도 지원하지 않으면, 일치에 실패한다.
그렇지 않으면 일치에 성공한다.

11.1.1. 인증기 확장 기능

또한 이 명세에 정의된 모든 인증기 확장(즉, 인증기 확장 처리를 정의하는 확장)에 대해 확장 기능을 정의한다.

기능	키	값 유형	설명
사용자 검증 방법 확장 지원	`"webauthn:extension:uvm"`	불리언	엔드포인트 노드의 WebAuthn WebDriver 구현이 사용자 검증 방법 확장을 지원하는지를 나타낸다.
대형 블롭 저장소 확장 지원	`"webauthn:extension:largeBlob"`	불리언	엔드포인트 노드의 WebAuthn WebDriver 구현이 largeBlob 확장을 지원하는지를 나타낸다.

기능을 검증할 때, value를 사용하여 인증기 확장 기능 key를 검증하는 확장별 하위 단계는 다음과 같다.

value가 불리언이 아니면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
그렇지 않으면 deserialized를 value로 설정한다.

기능을 일치시킬 때, value를 사용하여 인증기 확장 기능 key를 일치시키는 확장별 단계는 다음과 같다.

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 배열에 없는 인증기 확장은 절대로 지원해서는 안 된다.

uvm

사용자 검증 방법 확장을 처리할 때 인증기 확장 출력으로 설정할 UvmEntries 배열이다.

참고: 가상 인증기가 사용자 검증 방법 확장을 지원하지 않으면 이 속성은 아무런 효과가 없다.

11.3. 가상 인증기 추가

가상 인증기 추가 WebDriver 확장 명령은 소프트웨어 가상 인증기를 생성한다. 다음과 같이 정의된다.

HTTP 메서드	URI 템플릿
POST	`/session/{session id}/webauthn/authenticator`

인증기 구성은 parameters로 원격 종단 단계에 전달되는 JSON 객체이다. 다음과 같은 key 및 value 쌍이 포함된다.

키	값 유형	유효한 값	기본값
`protocol`	문자열	`"ctap1/u2f"`, `"ctap2"`, `"ctap2_1"`	없음
`transport`	문자열	`AuthenticatorTransport` 값	없음
`hasResidentKey`	불리언	`true`, `false`	`false`
`hasUserVerification`	불리언	`true`, `false`	`false`
`isUserConsenting`	불리언	`true`, `false`	`true`
`isUserVerified`	불리언	`true`, `false`	`false`
`extensions`	문자열 배열	확장 식별자가 포함된 배열	빈 배열
`uvm`	`UvmEntries`	최대 3개의 사용자 검증 방법 항목	빈 배열

원격 종단 단계는 다음과 같다.

parameters가 JSON 객체가 아니면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.

참고: parameters는 인증기 구성 객체이다.
authenticator를 새로운 가상 인증기로 설정한다.
parameters의 열거 가능한 각 자체 속성에 대해 다음을 수행한다.
1. key를 해당 속성의 이름으로 설정한다.
2. value를 parameters에서 key라는 이름의 속성을 가져온 결과로 설정한다.
3. parameters에서 key와 일치하는 key가 없으면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
4. value가 해당 key에 대한 valid values 중 하나가 아니면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
5. 속성을 설정하여 key를 value로 authenticator에 지정한다.
기본값이 정의된 인증기 구성의 각 속성에 대해 다음을 수행한다.
1. key가 authenticator에 정의된 속성이 아니면, 속성을 설정하여 key를 default로 authenticator에 지정한다.
인증기 구성의 각 속성에 대해 다음을 수행한다.
1. key가 authenticator에 정의된 속성이 아니면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
authenticator.extensions의 각 extension에 대해 다음을 수행한다.
1. extension이 확장 식별자가 아니거나 엔드포인트 노드의 WebAuthn WebDriver 구현에서 지원되지 않으면, WebDriver 오류를 WebDriver 오류 코드 지원되지 않는 작업과 함께 반환한다.
유효하고 고유한 authenticatorId를 생성한다.
속성을 설정하여 authenticatorId를 authenticatorId로 authenticator에 지정한다.
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`	자격 증명 ID를 base64url 인코딩을 사용하여 인코딩한 값.	문자열
`isResidentCredential`	`true`로 설정되면 클라이언트 측 검색 가능 자격 증명이 생성된다. `false`로 설정되면 대신 서버 측 자격 증명이 생성된다.	불리언
`rpId`	자격 증명의 범위가 지정된 신뢰 당사자 ID.	문자열
`privateKey`	[RFC5958]에 따른 단일 개인 키를 포함하며 base64url 인코딩을 사용하여 인코딩된 비대칭 키 패키지.	문자열
`userHandle`	자격 증명과 연결된 userHandle을 base64url 인코딩을 사용하여 인코딩한 값. 이 속성은 정의되지 않을 수 있다.	문자열
`signCount`	서명 카운터의 초기값이며, 이 카운터는 공개 키 자격 증명 소스와 연결된다.	숫자
`largeBlob`	자격 증명별 대형 블롭으로, 공개 키 자격 증명 소스와 연결되고 base64url 인코딩을 사용하여 인코딩된다. 이 속성은 정의되지 않을 수 있다.	문자열

원격 종단 단계는 다음과 같다.

parameters가 JSON 객체가 아니면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.

참고: parameters는 자격 증명 매개변수 객체이다.
credentialId를 base64url 인코딩으로 디코딩한 parameters의 credentialId 속성 결과로 설정한다.
credentialId가 실패이면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
isResidentCredential을 parameters의 isResidentCredential 속성으로 설정한다.
isResidentCredential이 정의되지 않았으면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
rpId를 parameters의 rpId 속성으로 설정한다.
rpId가 유효한 RP ID가 아니면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
privateKey를 base64url 인코딩으로 디코딩한 parameters의 privateKey 속성 결과로 설정한다.
privateKey가 실패이면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
privateKey가 P-256 곡선의 단일 ECDSA 개인 키를 포함하도록 유효하게 인코딩된 비대칭 키 패키지가 아니며, 이 패키지가 [RFC5958]을 따르지 않으면 WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
parameters의 userHandle 속성이 정의되어 있으면 다음을 수행한다.
1. userHandle을 base64url 인코딩으로 디코딩한 parameters의 userHandle 속성 결과로 설정한다.
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을 base64url 인코딩으로 디코딩한 parameters의 largeBlob 속성 결과로 설정한다.
2. largeBlob이 실패이면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
그렇지 않으면 다음을 수행한다.
1. largeBlob을 null로 설정한다.
credential을 새로운 클라이언트 측 검색 가능 공개 키 자격 증명 소스로 설정하는 것은 isResidentCredential이 true인 경우이며, 그렇지 않으면 다음 항목을 갖는 서버 측 공개 키 자격 증명 소스로 설정한다.

type

public-key

id

credentialId

privateKey

privateKey

rpId

rpId

userHandle

userHandle
서명 카운터 counter를 credential에 연결하고, 시작 값을 parameters의 signCount와 같게 설정한다. signCount가 null이면 0으로 설정한다.
largeBlob이 null이 아니면 자격 증명별 대형 블롭 중 credential과 연결된 것을 largeBlob으로 설정한다.
credential과 counter를 authenticator의 데이터베이스에 저장한다.
성공을 반환한다.

11.6. 자격 증명 가져오기

자격 증명 가져오기 WebDriver 확장 명령은 자격 증명 매개변수 객체를 공개 키 자격 증명 소스마다 하나씩 반환한다. 이러한 소스는 가상 인증기에 저장된 것이며, 자격 증명 추가 또는 navigator.credentials.create()를 사용하여 저장되었는지와 관계없다. 다음과 같이 정의된다.

HTTP 메서드	URI 템플릿
GET	`/session/{session id}/webauthn/authenticator/{authenticatorId}/credentials`

원격 종단 단계는 다음과 같다.

authenticatorId가 가상 인증기 중 가상 인증기 데이터베이스에 저장된 어느 것과도 일치하지 않으면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
credentialsArray를 빈 배열로 설정한다.
공개 키 자격 증명 소스 credential 각각에 대해, 해당 소스가 authenticatorId로 식별되는 인증기에 의해 관리되면 이에 대응하는 자격 증명 매개변수 객체를 구성하여 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 객체가 아니면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
authenticatorId가 가상 인증기 중 가상 인증기 데이터베이스에 저장된 어느 것과도 일치하지 않으면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
isUserVerified가 parameters에 정의된 속성이 아니면, WebDriver 오류를 WebDriver 오류 코드 잘못된 인수와 함께 반환한다.
authenticator를 가상 인증기 중 authenticatorId로 식별되는 것으로 설정한다.
authenticator의 isUserVerified 속성을 parameters의 isUserVerified 속성으로 설정한다.
성공을 반환한다.

12. IANA 고려 사항

12.1. WebAuthn 증명 구문 형식 식별자 등록 업데이트

이 절에서는 [RFC8809]에 의해 설정되고 원래 [WebAuthn-1]에서 등록된 IANA “WebAuthn 증명 구문 형식 식별자” 레지스트리 [IANA-WebAuthn-Registries]의 § 8 정의된 증명 구문 형식에 정의된 아래 증명 구문 형식을 이 명세를 가리키도록 업데이트한다.

WebAuthn 증명 구문 형식 식별자: packed
설명: “packed” 증명 구문 형식은 증명을 위해 WebAuthn에 최적화된 형식이다. 매우 간결하면서도 확장 가능한 인코딩 방식을 사용한다. 이 형식은 리소스가 제한된 인증기(예: 보안 요소)에서도 구현할 수 있다.
명세 문서: 이 명세의 § 8.2 Packed 증명 구문 형식
WebAuthn 증명 구문 형식 식별자: tpm
설명: TPM 증명 구문 형식은 원시 데이터와 서명 필드가 다르게 계산되지만 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 증명 구문 형식 식별자 등록

이 절에서는 [RFC8809]에 의해 설정된 IANA “WebAuthn 증명 구문 형식 식별자” 레지스트리 [IANA-WebAuthn-Registries]에 § 8 정의된 증명 구문 형식에서 새로 정의된 아래 증명 구문 형식을 등록한다.

WebAuthn 증명 구문 형식 식별자: apple
설명: Apple 기기의 플랫폼 인증기와 함께 사용된다.
명세 문서: 이 명세의 § 8.8 Apple 익명 증명 구문 형식
WebAuthn 증명 구문 형식 식별자: none
설명: WebAuthn 신뢰 당사자가 증명 정보를 수신하지 않겠다고 지정할 때 인증기가 제공한 증명 구문을 대체하는 데 사용된다.
명세 문서: 이 명세의 § 8.7 증명 없음 구문 형식

12.3. WebAuthn 확장 식별자 등록 업데이트

이 절에서는 [RFC8809]에 의해 설정되고 원래 [WebAuthn-1]에서 등록된 IANA “WebAuthn 확장 식별자” 레지스트리 [IANA-WebAuthn-Registries]의 확장 식별자 값 중 § 10 정의된 확장에 정의된 아래 값을 이 명세를 가리키도록 업데이트한다.

WebAuthn 확장 식별자: appid
설명: 이 인증 확장을 사용하면 기존 FIDO JavaScript API를 사용하여 이전에 자격 증명을 등록한 WebAuthn 신뢰 당사자가 어서션을 요청할 수 있다.
명세 문서: 이 명세의 § 10.1 FIDO AppID 확장 (appid)
WebAuthn 확장 식별자: uvm
설명: 이 등록 확장 및 인증 확장을 사용하면 사용자 검증 방법을 사용할 수 있다. 사용자 검증 방법 확장은 WebAuthn 작업에 사용된 사용자 검증 방법(요소)을 WebAuthn 신뢰 당사자에게 반환한다.
명세 문서: 이 명세의 § 10.3 사용자 검증 방법 확장(uvm)

12.4. WebAuthn 확장 식별자 등록

이 절에서는 [RFC8809]에 의해 설정된 IANA “WebAuthn 확장 식별자” 레지스트리 [IANA-WebAuthn-Registries]에 확장 식별자 값 중 § 10 정의된 확장에서 새로 정의된 아래 값을 등록한다.

WebAuthn 확장 식별자: appidExclude
설명: 이 등록 확장을 사용하면 WebAuthn 신뢰 당사자가 기존 FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI]로 생성된 지정된 자격 증명을 포함하는 인증기를 제외할 수 있다.
명세 문서: 이 명세의 § 10.2 FIDO AppID 제외 확장(appidExclude)
WebAuthn 확장 식별자: credProps
설명: 이 클라이언트 등록 확장을 사용하면 자격 증명 중 새로 생성된 자격 증명의 속성을 클라이언트가 판정하여 호출한 WebAuthn 신뢰 당사자의 웹 애플리케이션에 보고할 수 있다.
명세 문서: 이 명세의 § 10.4 자격 증명 속성 확장(credProps)
WebAuthn 확장 식별자: largeBlob
설명: 이 클라이언트 등록 확장 및 인증 확장을 사용하면 신뢰 당사자가 자격 증명과 연결된 불투명 데이터를 저장할 수 있다.
명세 문서: 이 명세의 § 10.5 대형 블롭 저장소 확장(largeBlob)

13. 보안 고려 사항

이 명세는 웹 API와 암호화 피어 엔터티 인증 프로토콜을 정의한다. Web Authentication API를 사용하면 웹 개발자(즉, “작성자”)가 자신의 등록 및 인증 세레모니에서 Web Authentication 프로토콜을 활용할 수 있다. Web Authentication 프로토콜의 엔드포인트를 구성하는 엔터티는 사용자가 제어하는 WebAuthn 인증기와 WebAuthn 신뢰 당사자의 컴퓨팅 환경이다. 이 환경은 신뢰 당사자의 웹 애플리케이션을 호스팅한다. 이 모델에서는 사용자 에이전트와 WebAuthn 클라이언트가 함께 인증기와 신뢰 당사자 사이의 중개자를 구성한다. 또한 인증기는 자신의 출처에 관해 증명하여 신뢰 당사자에게 제시할 수 있다.

현재 이 명세에는 상세한 보안 고려 사항이 포함되어 있지 않다. 그러나 [FIDOSecRef] 문서는 이 명세에 전반적으로 적용되는 보안 분석을 제공한다. 또한 [FIDOAuthnrSecReqs] 문서 모음은 인증기의 보안 특성에 관한 유용한 정보를 제공한다.

아래 하위 절은 현재 Web Authentication에 특화된 보안 고려 사항으로 구성된다. 대상 독자별로 구분되며, 일반적인 보안 고려 사항은 이 절의 직접적인 하위 절이고, 인증기, 클라이언트 및 신뢰 당사자 구현자에게 특별히 적용되는 보안 고려 사항은 각각의 하위 절로 묶인다.

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.4.5 폐기된 증명 인증서에 있는 신뢰 당사자 관련 보안 고려 사항도 참조하라.

13.4. 신뢰 당사자에 대한 보안 고려 사항

13.4.1. WebAuthn 신뢰 당사자에 대한 보안 이점

이 명세가 WebAuthn 신뢰 당사자에게 제공하는 주요 이점은 다음과 같다.

널리 호환되고 사용하기 쉬운 다중 요소 인증을 사용하여 사용자와 계정을 보호할 수 있다.
신뢰 당사자는 사용자에게 인증기 하드웨어를 제공할 필요가 없다. 대신 각 사용자는 규격을 준수하는 인증기를 독립적으로 구하여 동일한 인증기를 원하는 수의 신뢰 당사자와 함께 사용할 수 있다. 신뢰 당사자는 선택적으로 인증기가 반환한 증명 구문을 검사하여 인증기의 보안 속성에 관한 요구 사항을 적용할 수 있다.
인증 세레모니는 중간자 공격에 대한 내성이 있다. 등록 세레모니에 대해서는 아래의 § 13.4.4 증명의 한계를 참조하라.
신뢰 당사자는 코드를 거의 또는 전혀 변경하지 않고 여러 유형의 사용자 검증(예: PIN, 생체 인식 및 향후 방법)를 자동으로 지원할 수 있으며, 각 사용자가 선호하는 인증기를 선택하여 사용할 방법을 결정하도록 할 수 있다.
신뢰 당사자는 위의 이점을 얻기 위해 추가 비밀 정보를 저장할 필요가 없다.

적합성 절에 명시된 것처럼 신뢰 당사자는 위의 모든 보안 이점을 얻기 위해 반드시 § 7 WebAuthn 신뢰 당사자 작업에 설명된 대로 동작해야 한다. 그러나 여기서 약간 벗어나는 한 가지 주목할 만한 사용 사례는 아래의 § 13.4.4 증명의 한계에 설명되어 있다.

13.4.2. 임베디드 사용의 가시성 고려 사항

§ 5.10 iframe 요소 내에서 Web Authentication 사용에 설명된 것처럼 iframe과 같은 임베디드 컨텍스트에서 WebAuthn을 단순하게 사용하면 사용자가 “클릭재킹”이라고도 하는 UI 리드레싱 공격에 취약해질 수 있다. 이는 공격자가 신뢰 당사자가 의도한 UI 위에 자신의 UI를 겹쳐 놓고 사용자를 속여 신뢰 당사자를 통해 의도하지 않은 작업을 수행하도록 시도하는 공격이다. 예를 들어 공격자는 이러한 기법으로 사용자가 물품을 구매하거나 송금하도록 속일 수 있다.

WebAuthn 전용 UI는 일반적으로 클라이언트 플랫폼에서 처리되므로 UI 리드레싱에 취약하지 않지만, WebAuthn을 사용하는 콘텐츠를 임베드하는 신뢰 당사자는 해당 콘텐츠의 UI가 사용자에게 표시되도록 보장하는 것이 중요할 가능성이 크다. 이를 수행하는 새로운 방법은 실험적인 Intersection Observer v2의 isVisible 속성 상태를 관찰하는 것이다. 예를 들어 임베디드 컨텍스트에서 실행되는 신뢰 당사자의 스크립트는 isVisble이 false로 설정된 것을 감지하면 선제적으로 자신을 팝업 창에 로드하여 콘텐츠가 가려지는 상황을 피할 수 있다.

13.4.3. 암호학적 챌린지

Web Authentication은 암호화 프로토콜이므로 재전송 공격을 방지하기 위해 무작위 챌린지에 의존한다. 따라서 PublicKeyCredentialCreationOptions.challenge 및 PublicKeyCredentialRequestOptions.challenge 값은 반드시 신뢰 당사자가 신뢰하는 환경(예: 서버 측)에서 무작위로 생성해야 하며, 클라이언트의 응답으로 반환된 challenge 값은 반드시 생성된 값과 일치해야 한다. 이는 클라이언트의 동작에 의존하지 않는 방식으로 수행하는 것이 좋다. 예를 들어 신뢰 당사자는 작업이 완료될 때까지 챌린지를 임시로 저장하는 것이 좋다. 불일치를 허용하면 프로토콜의 보안이 손상된다.

재전송 공격을 방지하려면 챌린지에 추측이 불가능할 정도로 충분한 엔트로피가 반드시 포함되어야 한다. 따라서 챌린지의 길이는 16바이트 이상으로 하는 것이 좋다.

13.4.4. 증명의 한계

이 절은 규범적이지 않다.

새 자격 증명을 등록할 때 증명 구문이 존재한다면, WebAuthn 신뢰 당사자는 이를 통해 여러 인증기 특성에 관한 보증을 도출할 수 있다. 예를 들어 인증기 모델이나 자격 증명 개인 키를 저장하고 보호하는 방식에 관한 보증이다. 그러나 증명 구문만으로는 신뢰 당사자가 증명 객체를 사용자가 의도한 인증기가 생성했으며 중간자 공격자가 생성한 것이 아님을 검증할 수 없다는 점에 유의해야 한다. 예를 들어 이러한 공격자는 신뢰 당사자 스크립트에 주입한 악성 코드를 사용할 수 있다. 따라서 신뢰 당사자는 TLS 및 관련 기술과 같은 다른 수단에 의존하여 증명 객체를 중간자 공격으로부터 보호해야 한다.

등록 세레모니가 안전하게 완료되고 인증기가 자격 증명 개인 키의 기밀성을 유지한다는 가정하에, 해당 공개 키 자격 증명을 사용하는 이후의 인증 세레모니는 중간자 공격에 대한 내성이 있다.

위의 설명은 모든 증명 유형에 적용된다. 모든 경우에 중간자 공격자는 증명 구문과 등록할 자격 증명 공개 키를 포함한 PublicKeyCredential 객체를 대체할 수 있으며, 이후 같은 신뢰 당사자의 범위가 지정되고 같은 공격자를 통과하는 향후 인증 어서션을 변조할 수 있다.

이러한 공격은 탐지할 가능성이 있다. 신뢰 당사자가 사용자의 자격 증명 공개 키 대신 공격자의 것을 등록했으므로, 공격자는 해당 신뢰 당사자와 이루어지는 이후의 모든 인증 세레모니를 변조해야 한다. 변조되지 않은 세레모니는 실패하므로 공격이 드러날 수 있다.

자체 증명 및 증명 없음 이외의 증명 유형은 이러한 공격의 난이도를 높일 수 있다. 신뢰 당사자가 모델 명칭과 같은 인증기 정보를 사용자에게 표시할 수 있기 때문이다. 따라서 공격자는 사용자의 인증기와 같은 모델의 실제 인증기를 사용해야 할 수도 있으며, 또는 사용자가 신뢰 당사자에서 보고한 인증기 모델이 예상과 다르다는 점을 알아챌 수 있다.

참고: 위에 설명된 모든 중간자 공격 변형은 기존 암호 인증에 대한 중간자 공격보다 공격자가 수행하기 더 어렵다.

13.4.5. 폐기된 증명 인증서

중간 증명 CA 인증서의 폐기로 인해 증명 인증서 검증이 실패하고 신뢰 당사자 정책이 이러한 상황에서 등록/인증 요청을 거부하도록 요구한다면, 신뢰 당사자는 CA 침해 날짜 이후 동일한 중간 CA까지 이어지는 증명 인증서를 사용하여 등록된 공개 키 자격 증명도 등록 해제하거나 “자체 증명”과 동등한 신뢰 수준으로 표시하는 것이 권장된다. 따라서 신뢰 당사자가 등록 중에 중간 증명 CA 인증서를 기억하여, 해당 인증서가 폐기된 후 등록이 수행된 경우 관련 공개 키 자격 증명의 등록을 해제하는 것이 권장된다.

§ 13.3.2 증명 인증서 및 증명 인증서 CA 침해에 있는 인증기 관련 보안 고려 사항도 참조하라.

13.4.6. 자격 증명 손실 및 키 이동성

이 명세는 자격 증명 개인 키를 백업하거나 인증기 간에 공유하기 위한 프로토콜을 정의하지 않는다. 일반적으로 자격 증명 개인 키는 이를 생성한 인증기를 절대로 벗어나지 않을 것으로 예상된다. 따라서 일반적으로 인증기를 분실하면 분실한 인증기에 바인딩된 모든 자격 증명을 잃게 된다. 사용자가 신뢰 당사자에 등록한 자격 증명이 하나뿐이라면 계정에 접근하지 못하게 될 수 있다. Web Authentication API에서는 개인 키를 백업하거나 공유하는 대신 동일한 사용자에 대해 여러 자격 증명을 등록할 수 있다. 예를 들어 사용자는 자주 사용하는 클라이언트 기기에 플랫폼 자격 증명을 등록하고, 백업용이거나 새롭거나 거의 사용하지 않는 클라이언트 기기에서 사용할 하나 이상의 로밍 자격 증명을 등록할 수 있다.

신뢰 당사자는 사용자가 동일한 계정에 여러 자격 증명을 등록하도록 허용하고 장려하는 것이 좋다. 신뢰 당사자는 이러한 서로 다른 자격 증명이 서로 다른 바인딩된 인증기에 연결되도록 excludeCredentials 및 user.id 옵션을 사용하는 것이 좋다.

13.4.7. 보호되지 않은 계정 탐지

이 절은 규범적이지 않다.

이 보안 고려 사항은 비어 있지 않은 인증 세레모니를 첫 번째 인증 단계로 지원하는 신뢰 당사자에 적용된다. 여기서 allowCredentials 인수는 빈 상태가 아니다. 예를 들어 서버 측 자격 증명을 사용하는 인증을 첫 번째 인증 단계로 이용하는 경우이다.

이 경우 allowCredentials 인수는 어떤 사용자 계정에 WebAuthn 자격 증명이 등록되어 있고 어떤 계정에는 등록되어 있지 않은지에 관한 정보를 유출할 위험이 있으며, 이는 계정 보호 강도를 나타내는 신호가 될 수 있다. 예를 들어 공격자가 사용자 이름만 제공하여 인증 세레모니를 시작할 수 있고, 신뢰 당사자가 일부 사용자에게 비어 있지 않은 allowCredentials로 응답하고 다른 사용자에게는 실패 또는 암호 챌린지로 응답한다고 가정하자. 그러면 공격자는 후자의 사용자 계정이 성공적인 인증을 위해 WebAuthn 어서션을 요구하지 않을 가능성이 크다고 결론 내리고, 보안이 더 취약할 가능성이 있는 해당 계정에 공격을 집중할 수 있다.

이 문제는 § 14.6.2 사용자 이름 열거 및 § 14.6.3 자격 증명 ID를 통한 개인 정보 유출에 설명된 문제와 유사하며, 비슷한 방식으로 완화할 수 있다.

14. 개인 정보 보호 고려 사항

[FIDO-Privacy-Principles]의 개인 정보 보호 원칙도 이 명세에 적용된다.

이 절은 대상 독자별로 구분된다. 일반적인 개인 정보 보호 고려 사항은 이 절의 직접적인 하위 절이고, 인증기, 클라이언트 및 신뢰 당사자 구현자에게 특별히 적용되는 개인 정보 보호 고려 사항은 각각의 하위 절로 묶인다.

14.1. 익명성 해제 방지 조치

이 절은 규범적이지 않다.

Web Authentication API 설계의 여러 측면은 개인 정보 보호 우려에서 비롯되었다. 이 명세에서 고려하는 주요 우려는 사용자의 개인 신원, 즉 인간의 식별이나 서로 다른 신원이 동일한 인간에게 속한다는 상관관계를 보호하는 것이다. Web Authentication 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)도 현재 TCG에서 증명 CA(ACA) [TCG-CMCProfile-AIKCertEnroll]라고 부르는 대상을 “Privacy CA”라는 용어로 지칭했기 때문에, 이 명세의 구체적인 맥락에서 혼동을 줄이고자 여기서는 익명화 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.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.4.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를 반환하여 개인 정보 유출을 완화할 수 있다.

15. 접근성 고려 사항

사용자 검증 기능이 있는 인증기는 로밍 인증기인지 플랫폼 인증기인지에 관계없이 사용자에게 둘 이상의 사용자 검증 방법을 제공하는 것이 좋다. 예를 들어 지문 감지와 PIN 입력을 모두 제공할 수 있다. 이를 통해 선택한 사용자 검증 방법이 어떤 이유로 작동하지 않을 때 다른 방법을 대신 사용할 수 있다. 로밍 인증기의 경우 인증기와 플랫폼이 함께 작동하여 PIN 입력과 같은 사용자 검증 방법을 제공할 수 있음에 유의하라. [FIDO-CTAP]

신뢰 당사자는 등록 시 사용자가 향후 승인 동작을 올바르게 완료할 수 있도록 지원 수단을 제공하는 것이 좋다. 여기에는 인증기에 이름을 지정하거나, 기기와 연결할 그림을 선택하거나, 자유 형식의 텍스트 지침을 입력하는 작업(예: 자신을 위한 알림)이 포함될 수 있다.

세레모니 중 등록 세레모니(timeout 참조) 또는 인증 세레모니(timeout 참조)처럼 시간에 의존하는 세레모니는 [WCAG21]의 지침 2.2 충분한 시간을 따르는 것이 바람직하다. 클라이언트 플랫폼이 신뢰 당사자가 제공한 시간 제한이 앞서 언급한 [WCAG21] 지침을 적절히 준수하지 않는다고 판단하면 클라이언트 플랫폼은 그에 맞게 시간 제한을 조정할 수 있다.

16. 감사의 말

이 명세를 검토하고 기여해 주신 다음 분들께 감사드린다. Yuriy Ackermann, James Barclay, Richard Barnes, Dominic Battré, Julien Cayzac, Domenic Denicola, Rahul Ghosh, Brad Hill, Jing Jin, Wally Jones, Ian Kilpatrick, Axel Nennker, Yoshikazu Nojima, Kimberly Paulhamus, Adam Powers, Yaron Sheffer, Ki-Eun Shin, Anne van Kesteren, Johan Verrept, 그리고 Boris Zbarsky.

전체 등록 및 인증 흐름도 (그림 1 및 그림 2)를 제작한 Adam Powers에게 감사드린다.

Web Authentication 워킹 그룹의 공동 의장으로 기여한 Anthony Nadalin, John Fontana, 그리고 Richard Barnes에게 감사드린다.

W3C 팀 담당자로서 기여한 Wendy Seltzer, Samuel Weiler, 그리고 Harry Halpin에게도 감사드린다.

초록

이 문서의 상태

1. 소개

1.1. 명세 로드맵

1.2. 사용 사례

1.2.1. 등록

1.2.2. 인증

1.2.3. 새 장치 등록

1.2.4. 기타 사용 사례 및 구성

1.3. API 사용 예시 시나리오

1.3.1. 등록

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

1.3.3. 인증

1.3.4. 인증 작업 중단

1.3.5. 사용 중단

1.4. 플랫폼별 구현 지침

2. 적합성

2.1. 사용자 에이전트

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

2.2. 인증기

2.2.1. FIDO U2F와의 하위 호환성

2.3. WebAuthn 신뢰 당사자

2.4. 모든 적합성 클래스

3. 의존성

4. 용어

5. 웹 인증 API

5.1. PublicKeyCredential 인터페이스

5.1.1. CredentialCreationOptions 사전 확장

5.1.2. CredentialRequestOptions 사전 확장

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

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

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

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

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

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

5.2. 인증기 응답(인터페이스 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. 인증기 연결 열거형(enum AuthenticatorAttachment)

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

5.4.7. 증명 전달 선호도 열거형(enum 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. 자격 증명 유형 열거형(enum PublicKeyCredentialType)

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

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

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

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

5.9. 권한 정책 통합

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

6. WebAuthn 인증기 모델

6.1. 인증기 데이터

6.1.1. 서명 카운터 고려 사항

6.1.2. FIDO U2F 서명 형식 호환성

6.2. 인증기 분류 체계

6.2.1. 인증기 연결 양식

6.2.2. 자격 증명 저장 양식

6.2.3. 인증 요소 기능

6.3. 인증기 작업

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

6.3.2. authenticatorMakeCredential 작업

6.3.3. authenticatorGetAssertion 작업

6.3.4. authenticatorCancel 작업

5.1. `PublicKeyCredential` 인터페이스

5.1.1. `CredentialCreationOptions` 사전 확장

5.1.2. `CredentialRequestOptions` 사전 확장

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

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

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

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

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

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

5.2. 인증기 응답(인터페이스 `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. 인증기 연결 열거형(enum `AuthenticatorAttachment`)

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

5.4.7. 증명 전달 선호도 열거형(enum `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. 자격 증명 유형 열거형(enum `PublicKeyCredentialType`)

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

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

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

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

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

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