こんにちは、富士榮です。
今年も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
タイトルの通り受託人（医者とか会計士みたいにクライアントの代わりにプロフェッショナルとしてサービスを提供してくれる人たち）のデジタル版がどうやって信頼の形成に役に立つのか、という話です。
文明が生まれ部族社会が出来上がり社会の中と外の境界が生まれた。すごいところから始まりますね。
そんな中、人々が社会参加していくには信頼できる情報を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でアイルランドなので少しはマシかもしれません。
投稿
0 件のコメント:
コメントを投稿