7FSJGJBCMF$SFEFOUJBMTΛऔΓר͘ 0QFO*%ؔ࿈࢓༷ͷղઆ 1 Copyright © 2023, OpenIDファウンデーションジャパン, All Rights Reserved

今⽇はこれだけ覚えて帰ってください。 • OpenID4VC: VC/DID関連3仕様の俗称 • SIOPv2: OpenID Connect(OIDC)の既存仕様を拡張し、 DIDやhttps型のアプリ連携やクラウドウォレットに対応 • OpenID for VP: VC/VPを提⽰するためのOAuth2.0の拡張 新たにVPトークンを定義 • OpenID for VC Issuance: VCを発⾏するためのOAuth2.0の拡張。QR コードによる認可コードの連携が可能 • DCP WG: Digital Credentials Protocols Working Group • VC関連のさらなる仕様策定のために新たに設⽴したWG • HAIP: OpenID4VCを使って、SD-JWTによるクレデンシャル発⾏・利 ⽤時の相互運⽤性を確保するためのプロファイル • その他BLE利⽤、userinfo拡張などの仕様も策定中

⾃⼰紹介 • ⼩岩井 航介/Kosuke Koiwai • 2017年より KDDI株式会社でID/認証関係等を担当 • 2020年より OpenID Foundation Sustaining Board Member • eKYC-IDA仕様の共著者、FAPI1.0仕様の貢献者 • 2022年より OpenIDファウンデーション・ジャパン KYC WGリーダ • その他、FIDO Alliance, W3C でも標準化活動に参画中。 • KDDI は2015年より OpenID Foundation の Sustaining Corporate Sponsor として活動 https://openid.net/foundation/board/ https://news.kddi.com/kddi/corporate/newsrelease/2015/11/10/1444.html

⼀応ブロックチェーンは2016年から触ってます。 • 証券クリアリング(約定照合) をEthereum上で試作したのは 多分国内初・・・かも？ https://github.com/kkoiwai/SolidityTradeMatcher https://speakerdeck.com/kkoiwai/

認証関連仕様の外観 • OAuth2.0をベースに、あらゆる仕様が策定されている。 • Extension(拡張): 新たなユースケースのために既存の仕様にないものを追加 する • Profile(プロファイル): 仕様の範囲内で、特定のユースケースのために利⽤ 法（設定値等）を制限するもの • ユースケースに合わせて、組み合わせて利⽤する。（以下例） OAuth2.0 API Authorization Framework (RFC6749) OpenID Connect Core (OIDC) Financial-grade API (FAPI) eKYC-IDA OpenID for Verifiable Presentations Self-issued OP v2 OpenID for VC Issuance OID4VC High Assurance Interoperability Profile with SD-JWT VC (HAIP)

OpenID4VC: OpenID for Verifiable Credentials OpenID ConnectやそのベースであるOAuth2.0の仕組みを使い、 DIDやVerifiable Credentialを連携するための関連3仕様の俗称 https://openid.net/openid4vc/ OpenID BizDay #15 再掲 (2023/1/10 開催)

DID: Decentralized Identifier (分散型識別⼦) • 特定の事業者に依存しない識別⼦(Identifier) • Identity(属性の集合)ではなく、Identifier(識別⼦) • OpenID Connectでいうところの Sub値に該当 • W3Cにより標準化(did:method:xxxx) • DIDと紐づく鍵ペアを⽣成、秘密鍵へのアクセス=「所有」 • 識別⼦に紐づくDID Documentが分散台帳上等で公開される • DIDに紐づく秘密鍵で署名したデータをDID Document上の公 開鍵で検証する ことでDIDの「持ち主」が発⾏したデータであ ることを検証できる OpenID BizDay #15 再掲

