Quantcast
Channel: IdM実験室
Viewing all 769 articles
Browse latest View live

SIDI Hub東京サミット クィックレビュー

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

昨日、10/25にSIDI Hub東京が開催されました。
議論を充実させるために招待制だったこともありカジュアルに参加いただけるものではありませんでしたので、簡単に中身を紹介しておこうと思います。
(どっちにろ来週のIIWの前のOpenID Foundation Workshopの時に報告しないといけないので)



まずは、Gail、Elizabeth、Debora、Stephanieから全体の説明がありました。(私もちょっとだけご挨拶をしましたが)

この辺りは前々夜祭でも話をしましたが、18ヶ月前にGailとElizabethとMarkがSIDI Hubの構想を考え始めた時に「Interoperability by design」が重要だ、ということを考え始めた訳です。

要するにメールや電話やパスポートと同じようなレベルにデジタルアイデンティティを持ち上げる必要がある、ってことですね。

しかしながらなかなかハードルは高い訳です。
会場でサーベイしてみると、80億人に対してデジタルアイデンティティをデプロイするのにどのくらいの費用がかかると思うか?という質問には$10TB+が一番多そうな感じです。

続いてGlobal PlatformのAnaより今年のアクティビティについて説明。

今年の末までに何かレポートをちゃんと出す、ってことです。
楽しみです。

Elizabethからはヘルスケアに関する相互運用の事例としてCOVID-19のワクチン接種証明の話が。この時もいろんなフォーマットで取り組みが進みましたね。日本はSHCでした。


ということで今日のゴールはこちら。


次にWelcomeキーノートとして、OpenID1.0から始まるOpenIDコミュニティの歴史について崎村さんから話がありました。OpenIDファウンデーション・ジャパンの組成の話も含め、どのようにOpenID関連テクノロジーが普及していったのか、という話がありました。GoogleやAppleによる採用など本当にSignificantに普及してきた訳です。しかしながら国家によるAuthoritativeなID(国民ID)の整備と相互運用に向けた活動はまだまだこれからということもあり、そのためにこれまで日本で8月にFIDO/W3C/OIDF-Jがコミュニティを跨いで共同で開催したイベントや本日のSIDI Hubなどを通してこのような相互運用を推し進めていけるとさらにいいですよね!


次に日本政府からのWelcomeノートとしてデジタル庁の楠統括官から日本における国民IDの歴史について戸籍の歴史を紐解く形で紹介がありました。これは非常に興味深いです。

この辺の歴史は海外からのゲストにとってはもちろん、日本からの参加者からしても面白いものだったと思います。この辺りの歴史を踏まえた上で制度設計をしていくのが非常に大切なんだと思います。
住民データベースの歴史と外字の話を海外からのゲストに理解してもらうのは大変だったと思います。本当にお疲れ様でした・・・

ちょっと面白いw
アイデンティティの前にちゃんと文字の統一をしていかないとデータベースも作れないってのは確かになぁ、、、漢字の世界は深い。

そしてもちろん最後にデジタル庁認証アプリの話で締めです。

スマホ搭載の話が進んでいくにつれ、クレデンシャルをどこに保存するか?っていうオーソリテーティブなレジストリ問題が出てくるのを見ていると昔から住民データの保存場所の問題は解決していないんだなぁ、、というところですね。

ここからはRoom1/2に分かれてユースケース分析のワークストリームに入ります。


午前中は以下の2つのユースケースに分かれて話し合います。


私は教育の部屋にいたのでそちらを中心に。


話の中心はある国で教育を受けたクレデンシャルをもった人が他の国で就職する、というシナリオです。留学の話はワシントンD.C.でやったので今回はスキップです。

色々な団体がクレデンシャルの持ち運びや相互運用性に取り組んでいます。UNESCO、フローニンゲン宣言ネットワーク、DCC(Digital Credential Consortium)などですね。会場の半分くらいの人がこれらの団体の取り組みについて知っている、ということでした。


ここからは学位授与機構の坂口先生と野田先生からNQFの話です。

COVID-19で一旦は凹んでいますが海外からの留学生も増えていますし、政府の目標も設定されているそうです。

そんな中、5年前にNIADはNIC-Japanを立ち上げて資格枠組みの提供・認定を進めています。というのも日本人にとっても非常にややこしい学校の構造をちゃんと整理してNQF(National Qualification Framework)として提供、海外との相互運用をとることが重要となる訳です。


ヨーロッパではNQFは広がっていて、EQFとして提供されているようです。
これは職業訓練のみならず生涯学習にも使っていけるようになっているそうです。


日本では正式なNQFは存在しないので、NIADが定義をしようとしており、文科省が認定する最終段階にあるとのことです。

デジタル化についてはまだまだ進んでいないところが多いので、NIC-Japanではデジタル化についても推進していきたいとのことです。

デジタル化を推進するにあたり、どうも日本は中央集権を嫌う傾向にあるので分散と集中のハイブリッドモデルを導入するのはどうか?という話がありました。データは集めないけどお墨付きだけをつける、ってモデルですね。

