OIDC4IDAとは？本人確認(eKYC)の標準仕様を徹底解説

デジタルアイデンティティの進化に伴い、単なる認証だけでなく、eKYC（オンライン本人確認）による「身元確認の証拠」を安全に伝達する仕組みが求められています。そこで、ユーザーの属性情報が「いつ・どこで・どのように確認されたか」を厳密に連携可能にする国際標準規格「OpenID Connect for Identity Assurance（OIDC4IDA）」が登場しました。
本記事では、OIDC4IDAが解決する課題から、コアとなる技術仕様、具体的なデータ構造、そして実装に向けた実践的な考慮事項までを詳しく解説します。

はじめに：OIDC4IDAとは何か？

厳格な身元確認（eKYC）が求められる現代において、デジタルアイデンティティの信頼性をいかに担保するかは大きな課題です。そこで注目されているのが、OpenID FoundationのeKYC-IDA WGによって策定された「OpenID Connect for Identity Assurance（以下、OIDC4IDA）」です。

OIDC4IDAは、認証情報を連携するための国際標準規格であるOpenID Connect（OIDC）を拡張した仕様です。通常のOIDCが「誰が認証したか」を伝えるのに対し、OIDC4IDAは「そのユーザーの身元情報は、どのようなプロセスで、どの程度厳密に、確認された検証済み情報（Verified Claims）なのか」を連携することができます。

これにより、マネーロンダリング防止対策（AML）への対応や、各種サービスでの詐欺防止など、高い身元保証レベルが要求されるユースケースにおいて、標準化された手法で連携が可能になります。

OIDC4IDAが解決する「アイデンティティ保証」の課題

なぜOIDC4IDAという拡張仕様が必要になったのでしょうか。

従来のOIDCでは、情報のやり取りはRP（Relying Party：サービス側）とOP（OpenID Provider：ID提供側）間の暗黙の信頼関係の上に成り立っていました。自社で管理しているOPであれば身元確認のルールは明白ですが、外部のOPから連携されたユーザー情報については「どのようなルールで、どんな証拠をもとに本人確認されたのか」が不透明であり、RP側でその情報の利用可否を判断することが困難でした。

OIDC4IDAは、このブラックボックスを解消します。OPがRPに対し、単なるユーザー属性だけでなく、「どのようなトラストフレームワーク（ルール）に従って」「いつ」「どのような証拠（マイナンバーカードや運転免許証など）を用いて」確認したかというメタデータを一緒に提供できるようになります。これにより、RPは受け取った情報を自社の要件に照らし合わせて、安全に利用できるようになります。

OIDC4IDAにはいくつか関連仕様があります。ここでは、コア仕様であるOpenID Connect for Identity Assurance 1.0をメインに解説します。

仕様・ドキュメント名	概要	主な定義内容
OpenID Connect for Identity Assurance 1.0^[1]	検証済み情報（Verified Claims）を連携するためのプロトコル全体の動作とルール	・RPからOPへのリクエスト方法・検証済み情報（Verified Claims）の受け渡し方法・メタデータ（Discovery）
OpenID Identity Assurance Schema Definition 1.0^[2]	やり取りされる検証済み情報（Verified Claims）のデータ構造	・verified_claims 要素の基本構造・検証メタデータ（verification）の構成・ユーザーデータ（claims）の構成
OpenID Connect for Identity Assurance Claims Registration 1.0^[3]	検証対象となる具体的なユーザー属性の名称やフォーマットの標準	・名前、生年月日、住所などの標準クレーム名・各クレームのデータ型や表記ルール

コア仕様：Verified Claims（検証済みクレーム）の構造

OIDC4IDAの中核となるのが、verified_claimsという新しい要素の導入です。これは「OpenID Identity Assurance Schema Definition 1.0」に基づき、ユーザーの属性情報とその検証プロセスを構造化して表現します。

verified_claimsは、大きく分けて以下の2つの要素で構成されます。

verification要素：準拠しているトラストフレームワークや、本人確認に用いられた証拠の種類、検証方法などの「検証に関するメタデータ」を格納します。verification要素の各項目(クレーム)が取りうる値は事前定義する必要があります。具体例は、OpenID Foundation eKYC & IDA Working Groupのwikiページ^[4]にて確認できます。
claims要素：名前（name）や生年月日（birthdate）、住所（address）など、「実際に検証されたユーザーデータ」を格納します。

【データ構造のイメージ】

"verified_claims": {
  "verification": {
    "trust_framework": "jp_aml",
    "evidence": [
      {
        "type": "document",
        "method": "pipp",
        "document_details": {
          "type": "jp_individual_number_card"
        }
      }
    ]
  },
  "claims": {
    "name": "山田 太郎",
    "birthdate": "1990-01-01"
  }
}

このように、単なる「山田太郎」という文字列ではなく、「マイナンバーカード（jp_individual_number_card）を用いて対面と同等の方法（pipp）で検証された山田太郎」であることを機械可読な形で表現できます。

