| connect | T. Lodderstedt |
| Internet-Draft | D. Fett |
| Intended status: Standards Track | yes.com |
| Expires: February 16, 2020 | August 15, 2019 |
OpenID Connect for Identity Assurance 1.0
openid-connect-4-identity-assurance-1_0-07
This specification defines an extension of OpenID Connect for providing Relying Parties with verified Claims about End-Users. This extension is intended to be used to verify the identity of a natural person in compliance with a certain law.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 16, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この仕様では, OpenID Connect [OpenID] の拡張機能を定義して, 特定の法律に従って自然人の強力な identity verification のユースケースに対処している. 例には, マネーロンダリング防止法, 電気通信法, テロ対策法, eIDAS [eIDAS] などの信託サービスに関する規制が含まれる.
そのようなユースケースでは, 依拠当事者 (RPs) は, OpenID Connect プロバイダー (OPs) またはその他の信頼できるソースによって証明されたエンドユーザーに関する Claim の保証レベルと, identity verification プロセスに関連するエビデンスを知る必要がある.
OpenID Connect 仕様 [OpenID] の Section 2 で定義されている acr Claim は, OpenID Connect トランザクションで実行される認証に関する情報を証明するのに適している. ただし, identity assurance には次の理由で異なる表現が必要である: 認証は OpenID Connect トランザクションの側面であり, identity assurance は特定の Claim または Claim のグループのプロパティであり, それらのいくつかは通常, OpenID Connect トランザクションの結果として RP に伝えられる.
たとえば, 通常, OP が電子メールアドレスを証明できるという保証は「自己表明」または「オプトインまたは同様のメカニズムによって検証」される. 対照的にユーザーの姓は, OP オペレーターの訓練を受けた従業員に ID カードを提示することにより, それぞれのマネーロンダリング防止法に従って検証された可能性がある.
したがって, identity assurance には, エンドユーザーに関する各 Claim とともに保証データを伝達する方法が必要である. この仕様は, RP がエンドユーザーに関する検証済み Claim を identity assurance データとともに要求し, OP がこれらの検証済み Claim と付随する identity assurance データを表すために利用する適切な表現とメカニズムを提案する.
このセクションでは, NIST SP 800-63A [NIST-SP-800-63a] に大きな影響を受けた, このドキュメントで扱われているトピックに関連するいくつかの用語を定義する.
本仕様のスコープは, 検証された Claim をアサートするメカニズムを定義し, identity assurance スペースで必要とされるエンドユーザに関する新しい Claim を導入することである; 例の一つとして出生地がある.
RP は必要とする最小限のデータセットを要求し (データの最小化) , このデータと OP で利用されるエビデンス, および identity verification プロセスに関する要件を表すことができる.
この拡張機能は, eIDAS 公認 eID システムなどの identity assurance に関連する特定の規制の下で動作する OP, および他の OP で使用できる. 厳密に規制された OP は, はっきりと定義された責任を伴う明確に定義されたルールに従って動作することを承認されているため, さらなるエビデンスを提出することなく identity データを証明することができる.
例えば eIDAS のケースでは, ピアレビューが eIDAS のコンプライアンスを保証し, それぞれのメンバー国は公認 eID システムによる identity の主張に対して責任を負う. そのような明確に定義された条件下にない他のすべての OP は, 一般的に, RP が独自のリスク評価を実施し, OP から取得したデータを他の法律にマッピングできるように, identity evidence に加えて, RP に identity verification プロセスに関するデータを提供する必要がある. 例えば eIDAS で定義された要件を満たすために, マネーロンダリング防止法に従って維持されている identity データを使用することができる.
技術的な観点から, この仕様は OP が各トラストフレームワーク(と assurance レベル)についての情報に加えて, 検証済み Claim の証明を許可することを意味するが, identity verification プロセスに関する情報の表出化のサポートも行う.
この仕様で定義された表現方式は, 適切なチャネルを介してエンドユーザに関する検証済 Claim を RP に提供するために利用できる. OpenID Connect のコンテキストでは, 検証済 Claim は ID Token か UserInfo response の一部として証明することができる. また OAuth Token Introspection response ([RFC7662] 及び [I-D.ietf-oauth-jwt-introspection-response] を参照)で説明されている形式を利用して, 検証済 Claim をリソースサーバに提供することも可能である.
この拡張は真に国際的なものであり, 異なる管轄の identity assurance もサポートさせる予定である. そのためこの拡張機能は追加のトラストフレームワーク, 検証メソッド, identity evidenceをサポートするために拡張することができる.
実装者に可能な限りの柔軟性を与えるために, この拡張は既存の OpenID Connect の Claim および同じ OpenID Connect のアサーション(例えば, ID Token や UserInfo)内の他の拡張と組み合わせて使うことができる.
例えば, OpenID Connect [OpenID] は検証ステータスのないユーザの姓と名を表す Claim を定義している. これらの Claim はこの拡張に従って表現される検証済み Claim とともに同じ OpenID Connect のアサーションで使うことができる.
同じように, RP に phone_number と email Claim の検証ステータスを通知する既存 Claim もこの拡張とともに使うことができる.
検証済み Claim を主張する場合でも, この拡張は可能かつ妥当であれば既存の OpenID Connect の Claim を利用する. しかしながら, 拡張は RP が未検証 Claim を検証済 Claim として(誤って)解釈できないようにする.
identity assurance に関する一部の権限の要件を満たすために, この仕様では OpenID仕様 [OpenID] に定義されている Claim にユーザデータを伝達するための以下の追加の Claim を定義する:
一般的に, 強固な identity verification は参加者がプロセス全体の監査証跡を保持する必要がある.
[RFC8417] で定義されている txn Claim はこの拡張のコンテキストで使用され, OpenID Connect トランザクションに関わるの関係者全体の監査証跡を構築する.
OP が txn を発行する場合, 対応する監査証跡を維持する必要があり (MUST), 少なくとも次の詳細で構成される.
このトランザクションデータは, それぞれの規定による監査目的のためにトランザクションデータを保存する必要がある限り保存し続けなければならない (MUST).
RP はこの Claim を claims パラメータを介して, または scope 値によって識別されるデフォルトの Claim の一部として, 他の Claim と同様に要求する.
txn 値は必要に応じて RP がこれらのトランザクションを参照できるようにしなければならない (MUST).
注：トランザクションの詳細を, OP および, それらのフォーマットから取得するメカニズムはこの仕様の範囲外である.
OpenID Connect のこの拡張は, RP が検証済みの Claim と未検証の Claim を混在させ, 検証済みの Claim として未検証の Claim を偶発的に処理できないようにすることを目的としている.
それ故, 提案された表現は verified_claims コンテナ要素内で検証済み Claim を RP に提供することである. このコンテナは特定の検証プロセスに関連する検証のエビデンスとこのプロセスで検証されたエンドユーザについての該当 Claim で構成されている.
このセクションでは verified_claims の構造と意味について詳しく説明する. 機械可読な構文定義は Section 12 で JSON スキーマとして提供される. verified_claims 要素を含む JSON ドキュメントを自動的に検証するために使用できる.
verified_claims は以下のサブ要素で構成される:
注: 実装は, この仕様またはこの仕様の拡張で定義されていないサブ要素を無視しなければならない (MUST).
この要素には, 個人の身元を確認し, それぞれの個人データをユーザーアカウントにバインドするために実行されたプロセスに関する情報が含まれる.
verification 要素は以下の要素を含む:
trust_framework: 必須 (REQUIRED). OP の identity verification プロセスと, identity assurance レベルを管理する trust framework を定める文字列.
例としては eidas_ial_high で, これは eIDAS [eIDAS] 公認 eID システムを示し, assurance レベル "high" の identity assurance を提供する.
標準化された値の初期リストは, Trust Frameworks で定義されている. 追加の trust framework identifiers も導入できる [how？]. RP は理解できない trust framework identifiers を含む verified_claims Claim を無視しなければならない (SHOLUD).
trust_framework は, verification 要素の中で RP に提供される追加のデータを決定する. たとえば, eIDAS 公認 eID システムは, データを追加する必要はないが, eIDAS に管理されていない OP は RP が法的義務を果たすために verification evidence を提供する必要がある. 後者の例としては, ドイツのマネーロンダリング防止法 (de_aml) に基づいて行動する OP である.
time: ID の検証が行われた日時を示す ISO 8601:2004 [ISO8601-2004] YYYY-MM-DDThh:mm:ss±hh フォーマットのタイムスタンプ. 特定のトラストフレームワークでは, この要素の存在が必要になる場合がある.
verification_process: OP によって実行される identity verification プロセスへの一意の参照. 紛争(ないしは紛争解決)または監査の場合のバックトレースに使用される.特定のトラストフレームワークでは, この要素の存在が必要になる場合がある.
注：verification_process は OP での identity verification プロセスを指すが, txn Claim は OP が RP に対してユーザ検証済 identity データを証明した特定の OpenID Connect トランザクションを指す.
evidence: OP がユーザの identity を個別の JSON オブジェクトとして検証するために使用した evidence に関する情報を含む JSON 配列. すべてのオブジェクトには, エビデンスのタイプを決定する type プロパティが含まれている. RP はこの情報を evidence プロパティを適切に処理するために利用する.
重要:実装はこの仕様またはこの仕様の拡張で定義されていないサブ要素を無視しなければならない (MUST).
次のエビデンスのタイプが定義されている:
次の種類の属性が id_document エビデンスのサブ要素として含まれる.
method: 必須 (REQUIRED). id document を検証するために使われるメソッド. 事前に定義された値は Verification Methods で定義されている.
verifier: オプション (OPTIONAL). OP に代わって identity verification を実行した法人を示す JSON オブジェクト. このオブジェクトは, OP が identity verification を実行しなかった場合にのみ含める必要がある (SHOULD). このオブジェクトは次のプロパティで構成される:
time: この id document が検証された日付を表す ISO 8601:2004 [ISO8601-2004] YYYY-MM-DDThh:mm:ss±hh フォーマットのタイムスタンプ.
document: ID 検証に使用される id document を表す JSON オブジェクト. 次のプロパティで構成される:
次の種類の要素が utility_bill エビデンスのサブ要素として含まれる.
provider: 必須 (REQUIRED). 請求書を発行した各プロバイダを識別する JSON オブジェクト. オブジェクトは次のプロパティで構成される:
date: この請求書が発行された日時を含む ISO 8601:2004 YYYY-MM-DD フォーマットの文字列.
次の種類の要素が qes エビデンスのサブ要素として含まれる.
issuer: 必須 (REQUIRED). 署名者の証明書を発行した証明機関を示す文字列.
serial_number:必須 (REQUIRED). 署名に使用される証明書のシリアルナンバーを含む文字列.
created_at: 必須 (REQUIRED). ISO 8601:2004 YYYY-MM-DDThh:mm:ss±hh フォーマットの署名が作られた時間.
claims 要素にはプロセスによって検証され, 対応する verification 要素によって決定されたポリシーに従って検証されたエンドユーザについての Claim が含まれる.
claims 要素には OpenID Connect specification [OpenID] の Section 5.1 で定義されている以下の Claim が一つ以上含まれるかもしれない (MAY)
または Section 3.1 で定義されている Claim を含むかもしれない.
claims 要素は, 兄弟要素の verification で提示された検証プロセスでそれぞれの Claim の値が検証された場合, 他の Claim も含むかもしれない (MAY).
Claim 名は, OpenID Connect 仕様 [OpenID] の Section 5.2 で指定されている言語タグで注釈を付けてもよい (MAY).
Verified Claims は OpenID Connect specification [OpenID] の Section 5.5. に定義されている claims parameter を利用することで, End-User について 個々の Claims のレベルで要求できる.
verified_claims は claims パラメーターの userinfo か id_token 要素に追加される.
verified_claims にはネストされた claims 要素の中に End-User についての有効な Claims が含まれるため, syntax は次のようにネストされた要素の式を含むように拡張される. verified_claims 要素は claims 要素を含み, null 値を持つキーとして要求する Claims を含む. 以下に例を示す.
{
"userinfo":{
"verified_claims":{
"claims":{
"given_name":null,
"family_name":null,
"birthdate":null
}
}
}
}
claims パラメータを使用すると, RP はユースケースに必要な End-User に関する Claims を正確に選択できる. したがって, この拡張は RPs はデータ最小化の要件を満たすことができる.
RPs は, OpenID Connect specification [OpenID] の Section 5.5.1 で定義されている essential フィールドを利用することにより, 特定の Claim がユーザージャーニーの正常な完了に不可欠であることを示すことができる. 次の例では, 姓と名の両方を必須として指定している.
{
"userinfo":{
"verified_claims":{
"claims":{
"given_name":{"essential": true},
"family_name":{"essential": true},
"birthdate":null
}
}
}
}
この仕様では, RP が要求する特定の End-User Claim の移転の目的を説明できるようにするために, 追加のフィールド purpose を導入する. purpose フィールドは, 個々に要求された各 Claim のメンバー値にすることができるが, 1つの Claim には複数の関連する目的を含めることはできない.
purpose OPTIONAL. OP から特定の End-User Claim を取得する目的を説明する文字列. purpose は 3 文字未満か 300 文字以上となってはならない (MUST NOT). もしこのルールに違反した場合, authentication request は失敗し, OP は invalid_request エラーを RP にに返さなければならない (MUST). 移転されるデータの利用目的や承認しようとしている認可内容をユーザーに明示するため, OP は各同意画面にこの purpose を表示しなければならない (MUST). purpose パラメーターがリクエストに存在しない場合, OP は RP ごとに事前設定された値を表示できる (MAY). UI ローカリゼーションの詳細については, Section 8 参照.
例:
{
"userinfo":{
"verified_claims":{
"claims":{
"given_name":{
"essential":true,
"purpose":"To make communication look more personal"
},
"family_name":{
"essential":true
},
"birthdate":{
"purpose":"To send you best wishes on your birthday"
}
}
}
}
}
注: 値が null の claims サブ要素は, 考えられるすべての Claims に対するリクエストとして解釈される. 以下に例を示す:
{
"userinfo":{
"verified_claims":{
"claims":null
}
}
}
注: claims サブ要素は省略でき, これは, 値が null である claims 要素と同等である.
注: claims サブ要素が空か, Section 4.2 に定義されている要件を満たなさい Claims を含む場合, OP は invalid_request エラーでトランザクションを中断するだろう.
verification 要素内容は, 基本的にそれぞれの trust_framework と Claim source のポリシーによって決定される.
この仕様は RP が特定のデータを verification 要素に明示的に要求する方法も定義する. 構文は Section 5.1 で指定されたルールに基づいており, verification 要素の構造へのナビゲーションのためにそれらを拡張する.
次の例で示すように, verification 内の要素としてそれぞれの要素を追加することで, Section 5.1 に定義されているのと同じ方法でリクエストできる.
{
"verified_claims":{
"verification":{
"date":null,
"evidence":null
},
"claims":null
}
}
これは, 発行されたアサーションに検証の日付と利用可能な証拠が存在することを要求する.
注: verified_claims Claim の必須要素であるため, RP は明示的に trust_framework フィールドを要求する必要はない.
RP は, 構造を1段深く掘り下げ, 特定のデータがすべての evidence 内に存在することを要求する場合もある. result array 内のすべてのエントリのプロトタイプとして, 単一のエントリが使用される.
{
"verified_claims":{
"verification":{
"date":null,
"evidence":[
{
"method":null,
"document":null
}
]
},
"claims":null
}
}
この例では, 特定のユーザーアカウントで利用可能なすべての証拠について, method 要素と document 要素を要求する.
注: evidence エントリの必須要素であるため, RP は明示的に type フィールドを要求する必要はない.
RP は, document 要素内に特定のデータが存在することを要求する場合もある. これも, 上記で使用した構文規則に従う.
{
"verified_claims":{
"verification":{
"date":null,
"evidence":[
{
"method":null,
"document":{
"issuer":null,
"number":null,
"date_of_issuance":null
}
}
]
},
"claims":null
}
}
注: document エントリの必須要素であるため, RP は明示的に type フィールドを要求する必要はない.
RP に要求された検証データを提供するか決定するのは, Claim source の裁量である.
RP は verification サブ要素の要素に関する要件を表現できる (MAY).
ここでも再び, verified_claims claim のネストされた性質によって, OpenID Connect specification [OpenID] の Section 5.5. で定義されている構文の拡張が必要である.
OpenID Connect specification [OpenID] の Section 5.5.1 は, Claim の 追加情報/制約を持つ JSON object を要求するような Claim のメンバー値であることを許す構文を定義する. そのために, 特別なクエリの意味を持つ3つのメンバー (essential, value, および values) を定義し, 他の特別なメンバーを定義できるようにする (理解されていないメンバーは無視しなければならない).
この仕様はそのメカニズムを再利用し, 新しいそのような max_age メンバーを導入する (下記参照).
まず, value か values フィールドを利用して, trust_framework, evidence/type, evidence/method, 及び evidence/document/type の利用可能な値を制限することができる (MAY).
次の例は, RP が AML(訳注: Anti-Money Laundering) に基づいて, 政府発行のIDドキュメントを使用して, 銀行の支店で直接本人確認を行った人に限定したユーザーの証明を取得したいことを示している.
{
"userinfo":{
"verified_claims":{
"verification":{
"trust_framework":{
"value":"de_aml"
},
"evidence":[
{
"type":{
"value":"id_document"
},
"method":{
"value":"pipp"
},
"document":{
"type":{
"values":[
"idcard",
"passport"
]
}
}
}
]
},
"claims":null
}
}
}
RP は, 検証データの経過時間, すなわち verification 要素で主張された検証プロセスが実行されてからの経過時間に関する要件も表現できる (MAY).
したがって, この仕様では新しいメンバー max_age を定義している.
max_age: OPTIONAL. 日付またはタイムスタンプを含む Claims にのみ適用可能な JSON 数値. 日付/タイムスタンプの値からリクエストの時点までの経過を許可する最大時間 (秒) を定義する. OP は, 日付値の最後の有効な秒から開始した経過時間の計算を行わなければならない. 以下は, データの検証プロセスが 63113852 秒以前であることを認めない Claims のリクエストの例である.
以下に例を示す:
{
"userinfo":{
"verified_claims":{
"verification":{
"date":{
"max_age":63113852
}
},
"claims":null
}
}
}
OP はこの要件を満たそうとしなければならない (SHOULD). ユーザーの検証データがリクエストされた max_age よりも古い場合, OP はユーザーにオンラインでの identity verification プロセスを介して, ユーザーの確認を更新しようとするかもしれない (MAY). 例えば 電子IDカードまたはビデオ識別アプローチを利用することによって.
OP が要件を満たすことができない場合 (essential とマークされている場合でも), RP に利用可能なデータを提供し, RP はデータの使用方法を決定できる. OP は, 必須 Claims として要求されたすべての Claims を返すことができない場合にエラーを返してはならない (MUST NOT).
以下のセクションでは verified_claims に関する例を示す.
最初と 2つ目のセクションでは, 一般的な identity assurance のケースの JSON snippets を示し, RP には End-User に関する実際の Claims と一緒に, 様々な検証方法による verification evidence が提供される.
3つ目のセクションでは, OP が RP に対して identity verification プロセスのエビデンスを提供する必要がない eIDAS 公認 eID システムの場合, どのようにこのオブジェクトのコンテンツが見えるかを説明している.
後続のセクションでは, 異なる経路で verified_claims Claim を使用し, 他の (unverified) Claims と組み合わせて使用する例を含む.
{
"verified_claims":{
"verification":{
"trust_framework":"de_aml",
"time":"2012-04-23T18:25:43.511+01",
"verification_process":"676q3636461467647q8498785747q487",
"evidence":[
{
"type":"id_document",
"method":"pipp",
"document":{
"type":"idcard",
"issuer":{
"name":"Stadt Augsburg",
"country":"DE"
},
"number":"53554554",
"date_of_issuance":"2012-04-23",
"date_of_expiry":"2022-04-22"
}
}
]
},
"claims":{
"given_name":"Max",
"family_name":"Meier",
"birthdate":"1956-01-28",
"place_of_birth":{
"country":"DE",
"locality":"Musterstadt"
},
"nationality":"DE",
"address":{
"locality":"Maxstadt",
"postal_code":"12344",
"country":"DE",
"street_address":"An der Sanddüne 22"
}
}
}
}
{
"verified_claims":{
"verification":{
"trust_framework":"de_aml",
"time":"2012-04-23T18:25:43.511+01",
"verification_process":"676q3636461467647q8498785747q487",
"evidence":[
{
"type":"id_document",
"method":"pipp",
"document":{
"document_type":"de_erp_replacement_idcard",
"issuer":{
"name":"Stadt Augsburg",
"country":"DE"
},
"number":"53554554",
"date_of_issuance":"2012-04-23",
"date_of_expiry":"2022-04-22"
}
},
{
"type":"utility_bill",
"provider":{
"name":"Stadtwerke Musterstadt",
"country":"DE",
"region":"Thüringen",
"street_address":"Energiestrasse 33"
},
"date":"2013-01-31"
}
]
},
"claims":{
"given_name":"Max",
"family_name":"Meier",
"birthdate":"1956-01-28",
"place_of_birth":{
"country":"DE",
"locality":"Musterstadt"
},
"nationality":"DE",
"address":{
"locality":"Maxstadt",
"postal_code":"12344",
"country":"DE",
"street_address":"An der Sanddüne 22"
}
}
}
}
{
"verified_claims":{
"verification":{
"trust_framework":"eidas_ial_substantial"
},
"claims":{
"given_name":"Max",
"family_name":"Meier",
"birthdate":"1956-01-28",
"place_of_birth":{
"country":"DE",
"locality":"Musterstadt"
},
"nationality":"DE",
"address":{
"locality":"Maxstadt",
"postal_code":"12344",
"country":"DE",
"street_address":"An der Sanddüne 22"
}
}
}
}
この例では, RP は scope パラメーターを email address を要求するために使用し, さらに verified Claims を要求するために claims パラメータを使用することを想定する.
scope 値は次の通り: scope=openid email
claims パラメータ値は次の通り:
{
"userinfo":{
"verified_claims":{
"claims":{
"given_name":null,
"family_name":null,
"birthdate":null
}
}
}
}
それぞれの UserInfo レスポンスは次の通り:
HTTP/1.1 200 OK
Content-Type: application/json
{
"iss":"https://server.example.com",
"sub":"248289761001",
"email":"janedoe@example.com",
"email_verified":true,
"verified_claims":{
"verification":{
"trust_framework":"de_aml",
"time":"2012-04-23T18:25:43.511+01",
"verification_process":"676q3636461467647q8498785747q487",
"evidence":[
{
"type":"id_document",
"method":"pipp",
"document":{
"type":"idcard",
"issuer":{
"name":"Stadt Augsburg",
"country":"DE"
},
"number":"53554554",
"date_of_issuance":"2012-04-23",
"date_of_expiry":"2022-04-22"
}
}
]
},
"claims":{
"given_name":"Max",
"family_name":"Meier",
"birthdate":"1956-01-28"
}
}
}
この場合, RP は claims パラメーターで End-User に関する他の Claims と一緒に verified Claims を要求し, ID Token (grant type code の場合は token endpoint から配信される) にレスポンスを割り当てる.
claims パラメータ値は次の通り:
{
"id_token":{
"email":null,
"preferred_username":null,
"picture":null,
"verified_claims":{
"claims":{
"given_name":null,
"family_name":null,
"birthdate":null
}
}
}
}
それぞれの ID Token は次の通り:
{
"iss":"https://server.example.com",
"sub":"24400320",
"aud":"s6BhdRkqt3",
"nonce":"n-0S6_WzA2Mj",
"exp":1311281970,
"iat":1311280970,
"auth_time":1311280969,
"acr":"urn:mace:incommon:iap:silver",
"email":"janedoe@example.com",
"preferred_username":"j.doe",
"picture":"http://example.com/janedoe/me.jpg",
"verified_claims":{
"verification":{
"trust_framework":"de_aml",
"time":"2012-04-23T18:25:43.511+01",
"verification_process":"676q3636461467647q8498785747q487",
"evidence":[
{
"type":"id_document",
"method":"pipp",
"document":{
"type":"idcard",
"issuer":{
"name":"Stadt Augsburg",
"country":"DE"
},
"number":"53554554",
"date_of_issuance":"2012-04-23",
"date_of_expiry":"2022-04-22"
}
}
]
},
"claims":{
"given_name":"Max",
"family_name":"Meier",
"birthdate":"1956-01-28"
}
}
}
Note: 改行は掲載上の都合による
HTTP/1.1 200 OK
Content-Type: application/json
{
"iss":"https://server.example.com",
"sub":"248289761001",
"email":"janedoe@example.com",
"email_verified":true,
"_claim_names":{
"verified_claims":"src1"
},
"_claim_sources":{
"src1":{
"JWT":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3NlcnZlci5vdGh
lcm9wLmNvbSIsInZlcmlmaWVkX2NsYWltcyI6eyJ2ZXJpZmljYXRpb24iOnsidHJ1c3RfZnJhbWV3b3
JrIjoiZWlkYXNfaWFsX3N1YnN0YW50aWFsIn0sImNsYWltcyI6eyJnaXZlbl9uYW1lIjoiTWF4IiwiZ
mFtaWx5X25hbWUiOiJNZWllciIsImJpcnRoZGF0ZSI6IjE5NTYtMDEtMjgifX19.M8tTKxzj5LBgqGj
UAzFooEiCPJ4wcZVQDrnW5_ooAG4"
}
}
}
HTTP/1.1 200 OK
Content-Type: application/json
{
"iss":"https://server.example.com",
"sub":"248289761001",
"email":"janedoe@example.com",
"email_verified":true,
"_claim_names":{
"verified_claims":"src1"
},
"_claim_sources":{
"src1":{
"endpoint":"https://server.yetanotherop.com/claim_source",
"access_token":"ksj3n283dkeafb76cdef"
}
}
}
OP は 以下の新しい属性を利用して openid-configuration (see [OpenID-Discovery]) で verified Claims に関する機能を通知する.
verified_claims_supported: verified_claims をサポートするか, つまり OpenID Connect for Identity Assurance extension のサポートを示す Boolean 値.
trust_frameworks_supported サポートする全ての trust frameworks を含む JSON 配列.
evidence_supported OP が利用する全ての identity evidence の種類を含む JSON 配列.
id_documents_supported OP が identity verification に利用しているすべての identity documents を含む JSON 配列.
id_documents_verification_methods_supported Section 4.1 に定義される OP がサポートする id document verification method を含む JSON配列.
claims_in_verified_claims_supported verified_claims 内でサポートされる全ての claims を含む JSON 配列
以下に openid-configuration の snippet の例を示す.
{
...
"verified_claims_supported":true,
"trust_frameworks_supported":[
"nist_800_63A_ial_2",
"nist_800_63A_ial_3"
],
"evidence_supported":[
"id_document",
"utility_bill",
"qes"
]
"id_documents_supported":[
"idcard",
"passport",
"driving_permit"
]
"id_documents_verification_methods_supported":[
"pipp",
"sripp",
"eid"
]
"claims_in_verified_claims_supported":[
"given_name",
"family_name",
"birthdate",
"place_of_birth",
"nationality",
"address"
],
...
}
OP は claims パラメーターをサポートし, claims_parameter_supported 要素を利用して openid-configuration でこれを公開しなければならない (MUST).
この仕様では, RP が要求しているユーザーデータの移転目的の説明を可能にする purpose リクエストパラメーターを導入する.
purpose OPTIONAL. OP から特定のユーザーデータを取得する目的を説明する文字列. purpose は 3 文字未満か 300 文字以上となってはならない (MUST NOT). もしこのルールに違反した場合, authentication request は失敗し, OP は invalid_request エラーを RP にに返さなければならない (MUST).
移転されるデータの利用目的や承認しようとしている認可内容をユーザーに明示するため, OP は各同意画面にこの purpose を表示しなければならない (MUST).
一貫性のある UX を確保するために, RP は特定の言語で purpose を送信し, ui_locales パラメーターを使用して同じ言語を使用するよう OP に要求するかもしれない (MAY).
purpose パラメーターがリクエストに存在しない場合, OP は RP ごとに事前設定された値を表示できる (MAY).
注: インジェクション攻撃を防ぐために, OP はユーザーインターフェイスに表示される前にテキストを適切にエスケープしなければならない (MUST). OP は, RP によって提供された URL デコードされた purpose テキスト中に特殊文字を予期しなければならない (MUST). OP は, purpose テキスト内の特殊文字を使用して, OP の Web インターフェイスにコードをインジェクト (例: クロスサイトスクリプティング, 改ざんなど) 出来ないようにしなければならない (MUST). OP は適切なエスケープを適用しなければならない (MUST). OP は, この目的のために purpose テキストから文字を削除してはならない (SHALL NOT).
OP and RP MUST establish a legal basis before exchanging any personally identifiable information. It can be established upfront or in the course of the OpenID process.
The integrity and authenticity of the issued assertions MUST be ensured in order to prevent identity spoofing. The Claims source MUST therefore cryptographically sign all assertions.
The confidentiality of all user data exchanged between the protocol parties MUST be ensured using suitable methods at transport or application layer.
This section defines trust framework identifiers for use with this specification.
| Identifier | Definition |
|---|---|
| de_aml | The OP verifies and maintains user identities in conforms with the German Anti-Money Laundering Law. |
| eidas_ial_substantial | The OP is able to attest user identities in accordance with the EU regulation No 910/2014 (eIDAS) at the identitfication assurance level "Substantial". |
| eidas_ial_high | The OP is able to attest user identities in accordance with the EU regulation No 910/2014 (eIDAS) at the identitfication assurance level "High". |
| nist_800_63A_ial_2 | The OP is able to attest user identities in accordance with the NIST Special Publication 800-63A at the Identity Assurance Level 2. |
| nist_800_63A_ial_3 | The OP is able to attest user identities in accordance with the NIST Special Publication 800-63A at the Identity Assurance Level 3. |
| jp_aml | The OP verifies and maintains user identities in conforms with the Japanese Act on Prevention of Transfer of Criminal Proceeds. |
| jp_mpiupa | The OP verifies and maintains user identities in conformance with the Japanese Act for Identification, etc. by Mobile Voice Communications Carriers of Their Subscribers, etc. and for Prevention of Improper Use of Mobile Voice Communications Services. |
This section defines identity document identifiers for use with this specification.
| Identifier | Definition |
|---|---|
| idcard | An identity document issued by a country's government for the purpose of identifying a citizen. |
| passport | A passport is a travel document, usually issued by a country's government, that certifies the identity and nationality of its holder primarily for the purpose of international travel.[OxfordPassport] |
| driving_permit | Official document permitting an individual to operate motorized vehicles. In the absence of a formal identity document, a driver's license may be accepted in many countries for identity verification. |
| de_idcard_foreigners | ID Card issued by the German government to foreign nationals. |
| de_emergency_idcard | ID Card issued by the German government to foreign nationals as passports replacement |
| de_erp | Electronic Resident Permit issued by the German government to foreign nationals |
| de_erp_replacement_idcard | Electronic Resident Permit issued by the German government to foreign nationals as replacement for another identity document |
| de_idcard_refugees | ID Card issued by the German government to refugees as passports replacement |
| de_idcard_apatrids | ID Card issued by the German government to apatrids as passports replacement |
| de_certificate_of_suspension_of_deportation | identity document issued to refugees in case of suspension of deportation that are marked as "id card replacement" |
| de_permission_to_reside | permission to reside issued by the German governed to foreign nationals appliying for asylum |
| de_replacement_idcard | ID Card replacement document issued by the German government to foreign nationals (see Act on the Residence, Economic Activity and Integration of Foreigners in the Federal Territory, Residence Act, Appendix D1 ID Card replacement according to § 48 Abs. 2 i.V.m. § 78a Abs. 4) |
| jp_drivers_license | Japanese drivers license |
| jp_residency_card_for_foreigner | Japanese residence card for foreigners. |
| jp_individual_number_card | Japanese national id card. |
| jp_permanent_residency_card_for_foreigner | Japanese special residency card for foreigners to permit permanently resident. |
| jp_health_insurance_card | Japanese health and insurance card. |
| jp_residency_card | Japanese residency card |
This section defines verification method identifiers for use with this specification.
| Identifier | Definition |
|---|---|
| pipp | Physical In-Person Proofing |
| sripp | Supervised remote In-Person Proofing |
| eid | Online verification of an electronic ID card |
This section contains the JSON Schema of assertions containing the verified_claims claim.
{
"$schema": "http://json-schema.org/draft-07/schema#",
"definitions":{
"qes":{
"type":"object",
"properties":{
"type":{
"type":"string",
"enum":[
"qes"
]
},
"issuer":{
"type":"string"
},
"serial_number":{
"type":"string"
},
"created_at":{
"type":"string",
"format":"date"
}
},
"required": ["type","issuer","serial_number","issued_at"]
},
"utility_bill":{
"type":"object",
"properties":{
"type":{
"type":"string",
"enum":[
"utility_bill"
]
},
"provider":{
"type":"object",
"properties":{
"name":{
"type":"string"
},
"country":{
"type":"string"
},
"region":{
"type":"string"
},
"street_address":{
"type":"string"
}
}
},
"date":{
"type":"string"
}
},
"required": ["type","provider","date"]
},
"id_document":{
"type":"object",
"properties":{
"type":{
"type":"string",
"enum":[
"id_document"
]
},
"method":{
"type":"string",
"enum":["pipp","sripp","eid"]
},
"verifier":{
"type":"object",
"properties":{
"organization":{
"type":"string"
},
"txn":{
"type":"string"
}
}
},
"time":{
"type":"string",
"format":"time"
},
"document":{
"type":"object",
"properties":{
"type":{
"type":"string",
"enum":[
"idcard",
"passport",
"driving_permit",
"de_idcard_foreigners",
"de_emergency_idcard",
"de_erp",
"de_erp_replacement_idcard",
"de_idcard_refugees",
"de_idcard_apatrids",
"de_certificate_of_suspension_of_deportation",
"de_permission_to_reside",
"de_replacement_idcard",
"jp_drivers_license",
"jp_residency_card_for_foreigner",
"jp_individual_number_card",
"jp_permanent_residency_card_for_foreigner",
"jp_health_insurance_card",
"jp_residency_card"
]
},
"number":{
"type":"string"
},
"issuer":{
"type":"object",
"properties":{
"name":{
"type":"string"
},
"country":{
"type":"string"
}
}
},
"date_of_issuance":{
"type":"string",
"format":"date"
},
"date_of_expiry":{
"type":"string",
"format":"date"
}
}
}
},
"required":[
"type",
"method",
"document"
]
}
},
"type":"object",
"properties":{
"verified_claims":{
"type":"object",
"properties":{
"verification":{
"type":"object",
"properties":{
"trust_framework":{
"type":"string",
"enum":[
"de_aml",
"eidas_ial_substantial",
"eidas_ial_hig",
"nist_800_63A_ial_2",
"nist_800_63A_ial_3",
"jp_aml",
"jp_mpiupa"
]
},
"time":{
"type":"string",
"format":"time"
},
"verification_process":{
"type":"string"
},
"evidence":{
"type":"array",
"minItems": 1,
"items":{
"oneOf":[
{
"$ref":"#/definitions/id_document"
},
{
"$ref":"#/definitions/utility_bill"
},
{
"$ref":"#/definitions/qes"
}
]
}
}
},
"required":["trust_framework"],
"additionalProperties": false
},
"claims":{
"type":"object",
"minProperties": 1
}
},
"required":["verification","claims"],
"additionalProperties": false
},
"txn": {"type": "string"}
},
"required":["verified_claims"]
}
| [ICAO-Doc9303] | ORGANIZATION, I. C. A., "Machine Readable Travel Documents, Seventh Edition, 2015, Part 3: Specifications Common to all MRTDs", 2015. |
| [ISO3166-1] | Standardization, I. O. F., "ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 2013. |
| [ISO3166-3] | Standardization, I. O. F., "ISO 3166-1:2013. Codes for the representation of names of countries and their subdivisions -- Part 3: Code for formerly used names of countries", 2013. |
| [OpenID] | Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", Nov 2014. |
| [OpenID-Discovery] | Sakimura, N., Bradley, J., de Medeiros, B. and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 1", Nov 2014. |
| [RFC8417] | Hunt, P., Jones, M., Denniss, W. and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018. |
| [eIDAS] | European Parliament, "REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC", July 2014. |
| [I-D.ietf-oauth-jwt-introspection-response] | Lodderstedt, T. and V. Dzhuvinov, "JWT Response for OAuth Token Introspection", Internet-Draft draft-ietf-oauth-jwt-introspection-response-08, September 2019. |
| [NIST-SP-800-63a] | Grassi, P. A., Fentony, James., Lefkovitz, Naomi., Danker, Jamie., Choong, Yee-Yin., Greene, Kristen. and Mary. Theofanos, "NIST Special Publication 800-63A, Digital Identity Guidelines, Enrollment and Identity Proofing Requirements", June 2017. |
| [OxfordPassport] | Cane, P. and Mary. Conaghan, "The New Oxford Companion to Law. ISBN 9780199290543.", 2008. |
| [RFC7662] | Richer, J., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015. |
| [oidfj] | OpenIDファウンデーションジャパン, "OpenIDファウンデーションジャパン" |
| [oidfj-github] | OpenIDファウンデーションジャパン, "Githubレポジトリー" |
| [oidfj-kycwg] | OpenIDファウンデーションジャパン, "KYCワーキンググループ" |
| [oidfj-trans] | OpenIDファウンデーションジャパン, "翻訳・教育ワーキンググループ" |
The following people at yes.com and partner companies contributed to the concept described in the initial contribution to this specification: Karsten Buch, Lukas Stiebig, Sven Manz, Waldemar Zimpfer, Willi Wiedergold, Fabian Hoffmann, Daniel Keijsers, Ralf Wagner, Sebastian Ebling, Peter Eisenhofer.
I would like to thank Sebastian Ebling, Marcos Sanz, Tom Jones, Mike Pegman, Michael B. Jones, and Jeff Lombardo for their valuable feedback that helped to evolve this specification.
Copyright (c) 2019 The OpenID Foundation.
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
[[ To be removed from the final specification ]]
-07
-06
-05
-04
-03
-02
-01
-00 (WG document)
本仕様の翻訳は, OpenIDファウンデーションジャパン [oidfj] KYCワーキンググループ[oidfj-kycwg], 翻訳・教育ワーキンググループ [oidfj-trans] を主体として, 有志のメンバーによって行われました. 質問や修正依頼などについては, Githubレポジトリー [oidfj-github]にご連絡ください.