次はデジタル庁の杉浦さんから日EU間での教育クレデンシャルの相互運用に関する話がありました。日EUデジタルパートナーシップの話ですね。
デジタル化を行う際は相互運用性の意識を必須として進めていこう、ということです。


デジタル化だけでは相互運用はできないのでNIADの先生方がお話しされた仕組みと歩調を合わせてやっていけると良いですね。

議論も結構盛り上がっていたと思います。
  • データスキーマをどうやって合わせるか
  • どうやってIssuerを信じるか(Trusted registryの話)
  • どこにクレデンシャルを保存するか
  • ビジネスモデルをどう作っていくのか
などなど。

午後は、MR4I(Minimum Requirement for Interoperability)のセッションです。

そう、SAMLですよ。SAML。SAMLai、サムライ、侍です。

まずは学認の話をNIIの佐藤先生から。Academicフェデレーションは世界で一番成功したID連携のフェデレーションです。

SAMLは死んだ、SAMLはゾンビだ。
でもゾンビは死なないのであるぅぅぅぅ。という力強いお言葉からスタートです。


そう、すでにグローバルでInteroperableな世界がそこにはあるのである。

この後は学認の取り組みとしてSAMLメタデータの詳細が仕様上は定義されていないことによる互換性の問題、例えばShibbolethのメタデータはEntity名が固定でつけられることによりOktaとの連携が失敗する、などが紹介されました。
また、Level of Assuranceの表現方法についても相互運用性の実現においては課題が残る、ということも話されました。例えばIALは規定されたプロセスでコントロールされていたり、AALに関してもSMSをどう扱うのか、など含めて決めていかないといけないところから、ということでした。
まとめると、こんな課題があるようです。
  • 機関に所属していない研究者の問題
  • 他のトラストフレームワークとのインターフェイスの問題
  • 相互運用性の問題(Kantaraとのネゴシートの問題)

次にMark HaineからGAIN PoCの話を。
GAINではテクニカルなところにフォーカスが置かれており、OpenID ConnectやIDA、Federationなどのプロトコルを前提として実験をしていたとのことです。


まさにNetwork of Networksですね。プロキシベースの方式、複数プロトコルをサポートする方式、その組み合わせが検討されていたようです。

プロキシベースのアプローチの場合にどうやって署名の問題やオリジネーターの信頼の問題をクリアするのか?などについて議論が行われました。

今後はPoCの実行なども視野に入れて活動をしていくようです。


続いてTrust Frramework分析のセッションです。
Nickがリモートで参加してくれました。

OIXのDNA of Digital IDでこちらの国のトラストフレームワークの分析をしたそうです。


ちなみにOIXのトラストフレームワークを超えた相互運用性に関するドキュメントは上記QRコードで取得できます。中身は以下のURLですね。(要ユーザ情報の入力)


日本やオーストラリアを含めて分析が進んできました。

ニュージーランドではウォレットとクレデンシャルに関する標準化も進んでいるんですね。

分析を担当したMark、柴田さん、貞弘さんからのコメントでは、もっとドメインに特化したトラストフレームワークの分析(例えば銀行の口座解説とか教育とか)を深くやっていくとより相互運用性が実現して良いのではないか、という話がありました。他にも用語の定義をちゃんと棚卸しをしてマッピングしていく必要がある、という話がありました。しかし日本語で認証という言葉にまとめられてしまうCeritificationなのかAuthenticationなのか区別がつかなくなるって話もありなかなかタフな作業になりますよねぇ。。。


LoAの話に関連して、クレデンシャル(本人確認書類っていう意味で)の互換性の議論もありました。例えば日本ではパスポートを使って銀行口座を解説することはできないって言う話は他の国の人たちからすると新鮮だったのかもしれません。
同じ人が別の名前で複数パスポートを発行しちゃう、なんて話もあるので色々と各国の事情を見ながら丁寧にマッピングしていかないと相互運用性の話には到達しないんでしょうねぇ。

最後にUNDPのデジタルIDモデルの話も紹介されました。



次はガバナンスの話です。
ガバナンスといっても何の?という話もありますが、このスライドではクレデンシャルの話です。

これをみるだけでもクレデンシャルに関するガバナンスにも多くの領域があることがわかります。こう言う整理が進むことはこう言うコミュニティの良いところですね。

そして、SIDI Hubがこのような取り組みを進めていく上でどんなフレームワークが必要になるのか?のコンセプトをまとめたものが紹介されました。(実は前日に会議室でホワイトボードに書きながらギリギリまで議論していた図)


このDigital Commonsって考え方は結構面白いと思うので、改めて見ていく機会を作ろうかと思います。



最後のまとめ2025年に向けた戦略です。疲れてきました。

