2024年10月31日木曜日

IIW 39 Day2クィックレビュー

こんにちは、富士榮です。

ということでInternet Identity Workshop(IIW)も2日目です。

今日は朝からワーキンググループコールも入っていたので早めの時間から会場でZoomコールをしていたのでより疲れました。

ということで、本日のレシピは、
  • Delegation + Impersonation for Agents on behalf of human
  • Wallet + Key Attestation
  • Zero Knowledge Proof for mdoc
  • Originator Profile
  • JSON-LD VC with BBS Signature
の5本です。

ということで観ていきます。

Delegation + Impersonation for Agents on behalf of human… OIDC, OAuth

まずひとつ目です。最近よくきくエージェントに自分の代わりに何かをさせましょう、って話です。


まぁ、色々と話はしましたが結果的にOAuthのモデルに当てはめるとどう考えられるのか?という話だったのでそれほど目新しさはなかったですね。

当てはめとしては、
  • Resource owner : End user
  • Client : Agent
  • Relying party : API
とおいているので、まぁそうでしょうねぇ。

Agentかどうかは置いておいて普通のOAuthですね。Token Exchangeつかえそうだね、みたいな話もありましたが。

Wallet + Key Attestations - Paul, Christian, Kristina

ドイツのWalletの検討の話です。かなりノウハウが溜まってきていますね。

検討の対象は以下の2つのアテステーションです。
  • Wallet/Client Attestation:ウォレットが正しいかどうかを示す
  • Key Attestation : キーストレージの状態とユーザの認証状態を示す
EUでは政府認定の民間ウォレットに対して国がクレデンシャルを発行する、というモデルを取るため、野良ウォレットでないこと、ユーザが認証されていること、秘密鍵がちゃんと管理されていることを示さないとクレデンシャルの発行など怖くてできないわけです。

チェックのタイミングについても色々と考えていて、
  • Issuerがクレデンシャル発行をする際:WalletもKeyも必須
  • ウォレットからVerifierへクレデンシャルを提示する際:オプション(Issuerが発行時に確認しているから推移的に確認できる、という判断もあり)


アテステーション自体はWallet Providerが発行します。
ここの発行・管理プロトコルは標準化されていませんが、いずれ標準になってくるのかもしれません。(まぁウォレットベンダーがそれぞれやってよ、でもいいんだと思いますが)

この仕組みがあることで、以下のようなシナリオに対応ができるようになります。
  • スマホの機種変更
  • 複数端末の利用の管理
  • 端末を盗まれた、無くした
  • ウォレットに脆弱性が見つかった
どう言うことかと言うと、Issuerはクレデンシャルを発行する時に発行先のWalletの情報(アテステーション)を管理しているので、ウォレットプロバイダがウォレットアテステーションをRevokeするのをトリガーにIssuerは発行済みのクレデンシャルをRevokeする、という使い方ができます。こうすることで機種変更時や盗難時などに以前の端末に入っていたクレデンシャルを一括で無効化できるので安心、というわけです。
属性証明と違って本人確認書類とし利用する身分証明書となるとやはり発行管理が必要になるので、日本のように民間のウォレットがマイナンバーカードに依拠したクレデンシャル(いわばマイナンバーカードのコピー)を身分証明書として利用できるなんて変なことは起きないわけですね。

ちなみにVerifierに提示する際にWalletアテステーションを提示するかどうか、って議論もありましたが個人的にはLinkabilityが上がっちゃうのでやめたほうがいいんじゃないかな?って思います。やっぱりIssuer側でちゃんと管理って世界なのかと。

Zero Knowledge Proof for mdoc - Google

次はGoogleの方からmdocに関するZKPの実装の話です。

先ほどのWalletアテステーションのセッションのところにも書きましたが、mdocでもSD-JWTでもプロトコルの一部としてリンク可能性を高めてしまう情報が埋め込まれてしまうことがあります。
これをなんとかできないか?って話ですね。


そうするとデバイスとのバインドを示す鍵の置き場所はSEに限られてしまう、と。
この鍵はPresentation時に使われるので、BBS+などIssue時にデバイスバインドされた鍵の変更を要求する仕組みを使うのは非常に難しいってことになってしまいます。何しろ一番下のレイヤーの変更をしなきゃいけないって話になるので。

