Skip to content

Instantly share code, notes, and snippets.

@inabajunmr

inabajunmr/Web Authentication: An API for accessing Public Key Credentials Level 3 の 7 章の和訳.md

Last active May 8, 2022 04:32
Show Gist options
  • Save inabajunmr/86e478015a16e6eb6b2cb5417986f7a4 to your computer and use it in GitHub Desktop.
Save inabajunmr/86e478015a16e6eb6b2cb5417986f7a4 to your computer and use it in GitHub Desktop.
Download ZIP
Web Authentication: An API for accessing Public Key Credentials Level 3 の 7 章の和訳
Raw
Web Authentication: An API for accessing Public Key Credentials Level 3 の 7 章の和訳.md

Web Authentication: An API for accessing Public Key Credentials Level 3

Editor’s Draft, 6 April 2022

7. WebAuthn Relying Party Operations

A registration or authentication ceremony begins with the WebAuthn Relying Party creating a PublicKeyCredentialCreationOptions or PublicKeyCredentialRequestOptions object, respectively, which encodes the parameters for the ceremony. The Relying Party SHOULD take care to not leak sensitive information during this stage; see § 14.6.2 Username Enumeration for details.

登録や認証セレモニーは WebAuthn Relying Party が PublicKeyCredentialCreationOptions もしくは PublicKeyCredentialRequestOptions を作成し、それぞれセレモニーのためにパラメーターをエンコードする。Relying Party はこのステージでセンシティブな情報がリークしないよう気をつけるべきである。詳細は 14.6.2 Username Enumeration を参照すること。

Upon successful execution of create() or get(), the Relying Party's script receives a PublicKeyCredential containing an AuthenticatorAttestationResponse or AuthenticatorAssertionResponse structure, respectively, from the client. It must then deliver the contents of this structure to the Relying Party server, using methods outside the scope of this specification. This section describes the operations that the Relying Party must perform upon receipt of these structures.