これまでのサミットでも見えてきていたことですが、色々なユースケースを分析していくとグローバルとローカルのコンテキストをうまく繋がるようにしていかないといけない、ということがわかったり、トラストフレームワークの分析をしていくとポリシーからテクノロジーにわたって色々と分解していくことができること、テクノロジーについてもグローバルとローカルの間でNetwork of Networksの関係が成り立ったり、ガバナンスは階層的に考えていくのと同時にOSSやファンドのことも関連づけて考えていく必要がありそう、、、などなど色々と見てきました。


4つ目のポイントは結構面白いですね。
SIDI Hubの今後のあり方にも関係してきそうですが特定の法人格を持たないからこそできるHubとしての役割は必要なんだと思います。これはNetwork of NetworksやEducationのところでもコメントを少しだけしたのですが、色々な団体がバラバラと活動をしているとどうしても無駄が生まれますし、時に対立を産むことにもなるのでハーモナイズする役割を果たしていけると面白いと思います。


2025年の目標。てんこ盛りですな。



関連するステークホルダーへの推奨事項もまとめています。
今後も一緒にやっていけるといいですね。

最後にもう一回8Bの人たちに向けたデジタルアイデンティティをデプロイするのにいくらかかると思う?っていうサーベイが再び。

よりお金がかかる方に振れてるやんw
まぁ、さっき回答していない人もいますからね。。

今日取り上げなかったユースケースで取り上げた方が良いものはある?という設問では難民とか運転免許証とかが上がってました。

2025年にSIDI Hubが目標とすべき事項は?という設問では、PoCをやるべき、という話が散見されたので、実行フェーズに移行することが必要な時期に入ってきているってことかもしれません。

同じく2025年にトラストフレームワークマッピングのワークスストリームではユースケースに特化したマッピングやもっと多くの国を巻き込むべき、という話もありました。

さらにMR4Iに関しては、プロキシの実証やユースケースに特化したPoC、テクニカルガイドラインの作成が挙げられました。

SIDI Hub自体のセルフガバナンスやマルチステークホルダーによるガバナンスに関してどうしていくべきか?については、スコープを明確化すべき、ステークホルダーを明確化すべき、などが目立ちました。まだモヤモヤ感があるってことでしょうね。

SIDI Hubの成功メトリクスは何か?という質問ですが、PoCの実行を挙げる人が多かったかと思います。

東京でテーマに上がった災害と緊急時のユースケースはチャンピオンユースケースとして取り上げるべきか?という設問ではYesとMaybeがほぼ同数だったので、まぁまぁ前向きだったのかもしれません。

グローバルスタンダードはドメスティックなデジタルIDシステムを下支えするか?という設問は、まぁYesですね。若干誘導されていたような・・・

特にグローバルサウスがターゲットになるのでしょうが、トラベルファンドなどは役にたつ?これもYes。でしょうね。

技術レイヤーに関するコンフォーマンススイートやファンディングも役にたつ?まぁYesでしょう。

トラストフレームワークマッピングを国境や管轄、ポリシーとプロトコルを横断で進めていくべき?これもほぼYes。

デジタルID基盤はドメスティックとグローバルの国防に関するクリティカルコンポーネントとなるか?全員Yes。

誰がマルチステークホルダーガバナンスをリードするのがベストか?(政府?企業?)
まぁこれはハイブリッドの選択肢があったのでそちらに流れた感じ。

そして最後にもう一回8Bの人にデジタルIDをデプロイするためのコストはどのくらい?

やっぱり大変、ってことですよ。

SIDI Hubを続けていくべき?Yes。まぁ、きている人がそう言う人たちですからね。





最後にクロージングはデジタル庁の林さん。素晴らしいスピーチでした。

と言うことで、お疲れ様でした!













IETFに向けて色々とスペック案が。まずはToken Status Listから。

$
0
0

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

SIDI Hub東京サミットが終わったと思ったら、来週からはInternet Identity Workshop、その翌週はIETFですね。(そしてその間にもOpenID Foundation Workshopがあったりします)


IETFに向けてOAuth WGから色々と仕様ドラフトが出ていますので、少しずつ紹介しようかと思います。

まずはToken Status Listです。

https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/


Verifiable Credentialsに関するStatus ListといえばDIFからW3Cに場を移したBitstring Status List v1.0がありますが、今回のものをざっとみているとJWT以外にmdocやCWTにも適用できるように汎用化した感じでしょうか。

クレデンシャルフォーマットがバラついている状況では必要なものなんだと思います。


Introductionにはこんなことが書いてあります。

Token formats secured by JOSE [IANA.JOSE] or COSE [RFC9052], such as JSON Web Tokens (JWTs) [RFC7519], CBOR Web Tokens (CWTs) [RFC8392] and ISO mdoc [ISO.mdoc], have vast possible applications. Some of these applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as whether the token is considered invalidated or suspended by its issuer.

This document defines a Status List and its representations in JSON and CBOR formats that describe the individual statuses of multiple Referenced Tokens, which themselves are JWTs or CWTs. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List. Each Referenced Token is allocated an index during issuance that represents its position within this bit array. The value of the bit(s) at this index correspond to the Referenced Token's status. A Status List may either be provided via HTTPS or be protected within a Status List Token by cryptographic signature or MAC, whereas this document defines its representations in JWT and CWT. Status Lists may be composed for expressing a range of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. The document also defines how an issuer of a Referenced Token references a Status List (Token).

