openid-connect-4-identity-assurance-1_0 October 2024
Lodderstedt, et al. Standards Track [Page]
Workgroup:
eKYC-IDA
Published:
Authors:
T. Lodderstedt
sprind.org
D. Fett
Authlete
M. Haine
Considrd.Consulting Ltd
A. Pulido
Santander
K. Lehmann
1&1 Mail & Media Development & Technology GmbH
K. Koiwai
KDDI Corporation

OpenID Connect for Identity Assurance 1.0

Abstract

このドキュメントは，アクセスコントロール，資格決定やさらなる検証プロセスへの入力のための Claim または検証プロセス に関する，特定の検証レベル及び/または追加のメタデータを持つエンドユーザーに関する検証済みクレームを Relying Party に提供するための OpenID Connect の拡張機能を定義する．

Foreword

The OpenID Foundation (OIDF) promotes, protects, and nurtures the OpenID community and technologies. As a non-profit international standardizing body, it is comprised by over 160 participating entities (workgroup participant). The work of preparing implementer drafts and final international standards is carried out through OIDF workgroups in accordance with the OpenID Process. Participants interested in a subject for which a workgroup has been established have the right to be represented in that workgroup. International organizations, governmental and non-governmental, in liaison with OIDF, also take part in the work. OIDF collaborates closely with other standardizing bodies in the related fields.

Final drafts adopted by the Workgroup through consensus are circulated publicly for the public review for 60 days and for the OIDF members for voting. Publication as an OIDF Standard requires approval by at least 50% of the members casting a vote. There is a possibility that some of the elements of this document may be subject to patent rights. OIDF shall not be held responsible for identifying any or all such patent rights.

Introduction

OpenID Connect の本拡張機能は，Relying Party が追加の保証メタデータを使用してアイデンティティ情報を要求および受信する方法を標準化する．この仕様は，たとえば，マネーロンダリング防止法や健康データへのアクセスのような規制要件への準拠，リスクの軽減，不正防止のような，強力な保証を必要とするユースケースを可能にすることを目的としている．

そのようなユースケースでは, 依拠当事者 (RP) は, OpenID プロバイダー (OP) が伝達するエンドユーザーに関する Claim の信頼性または assurance level を，その検証に利用したプロセス関連情報やエビデンスと一緒に，知る必要がある.

OpenID Connect 仕様 [OpenID] の Section 2 で定義されている acr Claim は, OpenID Connect トランザクションで実行される認証に関する情報を証明するのに適している. しかし, identity assurance には異なる表現が必要である. 認証は OpenID Connect トランザクションの一面である一方, 保証と関連する検証の詳細は，特定の Claim または Claim のグループに対するプロパティである．それらは通常, OpenID Connect トランザクションの結果として RP に伝えられるようになる.

たとえば, 通常 OP が電子メールアドレスに与えることができる保証は「自己表明」または「検証済み」である. 対照的にエンドユーザーの姓は, OP オペレーターの訓練を受けた従業員に ID カードを提示することにより, それぞれのマネーロンダリング防止法に従って検証された可能性がある.

Identity assurance には, エンドユーザーに関する各 Claim とともに保証データを伝達する方法が必要である. このドキュメントは, RP がエンドユーザーに関する検証済み Claim を 保証データとともに要求し, OP がこれらの検証済み Claim と付随する保証データを表すために利用する適切な表現とメカニズムを定義する.

Warning

This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Notational conventions

The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.

▲

Table of Contents

1. Scope

本ドキュメントは，Relying Party がエンドユーザーに関する1つ以上の検証済み Claim を要求できるようにし，OpenID Provider が Relying Party に検証済み Claim を提供できるようにするための技術的メカニズムの定義である．("ツール")

法的側面(責任を含む)，トラストフレームワーク，商取引契約など，identity assurance の完全なソリューションを展開するために必要な追加の側面は範囲外である．本ドキュメントに基づくテクニカルソリューションをそれぞれの定義で補完するのは，個別の展開次第である．("ルール")

Note: そのような側面は範囲外であるが，仕様の目的は，世界中の管轄区域における異なる法律および商業的要件を満たすのに十分な柔軟性を備えたテクニカルメカニズムの実装を可能にすることである．従って，そのような要件は本ドキュメントで例として検討する．

2. Normative references

Normative References については Section 13 参照．

3. Terms and definitions

このドキュメントでは，以下の用語と定義を適用する．

3.1. claim

Entity に関する情報の部分集合.

3.2. identity proofing

エンドユーザーが OP または claim provider に自分自身を確実に識別できるエビデンスを提供し，それによって OpenID Connect provider (OP) または claim provider が有用な assurance level でその識別をアサート出来るようにするプロセス

3.3. identity verification

エンドユーザーの identity を確認するために，OP または claim provider が実施するプロセス

3.4. identity assurance

OP または claim provider が, RP に対してある一定の確からしさをもって特定のエンドユーザーの identity データを主張するプロセスで，通常は assurance level で表される. 法的要件に応じて, OP は identity verification プロセスのエビデンスを RP に提供するよう要求される場合もある.

3.5. verified claim

特定のエンドユーザーアカウントへの binding が identity verification プロセスの過程で検証されたエンドユーザー (通常は自然人) に関する claim

3.6. claim provider

エンティティに関する claim 情報を提供できるサーバー; OpenID Connect Core の "claims provider" と同義.

4. Requirements

RP は，必要最小限のデータセットの要求 (data minimization) と，このデータ，エビデンスおよび OP で採用されている identity verification プロセスに関する要件を表現できる．

この拡張機能は、eIDAS などの identity assurance に関連する特定の規制の下で動作する OP はもちろん，そのような規制なしで動作する他の OP でも使用できる．

適切な規制の下で運用されている OP は，明確に定義された責任を伴う明確に定義されたルールに従って運用することが承認されているため，追加のエビデンスを提供する必要なしに identity data を保証できると想定されている．例えば eIDAS の場合，ピアレビューは eIDAS コンプライアンスを保証し，それぞれの加盟国は、通知された eID システムによって主張された identity に対する責任を負う．

そのような明確な条件下で動作していない他のすべての OP は，RP が独自のリスクアセスメントを行い，OP から入手したデータを他の法律にマッピングできるように，identity evidence に加えて identity verification プロセスに関する data の提供要求を受け取るかもしれない． 例えば，もし OP がマネーロンダリング防止法に従って identity data を検証及び維持する場合，RP は eHealth や前述の eIDAS のような異なる規制のコンテキストでそれぞれのアイデンティティ属性を利用することを選択できる．

本ドキュメントのコンセプトは，OP が identity assurance プロセスに関するメタデータとともに，identity data を提供できることである．このデータを評価し，それを独自の法的コンテキストにマッピングするのは RP の責任である．

技術的な観点から，これは本仕様は OP が信頼するトラストフレームワークに関する情報とともに Verified Claim を提供できるようにするだけでなく，identity verification process に関する情報の外部化もサポートすることを意味する．

本仕様で定義される表現は，いずれかの適切なチャネルを介してエンドユーザーに関する Verified Claim を RP に提供できる．OpenID Connect のコンテキストにおいて，Verified Claim はID Token または UserInfo レスポンスの一部として提供できる．OAuth Access Token または Token Introspection レスポンスで記述される形式を用いてリソースサーバーに Verified Claim を提供することもできる．

本拡張は，真に国際的で異なる管轄区域を跨いで identity assurance をサポートすることを意図している． 本拡張は従って，様々なトラストフレームワーク，identity エビデンスや保証プロセスをサポートするために拡張可能である．

実装者に可能な限りの柔軟性を与えるために, この拡張は既存の OpenID Connect の Claim および同じ OpenID Connect のアサーション(例えば, ID Token や UserInfo)内の他の拡張と組み合わせて使うことができる.

例えば，OpenID Connect [OpenID] は検証ステータスのないエンドユーザーの姓と名を表す Claim を定義している．これらの Claim は本拡張に従って表現される Verified Claim とともに同じ OpenID Connect のアサーションで使うことができる．

同じように，phone_number と email Claim の検証ステータスを RP に通知する既存 Claim も本拡張とともに使うことができる．

Verified Claim を表す場合でも，本拡張は可能かつ妥当であれば，既存の OpenID Connect の Claim を利用する．しかしながら，拡張は RP が未検証 Claim を Verified Claim として (誤って) 解釈できないようにする．

identity assurance に関する一部の管轄区域の要件を満たすために, OpenID Connect for IDA claims [OpenID4IDAClaims] 仕様では OpenID Connect [OpenID] 仕様で定義されている Claims に加えて，End-User のデータを伝達するための多数の Claims が定義されている．

5. Verified claims

5.1. Verified claims schema

基本的な考え方は verified_claims と呼ばれるコンテナ要素を使用し，RP に一連の Claim と，これらの Claim の検証に関連するそれぞれのメタデータ及び検証のエビデンスを提供することである．この方法は，検証されている claims が明確になり，RP が誤って検証されていない claims を 検証済み として処理するリスクが軽減される．

このドキュメントでは，保証された digital identity 属性と identity assurance メタデータを表現するスキーマの定義として [!@IDA-verified-claims] ドキュメントを使用する．

次の例では，トラストフレームワーク trust_framework_example に従って，OP が提供された Claim (given_name と family_name) を検証したことを RP に表明する:

{
  "verified_claims": {
    "verification": {
      "trust_framework": "trust_framework_example"
    },
    "claims": {
      "given_name": "Max",
      "family_name": "Meier"
    }
  }
}

このドキュメントは，RP が [IDA-verified-claims] で定義されたスキーマを利用することを要求する．JSON Schema には実装者がスキーマを拡張できる箇所があるが，定義されたスキーマから逸脱することはこのドキュメントの正しい使用方法ではない． (訳注: 当文書内の JSON Schema はあくまで利便性のためであり，仕様を完全再現した物ではないため，仮に JSON Schema 上は拡張可能であっても，拡張を行うことで当文章準拠と言えなくなる場合がある点に注意すること．)

5.2. Verified claims delivery

verified_claims 要素は OpenID Connect UserInfo レスポンス，及び/または ID Token に追加することができる．

以下は，Verified Claims を含む ID トークンのペイロードの例である:

{
  "iss": "https://server.example.com",
  "sub": "248289761",
  "aud": "https://rs.example.com/",
  "exp": 1544645174,
  "client_id": "s6BhdRkqt3_",
  "verified_claims": {
    "verification": {
      "trust_framework": "example"
    },
    "claims": {
      "given_name": "Max",
      "family_name": "Mustermann"
    }
  }
}

OP または Authorization Server (AS) は上記の assertions に集約または分散された verified_claims を含めることも出来る (詳細は Section 6 参照)．

5.3. Requesting end-user claims

Verified Claims は OpenID Connect specification [OpenID] の Section 5.5 に定義されている claims パラメータを利用することで, End-User について 個々の Claims のレベルで要求できる.

注: verified_claims をリクエストするために使用される機械可読な構文定義は [verified_claims_request.json] で JSON スキーマとして提供され，これを利用して claims リクエストパラメータを自動的に検証することができる．提供される JSON スキーマファイルは本ドキュメントの標準ではない実装であり，存在する矛盾は実装のバグか，解釈のいずれかである．

検証済み Claim を要求するには，verified_claims 要素を claims パラメータの userinfo または id_token 要素に追加する．

verified_claims にはネストされた claims 要素の中に End-User についての有効な Claims が含まれるため, syntax は次のようにネストされた要素の式を含むように拡張される，verified_claims 要素は claims 要素を含み，必要な Claims がキーとして含まれる．各 claim の値は null (デフォルト), または object のいずれかである．Object には [OpenID] にて定義される value または values，及び/または以下で説明する essential キーを使用する制限を含めてもよい (MAY)．以下に例を示す.

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

claims パラメータを使用すると, RP はそのユースケースに必要な End-User に関する指定した Claims を要求できるようになる. これにより RP はユースケースに必要な claims のみを要求することで， データ最小化の要件を満たすことが出来る．

Note: OpenID Connect Core または本ドキュメントのメカニズムを使用して，sub-claims (例えば，address claim の country subclaim) を要求することは出来ない．

RP は OpenID Connect [OpenID] 仕様の Section 5.5.1 に定義された essential フィールドを使うことが出来る．次の例は，姓と名についてこれを示す．

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null
      },
      "claims": {
        "given_name": {
          "essential": true
        },
        "family_name": {
          "essential": true
        },
        "birthdate": null
      }
    }
  }
}

5.4. Requesting verification data

RP はエンドユーザーに関する Claim を要求するのと同じ方法で検証データを要求する．claims request parameter が利用されている場合，構文は Section 5.3 で指定したルールに基づき，verification 要素の構造にナビゲーションするためにそれらを拡張する．

次の例に示すように，verification 内の要素は，それぞれの要素を追加することによって要求される:

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null,
        "time": null
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

それは OP の準拠するトラストフレームワークとエンドユーザー Claim の検証日を要求する．

RP は OP が verification 要素に追加するデータを明示的に要求しなければならない (SHALL).

従って，RP はエビデンスを取得する場合，構造の1ステップ深くフィールドを設定しなければならない (SHALL)．evidence 配列の1つ以上のエントリは，result 配列のすべてのエントリのフィルタ基準とテンプレートとして使用される．次の例は，document タイプのみのエビデンスを要求するリクエストを示す．

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null,
        "time": null,
        "evidence": [
          {
            "type": {
              "value": "document"
            },
            "method": null,
            "document_details": {
              "type": null
            }
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

この例では OP に対して，evidence 配列メンバーごとに，それぞれの method と document 要素 (ドキュメントタイプに関するデータを含む) を，結果の verified_claims Claim に含むように要求している．

evidence 配列の単一エントリは，特定の evidence タイプの要素に対するフィルターを表す．従って，RP は適切な value サブ要素値を含む type フィールドを含めることによって，このタイプを指定しなければならない (SHALL)．values サブ要素を evidence/type フィールドに使用してはならない (SHALL NOT)．

evidence に複数のエントリが存在する場合，これらのフィルターは論理和によって紐付けられる．

check_details は evidence に適用されるプロセスの配列である．RP は1つ以上のサブ要素に特定の値を要求することで check_details をフィルタリング出来る．同じサブ要素に複数のエントリがある場合，これはそれらの間の論理 OR として機能する．

assurance_details は evidence と check_details がどのように trust_framework の要件を満たしているかを示す配列である．RP はこの情報を知る必要がある場合のみ要求することが望ましい (SHOULD)．assurance_details が RP によって要求された場合，OP は assurance_details 要素と，それが持つ全てのサブ要素を一緒に返さなければならない（SHALL）．RP が evidence と check_methods のタイプをフィルタしたい場合，それらのメソッドを使用しなければならない (SHALL)．例えば，assurance_type を要求しても，フィルタリング効果はないほうがよい (SHOULD)．

RP は document要素内の特定のデータの存在を要求することも出来る．これも上記で使用した構文規則に従う:

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null,
        "time": null,
        "evidence": [
          {
            "type": {
              "value": "document"
            },
            "method": null,
            "document_details": {
              "type": null,
              "issuer": {
                "country": null,
                "name": null
              },
              "document_number": null,
              "date_of_issuance": null
            }
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

5.5. Defining further constraints on verification data

5.5.1. Value/values

RP は value または values フィールドと evidence/type 要素を利用することで，trust_framework, evidence/method, evidence/check_details, 及び evidence/document/type 要素の value フィールドで利用可能な値を制限出来る．

注: evidence/type の制限の使用例は，以前のセクションで示した．

次の例は，RP がトラストフレームワーク gold または silver のいずれかに準拠した Claims をリクエストする方法を示す．

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": {
          "values": [
            "gold",
            "silver"
          ]
        }
      },
      "claims": {
        "given_name": null,
        "family_name": null
      }
    }
  }
}