create() や get() の実行に成功したら、[Relying Party]](https://w3c.github.io/webauthn/#relying-party) のスクリプトは AuthenticatorAttestationResponse や AuthenticatorAssertionResponse の構造体を含んだ PublicKeyCredential をクライアントから受け取る。この構造のコンテンツは Relying Party のサーバーに送られなければならないが、方法はこの仕様の範囲外である。この章では Relying Party がこれらの構造体を受け取った際に行う必要のあるオペレーションを説明する。

7.1. Registering a New Credential

In order to perform a registration ceremony, the Relying Party MUST proceed as follows:

登録セレモニーを行うため、Relying Party は以下のように処理を行わなければならない。

  1. Let options be a new PublicKeyCredentialCreationOptions structure configured to the Relying Party's needs for the ceremony.
  1. options に Relying Party がセレモニーに必要な設定をした新しい PublicKeyCredentialCreationOptions を代入する。
  1. Call navigator.credentials.create() and pass options as the publicKey option. Let credential be the result of the successfully resolved promise. If the promise is rejected, abort the ceremony with a user-visible error, or otherwise guide the user experience as might be determinable from the context available in the rejected promise. For example if the promise is rejected with an error code equivalent to "InvalidStateError", the user might be instructed to use a different authenticator. For information on different error contexts and the circumstances leading to them, see § 6.3.2 The authenticatorMakeCredential Operation.
  1. publicKey オプションとして options を渡し、navigator.credentials.create() を呼び出す。credential に成功した promise の結果を代入する。promise が拒否されたらユーザーから見えるエラーと共にセレモニーを終わるか、拒否された promise のコンテキストで利用可能なユーザー体験をガイドする。例えばエラーコード InvalidStateErr と共に promise が拒否されたら、ユーザーは異なる認証器を使うよう指示をするべきである。異なるエラーコンテキストとそれに至る状況については § 6.3.2 The authenticatorMakeCredential Operation を参照すること。
  1. Let response be credential.response. If response is not an instance of AuthenticatorAttestationResponse, abort the ceremony with a user-visible error.
  1. response に credential.response を代入する。もし response が AuthenticatorAttestationResponse のインスタンスではなかったら、ユーザーから見えるエラーと共にセレモニーを終わる。
  1. Let clientExtensionResults be the result of calling credential.getClientExtensionResults().
  1. clientExtensionResults に credential.getClientExtensionResults() の結果を代入する。
  1. Let JSONtext be the result of running UTF-8 decode on the value of response.clientDataJSON.
  1. JSONtext に response.clientDataJSON を UTF-8 でデコードした結果を代入する。

Note: Using any implementation of UTF-8 decode is acceptable as long as it yields the same result as that yielded by the UTF-8 decode algorithm. In particular, any leading byte order mark (BOM) MUST be stripped.

Note: どのような UTF-8 デコード の実装も、UTF-8 デコードアルゴリズムによる結果と同じ結果になるのであれば許容される。特に、あらゆるバイトオーダーマーク（BOM）は取り外す必要がある。

  1. Let C, the client data claimed as collected during the credential creation, be the result of running an implementation-specific JSON parser on JSONtext.
  1. C に クレデンシャル作成中に集められた client data を C に代入する。これは JSONtext を実装固有の JSON パーサーにかけた結果である。

Note: C may be any implementation-specific data structure representation, as long as C’s components are referenceable, as required by this algorithm.

Note: C はアルゴリズムにとって必要なように C の要素が参照可能であれば、どのような実装固有のデータ構造表現であってもよい。

  1. Verify that the value of C.type is webauthn.create.
  1. C.type の値が webauthnn.create であることを検証する。
  1. Verify that the value of C.challenge equals the base64url encoding of options.challenge.
  1. C.challenge が base64url エンコードされた options.challenge の値であることを検証する。
  1. Verify that the value of C.origin matches the Relying Party's origin.
  1. C.origin の値が Relying Party の origin とマッチすることを検証する。
  1. Verify that the value of C.tokenBinding.status matches the state of Token Binding for the TLS connection over which the assertion was obtained. If Token Binding was used on that TLS connection, also verify that C.tokenBinding.id matches the base64url encoding of the Token Binding ID for the connection.
  1. C.tokenBinding.status の値がアサーションを得た TLS 接続のトークンバインディングの状態（クライアントがトークンバインディングをサポートしているか、RP との接続時にトークンバインディングが使用されたか）にマッチするか検証する。もし TLS 接続においてトークンバインディングが使われていたら、C.tokenBinding.id が接続のためのトークンバインディング ID の base64url エンコーディングとマッチするか検証する。
  1. Let hash be the result of computing a hash over response.clientDataJSON using SHA-256.
  1. hash に response.clientDataJSON を SHA-256 でハッシュ化した結果を代入する。
  1. Perform CBOR decoding on the attestationObject field of the AuthenticatorAttestationResponse structure to obtain the attestation statement format fmt, the authenticator data authData, and the attestation statement attStmt.
  1. アテステーションステートメントのフォーマット fmt、認証器のデータ authData およびアテステーションステートメント attStmt を取得するために、AuthenticatorAttestationResponse 構造の attestationObject フィールドを CBOR でデコードする。
  1. Verify that the rpIdHash in authData is the SHA-256 hash of the RP ID expected by the Relying Party.
  1. authData の rpIdHash が Relying Party が想定している RP ID の SHA-256 ハッシュであることを検証する。
  1. Verify that the User Present bit of the flags in authData is set.
  1. authData の flags の User Present ビットが設定されていることを検証する。
  1. If user verification is required for this registration, verify that the User Verified bit of the flags in authData is set.
  1. この登録においてユーザー認証 が必要とされる場合、authData の flags の User Verified ビットが設定されていることを検証する。
  1. Verify that the "alg" parameter in the credential public key in authData matches the alg attribute of one of the items in options.pubKeyCredParams.
  1. authData の credential public key における "alg" パラメーターが、options.pubKeyCredParams に指定したいずれかの項目の alg 属性と一致するか検証する。
  1. Verify that the values of the client extension outputs in clientExtensionResults and the authenticator extension outputs in the extensions in authData are as expected, considering the client extension input values that were given in options.extensions and any specific policy of the Relying Party regarding unsolicited extensions, i.e., those that were not specified as part of options.extensions. In the general case, the meaning of "are as expected" is specific to the Relying Party and which extensions are in use.

options.extensions で与えられたクライアント拡張入力の値と Relying Party の未承諾拡張、つまり options.extensions で定義されていない固有のポリシーを考慮して、clientExtensionResults のクライアント拡張出力の値と authData の extenions における認証器拡張出力が期待通りであることを検証する。一般的な場合、"期待通りである"とは、Relying Party と Relying Party が利用している拡張に固有である。

Note: Client platforms MAY enact local policy that sets additional authenticator extensions or client extensions and thus cause values to appear in the authenticator extension outputs or client extension outputs that were not originally specified as part of options.extensions. Relying Parties MUST be prepared to handle such situations, whether it be to ignore the unsolicited extensions or reject the attestation. The Relying Party can make this decision based on local policy and the extensions in use.

Note: クライアントプラットフォームは追加の認証器拡張やクライアント拡張をセットし、options.extensions で本来定義されていない認証器拡張出力やクライアント拡張出力に値を出現させるローカルポリシーを実施してもよい。Relying Party はそのような状況をハンドリングする準備をするか、未承諾の拡張を無視するか、アテステーションを拒絶しなければならない。Relying Party はローカルポリシーと利用している拡張をもとにこの決定を行う必要がある。

Note: Since all extensions are OPTIONAL for both the client and the authenticator, the Relying Party MUST also be prepared to handle cases where none or not all of the requested extensions were acted upon.

Note: すべての拡張はクライアントと認証器両方において OPTIONAL であり、Relying Party はリクエストした拡張が全部、もしくは一部が対応していなかったケースをハンドリングする準備をしなければならない。

  1. Determine the attestation statement format by performing a USASCII case-sensitive match on fmt against the set of supported WebAuthn Attestation Statement Format Identifier values. An up-to-date list of registered WebAuthn Attestation Statement Format Identifier values is maintained in the IANA "WebAuthn Attestation Statement Format Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809].
  1. アテステーションステートメントのフォーマットは、サポートされる WebAuthn Attestation Statement Format Identifier と fmt を USASCII case-sensitive にマッチすることで決定する。登録済みの WebAuthn Attestation Statement Format Identifier の最新のリストは RFC8809 で発行された IANA "WebAuthn Attestation Statement Format Identifiers" レジストリ[IANA-WebAuthn-Registries]にて管理される。
  1. Verify that attStmt is a correct attestation statement, conveying a valid attestation signature, by using the attestation statement format fmt’s verification procedure given attStmt, authData and hash.
  1. アテステーションステートメントフォーマット fmt の検証手続き、与えられた attStmt、authData、hash を使って attStmt が正しいアテステーションの署名を伝達している正しいアテステーションステートメントであることを検証する。

Note: Each attestation statement format specifies its own verification procedure. See § 8 Defined Attestation Statement Formats for the initially-defined formats, and [IANA-WebAuthn-Registries] for the up-to-date list.

Note: 各アテステーションステートメントフォーマットは自身の検証手続きを指定する。最初から定義されているフォーマットのためのフォーマットは § 8 Defined Attestation Statement Formats を、最新のリストは [IANA-WebAuthn-Registries] を参照すること。

  1. If validation is successful, obtain a list of acceptable trust anchors (i.e. attestation root certificates) for that attestation type and attestation statement format fmt, from a trusted source or from policy. For example, the FIDO Metadata Service [FIDOMetadataService] provides one way to obtain such information, using the aaguid in the attestedCredentialData in authData.
  1. 検証が成功したら、信頼できるソースもしくはポリシーから、アテステーションタイプとアテステーションフォーマット fmt の許可されたトラストアンカー（つまりアテステーションルート証明書）のリストを得る。例えば FIDO メタデータサービス [FIDOMetadataService] は authData の attestedCredentialData の aaguid を使ってそのような情報を得る方法の 1 つを提供する。
  1. Assess the attestation trustworthiness using the outputs of the verification procedure in step 19, as follows:
  1. 以下のようにステップ 19 の 検証手続きの出力を使ってアテステーションの信頼性を評価する。

If no attestation was provided, verify that None attestation is acceptable under Relying Party policy.

If self attestation was used, verify that self attestation is acceptable under Relying Party policy.

Otherwise, use the X.509 certificates returned as the attestation trust path from the verification procedure to verify that the attestation public key either correctly chains up to an acceptable root certificate, or is itself an acceptable certificate (i.e., it and the root certificate obtained in Step 19 may be the same).

  • そうでない場合、アテステーション公開鍵が許可されているルート証明書に正しくチェーンされているか、それ自身が許可されている証明書であることを検証するため、検証手続きからアテステーションとラストパスとして返された X.509 証明書を利用する。（つまり、ステップ 19 で得たルート証明書が同じものである可能性がある）

  1. Verify that the credentialId is ≤ 1023 bytes. Credential IDs larger than this many bytes SHOULD cause the RP to fail this registration ceremony.

  2. credentialId <= 1023 バイトであることを検証する。これ以上大きい場合、RP はこの登録セレモニーを失敗とするべきである。

  1. Verify that the credentialId is not yet registered for any user. If the credentialId is already known then the Relying Party SHOULD fail this registration ceremony.
  1. credentialId がいずれかのユーザーによって登録済みでないことを検証する。もし credentialId が既知のものであれば、Relying Party はこの登録セレモニーを失敗とすべきである。

NOTE: The rationale for Relying Parties rejecting duplicate credential IDs is as follows: credential IDs contain sufficient entropy that accidental duplication is very unlikely. However, attestation types other than self attestation do not include a self-signature to explicitly prove possession of the credential private key at registration time. Thus an attacker who has managed to obtain a user’s credential ID and credential public key for a site (this could be potentially accomplished in various ways), could attempt to register a victim’s credential as their own at that site. If the Relying Party accepts this new registration and replaces the victim’s existing credential registration, and the credentials are discoverable, then the victim could be forced to sign into the attacker’s account at their next attempt. Data saved to the site by the victim in that state would then be available to the attacker.

Note: Relying Party が重複した Credential IDs を拒否する根拠は以下である。credential IDs は偶然の重複がまず発生しない十分なエントロピーをもっている。しかし、Self attestation 以外の attestation types は登録 時にクレデンシャル秘密鍵の保持を明示的に証明する自己署名を含まない。つまり、あるサイト用のユーザーの credential ID と クレデンシャル公開鍵 を得た（これはいくつかの方法で潜在的に実現可能）攻撃者が、被害者のクレデンシャルをあるサイトに自分にものとして登録を試みることができるということだ。もし [Relying Party] がこの新しい登録を受け入れ被害者の既存のクレデンシャル登録を交換し、クレデンシャルが [Discoverable] なものだと、被害者がつごの試行時に攻撃者のアカウントにサインインすることを強制される。その状態で被害者がサイトに登録したデータは、攻撃者が利用可能となる。

  1. If the attestation statement attStmt verified successfully and is found to be trustworthy, then register the new credential with the user account that was denoted in options.user:
  1. もしアテステーションステートメント attStmt の検証が成功し、それに信頼性があれば新しいクレデンシャルを options.user で指定されたユーザーアカウントと共に登録する。

Associate the user account with the credentialId and credentialPublicKey in authData.attestedCredentialData, as appropriate for the Relying Party's system.

Associate the credentialId with a new stored signature counter value initialized to the value of authData.signCount.

credentialId と、authData.signCount の値で初期化された新しく保存された署名カウンターの値を関連づける。

It is RECOMMENDED to also:

さらに以下も推奨される。

Associate the credentialId with the transport hints returned by calling credential.response.getTransports(). This value SHOULD NOT be modified before or after storing it. It is RECOMMENDED to use this value to populate the transports of the allowCredentials option in future get() calls to help the client know how to find a suitable authenticator.

credential.response.getTransports() の呼び出しにより返される transport hints と credentialId を関連づける。この値は保存の前後で変更すべきではない。その後の get() 呼び出しの allowCredentials の transports オプションにこの値を追加して、クライアントがどのように適当な認証器を見つけるか知るのに利用することを推奨する。

  1. If the attestation statement attStmt successfully verified but is not trustworthy per step 20 above, the Relying Party SHOULD fail the registration ceremony.

もしアテステーションステートメント attStmt の検証が成功し、ステップ 20 で信頼性がないとされた場合、Relying Party は登録セレモニーを失敗とすべきである。

NOTE: However, if permitted by policy, the Relying Party MAY register the credential ID and credential public key but treat the credential as one with self attestation (see § 6.5.3 Attestation Types). If doing so, the Relying Party is asserting there is no cryptographic proof that the public key credential has been generated by a particular authenticator model. See [FIDOSecRef] and [UAFProtocol] for a more detailed discussion.

NOTE: しかしポリシーで許容するのであれば、 Self アテステーションとして扱い（§ 6.5.3 Attestation Types を参照）Relying Party は credential ID とクレデンシャル公開鍵を登録する。その様にする場合、Relying Party は公開鍵クレデンシャルが特定のモデルの認証器によって生成されたという暗号学的な証明が無いとする。さらに詳細な議論は [FIDOSecRef] と [UAFProtocol] を参照すること。

Verification of attestation objects requires that the Relying Party has a trusted method of determining acceptable trust anchors in step 19 above. Also, if certificates are being used, the Relying Party MUST have access to certificate status information for the intermediate CA certificates. The Relying Party MUST also be able to build the attestation certificate chain if the client did not provide this chain in the attestation information.

アテステーションオブジェクトの検証は、Relying Party が上記ステップ 19 の受け入れ可能なトラストアンカーを決定する信頼された方法を持つことを必要とする。さらに、もし証明書が使われたら Relying Party は中間 CA 証明書の証明書ステータス情報にアクセスできる必要がある。さらに、Relying Party はもしクライアントがアテステーション情報にこのチェーンを提供しなかった場合、アテステーション証明書チェーンを構築できる必要がある。

7.2. Verifying an Authentication Assertion

In order to perform an authentication ceremony, the Relying Party MUST proceed as follows:

認証セレモニーを行うため、Relying Party は以下のように振る舞う必要がある。

  1. Let options be a new PublicKeyCredentialRequestOptions structure configured to the Relying Party's needs for the ceremony.
  1. options に Relying Party がセレモニーに必要な設定をした新しい PublicKeyCredentialRequestOptions を代入する。

If options.allowCredentials is present, the transports member of each item SHOULD be set to the value that was returned by credential.response.getTransports() when the corresponding credential was registered.

もし options.[allowCredentials] が存在したら、各項目の transports メンバーには対応するクレデンシャルが登録されたときに credential.response.getTransports() によって返された値をセットすべきである。

Note: Modifying or removing items from values returned from getTransports() could negatively impact user experience, or even prevent use of the corresponding credentials.

Note: getTransports() から帰った値から項目を変更したり削除したりするのは、ユーザー体験に悪影響を与えたり、対応するクレデンシャルの利用を妨げることがある。

  1. Call navigator.credentials.get() and pass options as the publicKey option. Let credential be the result of the successfully resolved promise. If the promise is rejected, abort the ceremony with a user-visible error, or otherwise guide the user experience as might be determinable from the context available in the rejected promise. For information on different error contexts and the circumstances leading to them, see § 6.3.3 The authenticatorGetAssertion Operation.
  1. publicKey オプションとして options を渡し、navigator.credentials.get() を呼び出す。credential に成功した promise の結果を代入する。promise が拒否されたらユーザーから見えるエラーと共にセレモニーを終わるか、拒否された promise のコンテキストで利用可能なユーザー体験をガイドする。異なるエラーコンテキストとそれに至る状況については § 6.3.3 The authenticatorGetAssertion Operation を参照すること。
  1. Let response be credential.response. If response is not an instance of AuthenticatorAssertionResponse, abort the ceremony with a user-visible error.
  1. response に credential.response を代入する。もし response が AuthenticatorAssertionResponse のインスタンスではなかったら、ユーザーから見えるエラーと共にセレモニーを終わる。
  1. Let clientExtensionResults be the result of calling credential.getClientExtensionResults().
  1. clientExtensionResults に credential.getClientExtensionResults() の結果を代入する。
  1. If options.allowCredentials is not empty, verify that credential.id identifies one of the public key credentials listed in options.allowCredentials.
  1. もし options.allowCredentials が空でなかったら、credential.id が options.allowCredentials に載っている公開鍵公開鍵クレデンシャルの一つを識別していることを検証する。
  1. Identify the user being authenticated and verify that this user is the owner of the public key credential source credentialSource identified by credential.id:
  1. 認証されたユーザーを識別し、そのユーザーが credential.id で識別された公開鍵クレデンシャルソース credentialSource のオーナーであることを検証する。

↪ If the user was identified before the authentication ceremony was initiated, e.g., via a username or cookie,

↪ もしユーザーが認証セレモニーの開始以前に、username やクッキー経由で識別されていたら、

verify that the identified user is the owner of credentialSource. If response.userHandle is present, let userHandle be its value. Verify that userHandle also maps to the same user.

識別されたユーザーが credentialSource のオーナーであることを検証する。もし response.userHandle が提示されたら、その値を userHandle に代入し、userHandle が同じユーザーに対応していることを検証する。

↪ If the user was not identified before the authentication ceremony was initiated,

↪ もしユーザーが認証セレモニーの開始以前に識別されていなかったら、

verify that response.userHandle is present, and that the user identified by this value is the owner of credentialSource.

もし response.userHandle が提示されたら、この値で識別されたユーザーが credentialSource のオーナーであることを検証する。

  1. Using credential.id (or credential.rawId, if base64url encoding is inappropriate for your use case), look up the corresponding credential public key and let credentialPublicKey be that credential public key.
  1. credential.id（もしくは base64url エンコーディングがあなたのユースケースに不適切な場合 credential.rawId）を利用して、対応するクレデンシャル公開鍵を探し、それを credentialPublicKey に代入する。
  1. Let cData, authData and sig denote the value of response’s clientDataJSON, authenticatorData, and signature respectively.

cData、authData、sig にレスポンスの clientDataJSON、authenticatorData、signature を代入する。

  1. Let JSONtext be the result of running UTF-8 decode on the value of cData.

JSONtext に cData の値を UTF-8 デコードした結果を代入する。

Note: Using any implementation of UTF-8 decode is acceptable as long as it yields the same result as that yielded by the UTF-8 decode algorithm. In particular, any leading byte order mark (BOM) MUST be stripped.

Note: どのような UTF-8 デコード の実装も、UTF-8 デコードアルゴリズムによる結果と同じ結果になるのであれば許容される。特に、あらゆるバイトオーダーマーク（BOM）は取り外す必要がある。

  1. Let C, the client data claimed as used for the signature, be the result of running an implementation-specific JSON parser on JSONtext.
  1. C に クレデンシャル作成中に集められた client data を C に代入する。これは JSONtext を実装固有の JSON パーサーにかけた結果である。

Note: C may be any implementation-specific data structure representation, as long as C’s components are referenceable, as required by this algorithm.

Note: C はアルゴリズムにとって必要なように C の要素が参照可能であれば、どのような実装固有のデータ構造表現であってもよい。

  1. Verify that the value of C.type is the string webauthn.get.
  1. C.type の値が webauthnn.get であることを検証する。
  1. Verify that the value of C.challenge equals the base64url encoding of options.challenge.
  1. C.challenge が base64url エンコードされた options.challenge の値であることを検証する。
  1. Verify that the value of C.origin matches the Relying Party's origin.
  1. C.origin の値が Relying Party の origin とマッチすることを検証する。
  1. Verify that the rpIdHash in authData is the SHA-256 hash of the RP ID expected by the Relying Party.
  1. authData の rpIdHash が Relying Party が想定している RP ID の SHA-256 ハッシュであることを検証する。

Note: If using the appid extension, this step needs some special logic. See § 10.1 FIDO AppID Extension (appid) for details.

Note: もし appid 拡張を使う場合、このステップは特別なロジックを必要とする。詳細は § 10.1 FIDO AppID Extension (appid) を参照すること。

  1. Verify that the User Present bit of the flags in authData is set.
  1. authData の flags の User Present ビットが設定されていることを検証する。
  1. If user verification is required for this registration, verify that the User Verified bit of the flags in authData is set.
  1. この登録においてユーザー認証 が必要とされる場合、authData の flags の User Verified ビットが設定されていることを検証する。
  1. Verify that the values of the client extension outputs in clientExtensionResults and the authenticator extension outputs in the extensions in authData are as expected, considering the client extension input values that were given in options.extensions and any specific policy of the Relying Party regarding unsolicited extensions, i.e., those that were not specified as part of options.extensions. In the general case, the meaning of "are as expected" is specific to the Relying Party and which extensions are in use.
  1. options.extensions で与えられたクライアント拡張入力の値と Relying Party の未承諾拡張、つまり options.extensions で定義されていない固有のポリシーを考慮して、clientExtensionResults のクライアント拡張出力の値と authData の extenions における認証器拡張出力が期待通りであることを検証する。一般的な場合、"期待通りである"とは、Relying Party と Relying Party が利用している拡張に固有である。

Note: Client platforms MAY enact local policy that sets additional authenticator extensions or client extensions and thus cause values to appear in the authenticator extension outputs or client extension outputs that were not originally specified as part of options.extensions. Relying Parties MUST be prepared to handle such situations, whether it be to ignore the unsolicited extensions or reject the assertion. The Relying Party can make this decision based on local policy and the extensions in use.

Note: クライアントプラットフォームは追加の認証器拡張やクライアント拡張をセットし、options.extensions で本来定義されていない認証器拡張出力やクライアント拡張出力に値を出現させるローカルポリシーを実施してもよい。Relying Party はそのような状況をハンドリングする準備をするか、未承諾の拡張を無視するか、アサーションを拒絶しなければならない。Relying Party はローカルポリシーと利用している拡張をもとにこの決定を行う必要がある。

Note: Since all extensions are OPTIONAL for both the client and the authenticator, the Relying Party MUST also be prepared to handle cases where none or not all of the requested extensions were acted upon.

Note: すべての拡張はクライアントと認証器両方において OPTIONAL であり、Relying Party はリクエストした拡張が全部、もしくは一部が対応していなかったケースをハンドリングする準備をしなければならない。

  1. Let hash be the result of computing a hash over the cData using SHA-256.
  1. hash に cData を SHA-256 でハッシュ化した結果を代入する。
  1. Using credentialPublicKey, verify that sig is a valid signature over the binary concatenation of authData and hash.
  1. credentialPublicKey を使って sig が authData と hash をバイナリで連結した値の有効な証明であることを検証する。

Note: This verification step is compatible with signatures generated by FIDO U2F authenticators. See § 6.1.2 FIDO U2F Signature Format Compatibility.

この検証ステップは FIDO U2F 認証器によって生成された署名と互換性がある。§ 6.1.2 FIDO U2F Signature Format Compatibility を参照すること。

  1. Let storedSignCount be the stored signature counter value associated with credential.id. If authData.signCount is nonzero or storedSignCount is nonzero, then run the following sub-step:
  1. credential.id に関連付けて保存された signature counter の値を storedSignCount に代入する。もし authData.signCount が 0 でない、もしくは storedSignCount が 0 でない場合、以下のステップを実行する。

If authData.signCount is

もし authData.signCount が

↪ greater than storedSignCount:

↪ storedSignCount より大きかったら

Update storedSignCount to be the value of authData.signCount.

storedSignCount を authData.signCount に更新する。

↪ less than or equal to storedSignCount:

↪ storedSignCount と同じか小さかったら

This is a signal that the authenticator may be cloned, i.e. at least two copies of the credential private key may exist and are being used in parallel. Relying Parties should incorporate this information into their risk scoring. Whether the Relying Party updates storedSignCount in this case, or not, or fails the authentication ceremony or not, is Relying Party-specific.

これは認証器がコピーされたシグナルである。つまり、クレデンシャル秘密鍵の少なくとも 2 つのコピーが存在し、平行に使われている。Relying Party はこの情報をリスクの計算に加味すべきである。Relying Party が storedSignCount を更新するかしないか、認証セレモニーを失敗扱いとするかどうかは Relying Party の仕様による。

  1. If all the above steps are successful, continue with the authentication ceremony as appropriate. Otherwise, fail the authentication ceremony.
  1. もし上記のステップが全て成功したら、適切に認証セレモニーを継続し、そうでなければ失敗とする。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment