From 80cbf9952fc2a0c8de28a67766fb3ca747754223 Mon Sep 17 00:00:00 2001 From: Yuu Kikuchi Date: Thu, 14 Mar 2024 14:25:42 +0900 Subject: [PATCH 1/4] update translate for constraints on verification data --- openid-connect-4-identity-assurance.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/openid-connect-4-identity-assurance.md b/openid-connect-4-identity-assurance.md index 4d272e9..91b7d65 100644 --- a/openid-connect-4-identity-assurance.md +++ b/openid-connect-4-identity-assurance.md @@ -282,19 +282,24 @@ RP は `document`要素内の特定のデータの存在を要求するも出来 ### value/values -The RP can limit the possible values of the elements `trust_framework`, `evidence/method`, `evidence/check_details`, and `evidence/document/type` by utilizing the `value` or `values` fields and the element `evidence/type` by utilizing the `value` field. + +RP は `value` または `values` フィールドと `evidence/type` 要素を利用することで，`trust_framework`, `evidence/method`, `evidence/check_details`, 及び `evidence/document/type` 要素の `value` フィールドで利用可能な値を制限出来る． -Note: Examples on the usage of a restriction on `evidence/type` were given in the previous section. + +注: `evidence/type` の制限の使用例は，以前のセクションで示した． -The following example shows how an RP may request Claims either complying with trust framework `gold` or `silver`. + +次の例は，RP がトラストフレームワーク `gold` または `silver` のいずれかに準拠した Claims をリクエストする方法を示す． <{{examples/request/verification_claims_different_trust_frameworks.json}} -The following example shows that the RP wants to obtain an attestation based on the German Anti Money Laundering Law (trust framework `de_aml`) and limited to End-Users who were identified in a bank branch in person (physical in person proofing - method `pipp`) using either an `idcard` or a `passport`. + +次の例は，RP がドイツのマネーロンダリング防止法 (トラストフレームワーク `de_aml`) に基づき，`idcard` または `passport` を利用して銀行の窓口にて対面で識別された (物理的な身元確認 - `ppid` 手法) エンドユーザーに限定した証明の取得を希望していることを示す． <{{examples/request/verification_aml.json}} -The OP MUST NOT ignore some or all of the query restrictions on possible values and MUST NOT deliver available verified/verification data that does not match these constraints. + +OP は可能な値のクエリ制約の一部または全部を無視してはならず (MUST NOT)，これらの制約に一致しない利用可能な検証済み/検証データを提供してはならない (MUST NOT)． ### max_age From b5b7744874659ff513a393029fbc9a0f52b5e5e5 Mon Sep 17 00:00:00 2001 From: Yuu Kikuchi Date: Mon, 25 Mar 2024 22:21:37 +0900 Subject: [PATCH 2/4] update translate added by spec division --- openid-connect-4-identity-assurance.md | 28 +++++++++++++++----------- 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/openid-connect-4-identity-assurance.md b/openid-connect-4-identity-assurance.md index 91b7d65..5121b19 100644 --- a/openid-connect-4-identity-assurance.md +++ b/openid-connect-4-identity-assurance.md @@ -167,12 +167,12 @@ Verified Claim を表す場合でも，本拡張は可能かつ妥当であれ ## Additional Claims about End-Users {#userclaims} -identity assurance に関する一部の権限の要件を満たすために, the OpenID Connect for IDA claims [@OpenID4IDAClaims] specification defines the a number of Claims for conveying End-User data in addition to the Claims defined in the OpenID Connect specification [@!OpenID]. +identity assurance に関する一部の権限の要件を満たすために, OpenID Connect for IDA claims [@OpenID4IDAClaims] 仕様では OpenID Connect [@!OpenID] 仕様で定義されている CLaims に加えて，End-User のデータを伝達するための多数の Claims が定義されている． # Verified Claims {#verified_claims} -This specification uses the [!@IDA-verified-claims] document as the definition of the schema for representation of assured digital identity attributes and identity assurance metadata. 基本的な考え方は `verified_claims` と呼ばれるコンテナ要素を使用し，RP に一連の Claim と，これらの Claim の検証に関連するそれぞれのメタデータ及び検証のエビデンスを提供することである． This way, it is explicit which Claims are verified, reducing the risk of RPs accidentally processing unverified Claims as Verified Claims. +本仕様は，保証された digital identity 属性と identity assurance メタデータを表現するためのスキーマの定義として [!@IDA-verified-claims] ドキュメントを利用する．基本的な考え方は `verified_claims` と呼ばれるコンテナ要素を使用し，RP に一連の Claim と，これらの Claim の検証に関連するそれぞれのメタデータ及び検証のエビデンスを提供することである．これにより，どの Claims が検証されたかが明確になり，RP が未検証の Claims を Verified Claims として誤って処理してしまうリスクが軽減される．． 次の例では，トラストフレームワーク `trust_framework_example` の例に従って，OP が提供された Claim (`given_name` and `family_name`) を検証したことを RP に表明する: @@ -214,7 +214,8 @@ OAuth Authorization Server は，JWT 形式のアクセストークンや Token } ``` -An OP or AS can also include aggregated or distributed `verified_claims` in the above assertions (see (#aggregated_distributed_claims) for more details). + +OP または AS は上記のアサーションに集約または分散された `verified_claims` を含めることも出来る (詳細は (#aggregated_distributed_claims) 参照)． ## Requesting End-User Claims {#req_claims} @@ -222,20 +223,21 @@ An OP or AS can also include aggregated or distributed `verified_claims` in the Verified Claims は OpenID Connect specification [@!OpenID] の Section 5.5 に定義されている `claims` parameter を利用することで, End-User について 個々の Claims のレベルで要求できる. -注: `verified_claims` をリクエストするために使用される機械可読な構文定義は [@verified_claims_request.json] で JSON スキーマとして提供され，これは `claims` リクエストパラメータを自動的に検証するために使用できる．The provided JSON schema files are a non-normative implementation of this specification and any discrepancies that exist are either implementation bugs or interpretations. +注: `verified_claims` をリクエストするために使用される機械可読な構文定義は [@verified_claims_request.json] で JSON スキーマとして提供され，これは `claims` リクエストパラメータを自動的に検証するために使用できる．提供されている JSON スキーマファイルは本仕様の no-normative な実装であり，存在する何らかの矛盾は実装のバグあるいは解釈のいずれかです． -To request Verified Claims, the `verified_claims` element is added to the `userinfo` or the `id_token` element of the `claims` parameter. + 検証済み Claim を要求するには，`verified_claims` 要素を `claims` パラメータの `userinfo` または `id_token` 要素に追加する． -`verified_claims` にはネストされた `claims` 要素の中に End-User についての有効な Claims が含まれるため, syntax は次のようにネストされた要素の式を含むように拡張される. The `verified_claims` element includes a `claims` element, which in turn includes the desired Claims as keys. For each claim, the value is either `null` (default), or an object. The object may contain restrictions using `value` or `values` as defined in [@!OpenID] and/or the `essential` or `purpose` keys as described below. 以下に例を示す. +`verified_claims` にはネストされた `claims` 要素の中に End-User についての有効な Claims が含まれるため, syntax は次のようにネストされた要素の式を含むように拡張される. `verified_claims` 要素には `claims` 要素が含まれ，この要素には目的の Claims がキーとして含まれる．各 claim について，値は `null` (デフォルト)，またはオブジェクトのいずれかである．オブジェクトは [@!OpenID] で定義された `value` または `values` 及び/または以下で説明する `essential` または `purpose` キーを使用した制限が含まれるかもしれない．以下に例を示す. <{{examples/request/claims.json}} - -`claims` パラメータを使用すると, RP はそのユースケースに必要な End-User に関する指定した Claims を要求できるようになる. This allows RPs to fulfill the requirements for data minimization by requesting only Claims needed for its use case. Note: it is not possible to request sub-claims (for example the ‘country’ subclaim of the ‘address’ claim) using mechanisms from OpenID Connect Core or this draft. + +`claims` パラメータを使用すると, RP はそのユースケースに必要な End-User に関する指定した Claims を要求できるようになる. これにより RPs はそのユースケースに必要な Claims のみをリクエストするすることでデータ最小化の要件を満たすことができる．注: OpenID Connect Core またはこのドラフトのメカニズムを利用して，サブクレーム（例えば 'address' クレームの 'country' サブクレーム） を要求することは出来ない． -RPs can use the `essential` field as defined in Section 5.5.1 of the OpenID Connect specification [@!OpenID]. The following example shows this for the family and given names. + +RPs は OpenID Connect 仕様 [@!OpenID] の Section 5.5.1 に定義された `essential` フィールドを使うことが出来る．次の例は，姓名についてこれを示す． <{{examples/request/essential.json}} @@ -267,11 +269,13 @@ RP は OP が `verification` 要素に追加するデータを明示的に要 `evidence` 配列の単一エントリは，特定のエビデンスタイプの要素に対するフィルターを洗わず．従って，RP は適切な `value` サブ要素値を含む `type` フィールドを含めることによって，このタイプを指定しなければならない (MUST)．`values` サブ要素を `evidence/type` フィールドに使用してはならない (MUST NOT)． -`evidence` に複数のエンドリが存在する場合，これらのフィルターは論理和によって紐付けられる． +`evidence` に複数のエントリが存在する場合，これらのフィルターは論理和によって紐付けられる． -`check_details` is an array of the processes that have been applied to the `evidence`. An RP can filter `check_details` by requesting a particular value for one or more of its sub-elements. If multiple entries for the same sub-element are present this acts as a logical OR between them. + +`check_details` は `evidence` に適用されるプロセスの配列である．RP は1つ以上のサブ要素に特定の値を要求することでｍ`check_details` をフィルタリング出来る．同じサブ要素に複数のエントリーがある場合，これはそれらの間の論理 OR として機能する． -`assurance_details` is an array representing how the `evidence` and `check_details` meets the requirements of the `trust_framework`. RP SHOULD only request this where they need to know this information. Where `assurance_details` have been requested by an RP the OP MUST return the `assurance_details` element along with all sub-elements that it has. If an RP wants to filter what types of `evidence` and `check_methods` they MUST use those methods to do so, e.g. requesting an `assurance_type` SHOULD have no filtering effect. + +`assurance_details` は `evidence` と `check_details` が `trust_framework` の要件をどのように満たしているかを表す配列である． RP はこの情報を知る必要がある場合のみこれを要求しなければならない (SHOULD)．`assurance_details` が RP によって要求された場合，OP は `assurance_details` 要素とそれが持つすべてのサブ要素を返却しなければならない (MUST)．RP が `evidence` や `check_methods` のタイプをフィルターしたい場合，そのためにそれらのメソッドを使用しなければならない (MUST)，例えば `assurance_type` をリクエストしても，フィルタリングの効果はない (SHOULD)． RP は `document`要素内の特定のデータの存在を要求するも出来る．これも上記で使用した構文規則に従う: From 04733196288d652dfd1a33a415d04c6f727740d3 Mon Sep 17 00:00:00 2001 From: Yuu Kikuchi Date: Mon, 25 Mar 2024 22:52:53 +0900 Subject: [PATCH 3/4] update translate for constraints on verification data (max_age section) --- openid-connect-4-identity-assurance.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/openid-connect-4-identity-assurance.md b/openid-connect-4-identity-assurance.md index 5121b19..cafe653 100644 --- a/openid-connect-4-identity-assurance.md +++ b/openid-connect-4-identity-assurance.md @@ -307,15 +307,20 @@ OP は可能な値のクエリ制約の一部または全部を無視しては ### max_age -The RP can also express a requirement regarding the age of certain data, like the time elapsed since the issuance/expiry of certain evidence types or since the verification process asserted in the `verification` element took place. Section 5.5.1 of the OpenID Connect specification [@!OpenID] defines a query syntax that allows for new special query members to be defined. This specification introduces a new such member `max_age`, which is applicable to the possible values of any elements containing dates or timestamps (e.g., `time`, `date_of_issuance` and `date_of_expiry` elements of evidence of type `document`). + +RP は特定のエビデンスタイプの発行/執行からの経過時間や，`verification` 要素でアサートされた検証プロセスが行われてからの経過時間のような，特定のデータの経過時間に関する要件を表現することもできる．OpenID Connect 仕様 [@!OpenID] の Section 5.5.1 では新しい特別なクエリメンバーを定義できるクエリ構文を定義している．この仕様では，日付またはタイムスタンプを含む要素 (例えば，タイプ `document` のエビデンスの `time`，`date_of_issuance` 及び `date_of_expiry` 要素) の取り得る値に適用される新しいメンバー `max_age` を導入する． -`max_age`: OPTIONAL. JSON number value only applicable to Claims that contain dates or timestamps. It defines the maximum time (in seconds) to be allowed to elapse since the value of the date/timestamp up to the point in time of the request. The OP SHOULD make the calculation of elapsed time starting from the last valid second of the date value. + +`max_age`: OPTIONAL. 日付またはタイムスタンプを含む Claims にのみ適用可能な JSON number 値．日付/タイムスタンプの値からリクエストの時点までに許容される最大経過時間(秒)を定義する．OP は日付値の最後の有効な秒から開始して経過時間を計算しなければならない (SHOULD)． + The following is an example of a request for Claims where the verification process of the data is not allowed to be older than 63113852 seconds: +次の例は，データの犬種おプロセスが 63113852 秒より古いことが許容されていない Claims の要求例である: <{{examples/request/verification_max_age.json}} -The OP SHOULD try to fulfill this requirement. If the verification data of the End-User is older than the requested `max_age`, the OP can attempt to refresh the End-User’s verification by sending them through an online identity verification process, e.g., by utilizing an electronic ID card or a video identification approach. + +OP は子の要件を満たすよう務めるべきである (SHOULD)．もし End-User の検証データが要求された `max_age` より古い場合，OP は例えば electronic ID card や video identification approach を利用するなど，オンラインの identity verification process を通じて End-User のverification を送信することで，End-User の verification の更新を試みることが出来る． ## Requesting Claims sets with different verification requirements From 4ac8025bbb50f096ba50585fc31767f18c7554e4 Mon Sep 17 00:00:00 2001 From: Yuu Kikuchi Date: Thu, 23 May 2024 21:53:49 +0900 Subject: [PATCH 4/4] translate "Requesting claims sets with different verification requirements" section --- openid-connect-4-identity-assurance.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/openid-connect-4-identity-assurance.md b/openid-connect-4-identity-assurance.md index 22305b0..45e23e7 100644 --- a/openid-connect-4-identity-assurance.md +++ b/openid-connect-4-identity-assurance.md @@ -354,19 +354,24 @@ OP は子の要件を満たすよう務めるべきである (SHOULD)．もし E ## Requesting claims sets with different verification requirements -It is also possible to request different trust frameworks, assurance levels, and methods for different claim sets. This requires the RP to send an array of `verified_claims` objects instead of passing a single object. + +異なった Claim Sets に対して，異なったトラストフレームワーク， assurance レベルや方法を要求することが出来る．これは RP が単一オブジェクトを渡すのではなく，`verified_claims` オブジェクトの配列を送信することを要求する． -The following example illustrates this functionality. + +次の例はこの機能を示す． <{{examples/request/verification_claims_by_trust_frameworks.json}} -When the RP requests multiple verifications as described above, the OP will process each element in the array independently. The OP will provide `verified_claims` response elements for every `verified_claims` request element whose requirements it is able to fulfill. This also means if multiple `verified_claims` elements contain the same end-user claim(s), the OP delivers the claim in as many verified claims response objects it can fulfil. For example, if the trust framework the OP uses is compatible with multiple of the requested trust frameworks, it provides a `verified_claims` element for each of them. + +RP が上記に従って複数の検証を要求すると，OP は配列内の各要素を個別に処理する．OP は要件を満たすことの出来るすべての `verified_claims` 要求要素に対して，`verified_claims` レスポンス要素を提供する．これは複数の `verified_claims` 要素に同じエンドユーザーの claim が含まれている場合，OP は満たせるだけ多くの verfied claims レスポンスオブジェクトで claim を配信することも意味する．例えば，OP が使用するトラストフレームワークが要求された複数のトラストフレームワークと互換性がある場合，それらのそれぞれに `verified_claims` 要素が提供される． -The RP can combine multiple `verified_claims` claims in the request with multiple `trust_framework` and/or `assurance_level` values using the `values` element. In that case, the rules given above for processing `values` are applied for the particular `verified_claims` request object. + +RP は `values` 要素を利用して，リクエスト中の複数の `verified_claims` claims を複数の `trust_framework` 及び/または `assurance_level` 値と組み合わせることが出来る．このケースにおいて，`values` を処理するための上記のルールが特定の `verified_claims` リクエストオブジェクトに適用される． <{{examples/request/verification_claims_by_trust_frameworks_same_claims.json}} -In the above example, the RP asks for family and given name either under trust framework `gold` with an evidence of type `document` or under trust framework `silver` or `bronze` but with an evidence `electronic_record`. + +上記の例では，RP は エビデンスタイプ `document` を持つトラストフレームワーク `gold` もしくは エビデンスタイプ `electronic_record` を持つトラストフレームワーク `silver` または `bronze` に基づいて，姓と名を要求する． ## Returning less data than requested