次の例は，RP がドイツのマネーロンダリング防止法 (トラストフレームワーク de_aml) に基づき，idcard または passport を利用して銀行の窓口にて対面で識別された (物理的な身元確認 - pipp 手法) エンドユーザーに限定した証明の取得を希望していることを示す．

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": {
          "value": "de_aml"
        },
        "evidence": [
          {
            "type": {
              "value": "document"
            },
            "method": {
              "value": "pipp"
            },
            "document": {
              "type": {
                "values": [
                  "idcard",
                  "passport"
                ]
              }
            }
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

OP は可能な値のクエリ制約の一部または全部を無視してはならず (SHALL NOT)，これらの制約に一致しない利用可能な検証済み/検証データを提供してはならない (SHALL NOT)．

5.5.2. Max_age

RP は特定のエビデンスタイプの発行/失効からの経過時間や，verification 要素でアサートされた検証プロセスが行われてからの経過時間のような，特定のデータの経過時間に関する要件を表現することもできる．OpenID Connect 仕様 [OpenID] の Section 5.5.1 では新しい特別なクエリメンバーを定義できるクエリ構文を定義している．このドキュメントでは，日付またはタイムスタンプを含む要素 (例えば，document タイプのエビデンスの time，date_of_issuance 及び date_of_expiry 要素) の取り得る値に適用される新しいメンバー max_age を導入する．

max_age: OPTIONAL. 日付またはタイムスタンプを含む Claims にのみ適用可能な JSON number 値．日付/タイムスタンプの値からリクエストの時点までに許容される最大経過時間(秒)を定義する．OP は日付値の最後の有効な秒から開始して経過時間を計算することが望ましい (SHOULD)．

次の例は，データの検証プロセスが 63113852 秒より古いことが許容されていない Claims の要求例である:

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": {
          "value": "jp_aml"
        },
        "time": {
          "max_age": 63113852
        }
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

OP はこの要件を満たすよう務めることが望ましい (SHOULD)．もし End-User の検証データが要求された max_age より古い場合，OP は例えば electronic ID card や video identification approach を利用するなど，オンラインの identity verification process を通じて End-User のverification を送信することで，End-User の verification の更新を試みることが出来る．

5.6. Requesting claims sets with different verification requirements

異なった Claim Set に対して，異なったトラストフレームワーク， assurance レベルや方法を要求することが出来る．これは RP が単一オブジェクトを渡すのではなく，verified_claims オブジェクトの配列を送信することを要求する．

次の例はこの機能の利用例である．

{
  "userinfo": {
    "verified_claims": [
      {
        "verification": {
          "trust_framework": {
            "value": "eidas"
          },
          "assurance_level": {
            "value": "high"
          }
        },
        "claims": {
          "given_name": null,
          "family_name": null
        }
      },
      {
        "verification": {
          "trust_framework": {
            "value": "eidas"
          },
          "assurance_level":{
            "values":[
              "high",
              "substantial"
            ]
          }
        },
        "claims": {
          "birthdate": null
        }
      }
    ]
  }
}

RP が上記に従って複数の検証を要求すると，OP は配列内の各要素を個別に処理する．OP は要件を満たすことの出来るすべての verified_claims 要求要素に対して，verified_claims レスポンス要素を提供する．これは複数の verified_claims 要素に同じエンドユーザーの claim が含まれている場合，OP は満たせるだけ多くの verfied claims レスポンスオブジェクトで claim を配信することも意味する．例えば，OP が使用するトラストフレームワークが要求された複数のトラストフレームワークと互換性がある場合，それらのそれぞれに verified_claims 要素が提供される．

RP は values 要素を利用して，リクエスト中の複数の verified_claims claims を複数の trust_framework 及び/または assurance_level 値と組み合わせることが出来る．このケースにおいて，values を処理するための上記のルールが特定の verified_claims リクエストオブジェクトに適用される．

{
  "userinfo": {
    "verified_claims": [
      {
        "verification": {
          "trust_framework": {
            "value": "gold"
          },
          "evidence": [
            {
              "type": {
                "value": "document"
              }
            }
          ]
        },
        "claims": {
          "given_name": null,
          "family_name": null
        }
      },
      {
        "verification": {
          "trust_framework": {
            "values": [
              "silver",
              "bronze"
            ]
          },
          "evidence": [
            {
              "type": {
                "value": "electronic_record"
              }
            }
          ]
        },
        "claims": {
          "given_name": null,
          "family_name": null
        }
      }
    ]
  }
}

上記の例では，RP は エビデンスタイプ document を持つトラストフレームワーク gold もしくは エビデンスタイプ electronic_record を持つトラストフレームワーク silver または bronze に基づいて，姓と名を要求する．

5.7. Returning less data than requested

5.7.1. General requirements

[OpenID] の section 3.3.3.6 に記載されているように，"OP は authorization endpoint からエンドユーザーに関する claim を少なく返すことを選択できる (MAY)"．このドキュメントではその規定を変更しない．OP は [OpenID4IDAClaims] で定義された verified_claims JSON スキーマに準拠している限り，任意の verified_claims の verification 要素のサブセットを返すことも出来る (MAY)．

例えばデータが利用できない，または RP の要件に一致しないなど，OPs は RP に要求されたデータを配信出来ない場合がある．これらのケースをハンドリングするルールを以下で説明する．

このドキュメントの拡張は追加のルール定義やルールの上書きが出来る，例えば

  • スキーム固有のチェックに応じて claims の使用を許可または禁止する，
  • データが利用できない，または基準に一致しない場合，OP の動作に対する RP のよりきめ細かい制御を有効にする，または
  • 要求を満たすことが出来ない場合に，トランザクションを中断する (エラーコードを返す)．

Important: 以下で説明する振舞いは，essential ([OpenID] の section 5.5.1 で定義) の使用とは独立している．

5.7.2. Unavailable data

OP が特定の claim に関するデータを持っていない場合，それぞれの claim を理解/サポートしていない場合，OPs は対応する ID Token または UserInfo レスポンスからそれぞれの claim を省略しなければならない (SHALL)．

5.7.3. Non-consented data

エンドユーザーの同意に基づいて共有する特定のデータを決定する場合，エンドユーザーは要求されたデータのサブセットのみを開示することを選択できる (MAY)．この場合，OP は共有についてエンドユーザーの同意を得ていない，対応する ID Token または UserInfo レスポンスデータを省略しなければならない (SHALL)．

または，エンドユーザーの同意に基づいて共有する特定のデータを決定する場合，エンドユーザーは要求されたデータを何も開示しないことを選択できる (MAY)．この場合，[OpenID] の section 3.1.2.6 で定義された 標準の OpenID Connect エラーレスポンスロジックが適用される．

5.7.4. Data not matching requirements

利用可能なデータが value, values, または max_age で表現された RP の要件を満たさない場合，以下のロジックが適用される:

  • それぞれの要件が verified_claims/verification 内の claim に対して表現された場合，OP は verified_claims 要素全体を省略しなければならない (SHALL)．
  • それ以外の場合，OP は 該当する各 claim をレスポンスから省略しなければならない (SHALL)．

いずれの場合も，OP はRP に対してエラーを返してならない (SHALL)．

5.7.5. Omitting elements

上記のルールに従って有効なレスポンスの要件である要素を省略する場合，OP はその親要素も省略しなければならない (SHALL)．この OP はレスポンスが有効になるまでこのプロセスを繰り返さなければならない (SHALL)．

5.7.6. Error handling

OP でエラーに遭遇した場合，[OpenID] の section 3.1.2.6 で定義された 標準の OpenID Connect エラーレスポンスロジックが適用される．

5.8. Requesting sets of claims by scope

エンドユーザーに関する Verified claims は OpenID Connect 仕様 [OpenID] の section 5.4 で定義された scope パラメータを利用して事前定義されたセットの一部として要求することが出来る．

このアプローチを使用する場合，scope 値に関連付けられた claims は OP で管理的に定義される．OP 構成と RP の request parameters によって，claim が ID Token 経由または OpenID Connect 仕様 [OpenID] の section 5.3.2 で定義された UserInfo endpoint 経由で返却されるかが決定する．

6. Aggregated and distributed claims

6.1. Aggregated and distributed claims assertions

分散クレームが使用される場合，分散された _claim_source サブ要素内の endpoint 要素の値である URL は，https URI スキームを使用しなければならず (SHALL)，返却される JWT はその他の URI スキーム経由でアクセス出来ることは望ましくない (SHOULD NOT)．

集約または分散クレームの場合，外部クレームソースによって提供されるすべてのアサーションは次を含まなければならない (SHALL):

  • 値 provided-claims+jwt を持つ typ ヘッダーパラメーター
  • Claim ソース を特定する iss Claim，
  • Claim ソース のコンテキストでエンドユーザーを識別する sub Claim, および
  • 1つ以上の verified_claims オブジェクトを含む verified_claims 要素．

アサーションが OpenID Connect ID Token と混同されないようにするため，アサーションは下記を含んではならない (SHALL NOT):

  • exp claim, または
  • aud claim.

集約または分散クレームオブジェクトの verified_claims 要素は，次のいずれかの形式でなければならない (SHALL):

  • 特定の Claim ソース ([OpenID] で定義) を参照する JSON 文字列
  • 様々な Claim ソースを参照する文字列の JSON 配列
  • 各オブジェクトの名前は，それぞれのクレームソースの名前である，verified_claims をリクエストするために定義された構文でフォーマットされたサブ要素で構成される JSON オブジェクト．すべてのこのような名前付きオブジェクトには，それぞれのクレームソースによって提供されるデータを表す claim と verification と呼ばれるサブオブジェクトが含まれる．これにより，これらのリクエストによって生じる余分な時間，コスト，データ衝突などを防ぐために，RP は分散クレームを実際にリクエストする前に先読みすることが可能になる．

注: あとの2つの形式は，verified_claims の特定のユースケースに対応するために OpenID Connect 仕様 [OpenID] の Section 5.6.2 で定義されている構文を拡張する．

以下は 集約 Claim としての 検証済み Claim を含むアサーションの例である

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "email": "janedoe@example.com",
  "email_verified": true,
  "_claim_names": {
    "verified_claims": "src1"
  },
  "_claim_sources": {
    "src1": {
      "JWT": "eyJhbGciOiJQUzI1NiIsImtpZCI6IjFlOWdkazciLCJ0eXAiOiJwcm92aWRlZC1jbGFpbXMrand0In0.eyJpc3MiOiJodHRwczovL3NlcnZlci5vdGhlcm9wLmNvbSIsInN1YiI6ImU4MTQ4NjAzLTg5MzQtNDI0NS04MjViLWMxMDhiOGI2Yjk0NSIsInZlcmlmaWVkX2NsYWltcyI6eyJ2ZXJpZmljYXRpb24iOnsidHJ1c3RfZnJhbWV3b3JrIjoiaWFsX2V4YW1wbGVfZ29sZCJ9LCJjbGFpbXMiOnsiZ2l2ZW5fbmFtZSI6Ik1heCIsImZhbWlseV9uYW1lIjoiTWVpZXIiLCJiaXJ0aGRhdGUiOiIxOTU2LTAxLTI4In19fQ.VAtHwi85ihW98uulbNOBCkyCyD4jeDrTeaMNdI3Wllks1z-LT8kyzN5Iz7Nu2HpMmmCKZpgY552O0fm_-Fr3Vls3BvmJsh1A524jh9VlsCL-1WezJ-DShjMUyP76_3Xbdl-iYHdWLjoQ5hFZQg6GLrLxOGlQXX9b-kxtQm3DV9nFJhOqMl_5_U8IU_A1LfypmRvXuD1Frw8ASS7OmyGOCkuFDOaV7Uu0BuZjYWiMC8Eem4M2A9RhuoLKDBYuVlwIFaHx-cuGcRJZWDg9K5DekIuLE73Iz1Cuh49HumkC9qGqkTV6EARSJeqFxPhjnZNkJY1e1P7Q7cgyT2HywjR6Tw"
    }
  }
}