JOSE [IANA.JOSE] または COSE [RFC9052] によって保護されたトークン形式、例えば、JSON Web トークン (JWT) [RFC7519]、CBOR Web トークン (CWT) [RFC8392]、ISO mdoc [ISO.mdoc] などには、幅広い用途が考えられます。これらのアプリケーションの一部では、トークンを発行し、そのトークンに関する特定の意味論が時間とともに変化する場合がある。これは、相互運用可能な方法で依拠当事者に通知することが重要であり、例えば、トークンが発行者によって無効または一時停止されたと見なされるかどうかなどである。

本書では、複数の参照トークン(それ自体はJWTまたはCWT)の個々のステータスを記述するステータスリストとその表現を、JSONおよびCBOR形式で定義します。すべての参照トークンのステータスは、ステータスリスト内のビット配列で伝達されます。各参照トークンには、発行時にこのビット配列内の位置を示すインデックスが割り当てられます。このインデックスのビットの値は、参照トークンのステータスに対応します。ステータスリストは、HTTPS経由で提供されるか、暗号署名またはMACによりステータスリストトークン内で保護される場合があります。一方、本書ではJWTおよびCWTにおける表現を定義しています。ステータスリストは、ステータスタイプの範囲を表現するために構成される場合があります。本書では、最も一般的なユースケースに対応する基本的なステータスタイプ、およびカスタムステータスタイプの拡張メカニズムを定義しています。また、参照トークンの発行者がステータスリスト(トークン)を参照する方法についても定義しています。


ちゃんとIHVモデルにも適用するモデルになっていますね。

issue present Referenced Referenced ┌────────┐ Token ┌────────┐ Token ┌───────────────┐ │ Issuer ├───────────►│ Holder ├───────────►│ Relying Party │ └─┬──────┘ └────────┘ └──┬────────────┘ ▼ update status │ ┌───────────────┐ │ │ Status Issuer │ │ └─┬─────────────┘ │ ▼ provide Status List │ ┌─────────────────┐ fetch Status List │ │ Status Provider │◄───────────────────────────┘ └─────────────────┘


サンプルも一緒に提示されています(こちらはJWTのケース)

{ "alg": "ES256", "kid": "12", "typ": "statuslist+jwt" } . { "exp": 2291720170, "iat": 1686920170, "status_list": { "bits": 1, "lst": "eNrbuRgAAhcBXQ" }, "sub": "https://example.com/statuslists/1", "ttl": 43200 }


まぁ、相変わらず微妙だなぁと思うのは結局Bitstringでステータスを表現している点(他のアイデアがあるかと言われるとありませんが)なわけですが、他にもStatus Providerをどうやって安全かつプライバシーに配慮した上で運営できるか?ってところになってきそうです。


いずれにしても非常に重要な仕様の一つだと思うので要ウォッチですね。


European Identity and Cloud Conference 2025のスピーカー募集が始まっています

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

早くも来年5月のEuropean Identity and Cloud Conference 2025(EIC 2025)のレジストレーションとスピーカー募集が始まっていますね。



今ならレジストレーションも1000ユーロとお得なので早めに申し込んでおきましょう。
また、スピーカーになればもっとお得ですのでアプライしてみるのも良いと思います。

今回もベルリンのコングレスセンターで5月6日〜9日です。

私も考えないと。。

OpenID Foundation Workshopクィックレビュー

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

今回も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本番が始まります。。


IIW 39 Day1クィックレビュー

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

今年も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でアイルランドなので少しはマシかもしれません。

IIW 39 Day2クィックレビュー

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

ということで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の両方を実現できるわけですね。



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


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


IIW 39 Day3クィックレビュー

$
0
0

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

いよいよIIWも最終日です。


かなり疲れてきたので頭が回らず英語が聞き取れなくなってきました。(来週いっぱいまで英語生活なので週末はゆっくりしないと・・・)

ということで今日も楽しい話題がいっぱいでした。


Credential Status Comparison Mechanisms - Paul

以前も書いたStatusList周りを含むクレデンシャルの取り消しに関する話題です。

確かに色々な方法があるんですよねぇ。古き良きOCSPとか。。。


そもそもクレデンシャルの取り消しをしたくなるトリガーとしては、こんなことが挙げられます。

  • Credentialデータセットが無効(例えばover18になった)
  • 発行システムの侵害
  • アルゴリズムの危殆化(量子コンピューターの発展など)
  • ウォレットや鍵の侵害

ドイツ政府はイタリアやフランスと協力してシナリオと方法論の比較検討を進めているみたいです。考えているシナリオはこんなところだそうです。

  • ユーザが死んだ
  • ユーザが自らRevokeしたい(スマホなくした)
  • キーストレージが脆弱性にさらされた