mdocやSD-JWTで選択的情報開示をすることでデータ見にマイゼーションの問題が解決できたとしても、リンク可能性の問題が残っちゃうよね、って話は前からありましたが、いよいよそこに手をつけ始めようとしている感じですね。



Googleでは内部ロジックの高速化などを図り、BBS+など従来の”スマートな”方法ではない方法(Hyrax)を模索していく、ということです。


Originator Profiles - Shigeya Suzuki

鈴木先生によるオリジネータープロファイルの話です。
何気に中身を詳しく聞いたことはなかったので非常に興味深かったです。

コンテンツの発行元とコンテンツの内容の真正性の両方をちゃんと検証できるようにしましょう、って話に加えて認められた場所(アグリゲーターなど)でその情報が発信されているかどうかを確認できるようにしましょう、という仕組みです。

現状はブラウザにエクステンションを入れてチェックするとブラウザの中で表示されているコンテンツ(ニュースなど)がどのメディアによって発行されたものなのか、そのメディアはどう言うプロファイルなのかなどが確認できるのと、ちゃんと許可されたサイトでコンテンツが表示されているか確認できます。

偽情報・誤情報を利用者自身で確認できるようになるのはいいですし、広告主が意図しないサイトに広告が掲載されてしまうことが防げるようになるとブランドイメージの保護などにも役立ちそうです。

今後が非常に楽しみです。


JSON-LD VC with BBS - Dan Yamamoto

最後はIIJの山本さんのBBSの話です。


BBSの部分は前回まででほぼ完成しているので今回のポイントはやはりリンク可能性です。今日はこのテーマで1日終わった感じです。やはり熱い領域です。

山本さんのアプローチはPseudonym did:keyを使うということです。
これはひとつの秘密鍵に対応する複数の公開鍵を作成できる技術をうまく使ってIssue時、Verify時にSubject Identifierとして使う署名検証鍵を含む識別子(did:key)の出汁わけができる、と言うことです。

ドメイン単位でこれを使うことでInner domain linkabilityとinter domain linkabilityの両方を実現できるわけですね。



まだ標準化へ持ち込めているわけではないそうですが、今後の標準化が望まれますね。


ということで明日は最終日です。


2024年10月30日水曜日

IIW 39 Day1クィックレビュー

こんにちは、富士榮です。

今年もInternet Identity Workshop(秋)が開催されています。
場所はお馴染みComputer History Museum@マウンテンビューです。

世界中からIdentity Geek達が集まってきて生煮えの技術について話し合います。
(まぁ、SIDI Hubを含めいつもの面々ですが)

ということでDay1について見ていきましょう。

Progressive Trusted Registry - Dmtri, etc

お馴染みのDmtri達の新しい論文をベースにしたセッションでした。

外だったので若干寒かったです。。

テーマは、どうやってTrusted Registryを構成するか?
KYC後、インクリメンタル・プログレッシブにトラストを構成していくためにLinked Claimsを使っていくアプローチについてのディスカッションです。
レピュテーション、他のトラストフレームワークによって管理されているEntityから発行されたVerifiableなアテステーションを用いる、などなど。
レピュテーションを買えてしまう時代なので、ネガティブClaimをうまく使ってノイズをフィルタリングをしていく、などのアプローチについて議論が行われました。
グラフ理論ですな。昔のConnect.meとかrespect networkの話を思い出しました。
レピュテーションのスコアリングの話も出ましたが、まぁ、結局はVerifierがクレデンシャルのIssuerを信じる度合いは、VerifierとIssuerが同じコンテキストにいるかどうか、というあたりも大きな要素ですよね、って話もあり、モデリングは非常に難しいよね、って話をしたりしました。共感認知の話ですな。

しかしこうやって見ていくと、みんなセントラル・レジストリを作りたがるんですよね。。
ダイナミックにGraphを構成したりDiscoveryしたりするための分散データベースのようなアーキテクチャの方がLinked Dataには合っている気がするんですが。
結局、やりたいことってSemantic Webですよね。。