及び，分散クレーム．

{
  "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"
    }
  }
}

次の例は，2つの異なる外部 Claim ソースからの verified_claims を含む ID トークンの例で，1つは集約 Claim，もう1つは分散 Claim である．

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "email": "janedoe@example.com",
  "email_verified": true,
  "_claim_names": {
    "verified_claims": [
      "src1",
      "src2"
    ]
  },
  "_claim_sources": {
    "src1": {
      "JWT": "eyJhbGciOiJQUzI1NiIsImtpZCI6IjFlOWdkazciLCJ0eXAiOiJwcm92aWRlZC1jbGFpbXMrand0In0.eyJpc3MiOiJodHRwczovL3NlcnZlci5vdGhlcm9wLmNvbSIsInN1YiI6ImU4MTQ4NjAzLTg5MzQtNDI0NS04MjViLWMxMDhiOGI2Yjk0NSIsInZlcmlmaWVkX2NsYWltcyI6eyJ2ZXJpZmljYXRpb24iOnsidHJ1c3RfZnJhbWV3b3JrIjoiaWFsX2V4YW1wbGVfZ29sZCJ9LCJjbGFpbXMiOnsiZ2l2ZW5fbmFtZSI6Ik1heCIsImZhbWlseV9uYW1lIjoiTWVpZXIiLCJiaXJ0aGRhdGUiOiIxOTU2LTAxLTI4In19fQ.FPYS2Xjz9y9qEOJhBe5nMfL2mTagLDxwISxjM6gv3zRUvU2YBK-GHI_byvK8h46ly1C90ie-X9gOp-DLvpURvyAlZTsvxNL8s0Hi3-SRZCs5huhiCZr5s4FJBG-l0PNrYOIZAHfeQtobJ7muDld3BytS628140V0CHgh_EM8UUjzQmN8NpDaR9HdH0tIeUFqIZEwBluctgwek9eomg3k10dj6NzBUQSSnpgGf_o6f_sYoIAkBhpgRursD5pHbPSOKTGE9cJ882BbHeido746XLxjEfrU5yQwfA0ggVk5I_e-wv-xVXfVGda4WySZfbkwS5PMCMgMJM9ZT_L1pci0yQ"
    },
    "src2": {
      "endpoint": "https://server.yetanotherop.com/claim_source",
      "access_token": "ksj3n283dkeafb76cdef"
    }
  }
}

次の例は，2つの異なる外部 Claim ソースからの verified_claims を含む ID トークンと，検証済み Claim のコンテンツに関する追加データを示す (先読み)．

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "email": "janedoe@example.com",
  "email_verified": true,
  "_claim_names": {
    "verified_claims": {
      "src1": {
        "verification": {
          "trust_framework": {
            "value": "trust_framework_example"
          }
        },
        "claims": {
          "given_name": null,
          "family_name": null
        }
      },
      "src2": {
        "verification": {
          "trust_framework": {
            "value": "grids_kyb"
          },
          "evidence": [
            {
              "type": {
                "value": "document"
              },
              "registry": {
                "country": {
                  "essential": true,
                  "value": "ES"
                }
              },
              "document": {
                "SKU": {
                  "value": "REX"
                }
              }
            }
          ]
        },
        "claims": {
          "given_name": null,
          "family_name": null,
          "email": null,
          "nationalities": null
        }
      }
    }
  },
  "_claim_sources": {
    "src1": {
      "JWT": "eyJraWQiOiJmMDgxZDI5OC1jNTgzLTQ3NDAtYWQ1NC02ZDUzMTljZjhiNWQiLCJhbGciOiJSUzI1NiJ9.ew0KICAgImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogICAic3ViIjogIjE0ODI4OTc2MiIsDQogICAidmVyaWZpZWRfY2xhaW1zIjogew0KICAgICJ2ZXJpZmljYXRpb24iOiB7DQogICAgICAidHJ1c3RfZnJhbWV3b3JrIjogInRydXN0X2ZyYW1ld29ya19leGFtcGxlIg0KICAgIH0sDQogICAgImNsYWltcyI6IHsNCiAgICAgICJnaXZlbl9uYW1lIjogIk1heCIsDQogICAgICAiZmFtaWx5X25hbWUiOiAiTWVpZXIiDQogICAgfQ0KICB9DQp9.jg_qxYfV0M2IU8On1iK9RBY0Cx9u3jRJ0Qzxe19Ol5VLoUTM7Uxbr3E0ZFCASHWpmz9d2g67XKGHQMppnJKX4SnEdphm6MqjnmZ9E0cirALrC016DX5geFy_0QFC8PAnCttcDgyVCyzCcDxUCaHBSRsrDwGjYe5AjgaDL8S-R72lFQHqch6uj9nhiFBtG24_0EsF6msssQ61WyqS6aju0F0PJms8danIfwc5lHyv-zKuDlY-0kw-fVn4274jY-VofElm4mhsrpo-YJhCKlz0O3CV0g9AW_60TQHCmhn6yoosaTbjlQqh5lREpqULz-MQKnD0wRmYLgBZXtzIhxb7ZA"
    },
    "src2": {
      "endpoint": "https://server.yetanotherop.com/claim_source",
      "access_token": "ksj3n283dkeafb76cdef"
    }
  }
}

Claim ソースは，信頼性の実証と否認防止を提供するために verified_claims を含むアサーションを署名することが望ましい (SHOULD)．

RP は署名されたアサーションの検証に使用されるキーマテリアルが，claim source の公開鍵を介しているかを判断することが望ましい (SHOULD)．これらのキーは openid-configuration メタデータドキュメント中の jwks_uri メタデータ値で利用可能な JSON web key set で利用できることが望ましい (SHOULD)．このドキュメントは特定の JWT の iss クレームを用いて検出できる．

OP は集約および分散 Claim を，それ自身が提供する verified_claims と組み合わせることが出来る (Appendix C.8 参照).

ID トークンや埋め込まれた集約 Claim のように verified_claims 要素が応答の複数の場所に含まれている場合，RP は 特定の verified_claims 要素のコンテキストとして Claim ソースを保持しなければならない (SHALL)．

注: 集約または分散 Claim を含む OP または AS によって提供されるアサーションには，同じエンドユーザー Claim の複数インスタンスを含むことが出来る．これらの様々なインスタンスを処理する方法を決定するのは RP 次第である．

6.2. Aggregated and distributed claims validation

クライアントは，依存する集約及び分散した verified_claims を以下の方法で検証しなければならない (SHALL):

  1. _claim_names と _claim_sources の両方がレスポンスに存在することを確認する．
  2. レスポンスの _claim_names メンバーに verified_claims 要素が存在することを確認する．
  3. verified_claims 要素に次のいずれの値が含まれていることを確認する: a. レスポンスの _claim_sources 要素内にキー名として存在する文字列． b. レスポンスの _claim_sources 要素内にキー名として存在する全てのメンバーを含む JSON 配列． c. レスポンスの _claim_sources 要素内にキー名として存在するすべての要素を含む JSON オブジェクトで，各要素は verified_claims を要求するために定義された構文でフォーマットされている．
  4. _claim_sources 要素が 1つ以上のサブ要素を持つ JSON 構造化オブジェクトであることを確認する．
  5. _claim_sources 要素のサブ要素が，レスポンスの_claim_names要素と一致する値を持つことを確認する．

verified_claims が分散クレームとして配信される場合，すなわち _claim_sources のサブ要素に endpoint クレームが含まれる場合, クライアントは次のことを行わなければならない (SHALL) :

  1. 分散された _claim_sources で定義された endpoint 要素が https URI スキームを使用していることを確認する．
  2. 分散された _claim_sources で定義された endpoint 要素から分散クレームオブジェクトを取得する．
  3. endpoint から返却されたオブジェクトが [RFC7519] に従った JWT であることを確認する．

verified_claims が集約クレームとして配信される場合，すなわち _claim_sources のサブ要素に JWT クレームが含まれる場合，クライアントは次のことを行わなければならない (SHALL) :

  1. JWT クレームの値が [RFC7519] に従って有効な JWT であることを確認する．

JWT が分散または集約メカニズムを介して配信されると，クライアントは次のことを行わなければならない (SHALL) :

  1. 返却された JWT の署名を検証する．
  2. JWT に typ, iss, sub, 及び verified_claims 要素が含まれること，及びそれらの値が null または空でないことを確認する．
  3. JWT に exp クレームまたは aud クレームが含まれていないことを確認する．
  4. JWT 中の typ ヘッダーパラメーターの値が provided-claims+jwt であることを確認する．

7. Requesting verified claims

OpenID Connect 仕様 [OpenID] の Section 5.5 で定義されている claims パラメータを利用することで，検証済み Claim と関連する検証データのリクエストを個々のデータ要素レベルで明示的にリクエストできる．