この辺りをスケーラビリティとプライバシー(Linkability)を考えつつ解くのは難しい問題ですよねぇ。。



こんなクライテリアで比較しているそうです。

  • Credential format(対応している種類)
  • Technology readiness level(成熟度)
  • Status tracking by verifier(トラッキング)
  • Holder tracking by issuer(トラッキング)
  • Unlinkability(紐付け可能度合い)
  • Complexity(0が高い)
  • Scalability(0が高い)
  • Offline/caching(オフラインシナリオへの対応)


色々と考慮点はあって、例えばBitStringでStatusListを作るとある程度サイズ圧縮は効くもののの上限はあるので、一定期間でガベージコレクションをしたり、クレデンシャルのバッチ発行をすることでリンク可能性に対策できるかどうか考えたり、、と。

しかし、こう言う比較検討の段階でIIWのようなプロフェッショナルが集う場所へ投げ込んでブラッシュアップするって方法、本当にいいと思うんですよね。プレゼンする方も「こう思うんだけどどう?」って投げかけてちゃんとその場で議論になる。これを政府や金融機関の中の人たちがちゃんとオープンな場でやっている、ってなかなか日本では考えられないことだと思います。日本政府もこう言う場に来ればいいのに(チラッ)


Digital Credentials API - Tim

次はDigital Credentials APIの話です。

カスタムURLスキームでウォレットが起動されるのではなくFIDOと同じようにCredentials APIで起動できるようにしましょう、って話です。

そもそもカスタムURLスキームで何が問題だったか、というと

  • 安全ではないコンテキストでアプリを起動
  • デバイス上でのフィッシング(悪意のあるアプリを選択)
  • リクエスターオリジン、アイデンティティがない

ということなので、この辺りはパスキーから学ぼうよ、という話です。この辺りが学びとしてあげられていました。
  • 呼び出し元のコンテキストがキーとなっている
  • クロスデバイス認証はセキュア・簡単・フィッシング耐性があることが必要
こんな構造です。

FIDOにおけるCTAPとWebAuthnとよく似てますね。

こんな感じで動くようです。

APIも割とシンプルです。

Presentation
let digiCred = await navigator.credentials.get({
signal: controller.signal,
digital: {
requests: [{
protocol: "openid4vp",
data: "{request json}"
}]
}
});

Issuance

let digiCred = await navigator.credentials.create({
signal: controller.signal,
digital: {
requests: [{
protocol: "openid4vci",
data: "{request json}"
}]
}
});


この辺りでdemoが見れますよ。

https://digital-credentials.dev/


OID4VCI Browser API Issuance Profiles - Joseph, Kristina, Paul

色々なシナリオを網羅的に考えていかないと社会基盤としては使えないということでかなり色々なユースケースを考えていますね。

https://bmi.usercontent.opencode.de/eudi-wallet/eidas-2.0-architekturkonzept/flows/Presentation-During-Issuance/

こちらにあるようなPresentationの結果を受けてIssuanceを行う、というシナリオもその一つです。

例として、学校でDegreeを発行してもらう際にmDLを提示して本人確認をする、みたいなシナリオが挙げられていました。

Presentationの結果を受けてPre-authorization用のコードを発行〜そのままOID4VCIを走らせるってことですね。


これもプレゼンテーションを行うクレデンシャルが入っていたWalletとIssuanceを行う先のWalletが異なるケースにどうやって対応するのか?みたいな話で議論が盛り上がりました。


OIDC4VCI Credential Versions / Purpose on presentation - Oliver, Daniel

こちらが最後のセッションでしたが、またマニアックな話題でした。

前半パートはOliverがクレデンシャルにバージョンをつけるとするとどうなるのか?という話をしていました。(何をもってそのバージョンが最新であるか、を証明することも含め)

まぁ、バージョンと言っても色々な解釈があるのでその辺りの整理をして議論をするところまで、となりましたが。

  1. 同じクレームとバリューを含んでいるが、別デバイスの鍵とバインドされていたり、別で発行された
  2. クレームは一緒でも値が異なる。値が変わった場合、Frequent Flyer Statusが変わった場合など
  3. クレームは一緒でも値が異なる場合。なぜなら別の人やものに関するもの
  4. クレームも値も異なる。全然別のクレデンシャルなので

誰がトリガーで発行し直すのか、Shared Signalで通知するのが良いのか、、などなど。。

後半はDanielがPresentation requestの中のクエリ言語(PEやDCQL)に指定するpurposeについての話題。(これもコアだな)

現状はクレデンシャルの単位でpurposeを指定するので、クレデンシャルセット全体に関するpurposeってないよね、とか多言語対応させるにはどうするべきなのか?みたいな話題で盛り上がりました。こちらも時間切れ。


ということであっという間の3日間でした。

とりあえず次はIETFということでこれからドイツ経由のダブリンへ移動します。。。






OpenID for Verifiable Presnetationsの新しいImplementer's draftのPublic Reviewが始まりました