Digital Fiduciary Initiative - Joe Andrew

タイトルの通り受託人(医者とか会計士みたいにクライアントの代わりにプロフェッショナルとしてサービスを提供してくれる人たち)のデジタル版がどうやって信頼の形成に役に立つのか、という話です。

文明が生まれ部族社会が出来上がり社会の中と外の境界が生まれた。すごいところから始まりますね。

機械化、IT化が進み人類の果たす役割は減っていく。まさに限界費用逓減。
そんな中、人々が社会参加していくには信頼できる情報をAssertしていくことが必要な一方で監視社会が進んでいく。
一方でビットコインはTrusted Authorityなしで(衆人環視の元)信頼できるトランザクションを実現することとなった(マネーロンダリングの温床となるなど問題も同時に産むこととなったが)。DIDはそのアイデアを識別子の世界に持ち込むことで一定のイノベーションを産んできたわけです。Login with FacebookがFacebookを信頼する必要があることに対してDIDは暗号アルゴリズムに対する信頼を行う、という点が異なる。分散型アイデンティティを実現する上で、VCをどうやって信頼するか?という問題が残っている。

Digital Fiduciary Initiativeのアプローチ

Fiduciary(受託者)、例えば医者や弁護者や会計士など人々に代わって特別な領域を扱う人々を指す。
デジタル受託者はアイデンティティを扱うのを助ける。Digital Fiduciary Initiativeは誰が受託者としてアイデンティティを扱うに資するためのResolution processを助けるプロトコルを提供している。


なるほど、受託したFiduciaryサービスが利用者にVerifiable Credentialsでクレデンシャル(Fair Witness Credential)を発行する、と。医者がカルテをVCで患者に提供したり会計士が会計監査した証明書をVCで発行したりするのに近いのかな?

情報銀行+公証人ってイメージかも。

こちらで活動しているから興味がある人はどうぞ、とのこと。


CBOR and Gordian Envelope - Christopher Allen

次はChristopher AllenのCBORとGordian Envelopeの話です。
暗号学者の話&資料なしのガチ議論セッションなので正直ついていけないところも多いのですがざっくりと。
ちなみに彼のBlogに色々と書いてあるので気になる人はそちらを見ましょう。



CBORの話は、DID Controller Document(いわゆるDID Document)をdCBORで作ることで鍵ローテーションや署名の追加などへの対応が軽くなるよね、って話でした。
現在のDID Controller Documentって鍵の追加・ローテーションを行うとどんどんサイズが大きくなるわけです。公開鍵の情報がどんどん追加されていくので。
なのでJSONベースでやるんじゃなく、そこをバイナリベースのCBORでやることでサイズを減らせる&分散台帳上でのブロック生成〜伝搬にかかるコストも下げられるし、IoTシナリオでは如実に通信コストが下げられるよね、って話です。

また、Float計算などコンピューターの系によって計算結果が若干異なってしまうことによるValueが決定的に扱えないことに対する解としてDeterministic CBOR(dCBOR)を使うのが良い(理由は後から)ってことです。

dCBORの仕様はこちら

で、ここでGordian Envelopeの話ですが、ざっくり理解だとEnvelopを構成する要素のSubject、Object、PredicateでMerkleツリーを作っていきましょう、という話っぽい。SubjectもObjectもPredicateもそれぞれが下位の構造を持つのでそれを含めて。

そしてその時の各要素に関するハッシュをdCBORで決定論的に値を作れば綺麗にTreeはできるし、計算量もさらに減らせる、みたいな話かな。と。(よくわかっていない。読まねば)

Gordian Envelopeの仕様はこちら

選択的情報開示などにも対応できるし、TreeをGraph構造としてみなした時のノード間のエッジに双方向の意味付けをすることでマルチシグやグループ署名にも対応できる、など色々とありそうですがもうちょい勉強します。

DCQL - Daniel Fett

次はOpenID for Verifiable Presentations向けの新しいクエリ言語「DCQL - Digital Credentials Query Language。ダックル」の話です。
みなさんご存知の通り現状のOID4VPはPresentation Exchangeを使っているわけですが、こちらが複雑すぎるので新しくクエリ言語を作ってしまえ、ということのようです。