scope を使用して，OpenID Connect 仕様 [OpenID] の Section 5.4 で定義されている1つ以上の特定の事前定義された Claim セットを要求することもできる．

注: OP は，要求しなかったデータを RP に提供してはならない (SHALL NOT)．ただし，OP はその裁量によりレスポンスから Claim を省略してもよい (MAY)．

このセクションの authorize 呼び出しの例では，次のエンコードされていない claims request パラメータの例を使用する:

{
    "id_token": {
      "given_name": null,
      "verified_claims": {
        "verification": {
          "trust_framework": null
        },
        "claims": {
          "family_name": null
        }
      }
    }
  }

以下は，ユーザーエージェントから authorization server に対して，クライアントの authorization code flow 開始に対する HTTP 302 リダイレクトレスポンスとして送信される non-normative な例である (改行は掲載上の都合による):

  GET /authorize?
     response_type=code
     &scope=openid%20email
     &client_id=s6BhdRkqt3
     &state=af0ifjsldkj
     &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
     &claims=%7B%22id_token%22%3A%20%7B%22
     given_name%22%3A%20null%2C%22
     verified_claims%22%3A%20%7B%22
     verification%22%3A%20%7B%22
     trust_framework%22%3A%20null%7D%2C%22
     claims%22%3A%20%7B%22
     family_name%22%3A%20null%7D%7D%7D%7D HTTP/1.1
  Host: server.example.com

8. OP metadata

OP は openid-configuration ([OpenID-Discovery] 参照) において，次の新しい要素を使用して verified claims に関する能力を告知する:

trust_frameworks_supported: Required. サポートする全てのトラストフレームワークを含む JSON 配列．この配列は少なくとも1つ以上のメンバーを持たなければならない (SHALL)．

claims_in_verified_claims_supported: Required. verified_claims 内でサポートする全ての claims を含む JSON 配列．この配列内に現れない claim は verified_claims オブジェクト内で返却してはならない (SHALL NOT)．この配列は少なくとも1つ以上のメンバーを持たなければならない (SHALL)．

evidence_supported: 1つ以上のタイプのエビデンスがサポートされている場合，必須 (Required)． OP が使用する全ての identity evidence タイプを含む JSON 配列．この配列は少なくとも1つ以上のメンバーを持たなければならない (SHALL)．この配列のメンバーは，evidence 要素 ([IDA-verified-claims] の section 5.4.4 参照) で OP がサポートするエビデンスのタイプのみであることが望ましい（SHOULD）．

documents_supported: evidence_supported に "document" を含む場合に必須 (Required). OP が identity verification に使用する全ての identity document タイプを含む JSON 配列．この配列は少なくとも1つ以上のメンバーを持たなければならない (SHALL)．

documents_methods_supported: Optional. OP が "document" タイプ ([predefined_values_page] 参照) のエビデンスに対してサポートする検証方法を含む JSON 配列．この配列は少なくとも1つ以上のメンバーを持たなければならない (SHALL)．

documents_check_methods_supported: Optional. OP が "document" タイプ ([predefined_values_page] 参照) のエビデンスに対してサポートするチェック方法を含む JSON 配列．この配列は少なくとも1つ以上のメンバーを持たなければならない (SHALL)．

electronic_records_supported: evidence_supported に "electronic_record" を含む場合に必須 (Required). OP のサポートする全ての electronic record タイプ ([predefined_values_page] 参照) を含む JSON 配列．この配列は少なくとも1つ以上のメンバーを持たなければならない (SHALL)．

以下は openid-configuration スニペットの例である:

{
...
   "trust_frameworks_supported":[
     "nist_800_63A"
   ],
   "evidence_supported": [
      "document",
      "electronic_record",
      "vouch",
      "electronic_signature"
   ],
   "documents_supported": [
       "idcard",
       "passport",
       "driving_permit"
   ],
   "documents_methods_supported": [
       "pipp",
       "sripp",
       "eid"
   ],
   "electronic_records_supported": [
       "secure_mail"
   ],
   "claims_in_verified_claims_supported": [
      "given_name",
      "family_name",
      "birthdate",
      "place_of_birth",
      "nationalities",
      "address"
   ],
...
}

OP が OpenID Connect 仕様 [OpenID] の section 5.5 で定義される claims パラメータをサポートする場合，OP は claims_parameter_supported 要素を使用して OP メタデータでこれを告知しなければならない (SHALL)．

OP が verified_claims 内において OpenID Connect 仕様 [OpenID] の section 5.6.2 で定義される分散及び/または集約クレームタイプをサポートしている場合，OP は claim_types_supported 要素を使用して，そのメタデータでこれを告知しなければならない (SHALL)．

9. Privacy consideration

scopes の利用は定義済みのクレームセットを要求するための潜在的なショートカットであるが，scopes を利用すると RP に返却されるデータが厳密に必要な量より多くなり，データミニマイゼーションの目標が達成されないかもしれない．RP は必要なエンドユーザーの claim とメタデータのみを要求することが望ましい (SHOULD)．

タイムゾーンコンポーネントを含むタイムスタンプは，人物のロケーションを明らかにするかもしれない．人物のプライバシーを保護するため，verification element 中のタイムスタンプと時間を表す verified claims は，タイムゾーンが検証済みデータ内の同意された時間に関連する claim の重要な部分であるなど，タイムゾーンを含める特別な理由がない限り，協定世界時 (UTC) で表すことが望ましい (SHOULD)．

10. Security considerations

10.1. Security profile

このドキュメントはエンドユーザーのクレームと付随するメタデータを JSON オブジェクトと JSON Web Token で運ぶメカニズムにフォーカスしており，通常これは OpenID Connect プロトコル交換の一部として行われる．このような交換はセキュリティにセンシティブなユースケースで行われるため，実装者は次のことを行わなければならない (SHALL):

  • OpenID Connect の適切なセキュリティプロファイルをこのドキュメントと組み合わせること，また，
  • エンドユーザーが強力な認証方法を使用して認証されていることを確認すること．

複数のセキュリティプロファイルと新しいセキュリティプロファイルが開発中であるため，このドキュメントは特定のセキュリティプロファイルを定義または要求しない． 実装者はニーズに最適なセキュリティプロファイルを柔軟に選択できる． 実装者は [FAPI-1-SP] または [FAPI-2-SP] を検討することが望ましい．