VC: Verifiable Credentials (検証可能なクレデンシャル） • 検証可能なデータモデル • Issuerから発⾏されたVCをユーザはHolder(Wallet)に保管。 Verifierに提⽰する時は、複数のVCを取捨選択した VP (Verifiable Presentation)として提⽰する。 • DIDと組み合わせて利⽤されることが多いが、必須ではない。 • 発⾏者(Issuer)のDIDに紐づく秘密鍵によりデジタル署名される • 発⾏者のDID Documentに含まれる公開鍵を使って検証可能 VCの発⾏ VPの提⽰ OpenID BizDay #15 再掲

Credential の定義の違い • OpenID Connect Coreと、W3C Verifiable Credentialsで、 "Credential”の定義が異なる • OIDC: アイデンティティやその他のリソースを使う権利の証明 • W3C: 同⼀エンティティによって⽰されたクレーム(属性)のセット OpenID BizDay #15 再掲

VC関連で策定中の関連OpenID仕様は3つ https://openid.net/wordpress-content/uploads/2022/05/OIDF-Whitepaper_OpenID-for-Verifiable-Credentials_FINAL_2022-05-12.pdf • VC/VPの授受(トランスポート)の仕様はW3Cでは⾮定義。 • OpenID Connectの拡張としてトランスポート仕様を策定中。 • 著者は、W3CのVerifiable Credentials WGのChairが兼任 VCの発⾏ VPの提⽰ OpenID BizDay #15 再掲

OpenID4VCでサポートするVCの種類 W3C Verifiable Credentials Data Model https://www.w3.org/TR/vc-data-model/ ISO/IEC 18013-5 mobile Driving License (mDL) https://www.iso.org/standard/69084.html ISO/IEC 23220-2 electronic Identification (eID) https://www.iso.org/standard/79124.html Anonymous Credentials https://www.hyperledger.org/use/hyperle dger-indy SMART Health Card(SHC) / FHIR (Fast Healthcare Interoperability Resources) https://ecqi.healthit.gov/fhir https://spec.smarthealth.cards/ • Verifiable Credentials には、いくつか仕様が存在。 • W3C のVCと、ISOのmDL (モバイル運転免許証) には互換性はない。 • ワクチン証明書に使われるSMART Health Cardは W3C VCベース。 • OpenID4VCは、下記いずれもサポートするよう設計されている。 OpenID BizDay #15 再掲

Self-Issued OpenID Provider v2 • OpenID Connect Core仕様のSIOPを拡張 • openid:// だけでなく、https://も使えるように • App Links, Universal Linksや、クラウド連携のWalletも想定 • sub値として、jwt Fingerprintだけでなく、DIDも使えるように • OpenID Connect⾃体にsub値の制限はないが、SIOP仕様ではjwt fingerprintと規定 WalletからVerifierに対してVCを提⽰する際に、 OIDC4VPと組み合わせて利⽤することを想定 VCの発⾏ VPの提⽰ OpenID BizDay #15 再掲

Self-Issued OpenID Provider v1 とは？ • OpenID Connect Core 仕様に当初から 定義されていた！！ https://openid.net/specs/openid-connect-core-1_0.html OpenID BizDay #15 再掲

Self-Issued OpenID Provider v1 とは？ • ⾃分の端末（スマホやPC）⾃⾝がOP/IdPになるための仕様 • ログイン時に、GoogleやFacebookにリダイレクトする代わり に、openid://スキーマを使ってスマホアプリを起動する • 通常であれば、OP(Googleなど)を信頼して、IDトークン内の 情報（claims)を信頼するが、SIOPの場合は、IDトークンを署 名した署名鍵を信頼する。 • SIOPの場合、IDトークン内のsub値以外の情報（claims）は⾃ ⼰申告ななので信頼できないが、Aggregated Claimsを組み合 わせることで信頼できる情報を提供できるようになる。 OpenID BizDay #15 再掲

Self-Issued OpenID Provider v2 • OpenID Connect Core仕様のSIOPを拡張 • openid:// だけでなく、https://も使えるように • App Links, Universal Linksや、クラウド連携のWalletも想定 • sub値として、jwt Fingerprintだけでなく、DIDも使えるように • OpenID Connect⾃体にsub値の制限はないが、SIOPv1仕様では jwt fingerprintと規定 WalletからVerifierに対してVCを提⽰する際に、 OIDC4VPと組み合わせて利⽤することを想定 VCの発⾏ VPの提⽰ OpenID BizDay #15 再掲

OpenID for Verifiable Presentations • OAuth2.0のプロトコルでVC/VPを返却する拡張 • 直近のドラフトで、OIDCからOAuth2.0ベースになっているので注意 • 新たに VP トークン を定義し、IDトークンと独⽴して返却 • OAuth2.0のスコープ(scope)に、求めるVC/VPの種類を指定、 もしくは presentation_definition で細かく指定 WalletからVerifierに対してVCを提⽰する際に、 SIOPV2と組み合わせて利⽤することを想定 VCの発⾏ VPの提⽰ OpenID BizDay #15 再掲

OpenID4VP: リクエストとレスポンスの例 リクエスト レスポンス vp_token には、JSONを格納したり、 mDL で使われる CBOR を base64 エンコードして格納して返却 presentation_definition に 欲しいVP/VCの形式等を指定 OpenID BizDay #15 再掲

OpenID for Verifiable Credentials Issuance • IssuerからWalletにVCを発⾏するためのOAuth2.0の拡張 • OAuth2.0のスコープ(scope)に、VCの種類を簡易的に指定、 もしくは authorization_details (RAR)で種類、形式を細かく指定 • 最初の認証をスキップし、認可コードをQRコードにして Walletに読み込ませることも可能 (pre-authorized code flow) IssuerがVCをWalletに対し発⾏する際に利⽤ Issuerがユーザを認証する際にVC/VPを提⽰させる場合、IssuerがVerifierにもなる VCの発⾏ VPの提⽰ OpenID BizDay #15 再掲

pre-authorized code flow の例 • 対⾯で本⼈確認を⾏った後、ユーザの端末にVCを発⾏する ユースケースで有⽤ 店頭などで本⼈確認を⾏った後、 Walletに読み込ませるQRコードの例 access tokenを受領して(中略) Credential EndpointからVCを取得 Walletはcredential_issuerのmetadataを 確認し、Token Endpointにアクセスする QRコードに含まれる Credential Offer オブジェクトの例 通常のOAuthフローで認可後に得られる 認可コードの代わりに、プレ認可コードが ここで得られる。 JWT形式のVCがここで得られる。 OpenID BizDay #15 再掲

Digital Credentials Protocols (DCP) Working Group とは • OpenID Foundationで新たに設⽴されたWG • 2023年8⽉31⽇に第1回開催、47名が参加 • WGのゴールは、Issuer-Holder-Verifier モデルのユースケー スに関連するOpenID仕様を開発し、あらゆるフォーマットの デジタルクレデンシャルの発⾏と提⽰、およびエンドユーザか らVerifierに対する仮名での認証(pseudonymous authentication)を実現すること。 https://openid.net/announcing-the-digital-credentials-protocols-working-group/ https://openid.net/wg/digital-credentials-protocols/charter/ https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20230828/000000.html

DCP WGで作成する仕様 • 既存の OpenID4VC 基本3仕様は、当⾯AB/Connect WGで 継続運⽤（WG間の仕様の移管⼿続、IPR(知財)の問題） • Self-Issued OpenID Provider v2 (SIOPv2) • OpenID Connect for Verifiable Presentations (OpenID4VP) • OpenID Connect for Verifiable Credentials Issuance (OpenID4VCI) • 新たに下記新仕様を開発予定 • OID4VC High Assurance Interoperability Profile with SD-JWT VC • OpenID for Verifiable Presentations over BLE • OpenID Connect UserInfo Verifiable Credentials • Security and Trust in OpenID for Verifiable Credentials

OID4VC High Assurance Interoperability Profile with SD-JWT VC (HAIP) • 基本3仕様(SIOPv2, VP, VCI)を使って、SD-JWTによるクレデンシャ ル発⾏・利⽤時の相互運⽤性を確保するためのプロファイル • VCI • pre-auth codeとauthorization code flow両⽅サポート必須 • DPoP対応必須（クライアントの所有する秘密鍵による認証） など • VP • presentation_definitionの送信必須（DIF Presentation Exchange準拠) • 認可リクエストには request_uriの利⽤必須 などなど • SIOPv2 • Wallet起動にはcustom url scheme対応必須 • sub値には DIDでは無くJWK-Thumbprintを使う など • EUのARFを強く意識して開発されているとのこと https://vcstuff.github.io/oid4vc-haip-sd-jwt-vc/draft-oid4vc-haip-sd-jwt-vc.html