ちなみにDanielのTシャツはDCQL。イラストもスライドの写真もダックスフンドです。

DCQLは次のOpenID for Verifiable PresentationsのImplementer's draftに盛り込まれる予定で、
  • OID4VPにおけるPresentation Exchangeを置き換えるかもしれない
  • クレデンシャル提示を求める際のJSONベースのシンタックス
  • クレデンシャルフォーマットを問わない(sd-jwt-vcでもmdocでもOK)
という特徴を持ちます。

開発に至るモチベーションとしては、
- PEがややこしい
- ブラウザAPIで使えるようにする必要がある
ということのようです。

具体的にPEのややこしさとしてあげられたのは、
- JSONPathが必要
- JSON Schema Filtersが必要
でした。

まぁ、PEは機能が豊富だが、OID4VPで全ての機能が必要だったわけではないということですね。この辺りはドイツのFUNKEのコンペの中で色々と学びがあったそうです。

余談ですが、スピーカーのDaniel FettはOpenID Connect for Identity Assuranceの仕様策定時にもAdvanced Syntax and Claims(ASC)というクエリ言語を作成して提案していましたので、かなりの部分で似た仕様になっています。そのうち統合するの?って聞いてみましたが、ありかもな〜という雰囲気。

使い方としてはAuthorization Requestにdqcl={....}という形でクエリパラメータとしてくっつける形を想定しています。
例えば、sd-jwt-vcの場合はこんな感じの書き方になるようです。
{
"credentials": [
{
"id": "my_credentoa;s".
"format": "vc+sd-jwt",
"meta": {
"vct_valies": ["httos;//xxxxx"]
},
"claims": [
{ "path": ["last_name"]},
{ "path": ["first_name"]},
{ "path": ["address", "street_address"]},
]
}
]
}

なお、mdocの場合はpathがないのでその代わりにネームスペースを使います。

クエリ言語としての機能としては、
- Claimのorが取れる
- クレデンシャルのorが取れる
- Claimのバリューマッチングができる
というところのようです。

例えば、xとA1、A2、yというクレームのセット、もしくはxとBとyでも良いよ、という書き方はこのようになります。
"claim_sets": [
["x", "A1", "A2", "y" ], →この組み合わせか
["x", "B", "y"] →この組み合わせでもOK
]

同じようにクレデンシャルを複数要求してみてその中のどれかを提示すれば良いよ、というクレデンシャルのorを取るならこんな感じです。
"credential": [
{
"id": "pid",
"format": "vc+sd^jwt"
},
"credential_sets": [
{
"purpose": "Identification",
"options": [
[ "pid" ],
[ "other", "other2"]
],
"purpose": "show your xxx",
"required": false,
"options": [
[ "nice_to_have" ]
]
}
]
]

optionsでidでorを書けるのに加えてrequiredでオプションかどうかについてもかけるわけですね。

そして最後に値によるマッチングです。
"claims": [
{
"path": ["last_name"],
"values": ["Doe"]
},
{
"path": ["postal_code"],
"values": ["90210","90211"]
}
]

こちらはわかりやすいですね。

なお、多言語化など未実装の事柄はたくさんあるそうなのでぜひFeedbackを、という話ですが、あんまりFeedbackしすぎで多機能化するとPEと同じものになってしまいそうなのでほどほどにしておくのが良さそうです。


Edge Identifiers - Christopher Allen

最後は再びChristopher Allenです。
先のセッションでも実は触れられていたのですが、このセッションはGraphを作成する時のEdgeを双方向にしてIdentifierをつけていく、というEdge Identifierについてです。

Edgeを双方向にして意味を持たせるってことみたいですが、正直理解が追いついていないのでこちらもおいおい勉強です。

親子という関係があった時に、親ノードA、子ノードBの間には以下のEdgeが出来上がります。
- AはBの親
- BはAの子
こう言う形で単にEdgeといっても方向性があり、それを双方向で表現することが肝のようでした。

こちらも彼のBlogに書かれています。