RPからOPへの検証済み情報リクエスト方法

RPがOPに対してこれらの検証済み情報を要求する場合、OIDCで定義されている認可要求のclaimsパラメータを活用します。

具体的には、claimsパラメータ内のuserinfoまたはid_tokenの中にverified_claimsを指定し、必要とする要素をリクエストします。さらに、RPは「特定のトラストフレームワークに準拠していること」や、「特定のエビデンス種別（例：公的機関の発行したドキュメント）で確認されていること」、あるいは「検証から経過した最大時間（max_age）」などを指定して、自社の要件に合致する情報のみをピンポイントで要求することが可能です。
リクエスト例は以下のとおりです。

GET /authorize?
  response_type=code
  &client_id=example_client
  &redirect_uri=https://client.example.com/callback
  &scope=openid
  &claims={
    "userinfo": {
      "verified_claims": {
        "verification": {
          "trust_framework": null,
          "time": null,
          "verification_process": null
        },
        "claims": {
          "given_name": null,
          "family_name": null,
          "birthdate": null,
          "place_of_birth": null,
          "nationalities": null,
          "address": {
            "locality": null,
            "postal_code": null,
            "country": null,
            "street_address": null
          }
        }
      }
    },
    "id_token": {
      "verified_claims": {
        "verification": {
          "trust_framework": {
            "value": "eidas"
          }
        },
        "claims": {
          "email": null,
          "email_verified": null
        }
      }
    }
  }
  &state=a1b2c3d4e5f6g7
  &nonce=xyz7890123

この例では、userinfoエンドポイントで、"trust_framework"、"time"、"verification_process"を含むverified_claimsを返却してほしい（各trust_framework、time等の項目の値は問わない(null)）、IDトークン内に、trust_frameworkが”eidas”で検証されたverified_claimsのみ返却してほしいというリクエストになります。

不必要な情報を取得しない（データ最小化の原則）という観点でも、このリクエスト方式は非常に重要です。

高度な連携：集約・分散クレームの活用

大規模で複雑なID連携エコシステムにおいては、OP自身が本人確認を行うとは限りません。外部の専門システム（Claim Provider）が検証したクレームを取り扱う仕組みも考慮されています。

OIDC4IDAでは、以下の2つの手法をサポートしています。

集約クレーム（Aggregated Claims）: 外部で検証された情報を含むJWTを、OPがまとめてRPに返却する方式。
分散クレーム（Distributed Claims）: OPは情報の取得先エンドポイント（URL）のみをRPに渡し、RPが直接外部システムへ情報を取得しに行く方式。

これにより、柔軟かつセキュアなID保証基盤を構築することが可能となります。

OPメタデータの拡張（Discovery）

RPは連携先のOPが「どのような本人確認レベルや証明書に対応しているか」を事前に知る必要があります。そのため、OIDC4IDAではOPのディスカバリー情報（/.well-known/openid-configuration）に対する拡張も定義されています。

主に追加される主要なメタデータは以下の通りです。

trust_frameworks_supported：サポートしているトラストフレームワーク（必須）
claims_in_verified_claims_supported：検証済みクレームとして提供可能な属性（必須）
evidence_supported：サポートする証拠の種別（必須）
documents_supported：身分証などのドキュメント種別（必須）

これらを事前に参照することで、RPはOPの実装仕様に合わせた適切なリクエストを動的に組み立てることができます。

まとめと実装に向けた次の一手

OIDC4IDAは、単なるプロトコルの拡張にとどまらず、世界中の法的・商業的な要件（AMLやKYCなど）を満たしながら、セキュアにアイデンティティを連携するための強力な技術メカニズムです。

しかし、ここまで解説したプロトコル仕様を実際のビジネス環境（eKYCサービスや各種デジタル認証アプリとの連携など）に適用する際には、仕様書を読むだけでは見えてこない「実装上の壁」が多数存在します。

例えば、

自社サービス群での連携（ファーストパーティモデル）と、外部企業との連携（サードパーティモデル）でのアーキテクチャの違い
eKYC実施前・実施後における、当人認証（パスキー等の追加認証や acr_values の活用）の強化ポイント
不要なサービスへ身元確認情報を返却してしまうリスクへの対策

など、システムを安全に稼働させるためには多くの考慮が必要です。

実案件におけるOIDC4IDAの具体的な適用ユースケースや、サービス導入時に落とし穴になりやすい実装上の考慮ポイントを知りたい方は、ぜひ以下の詳細資料をダウンロードしてご確認ください。

[1] https://openid.net/specs/openid-connect-4-identity-assurance-1_0-final.html

[2] https://openid.net/specs/openid-ida-verified-claims-1_0-final.html

[3] https://openid.net/specs/openid-connect-4-ida-claims-1_0-final.html

[4] https://bitbucket.org/openid/ekyc-ida/wiki/identifiers