SD-JWT とは • Selective Disclosure: 選択的開⽰ • 年齢確認だけのために、住所⽒名⽣年⽉⽇すべて含まれた⾝分証を提 ⽰する必要はない。 • 発⾏されたクレデンシャル内の、必要な情報だけを取り出して開⽰で きる仕組み。 • SD-JWTは、ソルトをつけてハッシュ化された値が含まれた JWT。開⽰したい情報と、ソルトを合わせて相⼿に渡せば、 ハッシュを検証することでJWTにその情報が含まれていること が分かる。 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05 https://www.imes.boj.or.jp/research/abstracts/japanese/23-J-08.html

SD-JWTによる選択的開⽰の⽣成 "_sd": ["Ch-DBcL3kb4VbHIwtknnZdNUHthEq9MZjoFdg6idiho”] ["2GLC42sKQveCfGfryNRN9w", "first_name", "Erika"] クレーム名 ソルト(乱数) 値 Base64URLエンコード WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImZpcnN0X25hbWUiLCAiRXJpa2EiXQ SHA256ハッシュ＋Base64URLエンコード ① ② ②の含まれたJWTだけを受領した相⼿は、中⾝に何が書いてあるのか分からない。 ①と②を受領した相⼿だけが、中⾝を知り、検証することができる。

SD-JWT とは • Selective Disclosure JWT • JWT内のクレームを、ソルトをつけてハッシュ化したもの

SD-JWT の弱点 • 毎回同じデータを相⼿に渡してしまうので、同⼀のSD-JWTを 受け取った複数or単⼀のVerifierは、相⼿が同⼀⼈物であると分 かってしまう。（名寄せ or リンク不可能性） • たとえば13才以上を証明してTwitterの裏垢をつくったら？ • これを解決するために、BBS+署名などのZKP(ゼロ知識証明) ⽅式を提案、推進している⼈たちもいる。 • ZKP⽅式は、まだ各国政府の採⽤暗号リストに掲載されておらず、 実装のバグが⾒付かるなど、まだmatureではないという意⾒もある • SD-JWT派は、ソルトを変えた複数のSD-JWTを使い分ければいいと主 張

OpenID for Verifiable Presentations over BLE • MOSIPから提供された仕様案 • MOSIP: The Modular Open Source Identity Platform • 「インド国内のデジタルIDプログラム (India Stack) をベースに、 eガ バメント (電⼦政府) のあらゆるデジタル公共サービス提供メカニズム の 基礎的なビルディング・ブロックを形作るデジタル⾝分証明(デジ タルID) プラットフォームを、第三国展開⽤にパッケージ化した」 • オフラインでも対⾯でBLE経由のVC/VP提⽰が可能。 • 当仕様にもとづくAndroid, iOSでの実装が、Open Wallet Foundation にコントリビュートされている。 https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-over-ble-1_0.html https://www.meti.go.jp/meti_lib/report/2020FY/000190.pdf https://openwallet.foundation/2023/08/23/openwallet-foundation-announces-google-as- premier-member/ ※MOSIPについては経産省資料が詳しい

OpenID Connect UserInfo Verifiable Credentials • OpenID Connectのuserinfoエンドポイントで得られる情報を、 VCに詰め込んで渡す⽅法を規定した、主にVCIのプロファイル • UserinfoでVCを渡すのではなく、VCにUserinfo相当の情報を詰める • ここでのVCとは、W3CのJWT-Formatted VCのこと • Issuerがサーバダウンしても Verifierが受領したVC/VPを検証 できるよう、 Issuerの公開鍵（JWK Sets）をJWT(signed)で公 開、第三者によるキャシュ、再配布も可能とした • UserinfoをVCに変換する標準的な⽅法を定めることで、既存の OpenID ProviderがVCを発⾏しやすくしたり、既存の拡張仕様 （IDAなど）をそのまま活⽤できるようになると期待される https://openid.net/specs/openid-connect-userinfo-vc-1_0-00.html

OpenID Connect UserInfo Verifiable Credentials presentationの⽅法はスコープ外 • 既存のjwks urlに Accept: application/jwtで アクセスすると、jsonの代わりにJWTが返 却される • Discovery metadataにcredential_endpoint、 credentials_supported を追加 • JWT-formatted VCのcredentialSubject内に、 userinfo相当のクレームを格納して返却 • scopeにuserinfo_credentialを追加指定 • tokenエンドポイントでc_nonce, c_nonce_expires_in を追加で返却 • credentialエンドポイントの利⽤

Security and Trust in OpenID for Verifiable Credentials • この仕様上ではあらゆるVCを対象とする。 • Issuer-Holder-VerifierモデルでTrustを実現するために必要な コンセプトやセキュリティ要件を⾔語化して定義 • Issuer Identification, Authenticity of Claims, Identity of Holder, Integrity of Interaction, Privacy, Context, Correctness of Claims, Wallet Integrity • Holder Binding: Credentialの主体を特定する⼿段を、 Biometric, Claim-based, Cryptographicの３種と定義 • ３者とも、必要以上のデータを保持してはならない などなど • さらに、定義した要件が、VC基本３仕様で満たせることを⽰す • 型式証明ではない：今後実施予定 https://vcstuff.github.io/oid4vc-security-and-trust/draft-oid4vc-security-and-trust.html

IDA: OpenID Connect for Identity Assurance OpenID Connectの仕組みを使い、本⼈確認済みの ID情報を連携するための仕様 おまけ OpenID BizDay #15 から⼀部修正

IDA: OpenID Connect for Identity Assurance • 本⼈確認済みのID情報(Identity Assurance) を連携するための、 OpenID Connect の拡張仕様群 • 年内にFinal化を⽬指して最終調整中。 • OpenID Connectでサポートされている各種個⼈情報に対して、 「誰が」「どのように」「いつ」「何を元に」確認したかを、 メタデータとして付与することができる。 • Verified Claims (verified_claims)というオブジェクトを定義 • 共著者として⼩岩井も名を連ねる OpenID BizDay #15 から⼀部修正

OIDCを拡張した トランスポート層 の定義 OpenID Connect for Identity Assurance 追加claimの定義 OpenID Connect for Identity Assurance Claims Registration place_of_birth、 birth_family_name 等の定義 verified_claimsの スキーマ定義 OpenID Identity Assurance schema definition verified_claims, vefirication, claims 等の定義 ファイルの添付 Attachments ● ● ● リクエスト・レスポンス OP metadata, aggregated_claims等 IDA仕様は主に3つの仕様からなる 式による表現 （age>20,name=太郎) Advanced Syntax for Claims 追加仕様も検討中