ということで初日は終わりです。
相変わらず日本時間とのダブル生活になるので西海岸は辛いですね。来週はIETFでアイルランドなので少しはマシかもしれません。

2024年10月28日月曜日

OpenID Foundation Workshopクィックレビュー

こんにちは、富士榮です。

今回もInternet Identity Workshop(IIW)に向けてマウンテンビューにきています。
今年はアイデンティティに関する動きが業界として激しかったので情報過多な回になりそうです。

ということで、恒例の前日イベント、OpenID Foundation Workshopに参加しました。

アジェンダはこちらにありますが、どうもURLが前回のままでCISCO開催っぽく見えますが今回はMicrosoftのシリコンバレーオフィスでの開催です。(IIWが開催されるコンピューター歴史博物館の隣です)

こちらが会場です。


アジェンダはこちらです。

TIME

TOPIC

PRESENTER(S)

5 min                     

Welcome

Nat Sakimura & Gail Hodges

5 min

OIDF New News

Gail Hodges

15 min

Authority Specification Concept

Rachel O’Connell, Mark Haine, & (TBC) Denise Tayloe

10 min

OIX Transition Update/Briefing

Elizabeth Garber & Mike Leszcz

10 min

Member Survey Findings + Member Feedback for Input to 2025 Planning

Elizabeth Garber & Paul Briault

15 min

OWF/SIDI Hub/ OIDF in 2025

Gail Hodges, Elizabeth Garber, and Daniel Goldscheider

15 min

Ecosystem CG/WG Brainstorming Session

Dima Postnikov & (TBC) Mark V., Elcio

15 min

Shared Signals & Open Banking Use Cases (OFB, CMF)

TBC 

10 min

OIDF Certification Program Update

Joseph Heenan, Mike L.

10 min

DADE CG Update + Next Steps

Dean Saxe

10 min

Introduction to the IPSIE WG

Aaron Parecki

5 min

WG Update – Connect

Mike Jones

5 min

WG Update – AuthZEN

Omri Gazitt

5 min

WG Update – DCP

Kristina Yasuda, Joseph Heenan & Torsten Lodderstedt

5 min

WG Update – eKYC & IDA

Hodari McClain

5 min

WG Update – FAPI

(TBC)

5 min

WG Update – iGov

John Bradley

5 min

WG Update – MODRNA

Bjorn Hjelm

15 min

US Open Banking/ CFPB / FDX Partnership Brief 

Gail Hodges & Joseph Heenan

15 min

Q&A

 


ということで順番に。

OIDF New News - Gail Hodges

ざっくりこの辺りがニュースとして報告されました。本当多いですね。
  • OpenID Connect for Identity Assurance final
  • OIDC is an ISO standard(PAS)
  • OIX staff and assets onboarded to OIDF
  • CA DMV+OIDF community hackathon #1
  • Security analysis on Federation approach delivered by Stuttgart
  • FAPI WS with Chilian Ministry of Finance
  • NIST SP800-64-4 submission completed
  • UAE $30k directed funding and membership underway - open banking
  • Updated Process document and IPR policy approved
  • CFPB financial rule published including communications protocol
  • SIDI Hub Summit Tokyo
FAPI、Open Banking周りはCFPB(Consumer Financial Protection Bureau。アメリカ合衆国消費者金融保護局)との関連も含め色々と動いていますね。

また、この後もIIWやDMV+OIDF community hackathon #2などイベントも予定されています。

Authority Specification Concept - Rachel, Mark, Denise

OpenID Connect for Identity Assuranceと同じくeKYC WGで検討しているAuthority Claims Extensionのユースケースについてです。こちらのエクステンションは対象のEntityと特定のEntity(主に法人)との関係性を表現するためのもので、例えば当該のEntity(人)が特定のEntity(法人)の代表権を持っている、などの関係性を表現できるのが特徴です。

こちらの法人にあたる部分をうまく使って親子関係を表現することで子供のオンラインアイデンティティを保護していこう、という取り組みです。
例えば、国によっては一定の年齢以下のアカウントについては親の同意が必要ということが法令等で定められていますが、これまで親子関係をうまく表現する方法がなかったので、そちらに対して何らかの解が出せないか?という話ですね。

