DIF Japan Monthly Call #5 『OID4VC, SD-JWT VC等』
OID4VC, SD-JWT VCの最新動向について
分散型IDのシステムを構成するクレデンシャルフォーマット、識別子、アルゴリズム、ステータス、トラスト・フレームワーク、発行プロトコル、検証プロトコル、認証プロトコル等の技術要素(前提)。
クレデンシャルと発行プロトコルごとにエンティティの識別子、対応する公開鍵を持ってくる仕組み、対応する識別子を信頼するためのトラスト・フレームワークが必要。暗号アルゴリズムも相互互換性の観点から重要。
個人とユーザーが関わってくるフローは、OpenID for VC スタックにまとまりつつある。クレデンシャルフォーマットはまだ時間かかりそう。
OpenID for Verifiable Credentials の仕様リスト:
OpenID for Verifiable Credential Issuance (OID4VCI) - 検証可能なクレデンシャルを発行するための API および対応する OAuth ベースの認証メカニズム
OpenID for Verifiable Presentations (OID4VP) – OAuth 2.0 の上に、プロトコルフローの一部として検証可能なクレデンシャルの形式でのクレームの提示を可能にするメカニズム
Self-Issued OpenID Provider v2 (SIOPv2) – ユーザーが管理する OpenID Provider (OP) を使用することを可能にする
OpenID for Verifiable Presentations over BLE – 検証可能なクレデンシャルの提示を要求するために、Bluetooth Low Energy (BLE)を使用できるようにする。OID4VP で定義されているリクエストとレスポンスのシンタックスを使用する(OID4VPオンフラインでどうするの問題を解決)。
OpenID Connect UserInfo Verifiable Credentials – OpenID Connect UserInfo Endpoint から現在提供されているユーザ属性を、検証可能なクレデンシャルとして発行できるようにする。
上三つがコアな仕様。BLEは、ISO/IEC TS 23220-4, ISO/IEC TS 18013-7 のmDLs (運転免許書)でオフラインではMDLs仕様のものしか送れない問題があり、オフラインでもVCが送れるようにOID4VP over BLEを検討。Moshipがフィリピンでのroll outでOID4VP over BLEを利用。もうちょっと実装者増えてほしい。IdP の UserInfo を VC にして、Identity Proofing を OID4VP で行う取り組みがある。
Verifiable Credential Data Model
W3C VC Working Group では、JSON-LD のみに。W3C VCDM が一般的なものではなくなる。OID4VC の Terminology では W3C VC を明示的に分けている。JSON で SD-JWT ができる技術仕様を IETF に提案してる人もいる、W3C と IETF 的な VC Data Model に分岐しそう。W3C VCDM2.0 の JSON-LD と SD-JWT VC, SD-JWT VP との mapping algorithm が定義、mapping しれば W3C VC だよねという決議。
High Assurance Profile of OID4VC with SD-JWT
各自が Profile を定義して OID4VC を利用するための SD-JWT VC のHigh Assurance Profile を公開。
4.2.2.2 Registered JWT Claims の `cnf` について
`cnf`: Cryptographic holder binding がサポートされる場合は必須。[RFC7800] で定義されている確認方法を含む。RFC7800 のセクション3.2で定義される JWK を含むべきであり、この場合、JWK に kid member が存在しなければならない(MUST)。Cryptographic holder binding の場合、presentation の holder binding JWT は、この claim で特定された鍵によって署名されなければならない(MUST)。
Holder の key rotation を前提としない場合には、confirmation claim 、did:key、did:jwk が選択肢。どちらから見るかの話。OID4VC holder binding では最低限 confirmation claim はサポートしてね。
RFC7800によるとこんな感じ。
{
"iss": "https://server.example.com",
"aud": "https://client.example.org",
"exp": 1361398824,
"cnf":{
"jwk":{
"kty": "EC",
"use": "sig",
"crv": "P-256",
"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
"y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
}
}
}
}
X.509 Certificate 使う場合、X.509 Certificate SHA-256 Thumbprint を x5t#S256という名前で `cnf` に加える ref: RFC8705
{
"iss": "https://server.example.com",
"sub": "ty.webb@example.com",
"exp": 1493726400,
"nbf": 1493722800,
"cnf":{
"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
}
}
質問: Issuer 側の公開鍵も、JWK として JWT にくっつければいいですか?
5.1 JWT Issuer Metadata Request に余白を残していて、 PKI ベースのアプローチも検討している。
`iss` がURLのときに /.well_known/jwt-issuer というpathを付与して、これを参照すると、issuerの jwks がみれるやりかた。
X.509: 欧州連合は eIDAS1.0 で X.509 のインフラが整ってるので、最初は X.509 を利用するのでは?
`client_id` scheme で`pre-registered`, `redirect_uri`, `did` 等を指定できる。ここに PR が飛んでいて、ここに `x509_san_dns` や `x509_san_uri` が指定できるようになる。header の thex5c をとって、domain が一致するのか確認する。
X.509 を JWT で作り直す動きもある(OpenID Connect Federation、X.509のJWT版)。
分散型のトラストチェーンをつくる動き、DI-Linked Resources (cheqd)
DIF Japan について
DIF Japan とは 分散型ID の標準化を推進する DIF: Decentralized Identity Foundation の Japan SIG です。現在 DIF Japan を運営する仲間を募集しています。詳細はこちらからご覧ください。
DIF Japan では毎月第四金曜日9:00-10:00 ( JST ) に Monthly Call を開催しています。
Monthly Call Schedule (2023.02.03時点)
2月3日(金)9:00-10:00 / zk-SPARQL: SPARQLクエリに対して検証とプライバシ保護が可能な結果を返すパーソナルRDFデータストア / Dan Yamamoto
2月24日(金)9:00-10:00 / M2MコミュニケーションにおけるDIDCommの実装と技術優位性 / Masayoshi Mitsui
4月7日(金)9:00-10:00 / Selective Disclosure JWT (SD-JWT) の実装 / Kazuhide Yasukata / Yumin Haku
4月28日(金)9:00-10:00 / DID・VCユースケースの紹介 / Naohiro Fujie
5月26日(金)9:00-10:00 / OID4VC, SD-JWT 最新動向 / Kristina Yasuda
6月30日(金)9:00-10:00 / 共助トラストのエコシステム構築 / DNP
ご関心のある方はぜひ気軽にご参加ください。
DIF Japan SIG のメーリスか、三井( mitsui@collabogate.com )までご連絡いただけると幸いです。
この記事が気に入ったらサポートをしてみませんか?