2つのVC • W3C の策定する Verifiable Credentialsと IDA仕様で定義された Verified Claims (verified_claims)との間に直接的な互換性はない。 • Verified Claimsは、OpenID Connect仕様の IDトークンの中に格納 されるため、IDトークンとして署名され、検証可能。 • Verifiable Credentials はそれ⾃体が署名され、検証可能。 • Verified Claimsは、属性情報とそのメタデータの記載⽅法も含め標 準化されている⼀⽅、Verifiable Credentialsの中⾝の標準化はこれ から。（ワクチン証明書のFHIRが⼀例） • Verifiable Credentials 内に本⼈確認済み情報を格納するため、 Verified Claims のデータモデル(スキーマ)の利⽤が検討されている。 ※ IDA仕様が3分割された理由の1つはスキーマの流⽤性確保 penID BizDay #15 再掲 OpenID BizDay #15 から⼀部修正

今⽇はこれだけ覚えて帰ってください。 • OpenID4VC: VC/DID関連3仕様の俗称 • SIOPv2: OpenID Connect(OIDC)の既存仕様を拡張し、 DIDやhttps型のアプリ連携やクラウドウォレットに対応 • OpenID for VP: VC/VPを提⽰するためのOAuth2.0の拡張 新たにVPトークンを定義 • OpenID for VC Issuance: VCを発⾏するためのOAuth2.0の拡張。QR コードによる認可コードの連携が可能 • DCP WG: Digital Credentials Protocols Working Group • VC関連のさらなる仕様策定のために新たに設⽴したWG • HAIP: OpenID4VCを使って、SD-JWTによるクレデンシャル発⾏・利 ⽤時の相互運⽤性を確保するためのプロファイル • その他BLE利⽤、userinfo拡張などの仕様も策定中