やるべきこととして、
  • 親による同意の取得
  • 親子関係の検証
  • 年齢の確認
などをプライバシーにうまく配慮しながら、法令等へちゃんと対応できる形で実装するために、ISOやOIDFの持っている仕様を拡張していく、また分散型のアプローチやゼロ知識証明(ZKP)についてもうまく使っていくことができないか?という検討をしています。


この辺りを見ているとかなり親子関係の確認にコストがかかっているようなので、技術で解決策を作れると良さそうです。


この辺りをISOやIDAのAuthority Claims Extensionで何とかできるかも、って話でした。


分散型のアプローチやZKPも含め進めていきましょう、と。

OIX transition update - Mike Leszcz

Open Identity Exchange(OIX)のリソース等をOpenID Foundationへ移管する動きです。そもそも論、OIXはオバマ政権の際にOpenID FoundationとInformation Card Foundationのジョイントで作られている背景もあるので、InfoCard無き今となってはOIDFへ巻き取られていくのは必然だったのかもしれません・・・・

移管対象はライブラリ、タレント(人など)、ワーキンググループです。

ワーキンググループは当面はコミュニティグループとして移管されるようになるみたいです。

終わっているものもすでにありますので、今後粛々と移管が進むようですね。
Interop and Wallet WG IPにはSIDI Hubで実施しているTrust Framework Mappingも含まれるようなので、Secure Identity Alliance(SIA)とOIDFの共同IPとしてSIDI Hubの代わりに共同で所有されることになるようです。

Member Survey Findings + Member Feedback for Input to 2025 Planning - Elizabeth

SIDI Hubサミットでも毎回行われますが参加者の意見をその場でサーベイする、という方法で今後のプランについてフィードバックを集めていきます。


やはり会場の声としてもStandardにしっかりと取り組んでいくべき、との声が多いようですね。当たり前かもしれませんが。


来年、何をしたいですか?→Party。。。はい、異議ありません。。


議論したいテーマは色々とありますね。先に挙げたAge Assuranceも大きな課題ですね。


OWF/SIDI Hub/ OIDF in 2025 - Elizabeth

Elizabethから先週東京で開催されたサミットの簡単な報告です。


まぁ、この辺りは先週書いたクィックレビューを見てください。

続いてOpen Wallet FoundationのDanielからOWFとOIDFのジョイントの今後について話題提供です。

各国でVCについて検討〜採用は進んでいるが相互に話をする機関がない、このような議論の場をOWFが持つことを想定している、ということです。
自分たちの子供の世代ではデジタルパスポートがあたりまえになる世界になるだろう、と。
だんだんSIDI Hubに似てきました。

Shared Signals and Open Banking Use Cases - Atul

WG Updateの前にSSFとOpen Bankingのユースケースについてです。
SSF自体のUpdateとしてはImplementers draftが出るなど結構進んでいますし、Interopイベントの開催など結構アクティブです。

そんな中、Open Finance(チリ、ブラジルなど)が結構興味を持ってくれている、という話でした。リスクイベントの共有などは特に金融業界では必要ですもんね。


DADE CG Update + Next Steps - Dean H. Saxe

先日話題になったDADE(Death and the Digital Estate)コミュニティグループです。

もう直ぐレギュラーミーティングが始まりますね。

APAC向けのタイムゾーンのミーティングもアレンジしようとしてくれています。いい感じですね。


WG Update – MODRNA - Bjorn

ここからは各WGのUpdateです。アジェンダの順番を入れ替えてリモート参加のBjornからMODRNAのUpdateを。

前回のWorkshopでも報告されましたが、CAMARA Projectとの連携も進んでいるようです。

着々とImplementers draftの作成も進めているようです。

Introduction to the IPSIE WG - Aaron

こちらも噂のIPSIE(Interoperability Profiling for Secure Identity in the Enterprise)です。

改めてゴールが紹介されました。


将来的にはFAPIなども入れていくようですが、当面はOIDC+SCIM+SSF+OAuthってところですね。