$
0
0

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

IIWや、その前日のOpenID Foundation Workshopでも取り上げられていたとおり、OpenID for Verifiable Presentationsの新たなImplementer's draftのPublic Review期間に入りました。



アナウンス

https://openid.net/public-review-period-for-proposed-third-implementers-draft-of-openid-for-verifiable-presentations-specification-3/


主な更新はこちら

  1. Introduces the Digital Credentials Query Language; this is an alternative to Presentation Exchange
  2. Introduces the transaction data mechanism that enables a binding between the user's identification/authentication and the user’s authorization, for example to complete a payment transaction, or to sign specific document(s) using QES (Qualified Electronic Signatures).
  3. Removes the client_id_scheme parameter and instead makes the client id scheme a prefix on the client_id; this addresses a security issue with the previous solution.

  1. デジタル・クレデンシャル・クエリ・ランゲージ(Digital Credentials Query Language)を導入。
  2. トランザクション・データ・メカニズムを導入し、ユーザの識別/認証とユーザの認可の間のバインディングを可能にする(例えば、支払いトランザクションの完了や、QES(Qualified Electronic Signatures)を使用した特定の文書への署名など)。
  3. client_id_schemeパラメータを削除し、代わりにクライアントIDスキームをclient_idのプレフィックスとする。


今後のスケジュールはこちら

  • Implementer's Draft public review period: Friday, November 1, 2024 to Sunday, December 16, 2024 (45 days)
  • Implementer's Draft vote announcement: Tuesday, December 3, 2024
  • Implementer's Draft early voting opens: Tuesday, December 10, 2024
  • Implementer's Draft official voting period: Tuesday, December 17 to Tuesday, December 24, 2024

年内に承認されそうですね。実装中の皆さんは対応方針を考えておきましょう。


Okta AD/LDAP DelAuthモジュールに関する脆弱性

$
0
0

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

Okta社よりAD/LDAP DelAuthモジュールに関する脆弱性が報告されていますね。


https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/

報告されている内容としては、AD/LDAP DelAuthモジュールを使っている環境で、過去にキャッシュログインに成功したことのある場合、ユーザー名が52文字以上だとパスワードなし(キャッシュのみで)ログインが成功してしまう、という話です。

こちら上記のサイトからの引用です。

On October 30, 2024, a vulnerability was internally identified in generating the cache key for AD/LDAP DelAuth. The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password. During specific conditions, this could allow users to authenticate by only providing the username with the stored cache key of a previous successful authentication.

Note: A precondition for this vulnerability is that the username must be or exceed 52 characters any time a cache key is generated for the user.

2024年10月30日、AD/LDAP DelAuthのキャッシュキーの生成において、内部的に脆弱性が確認されました。キャッシュキーの生成には Bcrypt アルゴリズムが使用され、userId + username + password を組み合わせた文字列がハッシュ化されます。特定の条件下では、ユーザー名と、過去に認証に成功した際に保存されたキャッシュ・キーだけを提供することで、ユーザーが認証できる可能性があります。

注:この脆弱性の前提条件として、キャッシュ・キーが生成される際には、ユーザー名が52文字以上でなければなりません。


すでにOktaのプロダクション環境では解消されているようですが、本モジュールを利用している場合(特にAD連携をしている場合はほぼ必ず使っているはずのモジュールなので)は、ユーザ名が52文字以上あるユーザがいるかどうか、侵入の痕跡がないか、など確認しておいた方が良さそうです。タイムラインを見ると脆弱性のあるモジュールがリリースされたのが2024/7/23で、発見されて対応されたのが2024/10/30となっており気が付かないまま3ヶ月経過しているので。

そもそも論としてAD/LDAP DelAuthってなんだ?って人もいると思うので簡単に。
要するに、クラウド上にあるOktaへオンプレのADやLDAPのパスワードを使ってログインできるようにするモジュールです。

AD版はこちら
https://help.okta.com/en-us/content/topics/security/enable_delegated_auth.htm
LDAP版はこちら
https://help.okta.com/en-us/content/topics/security/security_authentication.htm

ざっくりとした仕組みですが、Oktaへの認証要求があるとオンプレのAD/LDAPへ認証要求が行われ、成功するとパスワードハッシュのキャッシュがOktaクラウド側に置かれ、以降キャッシュが有効な間はオンプレ側への問い合わせなしにクラウド側だけで認証処理が行われる、という感じです。

すでに対応は終わっているとは言えなかなかな脆弱性ですね。。。
まぁ、ユーザ名が52文字以上って言うのもあんまりないとは思いますが。

今年もDigital Identity技術勉強会のAdvent Calendarの季節がやってきた

$
0
0

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

毎年恒例のAdvent Calendarの季節になってきましたね。(はやい・・・)