実装者は，OpenID Foundation Certification Program (https://openid.net/certification/) のような，OpenID プロバイダーと Relying Party の両方がプロファイルのセキュリティと相互運用性の要件に準拠していることを確認できる certification program またはその他のリソースを持つセキュリティプロファイルを選択することが望ましい (SHOULD)．

受信側は identity spoofing を防ぐため，発行されたアサーションの整合性と信頼性を確保しなければならない (SHALL)．

受信側はトランスポートまたはアプリケーション層で適切な方法を使用し，プロトコル当事者間で交換される全てのエンドユーザーデータの機密性を確保しなければならない (SHALL)．

10.2. End-user authentication

エンドユーザーのセキュアな識別は，OP での identity verification だけでなく，OP でのユーザー認証の強度にも依存する．強力な識別と弱い認証を組み合わせると，セキュリティの間違った印象と同時に攻撃の余地を与える．例えば OP が単純な PIN ログインを使用する場合，攻撃者は他のユーザーの PIN を推測し，高い identity assurance レベルを持つ RP で自身を他のユーザーとして識別できる．この種の攻撃を防ぐため，エンドユーザーの検証済みクレームを要求するときに，RP は OP に対して通常は多要素認証を利用するといった適正なレベルでユーザーを認証することを要求することが望ましい (SHOULD)．OpenID Connect は acr_values リクエストパラメータによってこれをサポートする．

11. Implementation and interoperability

セキュリティと相互運用性のベネフィットを最大限得るためには，このドキュメント，基盤となる OpenID Connect と OAuth 仕様，及び選択したセキュリティプロファイルの実装が完全かつ正確であることが重要である．OpenID Foundation は，デプロイメントが仕様通りに動作することを確認するために使用することが出来るツールを提供している．情報は https://openid.net/certification/ で入手できる.

12. Predefined values

このドキュメントは verified claims を伝達する技術的なメカニズムにフォーカスしているため，trust frameworks, documents, methods, check methods の identifiers は定義していない．これは，例えば実装者，アイデンティティスキーム，または管轄区域など，技術仕様の採用者に委ねられている．

このような identifiers を定義する各当事者は，これらの identifiers の衝突安全性を確保しなければならない (SHALL)．これは，https://mycompany.com/identifiers/cool_check_method のように，この当事者の管理下にあるドメイン名を identifier 名に含めることで実現される．

eKYC and Identity Assurance Working Group は，他の当事者と定義済みの値を共有するために使用できる wiki ページ [predefined_values_page] を管理している．

13. Normative References

[IDA-verified-claims]
Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. Koiwai, "OpenID Identity Assurance Schema Definition", , <https://openid.net/specs/openid-ida-verified-claims-1_0.html>.
[ISODIR2]
ISO/IEC, "ISO/IEC Directives, Part 2 - Principles and rules for the structure and drafting of ISO and IEC documents", <https://www.iso.org/sites/directives/current/part2/index.xhtml>.
[OpenID]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", , <https://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID-Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", , <https://openid.net/specs/openid-connect-discovery-1_0.html>.
[OpenID4IDAClaims]
Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. Koiwai, "OpenID Connect for Identity Assurance Claims Registration 1.0", , <https://openid.net/specs/openid-connect-4-ida-claims-1_0.html>.
[predefined_values_page]
OpenID Foundation, "Overview page for predefined values", , <https://openid.net/wg/ekyc-ida/identifiers/>.

14. Informative References

[FAPI-1-SP]
Sakimura, N., Bradley, J., and E. Jay, "Financial-grade API (FAPI) Security Profile 1.0 - Part 2: Advanced", , <https://openid.net/specs/openid-financial-api-part-2-1_0.html>.
[FAPI-2-SP]
Fett, D., Tonge, D., and J. Heenan, "FAPI 2.0 Security Profile - draft", , <https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html>.
[IANA.MediaTypes]
IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[RFC2046]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, , <https://www.rfc-editor.org/info/rfc2046>.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/info/rfc6838>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/info/rfc7519>.
[verified_claims_request.json]
OpenID Foundation, "JSON Schema for requesting verified_claims", , <https://openid.net/wg/ekyc-ida/references/>.

15. Translation References

[oidfj]
OpenID ファウンデーションジャパン, "OpenID ファウンデーションジャパン", <https://www.openid.or.jp>.
[oidfj-trans]
OpenID ファウンデーションジャパン, "翻訳・教育ワーキンググループ", <http://openid-foundation-japan.github.com/>.
[oidfj-kycwg]
OpenID ファウンデーションジャパン, "KYC ワーキンググループ", <https://www.openid.or.jp>.
[oidfj-github]
OpenID ファウンデーションジャパン, "Github レポジトリー", <https://github.com/openid-foundation-japan>.

Appendix A. IANA considerations

A.1. Media type registration

This section registers the application/provided-claims+jwt media type [RFC2046] in the IANA "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838], which is used to indicate that the content is a JWT describing aggregated claims.

  • Type name: application
  • Subtype name: provided-claims+jwt
  • Required parameters: n/a
  • Optional parameters: n/a
  • Encoding considerations: binary; An external claims JWT is a JWT; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters.
  • Security considerations: See https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#name-representing-verified-claim
  • Interoperability considerations: n/a
  • Published specification: Section 5.2 of [[ this specification ]]
  • Applications that use this media type: When using [[ this specification ]], this media type is used in the typ header of assertions provided as aggregated or distributed claims (see section 5.6.2 of the OpenID Connect specification [OpenID]).
  • Fragment identifier considerations: n/a

  • Additional information:

    • File extension(s): n/a
    • Macintosh file type code(s): n/a
  • Person & email address to contact for further information: Daniel Fett, mail@danielfett.de
  • Intended usage: COMMON
  • Restrictions on usage: none
  • Author: Daniel Fett, mail@danielfett.de
  • Change controller: IETF
  • Provisional registration? No

Appendix B. Example requests

This section shows examples of requests for verified_claims.

B.1. Verification of claims by a document 

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null,
        "time": null,
        "evidence": [
          {
            "type": {
              "value": "document"
            },
            "method": null,
            "document_details": {
              "type": null
            }
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

Note that, as shown in the above example, this document requires that implementations receiving requests are able to distinguish between JSON objects where a key is not present versus where a key is present with a null value.

Support for these null value requests is mandatory for identity providers, so implementers are encouraged to test this behaviour early in their development process. In some programming languages many JSON libraries or HTTP frameworks will, at least by default, ignore null values and omit the relevant key when parsing the JSON.

B.2. Verification of claims by trust framework and evidence types 

{
  "userinfo": {
    "verified_claims": [
      {
        "verification": {
          "trust_framework": {
            "value": "gold"
          },
          "evidence": [
            {
              "type": {
                "value": "document"
              }
            }
          ]
        },
        "claims": {
          "given_name": null,
          "family_name": null
        }
      },
      {
        "verification": {
          "trust_framework": {
            "values": [
              "silver",
              "bronze"
            ]
          },
          "evidence": [
            {
              "type": {
                "value": "vouch"
              }
            }
          ]
        },
        "claims": {
          "given_name": null,
          "family_name": null
        }
      }
    ]
  }
}

B.3. Verification of claims by trust framework and check method 

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": {
          "value": "it_spid"
        },
        "time": null,
        "evidence": [
          {
            "type": {
              "value": "document"
            },
            "check_details": [
              {
                "check_method": {
                  "value": "bvr"
                }
              }
            ],
            "document_details": {
              "type": null,
              "issuer": {
                "country": null,
                "name": null
              },
              "document_number": null,
              "date_of_issuance": null
            }
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

B.4. Verification of claims by electronic signature 

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null,
        "time": null,
        "evidence": [
          {
            "type": {
              "value": "electronic_signature"
            },
            "issuer": null,
            "serial_number": null,
            "created_at": null
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

Appendix C. Example responses

This section shows examples of responses containing verified_claims.

The first and second subsections show JSON snippets of the general identity assurance case, where the RP is provided with verification evidence for different methods along with the actual claims about the end-user.

The third subsection illustrates the possible contents of this object in case of a notified eID system under eIDAS, where the OP does not need to provide evidence of the identity verification process to the RP.

Subsequent subsections contain examples for using the verified_claims claim on different channels and in combination with other (unverified) claims.

C.1. Document 

{
  "verified_claims": {
    "verification": {
      "trust_framework": "nist_800_63A",
      "assurance_level": "ial2",
      "assurance_process": {
        "assurance_details": [
          {
            "assurance_type": "evidence_validation",
            "assurance_classification": "strong",
            "evidence_ref": [
              {
                "check_id": "DL1-93h506th2f45hf"
              }
            ]
          },
          {
            "assurance_type": "verification",
            "assurance_classification": "strong",
            "evidence_ref": [
              {
                "check_id": "v-93jfk284ugjfj2093"
              }
            ]
          }
        ]
      },
      "time": "2021-06-06T05:32Z",
      "verification_process": "7675D80F-57E0-AB14-9543-26B41FC22",
      "evidence": [
        {
          "type": "document",
          "check_details": [
            {
              "check_method": "vpiruv",
              "organization": "doc_checker",
              "check_id": "DL1-93h506th2f45hf"
            },
            {
              "check_method": "pvp",
              "organization": "face_checker",
              "check_id": "v-93jfk284ugjfj2093"
            }
          ],
          "time": "2021-06-06T05:33Z",
          "document_details": {
            "type": "driving_permit",
            "document_number": "I1234568",
            "date_of_issuance": "2019-09-05",
            "date_of_expiry": "2024-08-01",
            "issuer": {
                "name": "CA DMV",
                "country": "US",
                "country_code": "USA",
                "jurisdiction": "CA"
            }
          }
        }
      ]
    },
    "claims": {
      "given_name": "Inga",
      "family_name": "Silverstone",
      "birthdate": "1991-11-06",
      "place_of_birth": {
        "country": "USA"
      },
      "address": {
        "locality": "Shoshone",
        "postal_code": "CA 92384",
        "country": "USA",
        "street_address": "114 Old State Hwy 127"
      }
    }
  }
}

Same document under a different trust_framework

{
  "verified_claims": {
    "verification": {
      "trust_framework": "uk_diatf",
      "assurance_level": "medium",
      "assurance_process": {
        "policy": "gpg45",
        "procedure": "m1c",
        "assurance_details": [
          {
            "assurance_type": "evidence_validation",
            "assurance_classification": "score_3",
            "evidence_ref": [
              {
                "check_id": "DL1-93h506th2f45hf",
                "evidence_metadata": {
                  "evidence_classification": "score_3_strength"
                }
              }
            ]
          },
          {
            "assurance_type": "verification",
            "assurance_classification": "score_3",
            "evidence_ref": [
              {
                "check_id": "v-93jfk284ugjfj2093"
              }
            ]
          }
        ]
      },
      "time": "2021-06-06T05:32Z",
      "verification_process": "7675D80F-57E0-AB14-9543-26B41FC22",
      "evidence": [
        {
          "type": "document",
          "check_details": [
            {
              "check_method": "vpiruv",
              "organization": "doc_checker",
              "check_id": "DL1-93h506th2f45hf",
              "time": "2021-06-08T11:41Z"
            },
            {
              "check_method": "pvp",
              "organization": "face_checker",
              "check_id": "v-93jfk284ugjfj2093",
              "time": "2021-06-08T11:42Z"
            }
          ],
          "time": "2021-06-06T05:33Z",
          "document_details": {
            "type": "driving_permit",
            "document_number": "I1234568",
            "date_of_issuance": "2019-09-05",
            "date_of_expiry": "2024-08-01",
            "issuer": {
                "name": "CA DMV",
                "country": "US",
                "country_code": "USA",
                "jurisdiction": "CA"
            }
          }
        }
      ]
    },
    "claims": {
      "given_name": "Inga",
      "family_name": "Silverstone",
      "birthdate": "1991-11-06",
      "place_of_birth": {
        "country": "USA"
      },
      "address": {
        "locality": "Shoshone",
        "postal_code": "CA 92384",
        "country": "USA",
        "street_address": "114 Old State Hwy 127"
      }
    }
  }
}

C.2. Document and verifier details 

{
  "verified_claims": {
    "verification": {
      "trust_framework": "de_aml",
      "time": "2012-04-23T18:25Z",
      "verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
      "evidence": [
        {
          "type": "document",
          "method": "pipp",
          "organization": "Deutsche Post",
          "check_id": "1aa05779-0775-470f-a5c4-9f1f5e56cf06",
          "time": "2012-04-22T11:30Z",
          "document_details": {
            "type": "idcard",
            "issuer": {
              "name": "Stadt Augsburg",
              "country": "DE"
            },
            "document_number": "53554554",
            "date_of_issuance": "2010-03-23",
            "date_of_expiry": "2020-03-22"
          }
        }
      ]
    },
    "claims": {
      "given_name": "Max",
      "family_name": "Meier",
      "birthdate": "1956-01-28",
      "place_of_birth": {
        "country": "DE",
        "locality": "Musterstadt"
      },
      "nationalities": [
        "DE"
      ],
      "address": {
        "locality": "Maxstadt",
        "postal_code": "12344",
        "country": "DE",
        "street_address": "An der Weide 22"
      }
    }
  }
}

C.3. Evidence with all assurance details 

{
  "verified_claims": {
    "verification": {
      "trust_framework": "uk_diatf",
      "assurance_level": "medium",
      "assurance_process": {
        "policy": "gpg45",
        "procedure": "m1b",
        "assurance_details": [
          {
            "assurance_type": "evidence_validation",
            "assurance_classification": "score_2",
            "evidence_ref": [
              {
                "check_id": "DL1-85762937582385820",
                "evidence_metadata": {
                  "evidence_classification": "score_3_strength"
                }
              }
            ]
          },
          {
            "assurance_type": "verification",
            "assurance_classification": "score_2",
            "evidence_ref": [
              {
                "check_id": "kbv1-hf934hn09234ng03jj3",
                "evidence_metadata": {
                  "evidence_classification": "high_kbv"
                }
              },
              {
                "check_id": "kbv2-nm0f23u9459fj38u5j6",
                "evidence_metadata": {
                  "evidence_classification": "medium_kbv"
                }
              },
              {
                "check_id": "kbv3-jf9028h023hj0f9jh23",
                "evidence_metadata": {
                  "evidence_classification": "medium_kbv"
                }
              }
            ]
          },
          {
            "assurance_type": "counter_fraud",
            "assurance_classification": "score_2",
            "evidence_ref": [
              {
                "check_id": "GRO-9824hngvp9278hf5tmp924y5h",
                "evidence_metadata": {
                  "evidence_classification": "mortality_check"
                }
              },
              {
                "check_id": "fi-2nbf02hfn384ufn",
                "evidence_metadata": {
                  "evidence_classification": "id_fraud"
                }
              }
            ]
          }
        ]
      },
      "time": "2021-05-11T14:29Z",
      "verification_process": "7675D80F-57E0-AB14-9543-26B41FC22",
      "evidence": [
        {
          "type": "document",
          "check_details": [
            {
              "check_method": "data",
              "organization": "DVLA",
              "time": "2021-04-09T14:15Z",
              "check_id": "DL1-85762937582385820"
            }
          ],
          "time": "2021-04-09T14:12Z",
          "document_details": {
            "type": "driving_permit",
            "personal_number": "MORGA753116SM9IJ",
            "document_number": "MORGA753116SM9IJ35",
            "serial_number": "ZG21000001",
            "date_of_issuance": "2021-01-01",
            "date_of_expiry": "2030-12-31",
            "issuer": {
              "name": "DVLA",
              "country": "UK",
              "country_code": "GBR",
              "jurisdiction": "GB-GBN"
            }
          }
        },
        {
          "type": "electronic_record",
          "check_details": [
            {
              "check_method": "kbv",
              "organization": "TheCreditBureau",
              "check_id": "kbv1-hf934hn09234ng03jj3"
            }
          ],
          "time": "2021-04-09T14:12Z",
          "record": {
            "type": "mortgage_account",
            "source": {
              "name": "TheCreditBureau"
            }
          }
        },
        {
          "type": "electronic_record",
          "check_details": [
            {
              "check_method": "kbv",
              "organization": "OpenBankingTPP",
              "check_id": "kbv2-nm0f23u9459fj38u5j6"
            }
          ],
          "time": "2021-04-09T14:12Z",
          "record": {
            "type": "bank_account",
            "source": {
              "name": "TheBank"
            }
          }
        },
        {
          "type": "electronic_record",
          "check_details": [
            {
              "check_method": "kbv",
              "organization": "GSMA",
              "check_id": "kbv3-jf9028h023hj0f9jh23"
            }
          ],
          "time": "2021-04-09T15:42Z",
          "record": {
            "type": "mno",
            "source": {
              "name": "Vodafone"
            }
          }
        },
        {
          "type": "electronic_record",
          "check_details": [
            {
              "check_method": "data",
              "organization": "GRO",
              "check_id": "GRO-9824hngvp9278hf5tmp924y5h"
            }
          ],
          "time": "2021-04-09T16:12Z",
          "record": {
            "type": "death_register",
            "source": {
              "name": "General Register Office",
              "street_address": "PO BOX 2",
              "locality": "Southport",
              "postal_code": "PR8 2JD",
              "country": "UK",
              "country_code": "GBR",
              "jurisdiction": "GB-EAW"
            }
          }
        },
        {
          "type": "electronic_record",
          "check_details": [
            {
              "check_method": "data",
              "organization": "NextLex",
              "check_id": "fi-2nbf02hfn384ufn"
            }
          ],
          "time": "2021-04-09T16:51Z",
          "record": {
            "type": "fraud_register",
            "source": {
              "name": "National Fraud Database",
              "jurisdiction": "UK"
            }
          }
        }
      ]
    },
    "claims": {
      "given_name": "Sarah",
      "family_name": "Meredyth",
      "birthdate": "1976-03-11",
      "place_of_birth": {
        "country": "UK"
      },
      "address": {
        "locality": "Edinburgh",
        "postal_code": "EH1 9GP",
        "country": "UK",
        "street_address": "122 Burns Crescent"
      }
    }
  }
}

C.4. Notified eID system (eIDAS) 

{
  "verified_claims": {
    "verification": {
      "trust_framework": "eidas",
      "assurance_level": "substantial"
    },
    "claims": {
      "given_name": "Max",
      "family_name": "Meier",
      "birthdate": "1956-01-28",
      "place_of_birth": {
        "country": "DE",
        "locality": "Musterstadt"
      },
      "nationalities": [
        "DE"
      ]
    }
  }
}

C.5. Electronic_record 

{
  "verified_claims": {
    "verification": {
      "trust_framework": "se_bankid",
      "assurance_level": "al_2",
      "time": "2021-03-03T09:42Z",
      "verification_process": "4346D80F-57E0-4E26-9543-26B41FC22",
      "evidence": [
        {
          "type": "electronic_record",
          "check_details": [
            {
              "check_method": "data"
            },
            {
              "check_method": "token"
            }
          ],
          "time": "2021-02-15T16:51Z",
          "record": {
            "type": "population_register",
            "source": {
                "name": "Skatteverket",
                "country": "Sverige",
                "country_code": "SWE"
            },
            "personal_number": "4901224131",
            "created_at": "1979-01-22"
          }
        }
      ]
    },
    "claims": {
      "given_name": "Fredrik",
      "family_name": "Strömberg",
      "birthdate": "1979-01-22",
      "place_of_birth": {
        "country": "SWE",
        "locality": "Örnsköldsvik"
      },
      "nationalities": [
        "SE"
      ],
      "address": {
        "locality": "Karlstad",
        "postal_code": "65344",
        "country": "SWE",
        "street_address": "Gatunamn 221b"
      }
    }
  }
}

C.6. Vouch 

{
  "verified_claims": {
    "verification": {
      "trust_framework": "uk_diatf",
      "assurance_level": "very_high",
      "time": "2020-03-19T13:05Z",
      "verification_process": "76755DA2-81E1-5N14-9543-26B415B77",
      "evidence": [
        {
          "type": "vouch",
          "check_details": [
            {
              "check_method": "vcrypt"
            },
            {
              "check_method": "bvr"
            }
          ],
          "time": "2020-03-19T12:42Z",
          "attestation": {
            "type": "digital_attestation",
            "reference_number": "6485-1619-3976-6671",
            "date_of_issuance": "2021-06-04",
            "voucher": {
                "organization": "HMP Dartmoor"
            }
          }
        }
      ]
    },
    "claims": {
      "given_name": "Sam",
      "family_name": "Lawler",
      "birthdate": "1981-04-13",
      "place_of_birth": {
        "country": "GBR"
      },
      "address": {
        "postal_code": "98015",
        "country": "Monaco"
      }
    }
  }
}

C.7. Multiple verified claims 

{
  "verified_claims": [
    {
      "verification": {
        "trust_framework": "eidas",
        "assurance_level": "substantial"
      },
      "claims": {
        "given_name": "Max",
        "family_name": "Meier",
        "birthdate": "1956-01-28",
        "place_of_birth": {
          "country": "DE",
          "locality": "Musterstadt"
        },
        "nationalities": [
          "DE"
        ]
      }
    },
    {
      "verification": {
        "trust_framework": "de_aml",
        "time": "2012-04-23T18:25Z",
        "verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
        "evidence": [
          {
            "type": "document",
            "method": "pipp",
            "time": "2012-04-22T11:30Z",
            "document": {
              "type": "idcard"
            }
          }
        ]
      },
      "claims": {
        "address": {
          "locality": "Maxstadt",
          "postal_code": "12344",
          "country": "DE",
          "street_address": "An der Weide 22"
        }
      }
    }
  ]
}

C.8. Claims provided by the OP and external sources

This example shows how an OP can mix own claims and claims provided by external sources in a single ID Token.

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "email": "janedoe@example.com",
  "email_verified": true,
  "verified_claims": {
    "verification": {
      "trust_framework": "trust_framework_example"
    },
    "claims": {
      "given_name": "Max",
      "family_name": "Meier"
    }
  },
  "_claim_names": {
    "verified_claims": [
      "src1",
      "src2"
    ]
  },
  "_claim_sources": {
    "src1": {
      "JWT": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3NlcnZlci5vdGhlcm9wLmNvbSIsInN1YiI6ImU4MTQ4NjAzLTg5MzQtNDI0NS04MjViLWMxMDhiOGI2Yjk0NSIsInZlcmlmaWVkX2NsYWltcyI6eyJ2ZXJpZmljYXRpb24iOnsidHJ1c3RfZnJhbWV3b3JrIjoiaWFsX2V4YW1wbGVfZ29sZCJ9LCJjbGFpbXMiOnsiZ2l2ZW5fbmFtZSI6Ik1heCIsImZhbWlseV9uYW1lIjoiTWVpZXIiLCJiaXJ0aGRhdGUiOiIxOTU2LTAxLTI4In19fQ.FArlPUtUVn95HCExePlWJQ6ctVfVpQyeSbe3xkH9MH1QJjnk5GVbBW0qe1b7R3lE-8iVv__0mhRTUI5lcFhLjoGjDS8zgWSarVsEEjwBK7WD3r9cEw6ZAhfEkhHL9eqAaED2rhhDbHD5dZWXkJCuXIcn65g6rryiBanxlXK0ZmcK4fD9HV9MFduk0LRG_p4yocMaFvVkqawat5NV9QQ3ij7UBr3G7A4FojcKEkoJKScdGoozir8m5XD83Sn45_79nCcgWSnCX2QTukL8NywIItu_K48cjHiAGXXSzydDm_ccGCe0sY-Ai2-iFFuQo2PtfuK2SqPPmAZJxEFrFoLY4g"
    },
    "src2": {
      "endpoint": "https://server.yetanotherop.com/claim_source",
      "access_token": "ksj3n283dkeafb76cdef"
    }
  }
}

C.9. Self-Issued OpenID provider and external claims

This example shows how a Self-Issued OpenID provider (SIOP) may include verified claims obtained from different external claim sources into an ID Token.

{
  "iss": "https://self-issued.me",
  "sub": "248289761001",
  "preferred_username": "superman445",
  "_claim_names": {
    "verified_claims": [
      "src1",
      "src2"
    ]
  },
  "_claim_sources": {
    "src1": {
      "JWT": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3NlcnZlci5vdGhlcm9wLmNvbSIsInN1YiI6ImU4MTQ4NjAzLTg5MzQtNDI0NS04MjViLWMxMDhiOGI2Yjk0NSIsInZlcmlmaWVkX2NsYWltcyI6eyJ2ZXJpZmljYXRpb24iOnsidHJ1c3RfZnJhbWV3b3JrIjoiaWFsX2V4YW1wbGVfZ29sZCJ9LCJjbGFpbXMiOnsiZ2l2ZW5fbmFtZSI6Ik1heCIsImZhbWlseV9uYW1lIjoiTWVpZXIiLCJiaXJ0aGRhdGUiOiIxOTU2LTAxLTI4In19fQ.FArlPUtUVn95HCExePlWJQ6ctVfVpQyeSbe3xkH9MH1QJjnk5GVbBW0qe1b7R3lE-8iVv__0mhRTUI5lcFhLjoGjDS8zgWSarVsEEjwBK7WD3r9cEw6ZAhfEkhHL9eqAaED2rhhDbHD5dZWXkJCuXIcn65g6rryiBanxlXK0ZmcK4fD9HV9MFduk0LRG_p4yocMaFvVkqawat5NV9QQ3ij7UBr3G7A4FojcKEkoJKScdGoozir8m5XD83Sn45_79nCcgWSnCX2QTukL8NywIItu_K48cjHiAGXXSzydDm_ccGCe0sY-Ai2-iFFuQo2PtfuK2SqPPmAZJxEFrFoLY4g"
    },
    "src2": {
      "endpoint": "https://op.mymno.com/claim_source",
      "access_token": "ksj3n283dkeafb76cdef"
    }
  }
}

Appendix D. Example requests and responses

This section shows examples of pairs of requests and responses containing verified_claims.

D.1. verified claims in UserInfo response

D.1.1. Request

In this example we assume the RP uses the scope parameter to request the email address and, additionally, the claims parameter, to request verified claims.

The scope value is: scope=openid email

The value of the claims parameter is:

{
  "userinfo": {
    "verified_claims": {
      "verification": {
        "trust_framework": null
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

D.1.2. Response

The respective UserInfo response would be

{
  "sub": "248289761001",
  "email": "janedoe@example.com",
  "email_verified": true,
  "verified_claims": {
    "verification": {
      "trust_framework": "de_aml"
    },
    "claims": {
      "given_name": "Max",
      "family_name": "Meier",
      "birthdate": "1956-01-28"
    }
  }
}

D.2. verified claims in ID Tokens

D.2.1. Request

In this case, the RP requests verified claims along with other claims about the end-user in the claims parameter and allocates the response to the ID Token (delivered from the token endpoint in case of grant type authorization_code).

The claims parameter value is

{
  "id_token": {
    "email": null,
    "preferred_username": null,
    "picture": null,
    "verified_claims": {
      "verification": {
        "trust_framework": null,
        "time": null,
        "verification_process": null,
        "evidence": [
          {
            "type": {
              "value": "document"
            },
            "method": null,
            "time": null,
            "document_details": {
              "type": null,
              "issuer": {
                "name": null,
                "country": null
              },
              "document_number": null,
              "date_of_issuance": null,
              "date_of_expiry": null
            }
          }
        ]
      },
      "claims": {
        "given_name": null,
        "family_name": null,
        "birthdate": null
      }
    }
  }
}

D.2.2. Response

The decoded body of the respective ID Token could be

{
  "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:25Z",
      "verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
      "evidence": [
        {
          "type": "document",
          "method": "pipp",
          "time": "2012-04-22T11:30Z",
          "document_details": {
            "type": "idcard",
            "issuer": {
              "name": "Stadt Augsburg",
              "country": "DE"
            },
            "document_number": "53554554",
            "date_of_issuance": "2010-03-23",
            "date_of_expiry": "2020-03-22"
          }
        }
      ]
    },
    "claims": {
      "given_name": "Jane",
      "family_name": "Doe",
      "birthdate": "1956-01-28"
    }
  }
}

Appendix E. Acknowledgements

The following people at yes.com and partner companies contributed to the concept described in the initial contribution to this document: Karsten Buch, Lukas Stiebig, Sven Manz, Waldemar Zimpfer, Willi Wiedergold, Fabian Hoffmann, Daniel Keijsers, Ralf Wagner, Sebastian Ebling, Peter Eisenhofer.

We would like to thank Julian White, Bjorn Hjelm, Stephane Mouy, Alberto Pulido, Joseph Heenan, Vladimir Dzhuvinov, Azusa Kikuchi, Naohiro Fujie, Takahiko Kawasaki, Sebastian Ebling, Marcos Sanz, Tom Jones, Mike Pegman, Michael B. Jones, Jeff Lombardo, Taylor Ongaro, Peter Bainbridge-Clayton, Adrian Field, George Fletcher, Tim Cappalli, Michael Palage, Sascha Preibisch, Giuseppe De Marco, Nick Mothershaw, Hodari McClain, Dima Postnikov and Nat Sakimura for their valuable feedback and contributions that helped to evolve this document.

Appendix F. Notices

Copyright (c) 2024 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 document 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 document 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 document 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 document 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 document.

Appendix G. Translator

本仕様の翻訳は, OpenID ファウンデーションジャパン [oidfj] KYC ワーキンググループ [oidfj-kycwg], 翻訳・教育ワーキンググループ [oidfj-trans] を主体として, 有志のメンバーによって行われました. 質問や修正依頼などについては, Github レポジトリー [oidfj-github] にご連絡ください.

Authors' Addresses

Torsten Lodderstedt
sprind.org
Daniel Fett
Authlete
Mark Haine
Considrd.Consulting Ltd
Alberto Pulido
Santander
Kai Lehmann
1&1 Mail & Media Development & Technology GmbH
Kosuke Koiwai
KDDI Corporation