Certification Program Update - Joseph

続いてCertification Programです。

こちらも日本政府もサポートしていたOID4VPのテストの展開として、ドイツ政府のWalletコンペに使われたり、Verifier向けのテストのUpdateはIIWでデモが予定されいたり、といい感じで進んでいるようです。
一方でOID4VCIはまだ将来のロードマップにあるだけですね。。まぁ、午前中にDCP WGの会合も出たんですがまだまだBreaking Changesがありそうなのでテスト開発も難しいのかもしれません。

A/B Connect - Mike Jones

続いてConnect WGです。

メインだけありUpdateは多いですね。
  • OIDC specのうち9つがISO PASとして公開
  • OID4VPがDCPへ
  • OID4VP ID3がWGLCへ
  • OID Federation ID4が承認
  • シュツットガルト大学によるセキュリティ分析が進む(OpenID Federation)
  • OpenID Federationのプロダクション環境での利用
    • イタリア
    • オーストラリア
    • スウェーデン
  • Walletプラグフェストも開催

こちらがISOの標準になったOpenID Connect関連スペックファミリーです。これでISOから有料で仕様文書を購入することができるようになりました(笑?泣)

他にもOpenID Federation Walletアーキテクチャ周りのドキュメントなど出しています。


AuthZEN - Omri Gazitt

次はAuthZENです。ワーキンググループができて1年が経ちました。

この短期間でImplementers draftが出ているのがすごいですね。


今回のIIWでもセッションが予定されているようですし、Gartner IAMサミットでも登壇が予定されているようです。

Digital Credentials Protocol(DCP) Working Group Update - Kristina, Joseph, Torsten

午前中にFace to Face会議が行われたDCP WGです。

VP周りのトピックスは何といっても新しいクエリ言語「DCQL(だっくる)」のサポートですね。これまでPresentation Exchangeでしたがinput_descriptor周りが改良される見込みです。この辺りを含むImplementers draft 3もWGLCがかかっているのでもうすぐ出てきますね。

VCIについてもImplementers draft 2に向けた準備が開始される見込みなので、VPとほぼ同じタイミングでVoteが開始されそうです。破壊的変更に備えてフィードバックするなら今ですよ。

HAIPはもうちょっとかかりそうですが、EUとの調整がありなる早、ってところで急いでいるようです。

IIWでのセッションもてんこ盛りの予定です。今回はこれを聞いただけで終わるんじゃないかな・・・


eKYC & IDA WG - Hodari

我らがeKYC & IDA WGです。今回はMarkがまだ東京にいるので今回新しくco-chairにノミネートされているHodariが代わりに報告です。(お前がやれ、という話はしないでください)

何といってもIDAのファイナライズとISO PAS、JWT Claimsレジストリが認められた、という大きなニュースがありましたね。


ということで、Authority Claims ExtensionのImplementers draftに向けた動きやConformance Testの会はtうなど次に向けた動きが活発化していきそうです。

FAPI - Nat Sakimura

そして崎村さんからFAPI WGのUpdateです。

FAPI2のAttacker modelとSecurity Profileがもう直ぐPublic review、そしてMessage SigningはMessaging signingとHTTP Signatureの2つにスペックを分離する、と。


こちらも2025年の1〜3月に向けて仕様のファイナライズが進みそうですね。

iGov - John Bradley

次はJohnからiGovです。そういえば日本ではiGovあんまり聞きませんね。。


最近は政府でOAuth2.0プロトコルを使う場合のプロファイルについて作っているとのこと。主にセキュリティ関係かな。IPSIEがエンタープライズ向けならiGovは政府向けですね。


こうやってみるといろんな国でiGov適用をやってるんですね。

US OpenBanking / CFPB / FDX partnership - Gail, Joseph

リエゾン関係です。一言で言うとFAPIの普及のためにUSでやっているロビイングですね。

このままFDXがFAPIを採用するのを待つのがいいのか、など議論が続きますね。。。
やはりゼロイチよりもイチ→ヒャクの難しさは並大抵ではありません。



ということで今回のWorkshopはこんな感じでした。
いよいよIIW本番が始まります。。