ということでDigital Identity技術勉強会(#iddance)のAdvent Calendarも作られていますので、この機会にぜひ皆さん参加しましょう。

https://qiita.com/advent-calendar/2024/iddance


DID CommのFormal Verificationとセキュリティ強化

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

クレデンシャル交換のプロトコルとして適しているのはDID CommなのかOpenID for Verifiable Credentials(OID4VC)なのか、という議論がひところ各所で聞かれましたが最近はそんな議論も落ち着いてきているのかな?と思っている今日この頃です(エコーチェンバー)。

当時、DID Commを否定的に捉える論拠の一つにFormal Verificationもすんでないじゃん、という話がありましたが、ようやく?やったみたいです。

What Did Come Out of It? Analysis and Improvements of DIDComm Messaging



Abstractにはこんなことが書いてあります。
Self-Sovereign Identity (SSI) empowers individuals and organizations with full control over their data. Decentralized identifiers (DIDs) are at its center, where a DID contains a collection of public keys associated with an entity, and further information to enable entities to engage via secure and private messaging across different platforms. A crucial stepping stone is DIDComm, a cryptographic communication layer that is in production with version 2. Due to its widespread and active deployment, a formal study of DIDComm is highly overdue.
We present the first formal analysis of DIDComm’s cryptography, and formalize its goal of (sender-) anonymity and authenticity. We follow a composable approach to capture its security over a generic network, formulating the goal of DIDComm as a strong ideal communication resource. We prove that the proposed encryption modes reach the expected level of privacy and authenticity, but leak beyond the leakage induced by an underlying network (captured by a parameterizable resource).
We further use our formalism to propose enhancements and prove their security: first, we present an optimized algorithm that achieves simultaneously anonymity and authenticity, conforming to the DIDComm message format, and which outperforms the current DIDComm proposal in both ciphertext size and computation time by almost a factor of 2. Second, we present a novel DIDComm mode that fulfills the notion of anonymity preservation, in that it does never leak more than the leakage induced by the network it is executed over. We finally show how to merge this new mode into our improved algorithm, obtaining an efficient all-in-one mode for full anonymity and authenticity.

自己主権型アイデンティティ(SSI)は、個人や組織が自分のデータを完全にコントロールできるようにする。分散型識別子(DID)がその中心であり、DIDには、エンティティに関連する公開鍵のコレクションと、エンティティが異なるプラットフォーム間で安全かつプライベートなメッセージングを介して関与できるようにするためのさらなる情報が含まれている。その重要な足がかりとなるのがDIDCommであり、バージョン2で製品化された暗号通信レイヤーである。DIDCommは広く活発に展開されているため、DIDCommの正式な研究は非常に遅れている。

本稿では、DIDCommの暗号技術に関する初の形式的分析を行い、(送信者の)匿名性と真正性というDIDCommの目標を形式化する。DIDCommの目標を強力な理想的通信リソースとして定式化することで、一般的なネットワーク上での安全性を実現する。提案する暗号化モードは、期待されるプライバシーと真正性のレベルに達するが、(パラメータ化可能なリソースによって捕捉される)基礎となるネットワークによって誘発される漏洩を超えて漏洩することを証明する。

次に、匿名性と真正性を同時に達成し、DIDCommメッセージフォーマットに適合し、暗号文のサイズと計算時間の両方において、現在のDIDCommの提案をほぼ2倍上回る最適化アルゴリズムを提示する。最後に、この新しいモードを改良されたアルゴリズムにマージする方法を示し、完全な匿名性と真正性を実現する効率的なオールインワンモードを得る。


中身はまだ細かく見ていませんが、しっかりと分析を行うプロセスが実行された、ということなので良かったんじゃないかと思います。

いずれにしても特にIoTのユースケースなどDID Commの方が適しているものもある気がしますので、ちゃんと適切にプロトコルを選択していけると良いかと思います。


AuthZEN WG Authorization API 1.0 Implementer's draftの投票期間がもうすぐ始まります

Identiverse 2025のプレゼンテーション募集が始まっています

[監訳]デジタルアイデンティティのすべて

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

ようやくオープンにできる日がきました。

「デジタルアイデンティティのすべて」
 安全かつユーザー中心のアイデンティティシステムを実現するための知識


12月27日に出版です。Amazonや楽天Booksなどで購入いただけます。


本書はPhil Windleyの近著「Learning Digital Identity」の翻訳版で、私は技術監修をしています。翻訳してくれた有志の皆さん本当にお疲れ様でした。(まだ残ってるけど)

この本ですね。


日本語版の表紙も出てきました!(楽天Booksにはもう掲載されています)



ということでIIWではPhilにコメントをもらったりもしているので、出版後のどこかのイベントで皆さんにも共有できると思います。


先月末のIIWでPhilから日本の皆さんにコメントをもらってきました。


では、みなさんお楽しみに。





FAPI2.0のコンフォーマンステストがDPoPをサポートしました

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

FAPI2.0のコンフォーマンステストがDPoPをサポートしたようです。



国内はFAPIの普及はまだまだですが、ブラジルやサウジアラビア、UAEなど先進的な取り組みをしている国も増えてきていますので、ぜひ金融に限らず採用してけるといいですね。
そういう意味でもIPSIEは楽しみかもしれません。

IETF121 Dublinオーバービュー

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

先日のIIWからドイツ経由でダブリンにわたり、IETF 121 Dublinに参加してきました。
基本はWeb Authorization Protocolまわり(要するにOAuth)のセッションに参加しつつ、気になるSide Meetingに参加する、というスタイルで参加してきました。
なお、初めてだったこともあり、ほぼほぼ様子見となってしまったのであまりまとめてはいませんので、中身はOAuth WGのメーリングリストなどを参考にしてください。

OAuth WGのアジェンダはこちらです。
https://datatracker.ietf.org/doc/agenda-121-oauth/

テーマ盛りだくさんですね。
  • Token Status List
  • Attestation-based Client Authentication
  • Transaction Token
  • Extending RFC8414 with client-specific responses
  • OAuth Identity and Authorization Chaining Across Domains
  • Identity Assertion Authorization Grant
  • OAuth 2.1 update
  • OAuth Client ID Metadata Document
  • First Party Apps
  • SD-JWT
  • SD-JWT-VC
  • One-time confirmation tokens
  • One-time auth tokens

まぁ、IETFってそういうもんだ、という話でしたが結構生煮えな状態でドラフトを持ってきてみんなで叩く、って感じなんですね。新鮮でした。

印象に残ったものを2〜3点ばかり。

Token Status List

先日ここでも紹介したやつですね。

これは結構固まってきているイメージはありました。まぁ仕方がないとはいえBitStringを使うのは難しいですよね。ガベージコレクションなど工夫しないといつか枯渇するわけですが、じゃぁ、どうやってガベージコレクションするんだ?というあたりはまだこれから(というか運用マター)な感じでした。

OAuth Client ID Metadata Document

SAMLでいうSP Metadataですよね。。。Dynamic Client Registrationと棲み分けるのか置き換えるのか、あたりがポイントになりそうです。
FastFedあたりに使っていくのかな、って感じです。

SD-JWT/SD-JWT-VC

cty/typをどうするの?って話が面白かったですね。vc+sd-jwtからスタートしているわけですが、W3C VC DM 2.0ではvc+ld+jsonとかになってきているので、もう乱立状態です。
色々と大人の事情もありつつdc+sd-jwtにしようよ、って提案がありました。
うーん。正直ここまで来るとvcとかdcとか用途に近いことをprefixにつけるのは悪手に見えて仕方がありませんが・・・
まぁ、大事なところなので引き続き様子を見ていきます。


ということで次回はバンコクなので、引き続きオンラインで議論は続く感じです。ウォッチしていこうと思います。


しかし、ダブリンいいところですね。またいきたいです。

トリニティカレッジ

ギネスの生。もう缶には戻れません。



Token StatusListを深掘りしていく

$
0
0

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


昨日投稿したIETFの振り返りを含め各ドラフトについて少し深掘りしていこうと思います。

昨日の振り返りポスト

https://idmlab.eidentity.jp/2024/11/ietf121-dublin.html


まずは、Token StatusListです。

こちらはドラフトドキュメントを軽く見ましたが、今回の現地でのミーティングを踏まえ少しアップデートしておきましょう。

https://idmlab.eidentity.jp/2024/10/ietftoken-status-list.html


まぁ、基本的に以前書いた通りではあるのですが、Updateとして数点書いておきます。

履歴のリクエスト

オプションではありますが、特定の時点で当該のトークンが有効だったのか?ということを確認したいという要件があるようです。その要件に対応するためにクエリパラメータをサポートすることにしています。

これ、StatusList Providerの実装が面倒ですね・・・

Zlib以外の圧縮アルゴリズムをサポートするか

現状は以前も書いた通りBitString StatusListはZlibで圧縮されています。

このスライドにある通り、まずはサポートする圧縮方式のレポジトリを作ってとりあえずZlibだけ入れておこうか、という感じです。

レスポンスにContext-Typeをつけるかどうか

現状はレスポンスへのContent-Type付与が必須になっているわけですが、一部のCDNがサポートしていないということもありお悩みポイントになっているようです。

AsIsでいいんじゃないかと思いますが、WGLCまでには決まってくると思います。

とりあえずToken StatusListについてはこんなところです。




iddanceイベントが開催されます。今回はVCがテーマ!

パスキーのテストサイトがリニューアル

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

以前も何度かWebAuthnのテストをするためのサイトを紹介しましたが、今回Okta(Auth0)がパスキー学習サイトをリニューアルしてきたので試してみます。



なんと日本語に対応しています。

ユーザIDやユーザ名など登録に使う情報はあらかじめ決まっていますが、デモとして試すこともできますし、API仕様などを含むリソースもまとまっています。

スクラッチで実装する人も、パスキーを基礎から学習したい人にもとても良いサイトなのでぜひアクセスしてみると良いと思います。


OpenID Foundation Workshopの資料が公開されています

Viewing all 769 articles
Browse latest View live