こんにちは、富士榮です。
ものすごく久しぶりに書いている気がしますが、本当は4月ごろに書きたかったネタです。
簡単にいうと、
設定方法(コンソールで強制する設定)
で、amrはどうなるのか?
- パスワード
- QRコード
- シングルサインオン
- 自動ログイン(スマホのみ)
- パスワード:pwd
- QRコード:lineqr
- シングルサインオン:linesso
- 自動ログイン(スマホのみ):lineautologin
いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。 後は、関連するニュースなどを徒然と。
こんにちは、富士榮です。
ものすごく久しぶりに書いている気がしますが、本当は4月ごろに書きたかったネタです。
簡単にいうと、
こんにちは、富士榮です。
"Digital Identity技術勉強会 #iddance Advent Calendar 2022" 14日目の記事です。
最近DID(Decentralized Identifiers)やVC(Verifiable Credentials)をコネコネしてインターネット上でのデータや取引の信頼性をどうやって担保するか?みたいなことにトライをしているわけですが、どうしてもDIDを「分散型ID」という日本語に翻訳してしまうことにより「web3イェーイ!!」な人たちの変な関心・期待を集めてしまっている気がしています。今日のトピックではないので割愛しますが、インターネットの信頼性を高めたいというモチベーションにはDIDではなく「VC」こそが最重要のコンポーネントであり、DIDをVCと組み合わせることでよりスケーラブルなシステムを構築できるようになる、というのが本質的な位置付けだと思っています。どうしても「分散型ID」という訳語が強すぎるので「VC:検証可能な資格情報」のインパクトが出しきれず言葉が一人歩きしているんだろうなぁ、、、という課題感です。
さておき、本日はそんなweb3な文脈でしばしば出てくる、譲渡不可能なNFTであるSBT(Soul Bound Token)とDID/VCとの関係性について考えてみようと思います。
※NFTとは?については割愛します。
イーサリアムの提唱者のヴィタリック氏がSBT(Soul Bound Token)に関して以下の論文を発表しています。
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763
ものすごくざっくりいうと、アカウントやウォレットのアドレスを「ソウル」と呼ぶことで、従来のNFTに対して発行者のアイデンティティを紐づけることができるようにしよう、という考え方で、このソウルに紐づけられたトークンをSBT、つまりソウルに紐づけられたトークンと呼ぶことにしよう、という話です。
このことによりNFTについて群衆ベースで信頼性を向上することができたり、ウォレットのリカバリをコミュニティベースで行うことができるようになる、という利点があるとされています。
例えば、特定のソウル(アーティスト)に紐づいたアート作品をトークンとして発行する場合、多くのソウル(購入者)がトークンを受け取ることで、アーティストの信頼性が上がっていくという群衆ベース、レピュテーション(評判)ベースの信頼性を向上することができ、結果としてアーティストの実在可能性が高くなって無担保融資ができるようになったりする、ということも考えられたりします。また、ウォレットのリカバリをニーモニックで行ったりカストディアンに依存してしまっている現状から、繋がっているソウルからの証言によりリカバリができるようになる、といったコミュニティによるリカバリシナリオについても利点として挙げられています。
先にも書きましたが、アカウントやウォレットを「ソウル」と呼び、ソウルに紐づけられたトークンを「SBT」と呼ぶという考え方ですが、その一番の特徴は信頼の形成方法だと思います。
論文内で言及されるWeb2.0における世界観における信頼は既存のアカウント管理システム(例えばNFTマーケットだったらOpenSeaやTwitterなど)によって裏打ちされたアイデンティティがベースでしたが、本論文内においてSBTはレピュテーションをベースに信頼を構築することが考えられています。いわゆるブロックチェーンにおけるコンセンサスアルゴリズムのProof of Workのモデルそのものだな、と感じているのですが多くのアクティビティがあり、他のソウルとの関連があり良い評判が得られているソウルの信頼性は高く、必ずしも現実社会におけるエンティティとの紐付きをベースとしてお墨付きを必要としないという考え方です。
もちろん、このいわば直接民主主義的なのかコルホーズ的な考え方にも、すべての群衆が誰にも扇動されることなく正しい判断を行えるのか?という疑念は付きまとうわけです。これは歴史的に見ても社会システムとしての継続性には大いに疑問な訳で、特に群衆心理が強く働く日本社会においては各個人が本当に個人の意思を持って判断ができる状態になるのではないか、社会的・商業的なお墨付きがないものに対する正しい判断を各個人ができるだけにデジタル社会は成熟しているのだろうか?ネットリンチのようなことを生むことによりソウルに死がもたらされるのではないか?LinkedInが日本に浸透仕切っていない点からもソーシャルベースのReputationシステムに対する猜疑心を拭い去ることはできないのではないか?なんという疑問は尽きません。
同じく、マイクロファイナンスなど社会的弱者に対する寛容な仕組みは必要だとは思われますが、そもそも論として弱者に対する寛容性の欠如している世界観において社会的包摂は成立するのだろうか?なんていう疑問も出てきます。
ヴィタリックはこの点について論文の中でDAOを構成する上でSBTの相関を調べて投票ウェイトを下げるなどバイアスの排除のメカニズム(相関スコア)も提案しているので解決に向かう可能性もあるのでここは個人的にも要注目かと思っています。(要するに相関割引を導入して交節点の少ないノードに対する投票ウェイトを上げることで多数決における少数意見を拾い上げるシステム)
また、ヴィタリックが書いている段階で当然ですが、イーサリアムの利用を前提としたエコシステムの範囲内で実現される世界観を描いているものである点も大きな特徴なのかもしれません。つまり、パブリックかつパーミッションレスなブロックチェーンの世界の中で表現できるものが中心となるためPII(個人情報)に関する公開制御などプライバシーに関する考慮は現時点ではまだ解がなく、現時点では衆人環視を前提とした信頼の醸成となっているという点にも留意が必要です。(論文内でも今後の考慮点として記載されています)
いずれにしても現時点でSBTは実装系も多く存在しているわけではなくERCになっているわけでもないので、あくまで理念として捉えておくのが良いかと思います。
もちろんVCはデータモデルでしかないので、SBTの理念と相反しない使い方をすることも可能です。事実、論文内にもVCを利用することに関しての言及もあります。(こちらは後ほど)
少し脇道に逸れますが、そもそも論としてDIDに関してもIssuer DIDとHolder DIDは分けて考えるべきではないか?と思います。VCの文脈における典型的なIssuer/Holder/Verifierのモデルは原則事業者と消費者のモデルがベースとなっており、Issuerは事業者、Holderは消費者となることが想定されていますが、このモデルではいかにしてIssuerの信頼性を高めることができるのか?が焦点となります。この点はDIFのWell Known DID ConfigurationによるDNSのガバナンスへの依拠などにより解決をしてきた問題です。
しかしながら、SBTに関してはIssuer/Holder/Verifierがフラットに考えられているように感じます。つまり、VCのモデルではHolderの信頼性をDIDの信頼性によって担保が難しかった点(個人となることが多く、DNSとのバインディングでは解決しにくかった)についても群衆ベース・レピュテーションベースにより解決できる可能性がある点は大きな相違点なのかもしれません。なお、論文内にも記載がありますがSBTにおけるソウルを社会的なエンティティと紐づけて信頼性を向上すること自体はヴィタリックも否定はしていませんので、この点においてはDID/VCにおける信頼性向上のアプローチと補完関係にあると言えると思います。
つまり、結果としてどちらが良いというものはないが、全公開の前提において衆人環視の元で信頼性を向上するSBTのアプローチか、現実世界のガバナンスモデルを元に信頼を構築するVCのエコシステムは信頼に関するアプローチの違いということができるのではないかと思います。そしてもちろんVC/DIDの世界観においてもSBTの衆人環視のアプローチによるレピュテーションベースの信頼性向上の仕組みを構築することは当然可能だといえます。
ヴィタリックも論文の中でVCについても触れており、SBTがプライバシーの課題に対する解決策を見つけるまでは補完関係になると言っています。
特徴として、
など挙げられています。
また、各ソウル(DID)の信頼性を向上するという意味合いにおいても、
ということも言えますので、うまくSBTの理念をDID/VCの世界の中に持ち込んでいくと面白い世界観が実現できる可能性は十分にありそうです。
論文内ではVCはコミュニティベース、レピュテーションベースの信頼性向上の仕組みを持っていないので、ソーシャルレンディングや無担保のアパート賃貸契約などのユースケースには対応できない、という話もありましたが、うまく補完しつつシナリオ毎に使い所を分類していけると良いのではないかと感じています。
ただ、先にも書きましたが現時点においてSBTはあくまで理念・概念にしかすぎないのが現実だと思うので、もう少し実装に踏み込んめるとより議論を深められるな、と思っています。
最後におまけです。
2023年3月1日〜3日にIIWのスピンオフイベントがタイであるようです。アジアでもこの手の議論が盛り上がってきていると思うので、可能な方は参加されてはいかがでしょうか?
https://identitywoman.net/save-the-date-apac-digital-identity-unconference-march-1-3-2023/
こんにちは、富士榮です。
今日はちょっとマニアックなところを。(完全に自分向けのメモです)
Microsoft Entra Verified IDは発行済みのVerifiable Credentialsの状態(有効・取り消し済み)を管理するためにDecentralized Identity Foundation(DIF)のStatus List 2021とIdentity Hubという仕様を使っています。
Decentralized Web Nodeの仕様
基本的にやりたいことはとしては、
{ "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1" ], "type": [ "VerifiableCredential", "hogehogeVC" ], "credentialSubject": { "name": "hoge taro", "mail": "hoge@exampple.jp" }, "credentialStatus": { "id": "urn:uuid:6fa4e682-f427-41cf-b0e5-59179d66fea3?bit-index=5", "type": "RevocationList2021Status", "statusListIndex": 5, "statusListCredential": "did:web:example.jp?service=IdentityHub&queries=W3sibWV0aG9kIjoiQ29...(省略)...jZmZWEzIn1d" }, (以下省略)
[ { "method": "CollectionsQuery", "schema": "https://w3id.org/vc-status-list-2021/v1", "objectId": "6fa4e682-f427-41cf-b0e5-59179d66fea3" } ]
https://discover.did.msidentity.com/1.0/identifiers/{IssuerのDID}
{ "id": "did:web:example.jp", "@context": [ "https://www.w3.org/ns/did/v1", { "@base": "did:web:example.jp" } ], "service": [ { "id": "#linkeddomains", "type": "LinkedDomains", "serviceEndpoint": { "origins": [ "https://example.jp/" ] } }, { "id": "#hub", "type": "IdentityHub", "serviceEndpoint": { "instances": [ "https://hub.did.msidentity.com/v1.0/{tenant id}" ] } } ], (以下省略)
{
"requestId": "c5784162-84af-4aab-aff5-f1f8438dfc33",
"target": "did:web:example.jp",
"messages": [
{
"descriptor": {
"method": "CollectionsQuery",
"schema": "https://w3id.org/vc-status-list-2021/v1",
"objectId": "6fa4e682-f427-41cf-b0e5-59179d66fea3"
}
}
]
}
{
"requestId": "c5784162-84af-4aab-aff5-f1f8438dfc33",
"replies": [
{
"messageId": "bafkreicksslcxa7xraqg6luqqfsezkpfalpqdqk6jzealwqxrkv7svu5vy",
"status": {
"code": 200
},
"entries": [
{
"descriptor": {
"method": "CollectionsWrite",
"schema": "https://w3id.org/vc-status-list-2021/v1",
"dataFormat": "application/vc+jwt",
"objectId": "6fa4e682-f427-41cf-b0e5-59179d66fea3",
"clock": 0,
"cid": "bafkreib5cnsi7kw5ya6otq2lybvwnqlh2ga2gmud7x7t46f4zkkcca6s5y"
},
"data": "ZXlKaGJHY2lPaUpG...(省略)...IydDNXaWhR"
}
]
}
]
}
{
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vc-status-list-2021/v1"
],
"type": [
"VerifiableCredential",
"StatusList2021Credential"
],
"credentialSubject": {
"id": "urn:uuid:6fa4e682-f427-41cf-b0e5-59179d66fea3",
"type": "RevocationList2021",
"encodedList": "H4sIAAAAAAAAA-3BAQEAAAgCoPw_qmsOEfgcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAhAJmaUnkqGEAAA"
}
},
"jti": "did:web:example.jp?service=IdentityHub&queries=W3sibWV0aG9kIjo3...(省略)...zlkNjZmZWEzIn1d",
"iss": "did:web:example.jp",
"sub": "urn:uuid:6fa4e682-f427-41cf-b0e5-59179d66fea3",
"iat": 1667651604
}
こんにちは、富士榮です
これまで当BlogでもVerifiable Credentials周りは色々と触ってきましたが、今回はAuth0ラボで公開しているサービスを触ってみます。
こんな感じでCredentialを作れるサービスです。
参考)これまで触れてきたDID/Verifiable Credentials関係のポストの一部
※まぁ、古くはConsensysのuPortなんてのをガリガリ触っていた時期もあるんですが。。。
ということで一通り触ってみましょう。
注)その名の通りラボなのでプロダクションで使うのはやめましょう。
こんにちは、富士榮です。
最近アクティビティが減っていますが分散型IDを含む諸々の活動は継続していますので時間をとって何かアウトプットしていかないとなぁ、と考えている今日この頃です。
ちょうどIgniteがあったのでAzure AD周りも色々と発表がありましたが、その中でもやっとか・・・というのがAzure ADのデータの置き場所問題です。
これまでAzure ADのデータは日本リージョンにテナントを作っても他の地域へレプリケーションされていましたが、今回のUpdateで日本データセンターに配置されることになりました。(今回の発表はAzure ADのみが対象でB2B/B2Cを含む各種サブセットについては対象外です。各コンポーネントごとのデータ配置は後述のサイトで確認できます)
公式Blog:「Announcing a New Azure AD, part of Microsoft Entra, region in Japan」
ざっくりいうと、
ということです。
なお、コンポーネント単位のデータ配置場所は「https://aka.ms/aaddatamap」で確認することができます。
「AAD Directory Data & Management」や「Authentication」など対象となっているサービスを選択すると「大阪、東京、埼玉(笑)」と出ます。
では、自分のテナントのデータの配置場所がどこになっているのか?はどうやって確認するのかですが、2つ方法があります。
一つ目は単純にポータルからディレクトリのプロパティを見る方法です。
■10月に新しく作ったテナント
リージョン(国または地域):Japan
データの場所:Japan datacenters
国または地域(リージョン):Japan
データの場所:Asia, United States, Europe datacenters
もう一つの方法はアクセストークンの中のClaimを見る方法です。
アプリケーションでリージョンを絞りたい場合などはこちらを使うことができそうです。
こちらが日本データセンターにデータがあるテナントのアクセストークンをjwt.ioでデコードしたものです。
tenant_region_scopeというClaimに"JPR"という値が入っています。
自治体とか金融機関とか医療関係などデータの置き場所に縛りのあるシナリオではこの辺りをうまく活用していくと良いでしょう。
こんにちは、富士榮です。
5月末にMicrosoftからAzure Active Directory、CloudKnox Permissions Management、Azure AD Verifiable CredentialsをまとめたMicrosoft Entraが発表されたこともあり、先日のOffice365勉強会で分散型ID(DID/Decentralized Identifiers)、検証可能な資格情報(VC/Verifiable Credentials)に関するプレゼンをさせていただきました。
事前申し込みも400オーバー、当日も230名くらいの方にご参加いただき、slidoの質問やコメントも止まらない感じで時間を大幅に超えて23時くらいまでやらせていただくくらいには盛況だった様です。(みんなそんなにDIDとVCに興味あるのかな?)
また、そんな中、W3Cでは長らくFormal Objectionによるこう着状態が続いていたDID Core Specificationに決着がつきW3C勧告へ進むことが承認された、との発表がありました。
これでますます開発者の人たちは安心してこの技術領域へ突き進んでいけますね!
ということで、先の勉強会でも発表させていただいたのですが、DID/VCに興味のあるエンジニアの皆さんが集まる場が欲しいよね、ということでCollabogateの三井さんやBlockBaseの山村さんたちと「DID Developer Community(仮)」を立ち上げることにしました。
ということでぜひご参加ください。
https://discord.gg/nn53BRRz(招待リンクが切れていたので張り替えました)
あ、参考までに先の勉強会で使った資料も貼っておきます。
こんにちは、富士榮です。
なんだかんだでuPortを触ったり現Azure Active Directory Verifiable Credentialsの前身を触ったり、最近だと数カ所で実証実験プロジェクトを立ち上げたり、MS主催のDecentralized Identity Hackathonで入賞してみたり、と分散型IDに関わり始めて5年くらい経っていたりしますので、現時点で分かったことをメモしておこうかと思います。(往々にして数年後に見返すとう〜ん、となるやつだけど気にしないことにする)
※そういう意味では2019年の#didconでその時点でわかっていることをある程度まとめて発表してからおよそ3年も経つんですね・・・
また機会があればdidconでも開催してじっくりお話させていただこうと思うので思うがままに書いた乱文ですが、こんな感じかと。(いうまでもありませんが、完全に私見です。私が関与している各種団体や事業者には一切関係ありませんので悪しからず)