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

Universal ResolverでIONのDIDを解決可能に

$
0
0

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


永らくMicrosoftの提供するION(アイオン)のDID Method、did:ionはUniversal Resolverでは解決できず、Microsoftが提供するリゾルバ(discover.did.microsoft.com)を使うしかありませんでした。

参考)DIDリゾルバあれこれ


今回、Universal ResolverのレポジトリにIONサポートのコードがマージされたことで、did:ionの解決ができるようになりました。

https://github.com/decentralized-identity/universal-resolver/pull/154


早速、レポジトリをcloneして試してみましょう。

手順はREADME.mdにある通り、

git clone https://github.com/decentralized-identity/universal-resolver
cd universal-resolver/
docker-compose -f docker-compose.yml pull
docker-compose -f docker-compose.yml up

とするだけです。

面倒ならhttps://dev.uniresolver.io/を使うのも良いと思います。


ローカルにデプロイしたUniversal ResolverとMicrosoftがホストしているリゾルバ、dev.uniresolver.ioそれぞれでテスト用のdidを解決してみました。

■ローカル

http://localhost:8080/1.0/identifiers/did:ion:xxxxxxxxxxxxxxxx


■Microsoftのリゾルバ

https://beta.discover.did.microsoft.com/1.0/identifiers/did:ion:xxxxxxxxxxx

■dev.uniresolver.io



まぁ、当たり前に解決できます。


ただ、MicrosoftのVerifiable Credentialsサービス経由で発行したdidは今のところローカルにデプロイしたdid driverでは何故か解決できませんでした。Microsoftのdiscoverサービスやuniresolver.ioだと解決できるので、まだコードに差分があるのかもしれません。


引き続き要ウォッチです。




OpenID Connectの脇役たち

$
0
0

本記事は Digital Identity技術勉強会 #iddance Advent Calendar 2020 17日目の記事です。


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

今日は年末ということもあり、普段はあまり表舞台に出てこないOpenID ConnectのOptionalなオプションにフォーカスを当ててみようかと思います。
対象とする仕様は「OpenID Connect Core 1.0」とします。


OpenID Connectの設計思想

OpenID ConnectはいわゆるID連携(Federation)を行うための仕様として、OAuth2.0の上位にアイデンティティ層を載せる形で定義されています。

そして、その設計思想は、
  • 簡単なことは簡単に
  • 難しいことも可能に
  • モジュラーデザイン
という原則に則っています。

この中の最初の原則である「簡単なことは簡単に」という部分が普段みなさんが使っているOpenID Connectを使ったログオンの実装の大半で、上記の仕様の第2章「Authentication」に定義されているAuthorization code flow、Implicit flow、Hybrid flowの3つ、特にAuthorization code flowを覚えておけば基本的なWebアプリケーションへのログインのシナリオでは何も難しいことはありません。
※当然、セキュリティ上の考慮事項などはそれなりに存在するため、stateやnonceを正しく使ってcodeを横取りされたりid_tokenを使いまわされることを防いだりする必要はありますので運用環境で使うためにはちゃんと仕様を理解して実装する必要はありますが。。。

また、2つ目の「難しいことも簡単に」、3つ目の「モジュラーデザイン」の原則の通り、OpenID Connect DiscoveryやOpenID Connect Dynamic Client Registrationなど関連仕様との組み合わせでより高度なシナリオにも対応することができるようになっています。

今回はニッチを狙いますので、OPTIONALなパラメータを重点的に見ていきたいと思います。

RFCにおける要求レベルの定義

仕様を読んでいるとMUST、SHOULD、MAY、OPTIONALなど各パラメータ毎に要求レベルが定義されています。
この要求レベル自体はRFC2119で以下の通り定義されています。
※RFC2119の日本語訳はIPAのホームページで公開されています。

以下、IPAの日本語訳です(赤字・太字は筆者)。
  1. 「しなければならない( MUST )」 
  • この語句、もしくは「要求されている( REQUIRED )」および「することになる( SHALL )」は、その規定が当該仕様の絶対的な 要請事項であることを意味します。
  • 「してはならない( MUST NOT )」
    • この語句、もしくは「することはない( SHALL NOT )」は、その規定が当該仕様の絶対的な禁止事項であることを意味します。
  • 「する必要がある( SHOULD )」
    • この語句もしくは「推奨される( RECOMMENDED )」という形容表現は、 特定の状況下では、特定の項目を無視する正当な理由が存在するかもしれませんが、 異なる選択をする前に、当該項目の示唆するところを十分に理解し、 慎重に重要性を判断しなければならない、ということを意味します。
  • 「しないほうがよい( SHOULD NOT )」 
    • この語句もしくは「推奨されない( NOT RECOMENDED )」という形容表現は、 特定の動作が容認できる、ないし、非常に有用である、というような 特定の状況下では、正当な理由が存在するかもしれませんが、 このレベルの動作を実装する前に、当該項目の示唆するところを十分に理解し、慎重に重要性を判断しなければならない、ということを意味します。
  • 「してもよい( MAY )」 
    • この語句、もしくは「選択できる( OPTIONAL)」という形容表現は、ある要素が、まさに選択的であることを意味します。 その要素を求めている特定の市場があるから、あるいは、 他のベンダーはその要素を提供しないだろうが、その製品機能を拡張する と察知して、その要素を含む選択をするベンダーがあるかもしれません。 特定の選択事項(オプション)を含まない実装は、おそらく機能的には劣る ことになるでしょうが、そのオプションを含む他の実装との相互運用に備えなければなりません( MUST )。 同様に、特定のオプションを含む実装は、そのオプションを含まない実装 との相互運用に備えなければなりません( MUST )。(当然ながら、そのオプションが提供する機能は除かれます。)

    まさに今回のターゲットはMAY、もしくはOPTIONALな部分です。

    MAYとOPTIONALを仕様から抽出する

    早速、仕様の中にどのくらいMAYとOPTIONALがあるのか抽出してみます。
    • MAY:87個
    • OPTIONAL:53個
    ・・・結構ありますね。

    全部カバーしているとキリがないので、独断と偏見でMAY/OPTIONALを5個選んで番付的に紹介してみようと思います。
    ※もちろんOPTIONALなので実装しているOpenID Providerばかりではありませんので、動かしてみても期待する反応がえられないケースが多いので悪しからず。

    十両:prompt

    認証リクエストにpromptパラメータを付加することで再認証や同意を求めることができます。

    仕様では3.1.2.1のAuthentication Requestの項に定義されています。(OpenIDファウンデーションジャパンの日本語訳から引用)
    OPTIONAL. Authorization Server が End-User に再認証および同意を再度要求するかどうか指定するための, スペース区切りの ASCII 文字列のリスト. 以下の値が定義されている.
    none
    Authorization Server はいかなる認証および同意 UI をも表示してはならない (MUST NOT). End-User が認証済でない場合, Client が要求する Claim 取得に十分な事前同意を取得済でない場合, またはリクエストを処理するために必要な何らかの条件を満たさない場合には, エラーが返される. 典型的なエラーコードは login_requiredinteraction_required であり, その他のコードは Section 3.1.2.6 で定義されている. これは既存の認証と同意の両方, またはいずれかを確認する方法として使用できる.
    login
    Authorization Server は End-User を再認証するべきである (SHOULD). 再認証が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは login_required である.
    consent
    Authorization Server は Client にレスポンスを返す前に End-User に同意を要求するべきである (SHOULD). 同意要求が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは consent_required である.
    select_account
    Authorization Server は End-User にアカウント選択を促すべきである (SHOULD). この prompt 値は, End-User が Authorization Server 上に複数アカウントを持っているとき, 現在のセッションに紐づくアカウントの中から一つを選択することを可能にする. End-User によるアカウント選択が不可能な場合はエラーを返す (MUST). 典型的なエラーコードは account_selection_required である.
    prompt パラメータは Client に対して, End-User のセッションがアクティブであることを確認したり, End-User にリクエストに対する注意を促すことを可能にする. none がその他の値とともに用いられる場合はエラーとなる.

    アプリの仕様でトランザクションの種類によって強制再認証を求めたり、同意を求めたりするケースもあると思うので、そのような場合はうまくpromptパラメータを使うと良いですね。

    前頭:target_link_uri

    SAMLでいうrelayStateですね。

    仕様にも記載がありますが、全てのログインフローがRelying PartyからOPへのリクエストによって始まるわけではなく、OP起点だったり別のシステム(ポータルなど)から起動されることもあります。そのような場合、ログインフローを起動するシステムはRPのログイン開始エンドポイントへユーザをリダイレクトしてフローを起動するわけですが、ログインが完了した後、必ずしもRPのデフォルトのランディングページに着地させたいわけではなく、別のページへ飛ばしたい、というケースもあります。そのような場合にtarget_link_uriに指定するとログイン完了後に望むページへ遷移させることができます。

    ただ、注意点として記載がある通りOpenリダイレクタにならないように指定できるURLはきちんと検証しないといけません。

    仕様では4のInitiating Login from a Third Partyの項に定義されています。(OpenIDファウンデーションジャパンの日本語訳から引用)
    target_link_uri
    OPTIONAL. 認証後, RP がリダイレクトするよう要求された URL. RP は外部サイトへのオープンリダイレクターとして使用されることを防ぐために target_link_uri の値を検証しなければならない(MUST).
    SAMLを使ったシステム導入の際はrelayStateに関する要望は結構あったので、今後このパラメータもメジャーになってくるかな?と思います。

    関脇:request/request_uri

    いわゆるRequest Objectです。FAPI Part2では認可要求自体への署名が要求されるので、普通にQuery Stringに各種リクエストパラメータをくっつけるのではなく、JWTとして認可サーバへ渡してあげる必要があります。また認可要求にJWTそのものを渡すこともできますが、request_uriに指定したエンドポイントを参照させることによりリクエストパラメータを取りに来てもらうこともできます。

    仕様では6のPassing Request Parameters as JWTsの項に定義されています。(OpenIDファウンデーションジャパンの日本語訳から引用)
    request
    OPTIONAL. このパラメータにより, OpenID Connect リクエストを単一の self-contained なパラメータとすることができ, 任意で署名および暗号化を施せるようになる. パラメータ値は Request Object 値である (Section 6.1 参照). Request Object は, 各 Claim がリクエストパラメータとなる JWT である.
    request_uri
    OPTIONAL. このパラメータにより, 値そのものではなく参照を送ることが可能になる. request_uri 値は https スキーマで始まる URL であり, Request Object 値を含むリソースへの参照となる. 参照先の Request Object は, リクエストパラメータを含む JWT である.
    金融サービスに限らず要求についても隠蔽したいケースや署名をつけて確実に渡したいケースではこのパラメータは活躍する場面がありそうです。

    大関:id_token_hint

    完全に個人的な趣味です。実はAzure ADを使っていると結構活躍の機会が多いんです。例えば今はもう新規のサポートは受け付けていませんがPremium P2の機能のカスタムMFAプロバイダへのセッション引き継ぎはid_token_hintを使って行っていましたし、そもそもOffice365→Azure AD→外部IdPというようなチェーン構成のフェデレーションでは前段で入力されたユーザ名のドメインパートに基づきログイン先のIdPを動的に変更する、なんということもよくやります。そのようなケースでは前段のIdPでのユーザの挙動(入力した値や、その値から導き出された値など)を連鎖する後段のIdPにも伝えないと、ユーザ名を2回入力する必要が出てきたり、とUXを毀損してしまいがちです。

    このようなケースではid_token_hintの中に必要なパラメータを詰め込んで後段のIdPへJWTとして渡してあげることで格段にUXが向上します。
    (Office365のケースではOpenID Connect→ws-federationの連鎖なのでusernameというパラメータを使っていますが)

    仕様では3.1.2.1のAuthentication Requestの項に定義されています。(OpenIDファウンデーションジャパンの日本語訳から引用)
    id_token_hint
    OPTIONAL. Authorization Server が以前発行した ID Token. Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される. もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す. さもなければ, Authorization Server は login_required のようなエラーを返す (SHOULD). prompt=none を利用する場合は, 可能であれば id_token_hint を指定するべきであり (SHOULD), さもなければ invalid_request を返しても良い (MAY). ただしサーバーはその場合可能な限りサクセスレスポンスを返すこと. id_token_hint 利用時は, ID Token の audience に Authorization Server 自身が含まれている必要はない.
    id_token_hint として使用するために RP によって受信された OP からの ID Token が暗号化されていた場合, クライアントは暗号化された ID Token を含んだ署名済みの ID Token を復号しなければならない (MUST). クライアントは Authentication Server に送信する署名済みの ID Token をサーバーが ID Token を復号できる鍵を用いて再暗号化し, id_token_hint の値として使用してもよい (MAY).

    横綱:claims

    最後の横綱級はなんといってもclaimsでしょう。理由はシンプルで私も共同議長を勤めさせていただいるOpenID FoundationのeKYC and Identity Assurance WGで策定中のOpenID Connect for Identity Assuranceの仕様はclaimsがあるから成り立っている、といっても過言ではないからです。

    パラメータの意味合いとしてはRPからOPへの認証要求時にclaimsに指定した属性をid_tokenもしくはuserInfoとして提供することを明示的に求める、というものです。OpenID Connect for Identity Assuranceではこの機能を拡張してRPがOPに検証済みの属性を要求する、ということを実現しています。

    仕様では5.5のRequesting Claims using the "claims" Request Parameterの項に定義されています。(OpenIDファウンデーションジャパンの日本語訳から引用)
    claims
    OPTIONAL. 当パラメータは, 特定の Claim の返却を要求するのに用いられる. 値は要求する Claim をリスト化した JSON オブジェクトである.

    claims Authentication Request パラメータは, 特定の Claim を UserInfo Endpoint から, かつ/または ID Token 内で, 返却することを要求する. これは要求する Claim のリストを含む JSON オブジェクトとして表される. 要求する Claim のプロパティが指定されていてもよい (MAY).

    claims パラメータのサポートは任意である (OPTIONAL). 当パラメータをサポートしない OP に対して RP が当パラメータを使用したとき, OP は 適切と思われるヒューリスティックな方法を用いて, RP と End-User にとって有益と思われる Claim のセットを返すべきである (SHOULD). Discovery で得られる claims_parameter_supported は, OP が当パラメータをサポートしているかどうかを示す.

    claims パラメータ値は, OAuth 2.0 要求の中で, UTF-8 でエンコードされた JSON として表される (最終的には OAuth パラメータとして受け渡されるときに form-urlencoded される). Request Object 値として使用される際は, Section 6.1 により, JSON が claims メンバーの値として使用される.

    Claim 要求 JSON オブジェクトのトップレベルメンバーは以下の通り:

    userinfo
    OPTIONAL. UserInfo Endpoint へ返却を要求する個々の Claim のリストを示す. 当メンバーが存在した場合, scope 値で要求された Claim に加え, 当メンバーでリストされた Claim も返却される. 当メンバーが存在しなかった場合, scope 値で要求された Claim のみが返却される.
    userinfo メンバーを指定する際は, UserInfo Endpoint を使用するために, response_type に対し, Access Token を Client に発行するタイプの値を指定しなければならない (MUST).
    id_token
    OPTIONAL. ID Token 内に格納して返却を要求する個々の Claim のリストを示す. 当メンバーが存在した場合, デフォルトの Claim に加え, 当メンバーでリストされた Claim も返却される. 当メンバーが存在しなかった場合, デフォルトの Claim のみが返却される. デフォルトの Claim 等の ID Token の定義については Section 2を, フロー毎の ID Token 要件については Section 3.1.3.63.2.2.103.3.2.113.3.3.6 を参照すること.

    上記以外のメンバーが存在してもよい (MAY). 認識できないメンバーが使用された場合は無視しなければならない (MUST).


    通常のOPでclaimsを利用している実装ってあまり見かけないのですが、先日某芸能事務所のファンクラブサイトに娘がログインするところをトレースしていたらclaimsを使っているのが判明し驚愕しました(w)
    ちなみになぜclaimsを使っているのかはよくわかりません。。。自前RPと自前OPのはずなのでこんなことをしなくてもOPが必要な属性をid_tokenやuserInfoに入れて返してあげれば済むと思うのですが・・・



    いかがでしたか?
    他にもご紹介したいニッチなパラメータもいっぱいあるので、また機会があればご紹介できればと思います。

    MATTRの分散型IDプラットフォームを触ってみる - その 1

    $
    0
    0

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

    ここ数年、uPort〜Microsoft VC as a Serviceなど分散型ID(DIDs/VCs*)に絡んでいるわけですが、一昨年秋のIIWに参加したときにPoCの話を聞いたMATTRのプラットフォームがかなりいい感じに進化していたので触ってみました。

    * DIDs: Decentralized Identifiers

    * VCs: Verifiable Credentials


    MATTRについて

    会社自体についてはそこまで詳しく知りませんが、ニュージーランドの会社です。

    この辺りこの辺りでは有名ですね。

    現在、MATTRが提供しているのはプラットフォームと関連する開発ツール群のようです。

    プロダクトページより)


    MATTR Platformについて

    プラットフォームはコア機能として、

    • DID
    • Messaging
    • Verifiable Credentials
    • Verifiable Presentations
    に関する生成、取得、削除、検証に関する機能群を提供しています。

    また、拡張機能として、
    • OIDC Bridge
    • White Label Mobile Wallet & SDKs(提供予定)
    が、ロックイン回避のために以下の機能もあらかじめ提供しているようです。
    • 複数のDID Methodのサポート
    • Secure Storageのサポート
    • プラガブルなKey Managementのサポート
    IIWではOIDC Bridgeの部分のデモを見せてもらいました。
    当時、私はuPortとAzure AD B2CとLibJeIDを組み合わせて免許証をトラストアンカーにしたuPort Credentialを発行、B2BのWebサイトでの身元確認を行う、というようなデモを作ったりしていました。懐かしい。


    開発ツールについて

    プラットフォーム以外にも開発者向けに以下の機能が提供されています。
    • MATTR Mobile Wallet App
    • Sample Applications
    • MATTR Command Line Interface(提供予定)


    今回、プラットフォームのコア部分に関するSandbox環境を払い出してもらったので少し触ってみます。

    では、早速レビューを。

    トライアル申し込みをする

    まずは環境をもらうところからですが、先程のプロダクトページの一番下にSandbox環境のトライアル申し込みがあるので申し込んでみました。

    しばらくするとメールとSlackへの招待がくるので、Slackで担当の方と会話をすることになります。基本的にはKeybase上でトライアルテナントの情報とかシークレットなどを渡すからまずはKeybaseのアカウントを教えるように言われるのでアカウント名を伝えます。
    (Keybaseのアカウントを作るところから始めました)

    アカウントを伝えると今度はKeybaseのチャットで担当の人から以下の情報をもらえます。
    • tenantSubdomain: xxxx.sandbox.platform.mattr.global
    • tenantId: xxx-xxx-xxx
    • url: https://mattr-prod.au.auth0.com/oauth/token(Auth0使ってるんですね)
    • audience: https://platform.mattr.global
    • client_id: xxxxxxxxxxx
    • client_secret: xxxxxxxxxxx

    プラットフォームの設定を行う

    先にもらった情報があるとプラットフォームにアクセスできるようになります。(といってもAPIだけしか存在しないので、APIを叩きまくるんですが)

    詳細は
    に手順がのっているのでこちらをみながら進めます。

    API Auth Tokenを取得する

    要するに、先程Keybaseで伝えられたclient_idやclient_secretはAuth0のプラットフォームでaccess_token(MATTRプラットフォームのAPI Auth Token)を取得するためのものだったわけです。
    普通にclient_credentialsでaccess_tokenを取得します。

    curl --request POST \
    --url https://mattr-prod.au.auth0.com/oauth/token \
    --header 'Content-Type: application/json' \
    --data '{"client_id": "xxxxxxxxxx",
    "client_secret": "xxxxxxxxxx",
    "audience": "https://platform.mattr.global",
    "grant_type": "client_credentials"
    }’

    DIDを生成する

    まずはDIDを生成してます。
    methodとしてはkey、web、sovの3種類をサポートしているようです。
    didのエンドポイントにAPI Auth Tokenをつけて生成リクエストをPOSTするだけなので非常にシンプルです。
    curl --request POST \
    --url https://tenant.platform.mattr.global/v1/dids \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --header 'Authorization: Bearer REPLACE_ACCESS_TOKEN' \
    --data '{ "method":"key",
    "options": {
    "keyType":"ed25519"
    }
    }'

    うまくいくとDID Documentが返ってきます。
    MATTRのResolver APIもありますが、Universal Resolverでもちゃんと解決できるようになります。

    Issuerに関する情報を確認する

    DIDを発行することでIssuerのDID構成情報を確認することができるようになります。DIFのWell Known DID Configurationのスペックに対応しているようです。

    curl --request GET \
    --url https://tenant.platform.mattr.global/.well-known/did-configuration \
    --header 'Accept: application/json'

    結果、IssuerのDID構成情報が確認できます。

    VCを発行する

    こちらもAPIが用意されていますので、IssuerのDID、SubjectのDID、VCに含めるClaimなどを決めてPOSTしてあげるだけです。
    curl --request POST \
      --url https://tenant.platform.mattr.global/v1/credentials \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --header 'Authorization: Bearer REPLACE_ACCESS_TOKEN' \
    --data '{"@context":["https://www.w3.org/2018/credentials/examples/v1" , "https://www.w3.org/2018/credentials/v1"],
    "subjectId":"did:key:z6MkjBWPPa1njEKygyr3LR3pRKkqv714vyTkfnUdP6ToFSH5",
    "type":["AlumniCredential"],
    "claims":{"givenName":"Jamie",
    "familyName":"Doe",
    "alumniOf":"Example University"},
    "issuer":{"id":"did:key:z6Mkg7FkYxUpSKBEUJMeG91A9vz66GfWxB4m9Lq81AMZ7wNT",
    "name":"Example University"},
    "persist":true,
    "revocable":true
    }'

    ありがちな卒業生である証明を発行するサンプルですね。

    発行したVCは同じAPIのエンドポイントにGETしてあげると一覧表示されます。

    とりあえず最低限必要な機能はちゃんと動いていますし、他にもVCのRevokeなど管理系のAPIも充実している感じです。

    Walletアプリも使えるようにしてもらったので、次回はOIDC Bridgeと合わせてWalletへのVP/VC発行とOIDC-DID Authのゲートウェイでのログインなどチュートリアルにそって試してみようかと思います。

    MATTRの分散型IDプラットフォームを触ってみる - その2

    $
    0
    0

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

    前回に引き続きMATTRの分散型IDプラットフォームを触ってみます。

    前回はプラットフォーム自体のセットアップとIssuer DID、VC(Verifiable Credential)の設定までを行いましたので、今回はWalletに対して実際にVCを発行するところまでをやってみます。

    MATTRの基本的な考え方としては、バックエンドのプラットフォーム自体は認証やユーザ管理の機能を持たず外部のIdentity Providerと連携したIssuerを通じてVCを発行する、という形となっています。

    公式ドキュメントではAuth0と連携したIssuerを作成し、VCを発行する仕組みが紹介されていますので、まずはこれをやってみたいと思います。

    やるべきことは以下の3つです。

    • 外部OpenID Providerの構成
    • 外部OpenID Providerと連携したIssuerの定義を作成
    • 出来上がったIssuerでの発行リクエストをQRコードにしてWalletで読み取りVCを発行

    順番にやっていきましょう。

    外部OpenID Providerの構成

    先に触れた通り、Auth0を使って構成します。
    (ちなみに、Azure AD B2Cで構成しようとするとwell-knownまでのパスが深すぎてMATTR側でInternal Server Errorが出ます。リバプロなどでAzure AD B2Cをカスタムドメイン化して動かしてあげる必要があります。これは別のポストで今後紹介していこうと思います)

    Auth0は普段使っているテナントがそのまま使えるので特に問題はありません。
    やるべきことは、
    • アプリケーション(Client)を作成する
    • ユーザに発行すべきcredentialの型と値を属性として持たせる

    の2点だけです。

    まずはアプリケーション登録ですが、通常のRegular Web Applicationとしてクライアント定義をしていきます。


    MATTR側に設定するために必要なのはclient_idとclient_secretのみなのでアプリケーションを作成したこれらの値をメモしておきましょう。

    ちなみにredirect_uriについてはMATTR側でIssuer定義を行うと生成されますのでここでは設定しなくてもOKです。


    次にユーザに必要な属性を設定します。これもAuth0側の設定となりますが、該当のユーザを開き、user_metadataとして属性と値を設定します。サンプルに従いこんな感じに設定します。

    {
    "educationalCredentialAwarded": "Almuni 2020"
    }


    一旦はOpenID Provider側の設定はおしまいです。

    Issuerの作成

    次はMATTRのAPIを使って先のOpenID Providerと連携したIssuerの定義を行います。
    やるべきことは、以下のデータを設定したJSONをエンドポイントにPOSTするだけです。
    • 前回のPOSTで生成したIssuer DID
    • 先に取得したclient_id、client_secret、OPのurl(内部的に.well-knownを取得しにいくのでドメイン名の部分まで)
    • 属性のマッピング
    この辺りはMicrosoftの仕組みとほぼ同じですね。Rulesの定義の仕方もDIF(Decentralized Identity Foundation)で仕様化をしようとしているので、今後は統一されてくるのかもしれませんが。

    以下がサンプルに書いてあるIssuer作成のリクエストです。

    curl --request POST \
    --url https://tenant.platform.mattr.global/oidc/v1/issuers \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --header 'Authorization: Bearer REPLACE_ACCESS_TOKEN' \
    --data '{"credential": {
    "issuerDid": "did:key:z6MkjBWPPa1njEKygyr3LR3pRKkqv714vyTkfnUdP6ToFSH5",
    "name": "University Attendance Credential",
    "context": [
    "https://schema.org"
    ],
    "type": [
    "AlumniCredential"
    ]
    },
    "federatedProvider": {
    "url": "https://example-university.au.auth0.com",
    "scope": [
    "openid",
    "profile",
    "email"
    ],
    "clientId": "vJ0SCKchr4XjC0xHNE8DkH6Pmlg2lkCN",
    "clientSecret": "QNwfa4Yi4Im9zy1u_15n7SzWKt-9G5cdH0r1bONRpUPfN-UIRaaXv_90z8V6-OjH"
    },
    "claimMappings": [
    {
    "jsonLdTerm": "alumniOf",
    "oidcClaim": "alumni_of"
    }
    ]
    }'

    結果、CallbackUrlを含むIssuerの設定情報が返ってくるので、この値をAuth0側のアプリケーション設定に追加します。

    小さくてわかりにくいですが、Response Bodyの中にCallbackUrlが見えます。


    WalletへVCを発行する

    ここまででVC発行の準備は整いましたので、Walletアプリを使ってVC発行要求を読み込んでみます。

    発行要求はこんなURLになるので、適当にQRコードにしてMATTRモバイルアプリで読み込ませます。
    openid://discovery?issuer=https://tenant.platform.mattr.global/oidc/v1/issuers/983c0a86-204f-4431-9371-f5a22e506599
    ※この最後のIDは先に生成したIssuerのIDです。


    QRコードを読み取ると左端の画像のようにCredential Offerとして表示され、ProceedをタップするとAuth0のログオンが要求され、成功するとCredentialを受け取流ことができます。



    発行されたVCはこんな感じで中身の確認ができます。


    全体に結構簡単でした。

    今後はMicrosoftのVC基盤との連携や連携するID基盤としてAzure AD B2Cを使う、などのカスタマイズを入れていこうと思いますので、ネタが溜まってきたらまたご紹介させていただこうと思います。


    [Azure AD B2C]遂にカスタムドメインがやってきた

    $
    0
    0

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


    おそらくAzure AD B2Cユーザ最大の要望だったカスタムドメイン(b2clogin.comのサブドメインではなく持ち込みのドメイン)がようやくパブリック・プレビューになりました。

    参考)b2clogin.comのサブドメインをカスタムドメインと言っていた頃の記憶


    当時もコレジャナイ感を感じつつ、Azure AD B2Cを使っているはずのレアル・マドリードのサイトを見ると自前ドメインを使ってるやん、、的な羨望の眼差しを抱えつつ実案件ではUSまで押しかけてプライベート・プレビューとして個別にカスタムドメインをアンロックしてもらったり、と苦労していたものです。。。


    この苦労は当然世界共通で、中にはWeb Appをフロントにたててrewriteを使って無理矢理カスタムドメインを実現してしまう猛者まで現れる、という状態でした。

    (ちなみにこの方法、当然のことながら可用性は落ちますし、Identity Protectionを使ったクライアント判定もできなくなるのでオススメはできません)



    ということで、ようやくパブリック・プレビューです。

    https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/custom-domain?pivots=b2c-custom-policy


    仕組みとしては、Azure Front DoorをAzure AD B2Cの手前においてURLのRewriteする、という形です。ってこれ、上で紹介した猛者のやってた技をオフィシャルに実装した、という感じなんですね。

    Identity Protectionなどはちゃんと効くのか、などはおいおい深堀りしてみるとして、まずはファーストルックです。


    大まかな手順としては、

    1. Azure AD B2Cの実体となっているAzure ADにカスタムドメインを追加する
    2. Azure Front Doorを作り、b2clogin.comへ振り分け設定をする
    3. Azure Front Doorにカスタムドメインを設定する
    という流れです。


    順に確認してみましょう。

    1. Azure AD B2Cの実体となっているAzure ADにカスタムドメインを追加する

    ご存知の通り、Azure AD B2Cには実体となっているAzure ADが存在します。ポータルからAzure AD B2Cを立ち上げると、別のテナントが開き、その中でAzure AD B2Cの管理を行う、という形になります。この別テナントにもAzure ADが存在しているので、Azure AD B2Cの管理画面からテナントを変えずにAzure Portalのホームへ遷移、改めてAzure ADの管理メニューを開くと実体の管理ができるようになります。(分かりにくいですね)

    そのテナントは通常のAzure ADなのでカスタムドメインを追加することができます。


    ここで普通にカスタムドメインを追加し、ドメインの所有権の確認を行います。

    これで第1段階はOKです。


    2. Azure Front Doorを作り、b2clogin.comへ振り分け設定をする

    次はAzure Front Doorを作って構成します。

    Azure Front Doorは単純なエッジで動くレイヤ7のフロントサービスで、SSLのオフロードなどを含め高スケーラビリティなWebアプリをデプロイするのに役に立つサービスです。

    必要な設定は、

    • フロントエンド設定(リクエストを受けるドメイン)
    • バックエンド(振り分け先となるWebアプリケーション)
    • 振り分けルール(パスやポートなど、バックエンドへの振り分け条件の設定)
    の3種類です。

    まずはフロントエンドです。この段階では適当な名前でAzure Front Doorドメイン(azurefd.net)上の名前を定義します。※どっちみち後でカスタムドメインをつけるので適当でOK、っていうことです。


    次にバックエンドです。今回はAzure AD B2Cがバックエンドとなりますので、カスタムドメインを使いたいAzure AD B2Cのテナントドメイン名(xxx.b2clogin.com)を設定します。

    最後が振り分けルールです。

    ここでは特に考えずにフロントとバックエンドをストレートにマッピングしておきます。

    ここもカスタムドメインを追加した後でちゃんと設定しますので仮でOKです。

    これでAzure Front Doorの基本設定は完了です。


    3. Azure Front Doorにカスタムドメインを設定する

    次はAzure Front Doorにもカスタムドメインを設定します。ここで設定するドメインは先にAzure ADに設定したドメインと同じものを使う必要があります。

    Azure Front Doorのフロントエンドまたはドメインよりカスタムドメインを追加します。

    CNAMEの設定と検証が走るので必要なレコードをDNSサーバ上に設定する必要がありますが、設定としては単純にカスタムドメインを追加するだけです。


    正常にドメインが追加できたら、振り分け規則についてもカスタムドメインの設定を行います。フロントエンドまたはドメインの設定より追加したカスタムドメインを選択するだけなので特に難しいことはありません。


    とりあえず設定関係はこれで完了です。

    (ちなみにSSL証明書もAzure Front Door側が勝手に設定するので別途買う必要はありません)

    ただ、忘れがちな点が何点かあります。

    • カスタムHTMLをAzure Storage上に配置している場合はCORS設定を行う
    • redirect_uriや各種エンドポイントのアドレスも当然変わるので外部IdPなどに設定してあるredirect_uriやアプリに設定してあるエンドポイントアドレスを修正する

    カスタムHTMLを使っている場合のCORS設定

    外部IdP(LINEの例)のredirect_uriの追加



    これで本当に設定完了です。


    試してみる

    とりあえず適当なアプリの設定を変えたらログイン要求をしてみます。



    ちゃんとカスタムドメインで動きます。

    id_tokenの中のIssuerのURIも変わっていることが分かります。


    特にむずかしいことはなく、問題なく動きました。


    とはいえ気になる点は何点か。
    • Identity Protectionなどフロントの環境を取得して動くサービスやカスタムポリシーの要求リゾルバはちゃんと動くのか?
    • カスタムドメインを設定しても、https://カスタムドメイン/xxx.onmicrosoft.com(もしくはテナントID)となってしまうのをhttps://カスタムドメインだけにできないか?(ルール設定でなんとかなる気もしなくもない)
    • SAML IdPとしてAzure AD B2Cをつごかす場合のIdPのEntityIDも変わっちゃう?
    などなど。


    引き続き試してみようと思います。











      Azure AD Verifiable Credentialsがやってきた(Public Preview)

      $
      0
      0

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

      ようやく出ました、Azure AD Verifiable CredentialsのPublic Preview。


      AlexのBlog

      https://techcommunity.microsoft.com/t5/azure-active-directory-identity/announcing-azure-ad-verifiable-credentials/ba-p/1994711


      各種リソース

      https://www.microsoft.com/en-us/security/business/identity-access-management/verifiable-credentials

      某社もソリューションパートナーになってます。

      この辺りからチュートリアルも触れるのでガシガシ触っていけると面白いと思います。

      Microsoft Authenticatorを最新版にアップデートするとこんな感じでVerifiable Credentialsをどんどん発行していけます。これで各種デジタルな証明書を持ち運んでIdPにアクセスすることなくVerifierへ証明書を提示していくことができるようになるはずです。





      詳しくは以前didconで話したので、こちらをみてもらえるとある程度の技術は抑えられるかと思いますので是非。



      ちなみに、先日ベースとなる分散台帳であるIONも無事にmainnetに移行したので、Azure Portalで生成したDID(Decentralized Identifier)に関するDID Documentもちゃんと公開されています。(少し時間がかかりますが)

      ここで確認できます。




      [Azure AD B2C]カスタムポリシー内のエラーハンドリング

      $
      0
      0

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

      たまには小ネタを。


      Azure AD B2Cのカスタムポリシーを使ってUserJourneyを構成する際に悩ましいことの一つはエラーハンドリングです。

      初期状態だと、UserJourney内のOrchestrationStepでエラーが発生した場合はエラーメッセージをパラメータにつけて呼び出し元のアプリケーションへリダイレクトする、という振る舞いをするので、アプリケーション側で発生しうるエラー毎に振る舞いを定義してあげる必要があります。


      かっちりした開発をする場合はちゃんとアプリケーション側でエラーハンドリングをするのが正解だとは思いますが、アプリ側に手が入れにくい場合などある程度Azure AD B2C側でエラー画面を出して処理を止めたい場合もあります。こういう時に使うのがUserJourneyBehaviorsに定義するOnError Modeです。
      とりうるパラメータと振る舞いは以下の通りです。
      • DisplayInService:Azure AD B2Cのフローの中でエラーメッセージを表示して処理を止める
      • ReturnToRequestor(Default):呼び出し元アプリケーションへエラーメッセージをつけて戻す

      試しに絶対にエラーになるREST APIを呼び出すClaimsProviderを作りUserJourneyの中で呼び出して見ます。

      ServiceUrlがhttps://www.example.com/apiとなっているのでNot Foundとなり、このTechnical Profileは絶対に失敗します。

      このUserJourneyを呼び出すRelyingPartyのOnError ModeをDisplayInServiceにセットして見ます。


      これでフローを実行してみると一番最初に貼り付けた画像の挙動(初期状態)とはことなり、Azure AD B2Cのフローの中でエラーメッセージが表示され、フローが停止します。



      どちらが良いかはシナリオ次第ですが、デバッグ時はこちらのモードを使ったほうがわかりやすいかもしれませんね。


      Build 2021で発表されたAzure AD B2Cのアップデート

      $
      0
      0

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


      今年も Build のシーズンですね。

      Ignite に比べて主に Developer 向けの Update がメインなカンファレンスなので Identity 要素は薄めですが、もろもろ発表はありました。

      ※主にこのセッションからです。


      ざっくりですが、すでに発表済みだったものも入れるとこんな感じです。

      (ドキュメントが公開されているものはリンクしておきます)



      Apple ID サポートは2年くらい前にカスタムポリシーで実装してたやつですね。その後 Private Preview で一部では提供されていたので私も評価していたんですが、しばらく前に全面的にリニューアルされて出てきました。ただ、個人的には iOS も最近は Platform Authenticator としてつかえるので Apple ID としてサポートするよりも FIDO として実装しちゃった方がいいじゃないかな?と思ってます。(仕事で Azure AD B2C のデプロイする場合は FIDO でやっちゃってます)

      昔実装した様子の動画



      Verifiable Credentials を使ったログインは個人的にも注目している領域です。デモはされていましたが、正式に Claims Provider として Verifiable Credentials がサポートされるのかどうかはわかりません。




      実は私も半年くらい前にこの辺りの実装をしてみてました。こんな感じの動きになります。



      Identity Protection 連携はこちらも以前投稿したやつですね。ようやくGAです。



      API Connector はカスタムポリシーを使いたくない人向けですね。(私はユーザーフローは基本使わない人なのであんまり興味ないです)



      カスタムドメインもちょうど先日投稿したやつですね。Azure Front Door を使って実装するやつです。これまで Microsoft と交渉しないと使えなかった機能なので、今更ながらに非常に嬉しい機能です。



      他にも Ask the Expert セッションを聴いていると色々とポロリもあったりして面白かったです。(TOTP の Private Preview の話とか)


      最近は Identity Verification Partner との連携などエコシステムも育ってきつつある Azure AD B2C ですが、Microsoft 自身によるエンハンスも着実に進んでいるみたいなので引き続き楽しんで触っていけそうです。




      必読!「デジタルアイデンティティー」

      $
      0
      0

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


      ついに発売されました。米OpenID Foundation理事長の崎村夏彦さんによるデジタルアイデンティティに関する集大成とも言える書籍、その名も「デジタルアイデンティティー 経営者が知らないサイバービジネスの核心」です。

      献本いただきましたので早速熟読してみました。


      もう一言では言い尽くせないのですが、何しろ素晴らしい。(ボキャブラリー不足、、汗)

      ここまで体系的かつ広い視点でデジタルアイデンティティに関して俯瞰した書籍は洋書を含めて存在していなかったんじゃないか?と思います。(Phil Windleyの「Digital Identity」はもちろん良書ですが、如何せん2004年の書籍なので古くなってきています)


      とにかくこちらから購入できるので、まだの人は今すぐポチるのです。


      ざっと感想を含め見どころを。

      • 言葉の定義が経緯を含めとにかく丁寧に書かれている
        • これを見ると世の中に出回っている記事がどれだけ適当な理解で書かれているのかわかってしまいます。この辺がこの領域をわかりにくくしている原因の一つだと思います。
      • 技術仕様がなぜ必要なのか、OAuth/OpenID Connectがなぜ必要となったのか、など歴史的な経緯を含め解説されている
        • 頑張って仕様を読んでも、あくまで結果をみているだけなので、なぜこのような仕様になったのか?がわからず腹に落ちにくい点もあると思います。もちろん解説記事やイベントでのプレゼンテーションは存在するのですが、分散してしまっているので体系的に理解するのは至難の業です。
      • FAPIやeKYC&IDAなど若い仕様についても言及されている
        • 単純にフレームワークとしてのOAuth/OpenID Connectだけでは不足している実世界でのユースケースと対応するためのプロファイル群についても詳細に記載されている。
      • よく知っている事件を例に何が必要だったのかを解説しており、理解しやすい
        • ドコモ口座事件、SBI証券の不正出金の件、Facebookのアクセストークン漏洩事件などIT業界のみならず広く報道された事件の裏側がデジタルアイデンティティの側面から解説されており、腹落ちしやすい。
      • プライバシーと個人情報保護の関係、トラストフレームワークなどビジネス担当も技術担当も周辺知識として知っておく必要がある知識もカバーしている
        • まさにサブタイトルにもなっている「経営者がしならない〜」という点にも繋がりますが、システム担当だけでなくビジネス担当やまさに経営者の方も知らなかった、では済まされないプライバシー尊重に関する考え方についても非常に易しく書かれており、非技術者でも読みやすい。

      書き始めるとキリがないので、この辺りでやめておきます。

      また、大きな特徴として「他の文献への参照が異常に少ない」という点が挙げられると思います。これは常に第一線でデジタルアイデンティティに取り組んでこられた崎村さん自身が執筆している、ということが大きく影響していると思われます。つまり、本書は今後の文献では一次ソースとして扱われることになる、ということを示しています。その点においても必携・必読であるとも言えます。


      ちなみに、OpenIDファウンデーション・ジャパンでは崎村さんをお招きして本書の見所解説などを直接お話しいただく出版記念イベントを企画している最中です。こちらは纏まりましたら改めてお知らせしたいと思います。(サインもらえるかも!)

      新Sign in with SlackでAzure AD B2CにSlackでサインインできるようにする

      $
      0
      0

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


      Sign in with SlackがOpenID Connectに対応したので、Azure AD B2Cに繋いでみました。

      Slackのドキュメントはこちら



      ふむふむ。昔のSlack連携はOAuth2.0でidentity.*というスコープが使われていたところがOpenID Connectに対応したってことですね。

      ではやってみましょう。


      まずはSlack側にアプリ定義を作成

      こちらからSlackアプリ定義を作ります。メインはAzure AD B2C(今回のケースだとRelying Partyになります)に渡すためのclient_id、client_secretを作るための行為です。

      Create an Appをクリックするとスクラッチから作るかapp manifestを使って作るかを聞かれますので、今回はスクラッチから作ることにします。


      アプリ名と対象となるワークスペースを選択して次へ進みます。


      ナビゲーションメニューからOAuth & Permissionsを開きます。


      少し下にスクロールするとredirect_uriを設定するところがあるので、Azure AD B2CをRelying Partyとして使う場合のCallback Uriを設定します。以下の形式のUriです。

      https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp

      これでSlack側への設定は終わりです。

      左のナビゲーションメニューのBasic Informationからclient_id、client_secretが取得できるのでメモしておきましょう。後でAzure AD B2C側に設定します。


      Azure AD B2CにIdentity Providerを設定する

      次はAzure AD B2C側です。

      IDプロバイダのメニューから新しいOpenID Connectプロバイダーをクリックして設定を開始します。

      必要なのは以下の設定です。

      • 名前:適当に
      • メタデータURL:https://slack.com/.well-known/openid-configuration
      • クライアントID、シークレット:Slack側で取得した値
      • スコープ:openid profile email
      • 応答の種類:code
      • 応答モード:form_post
      • ドメインのヒント:なし
      • IDプロバイダーの要求のマッピング
        • ユーザーID:sub
        • 表示名:name
        • 名:given_name
        • 姓:family_name
        • 電子メール:email

      上記を設定して保存をしたら設定はおしまいです。


      ユーザーフローを実行してみる

      早速ですが適当なユーザーフローを作ってテストしてみます。アプリはお馴染みのhttps://jwt.msを使います。

      フローを実行するとSlackへリダイレクトされて権限に関する同意を要求されます。
      その後、素直にAzure AD B2Cへ戻り、Slackから取得した属性が渡ってきていることが確認できます。



      ということで、サクッと15分くらいでできてしまうので、ぜひみなさまも試してみてください。




      LINEがFIDO2サーバーをOSSで公開したので触ってみた

      $
      0
      0

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

      もうすでに記憶の彼方ですがLINEさんは過去にFIDO2サーバーをOSSで公開する!と宣言していました。それが遂に公開されました!素晴らしい!

      ということでとりあえず動かしてみました。(まだ中身は全然みてません、単に動かしただけです)




      とりあえず公開されているレポジトリをcloneしてREADME.mdに記載の通り動かしてみました。


      # Start RP Server
      cd rpserver
      ./gradlew bootRun
      # Start FIDO2 Server or Line-fido2-spring-boot Demo
      cd server
      ./gradlew bootRun
      cd spring-boot-starter/line-fido2-spring-boot-demo
      ./gradlew bootRun


      やることとしては以上です。

      これで http://localhost:8000 にアクセスするとテスト用のトップ画面が出てきます。

      まずは認証器の登録

      まず画面上部のuser nameとdisplay nameに適当に名前を入れます。

      その状態で画面下部のregisterをクリックすると認証器の登録を求められます。今回はMacbook ProのTouch IDを使っていますが、Yubikeyなどのローミングキーやモバイルの場合はFace IDなども使えます。

      うまくいけば成功したよ、というメッセージが表示されます。



      認証器を使って認証してみる

      次は登録した認証器を使って認証してみます。resident_keyにも対応しているので画面丈夫のuser nameを入れないとユーザ名の選択をするところからスタートしてくれます。とっても便利です。
      もちろんuser nameを入れてAuthenticateをクリックするとユーザ名を選択することなく認証することもできます。

      こちらもうまく認証されると画面下部に成功!とメッセージが出ます。




      とりあえず動かしてみた、というだけなので簡単ではありますが以上となります。

      OSSでピュアなFIDOサーバーの実装が出てきたというのは非常に画期的なので、これから実装をする方にとってはもちろん、自社のWebサイトへFIDO認証を組み込む方にとっても一つの選択肢になるのかもしれません。(もちろんこれまでもKeycloakのようにOSSでFIDOをサポートしたソフトウェアはありましたが、FIDOの部分だけ抜き出すのも苦労するので)




















      訃報:アイデンティティ界の精神的支柱、Kim Cameron氏逝く

      $
      0
      0

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


      最近忙しすぎて全く更新できていませんでした。

      ブランク明けの投稿が非常に悲しいニュースとなり、とても残念です。

      すでにKuppingerColeのサイトに掲載され、Twitter等でも話題になっている通り、アイデンティティ界の思想的リーダーであり、MicrosoftのDistinguished EngineerであったKim Cameron氏が2021年11月30日に永眠されました。


      2018年のEuropean Identity and Cloud Conferenceにて。その後も色々とイベントでお会いしてますが気さくなおじさんでした。


      OpenID Foundationでも彼の功績を集めて記録しておこうという動きもありますので、まとまったら公開されるのではないかと思いますが、ここでは個人的に影響を受けたものを数点あげて故人を偲ぼうと思います。


      1. The Laws of Identity

      これはアイデンティティ業界の人は知らないとモグリだと思いますが、2005年にKimが発表しMicrosoft製品はもちろん様々なアイデンティティ系サービスの設計の基礎となっているものです。

      このブログでも2009年に紹介+日本語訳を掲載していますね。


      しかし、今後は彼のブログなどの知財をどうやって世の中に残すのかが非常に気になります。(すくなくともドメインとかサーバとかは誰かが維持して欲しい・・・)


      2. Microsoft Identity Manager / Azure AD Connect

      ご存知の方もいらっしゃるとは思いますが、Microsoft Identity Manager、Azure AD ConnectのベースとなっているSynchronization Managerは元々は彼がCTO(だったと思う)を務めていたZoomitという会社のVIAをMicrosoftが買収して作られたMMS(Microsoft Metadirectory Services)がMIIS(Microsoft Identity Integration Server)、ILM(Identity Lifecycle Manager)、FIM(Forefront Identity Manager)、MIM(Microsoft Identity Manager)と名前を変えつつ成長してきたものだったりします。製品名が変わってもコアとなっているSynchronization Managerの設計思想とコードは20年以上が経過してもほとんど変わっていないというのはものすごいことだと思います。

      ちなみに本ブログを開始した時のそもそものきっかけがILMだったこともあり、個人的に思い入れがある製品だったりします。MVP受賞時のカテゴリはILMでしたし。

      以下、2012年の.NETラボの勉強会でFIMとADFSのハンズオンをやった時に使ったFIMの歴史スライドです。



      3. Azure Active Directory / Identity Experience Framework

      このブログでも何度も取り上げてきたAzure Active Directory(当時Active Directory vNextと呼ばれてました)とその開発フレームワークであるIdentity Experience Framework(IEF)のデザインは彼が中心となって進めたとのことです。Identiverseの会場でIEFへのプライベートアクセス版をこっそり貰ったのはもう時効かな。。。



      なお、彼の最後の対面での登壇が2020年1月のOpenID Summit Tokyoでした。この時は崎村さんと私でKimやIDProのIan Glazerなどの外タレのアレンジをさせていただき、宮崎での合宿で自己主権型IDに関するディスカッションをしたのも良い経験・思い出です。

      崎村さんがOpenID Summit TokyoでのKimのセッションをYoutubeにあげてくれましたので貼っておきます。


      なお、軽く文字起こし&翻訳をしましたので動画を見る時間がない方はどうぞ。

      (Google Docsの音声入力&Deeplそのままなので誤訳などあると思いますが・・・)


      まずは英語文字起こし(日本語訳は下の方にあります)

      Thank you. Hello I'd like to talk to you about digital transformation of a different kind than we normally discuss. The world, the technology world has certainly been full of discussion of digital transformation of the enterprise. But my thesis will be that when the enterprise changes the way it treats individuals. It creates a digital transformation for the individual, the lives of people change when the way enterprises treat them changes.


      So in getting to that discussion I'd like to look at what we've actually achieved as identity professionals.


      Well, really we’ve achieved some great things. We've satisfied all of the basic requirements of digital transformation in which enterprises redefine themselves to deal digitally with us as individuals. We've streamlined and we've professionalized the technology for distinguishing us. If you go back 10 years, that technology was really a catastrophe of amateurism and we have professionalized the way it is written, the way it is run and the way it appears. We've transitioned the world from raw authentication where only based on secrets to one where whether it be SAML or OpenID connect. We're talking about the transmission of claims. I will come back to that in a second but this is one of the most fundamental changes we've brought about. We've enabled a reliable identity dial tone for the internet and interoperability between diverse systems all of which was just a pipe dream 15 years ago. In addition we can even say we have increased dramatically the security of the internet in spite of all the work that remains to be done. I remember the day when we sat and talked about the fact that we needed to change our paradigm from attributes to claims. Attributes was the word for characteristics in a closed world of single enterprise and we realize that when you open the world and go between domains. It isn't simply a question of attributes, it's a question of who says what about whom. Attributes are spoken by an entity and you must decide whether you actually believe that entity. In other words that's where we came to the concept of claims where claims are attributes that are in doubt and you need technology to decide what you trust for which purposes. This was a fantastic change in technology without which we couldn't have moved out into an actual internet identity we would have been stuck with this prison of the individual enterprise. So I don't say all of this to puff us up and make us overly proud of ourselves. I say this to remind us all that we can do really difficult and almost unthinkable things. Claims which the notion of claims began as something which was almost impossible to explain and now the entire world bases its technology on the concept of claims of assertions that are in doubt. So we were able to transform technology on a scale that was unimaginable if you at the time. And the reason I say this is because we must bear in mind that we can do that again, we can do that now. We mustn't look at the current state of technology and say that's what it is. Our role as professionals is to actually go beyond that.


      So at the same time that we congratulate ourselves let's look at how we failed.


      We’ve failed to recognize that the digital transformation of enterprise created the digital transformation of individual people and we left them really in a situation of chaos. You know the thing about this is we haven't seen the fact that when all of the enterprise's digitalize then the individual faces a new problem of scale. Instead of having to deal with one enterprise or five enterprises of 20 enterprises they have to deal with hundreds and I would say thousands at this point. In addition it isn't simply a scale in terms of the number it's the question of intensity. And by intensity I mean the frequency of dealing with the services and the immersiveness of the relationship with the services. So this is a change which is really significant and further despite the hopes of the telcos who I love of course. The fact remains that people will require multiple different devices in order as it come more intensive and we're using devices in more parts of our lives for more things we need more kinds of devices and we need multiple devices and we all have Alexas now and we all have tablets and we have phones so there's not one single device and this is our we have devices in our cars and devices are propagating. And we've left people in a world where all the technology is device-specific and there is no interoperability between devices really because of the control of the operating system of the device manufacturers. And lastly well of course we have left people with all the problems of privacy and profiling and we have created a need for technological longevity and this may be one of the most difficult problems. In other words you don't just have a device you have a device that one day a terrible thing happens and you have to move to a you have to upgrade to a new device or you lose your device or whatever. So there's longevity in terms of as more is concentrated in the device the need to be able to move the device to other devices becomes greater and we have no answer for this. And similarly we have no answers to help people cope with changing service providers. When one service provider begins to disappoint us or fail us or betray us, how do we transfer our digital life to another service provider? And finally there's the problem of accommodating aging. I speak with experience about what happens when one's memory begins to fade. All of our technology depends on remembering passwords. So basically you are cut from the digital world just through the process of aging and at the point of death the process of inheritance in the digital world of your digital assets is just a chaos.


      So let me ask if we've been so clever about all the things we've achieved, how could we fail in so many ways. I would say the reason is because the problems of the personal digital transformation are very gradual and they grow very very slowly. You know you don't get all of your thousands of relationships in one day. You don't have the need for multiple devices all of a sudden everything is very gradual. It's like the lobster who is putting cold water in and the water is heated slowly and the lobster doesn't complain until it's too late. This gradualness has allowed us to escape the recognition that at a certain point. That change in quantity will become a change in quality and becomes something which really causes deep social resistance.


      So I have the thesis that PDT(Personal Digital Transformation)’s gradual changes are eventually making our systems usable. And that our organizations do not understand the coming social disjuncture. That is implicit in personal digital transformation. I also think that only those of us who have expertise in identity have the ability to perceive the underlying dynamics and to sound the warning bell and to adjust course within our enterprises. Only we can take the leadership recognizing and addressing the emergent realities.


      Now you know in the physical world people have been expertly handling human identity for many millennia. But there has been no attempt to replicate those abilities in the digital world. The creators of digital services we the enterprises and governments have scoped our efforts to solving our own problems as enterprises. And forgetting about the requirements really of the individuals as long as they could cope incrementally with what we were dishing out to them. So the systems that we build cause rather than solve the problems of the personal digital transformation. Because they have been one-sidedly built solely from the point of view of the enterprise. So my thesis is that personal digital transformation requires us to transpose human identity in all of its brilliance and subtlety into the digital world.


      Now if you look at let's look at the pattern by which digital reality has been created. I propose that what has happened is that things begin with a deep understanding of a phenomenon. Then there is innovation in order to bring about what I called transposition by transposing. It's like in music where you move from one key to another key. And here this is moving from one part of reality physical to another part of reality digital. And this pattern leads to a holistic digital equivalent. So if we think about digital audio.


      People, scientists had a very good understanding of what audio was. They knew audio was a form of sound waves. And the innovation was to take those waves and sample them to see different amplitudes and then be able to say okay we can express those amplitudes as digital data and produce a holistic equivalent of the sound so that the process could be reversed to create the digital audio. And so now the end result is 50 million songs for $9.95 a month from Amazon. I mean this is a fundamental thing that was done through a holistic approach to solving the transposition problem.


      But if you look at the rest of the internet this problem of transposition has been solved in a similar way. Let's take the case of just digital banking. It began with people who had a deep understanding of the phenomenon of banking, then analysts came in and understood the processes and the aspects and the things that had to be replicated. And then innovators built the visual experiences that allowed this to be used by millions and hundreds of millions and billions of people.


      So what about digital identity? Where are the experts in what human identity has been for these thousands of years? Who are they? What is the invitation? What is innovation?  Where's the transposition? What's the holistic digital equivalent?


      Basically I have been looking at this for almost 50 years. It is impossible to find an equivalent in terms of scientists or sociologists or psychiatrists. The only thing that has been studied really is basically identification in other words for example the way that governments have handled identity you know during the last hundreds of years. And not only that when on the internet when you read about identity you read all kinds of things when you read about digital identity. And basically people just make up words and use them in ways that they just pull them out of the sky. So I believe we have to realize there are tools that can help us. One of them is in English and I'm curious to know if there are similar tools that can help us in Japanese culture, Chinese culture and other cultures. But the European because you say the whole notion of identity, it actually comes from French. So it isn't simply English, it's sort of the European experience that has been studied, and in great detail by the Oxford English Dictionary.


      You may not know that dictionary, because you are not that involved in studying the details of English Origins. But you actually have not only the definition, but the uses of these words throughout time since they were first recorded in writing. And so you really can have an understanding if you look up something like identity there is great wisdom in what is expressed. I'm going to leave this with my slides but these notions that are really the essence of the Oxford English Dictionary definition are hugely accurate and important and worth reading and I would love you to share other things from your culture that would lead us to greater insights.


      But I have actually distilled this my reading of the dictionary into two concepts one is selfness and one is who-ness. So selfness is the sameness of the person, the thing at all times, the condition of being a single thing, the fact that a person is itself and not something else. That's the self and selfness. Who-ness is what is said about people, the characteristics of the person, the ability to recognize the person. And I called this selfness and who-ness and somebody may think gee Kim you just said you shouldn't make up words now you're making up words but the words. Selfness originated in 1574. And the word who-ness originated in 1611. People have been thinking about these problems for a really long time.


      So to make it simpler, selfness is the aggregate of all the attributes and experiences of a person through their life. Who-ness is what you share in individual relationships.


      Perhaps the most important concept is that this aggregate is never visible in the physical world. To the people in your relationships they never see the whole, only you, only the self has a visibility on to all that has happened, but it has that visibility and that is fundamental to the way it exists. Privacy is the fact that the who-ness are not convertible into selfness, all right and that's what creates the distinction you know our own individuality is distinct.


      So now I imagine you’re asking, okay but how do these concepts map onto current digital technology.


      Well, the truth is digital identification which is what we have. We don't have digital identity yet , we have digital identification so far. Which is the who-ness from the point of view of enterprises and governments. We actually have made some progress in who-ness and that's what we've achieved as I discussed at the beginning of this presentation. But there's virtually zilch you know zero in terms of technology for selfness.


      So to solve the problems of personal digital transformation, we have in order to do an MVP for digital transformation. We need massive new construction in order to build technology for selfness and we need major renovation so that who-ness can be made compatible with selfness.


      Selfness is technology, you know basically the self needs its own technology just as we've automated the enterprise we haven’t automated the self and you know Ian spoke about this in terms of his concepts like active clients and so on. We need to be able to remember and manage our relationships. We need digital technology to do that for us. We need to have digital technology that handles the problem of recognition without our consciousness just as happens in this world in the physical world. We aren't conscious of meeting each other and this is an identity relationship it's simply an identity relationship. Our technology must do the same and provide this recognition layer. We must be able to move between devices from any manufacturer and use new devices without perceiving any change. And I will assert that regardless of what the device manufacturers want to do, the need to do these things as so significant that there will be social and governmental intervention in order to make just as there was around privacy in order to solve these problems of having a self across multiple devices without being prisoners of powerful corporations, and so on. We need to be able to use the services to fill in its memory to fill in the self’s memory as people age. The services can guide them and take over the problem, automate the problems of aging so that they can continue to be part of their digital world. And the digital world at the digital who-ness must evolve in the sense that we have to separate the problem of recognition of ID from the problem of characteristics of claims. So that we don't have to be conscious of all of the ID work and can achieve a world similar to the physical world.


      Now to bring this down to something concrete with respect to current technology. In who-ness we need to separate the layers and and I was so pleased I was at the OpenID (Foundation) Japan meeting today and the the leaders of OpenID (Foundation Japan) are perfectly aware of this problem and are working two separate the problem of recognition and distinct impression from the problem of characteristics by splitting up ID technology from the actual claims provider technology. And we have these things. We have many initiatives here DIDs, OpenID SIOP and FIDO2. Any characteristics, we have two phenomena, one is verified credentials and one is aggregated and distributed claims. Now the important thing here is that we not unleash 10 different technologies on the people who are already victims of the personal digital transformation. So between us we as technical people must ensure the convergence of these technologies. So that they're interoperable with each other ,for example a key recognition that is that I can have when I'm using OpenID and recognition I can have when I'm using FIDO those should be once it's established in one it should be established in the other and it should automatically be because it's part of the self be shared between those different ways of doing who-ness. In terms of selfness we have been one I think an important innovation which is this notion of authenticators. The authenticators, Google has done a very good job actually of initiating this notion of authenticator. Google has done an excellent job here, but this is all very very primitive and as Ian pointed out we need to have much more advanced technology for the self.


      So I'll just give my conclusions. A bullet train is headed straight for us in the form of personal digital transformation. We need to see it coming and get out of its way by evolving a holistic digital identity. OIDC which you're here to celebrate today the most promised I think it's undoubtedly the most promising deployed identification technology should be triaged and is being triaged to determine how it can fit into holistic digital identity. Then self sovereign identity, OpenID Connect SIOP and FIDO should be rethought so they fit together to solve the problems of the personal digital transformation. Otherwise they'll just make things worse, wasting everyone's time and money. This requires a great deal of careful thought. I have some examples but I've gone on too long so I'll leave the examples for people who would like to look at the slides later. So thank you very much.


      日本語訳(Deeplそのままなので変なところはあります。おいおい直します・・・)

      ありがとうございます。こんにちは。今回は、普段とは異なるデジタルトランスフォーメーションについてお話したいと思います。世の中、テクノロジーの世界では、確かに企業のデジタルトランスフォーメーションについての議論が盛んに行われています。しかし、私が言いたいのは、企業が個人への接し方を変えると、個人にとってのデジタルトランスフォーメーションが生まれるということです。企業が個人に対する接し方を変えることで、個人のデジタルトランスフォーメーションが実現し、人々の生活が変わります。

       そこで、その議論のために、私たちがアイデンティティの専門家として実際に達成したことを見てみたいと思います。

       さて、私たちはいくつかの素晴らしいことを成し遂げました。企業が自らを再定義し、個人としての私たちにデジタルで対応するという、デジタルトランスフォーメーションの基本的な要件をすべて満たしています。また、私たちを識別するための技術を合理化し、専門化しました。10年前に遡ると、この技術はアマチュアリズムの大惨事でしたが、私たちはその書き方、運営の仕方、表示の仕方をプロ化しました。私たちは世界を、秘密のみに基づいた生の認証から、SAMLやOpenID Connectのような認証へと移行させました。私たちは、クレームの送信について話しています。この話は後ほどしますが、これは私たちがもたらした最も基本的な変化の一つです。インターネット上で信頼性の高いIDダイヤルを実現し、多様なシステム間の相互運用性を可能にしましたが、これらは15年前には夢物語でした。さらに、まだまだ課題はありますが、インターネットのセキュリティを劇的に向上させたとも言えます。私は、属性からクレームへとパラダイムを変更する必要があると話し合った日のことを覚えています。属性とは、単一企業の閉じた世界での特性を表す言葉でしたが、世界を開いてドメイン間を行き来するようになると、そのことに気付きます。それは単に属性の問題ではなく、誰が誰について何を言っているかという問題です。属性はある存在によって語られ、その存在を実際に信じるかどうかを判断しなければなりません。つまり、クレームという概念が生まれたのです。クレームとは、疑わしい属性のことであり、どのような目的のために何を信用するかを決めるための技術が必要なのです。これはテクノロジーの素晴らしい変化でしたが、これがなければ実際のインターネット・アイデンティティに移行することはできず、個々の企業という牢獄から抜け出せなかったでしょう。私はこのようなことを、自分たちを誇示するために言っているのではありません。私がこのようなことを言うのは、私たちが本当に難しい、ほとんど考えられないようなことをすることができるということを思い出させるためです。クレームという概念は、ほとんど説明できないことから始まりましたが、今では全世界の技術が、疑わしい主張をするクレームという概念に基づいています。つまり、当時のあなたには想像もつかない規模でテクノロジーを変革することができたのです。そして、なぜこのようなことを言うのかというと、私たちはそれが再びできる、今でもできるということを念頭に置かなければならないからです。技術の現状を見て、「そういうものだ」と言ってはいけないのです。私たちプロフェッショナルの役割は、実際にそれを超えていくことです。

      だからこそ、自分たちを称賛すると同時に、失敗したことを振り返ってみよう。

      私たちは、企業のデジタルトランスフォーメーションが個人のデジタルトランスフォーメーションを生み出したことを認識しておらず、個人を混沌とした状況に置いています。これについては、すべての企業がデジタル化すると、個人はスケールの新しい問題に直面するという事実を認識していないことです。1つの企業、5つの企業、20の企業を相手にするのではなく、数百、いや数千の企業を相手にしなければならないのです。さらに、単純に数の問題だけではなく、強度の問題もあります。強度というのは、サービスを利用する頻度やサービスとの関係性の深さを意味します。もちろん、私が大好きな通信会社の希望とは裏腹に、これは本当に重大な変化です。実際には、人々は、より集中的に、より多くのもののために生活のより多くの部分でデバイスを使用するようになると、より多くの種類のデバイスを必要とし、複数のデバイスを必要とすることになります。私たちは、すべてのテクノロジーがデバイス固有のものであり、デバイスメーカーがOSをコントロールしているために、デバイス間の相互運用性がない世界に人々を置き去りにしています。そして最後に......もちろん、プライバシーやプロファイリングの問題を残したまま、技術の長寿命化というニーズを生み出しましたが、これは最も難しい問題のひとつかもしれません。言い換えれば、単にデバイスを持っているだけではなく、ある日とんでもないことが起こって、新しいデバイスに移行しなければならなかったり、デバイスを紛失してしまったりするということです。つまり、デバイスに集中するほど、そのデバイスを他のデバイスに移動させる必要性が高まるという意味での長寿命化があるのですが、私たちはこれに対する答えを持っていません。同様に、サービスプロバイダーの変更に対応するための答えもありません。あるサービスプロバイダーが私たちを失望させたり、裏切ったりし始めたとき、私たちのデジタルライフをどうやって別のサービスプロバイダーに移せばいいのでしょうか?そして最後に、高齢化への対応という問題があります。私は、記憶力が衰えてきたときに何が起こるかを経験的に知っています。私たちのテクノロジーはすべて、パスワードの記憶に依存しています。つまり、基本的には加齢というプロセスだけでデジタルの世界から切り離され、死の時点ではデジタル資産のデジタルの世界での継承プロセスはただの混乱に陥ってしまうのです。

      では、もし私たちがこれまでに達成してきたことがとても賢いものであったとしたら、なぜこれほど多くの点で失敗してしまったのか、お聞きしたいと思います。その理由は、パーソナル・デジタル・トランスフォーメーションの問題は非常に緩やかで、成長も非常に遅いからだと思います。何千もの人間関係を1日ですべて手に入れることはできませんよね。突然、複数のデバイスが必要になるわけでもなく、すべては非常に緩やかなものです。ロブスターが冷たい水を入れると、ゆっくりと水が温められ、手遅れになるまでロブスターが文句を言わないのと同じです。この漸進性のおかげで、ある時点で、という認識から逃れることができました。その量の変化は質の変化となり、社会的に深い抵抗を引き起こすものとなるのです。

      そこで私は、PDT(Personal Digital Transformation)の緩やかな変化によって、最終的にはシステムが使えるようになるのではないか、という仮説を立てました。そして、私たちの組織は、来るべき社会的断絶を理解していません。それがパーソナル・デジタル・トランスフォーメーションの暗黙の了解です。また、アイデンティティに関する専門知識を持っている私たちだけが、根底にあるダイナミクスを察知し、警鐘を鳴らし、企業内で軌道修正することができると思います。私たちだけが、出現した現実を認識し、それに対処するためのリーダーシップをとることができるのです。

      物理的な世界では、人々は何千年も前から人間のアイデンティティを巧みに扱ってきたことをご存知でしょう。しかし、その能力をデジタルの世界で再現しようという試みはありませんでした。デジタルサービスの生みの親である企業や政府は、企業としての問題を解決することに努力を傾けてきました。そして、私たちが提供するものに段階的に対応できる限り、実際に個人が必要とするものは忘れてしまいました。つまり、私たちが構築するシステムは、個人のデジタルトランスフォーメーションの問題を解決するというよりも、むしろその原因となっているのです。なぜなら、それらは企業の観点からのみ一方的に構築されたものだからです。そこで私は、パーソナル・デジタル・トランスフォーメーションを実現するためには、人間のアイデンティティを、その輝きと繊細さのすべてにおいて、デジタルの世界に移すことが必要だと考えています。

      さて、デジタル・リアリティがどのようなパターンで作られてきたのかを見てみましょう。私が提案するのは、ある現象を深く理解することから始まるということです。そして、私が「移調による移調」と呼んでいるものを実現するために、イノベーションが起こるのです。音楽で言えば、あるキーから別のキーに移すようなものです。ここでは、物理的な現実のある部分からデジタルの現実のある部分へと移動することです。そしてこのパターンは、全体的なデジタルの等価物につながります。つまり、デジタルオーディオについて考えてみましょう。

      人々、科学者たちは、オーディオとは何かということを非常によく理解していました。オーディオが音波の一形態であることは知っていました。そして、それらの振幅をデジタルデータとして表現し、音の全体像に相当するものを作成することで、プロセスを逆にしてデジタルオーディオを作成することができるようにしたのです。その結果、今では5,000万曲の音楽をAmazonで月9.95ドルで購入できるようになりました。つまり、これは移調問題を解決するためのホリスティックなアプローチによって行われた基本的なことなのです。

      しかし、インターネットの他の分野に目を向けると、この移調の問題は同様の方法で解決されています。単なるデジタルバンキングの場合を考えてみましょう。銀行という現象を深く理解している人たちから始まり、アナリストが入ってきて、プロセスや側面、再現しなければならないものを理解しました。そして、イノベーターたちが、何百万人、何億人、何十億人もの人々に利用してもらえるようなビジュアル体験を構築しました。

      では、デジタル・アイデンティティについてはどうでしょうか。人間のアイデンティティが何千年も続いてきたことについての専門家はどこにいるのでしょうか?彼らは誰なのか?招待とは何か?イノベーションとは何か? 転置とは何か?ホリスティックなデジタルとは?

      基本的に私は50年近くこのことを見てきました。科学者や社会学者、精神科医で同等の人を見つけるのは不可能です。唯一研究されているのは、基本的にアイデンティティー、つまり過去数百年の間に政府がアイデンティティーをどう扱ってきたかということです。それだけではなく、インターネット上でアイデンティティについての記事を読むと、デジタルアイデンティティについての記事を読むと、いろいろなことが書かれています。基本的に人々は言葉を作り、それを空から引っ張ってきたような方法で使っています。ですから、私たちは助けになるツールがあることに気づかなければならないと思います。日本の文化や中国の文化、その他の文化でも同じようなツールがあるのか知りたいですね。しかし、ヨーロッパでは、アイデンティティという概念は、実はフランス語から来ていると言われています。単純に英語だけではなく、ヨーロッパでの経験が研究されていて、オックスフォード・イングリッシュ・ディクショナリーではその詳細が紹介されています。

      あなたは、英語の起源の詳細を研究することにそれほど関与していないので、その辞書を知らないかもしれません。しかし、実際には、定義だけでなく、これらの言葉が最初に文字として記録されて以来、時代を超えて使用されてきました。ですから、identityのようなものを調べれば、表現されていることに大きな知恵があることを理解することができるのです。この話は私のスライドに譲りますが、オックスフォード英語辞典の定義の本質であるこれらの概念は、非常に正確で重要であり、読む価値があります。

      しかし、私はこの辞書の読み方を2つの概念に集約しました。1つは「Selfness」、もう1つは「Who-ness」です。つまり、Selfnessとは、人や物が常に同一であること、単一のものであるという状態、人が他の何かではなく自分自身であるという事実のことです。それが自己であり、Selfnessである。Who-nessとは、人について言われていること、その人の特徴、その人を認識する能力のことです。私はこれを「Selfness」と「Who-ness」と呼んでいますが、Kimはさっき言葉を作るべきではないと言ったばかりなのに、今度は言葉を作っている、と思うかもしれません。Selfnessという言葉は1574年に生まれました。そして、Who-nessという言葉は1611年に生まれました。人々は本当に長い間、これらの問題について考えてきました。

      つまり、もっと簡単に言うと、Selfnessとは、その人の人生を通じたすべての属性と経験の集合体です。Who-nessは、個々の人間関係において共有するものです。

      おそらく最も重要な概念は、この集合体は物理的な世界では決して見えないということです。人間関係の中にいる人たちは、全体を見ることはありません。あなただけが、起こったことすべてを見ることができるのは自己だけです。プライバシーとは、「Who-ness」が「Selfness」に変換できないという事実であり、それが私たちの個性を際立たせているのだと思います。

      では、これらのコンセプトを現在のデジタル技術にどのようにマッピングするのか、という疑問をお持ちではないでしょうか。

      真実は、私たちが持っているデジタルIDなのです。デジタルIDはまだありませんが、デジタルIDは今のところあります。これは、企業や政府の観点から見た「誰であるか」を示すものです。このプレゼンテーションの冒頭でお話したように、私たちは実際に「Who-ness」という点ではある程度の進歩を遂げています。しかし、「Selfness」を実現するための技術は、ほとんどありません。

      つまり、個人のデジタルトランスフォーメーションの問題を解決するためには、デジタルトランスフォーメーションのためのMVPを行う必要があるのです。自分らしさのためのテクノロジーを構築するためには大規模な新築が必要ですし、Who-nessをSelfnessと両立させるためには大規模な改修が必要です。

      企業が自動化されたように、自己は自動化されていません。イアンは、アクティブ・クライアントなどの概念でこのことを語っています。私たちは、自分の人間関係を記憶し、管理する必要があります。そのためには、デジタルテクノロジーが必要です。物理的な世界で起きているのと同じように、意識せずに認識の問題を処理するデジタル技術が必要なのです。私たちはお互いに会うことを意識していませんし、これはアイデンティティの関係であり、単なるアイデンティティの関係です。私たちのテクノロジーも同じように、この認識層を提供しなければなりません。私たちは、どのメーカーのデバイス間でも移動でき、何の変化も感じずに新しいデバイスを使うことができなければなりません。そして、デバイスメーカーが何をしたいかに関わらず、これらのことを行う必要性が非常に大きいため、プライバシーに関する問題があったように、強力な企業の虜になることなく複数のデバイスにまたがって自己を持つという問題を解決するために、社会や政府による介入が行われるだろうと断言します。人が歳をとったときに、サービスを使って自己の記憶を埋めることができるようにしなければなりません。サービスは彼らを導き、加齢の問題を引き継いで自動化し、彼らがデジタル世界の一部であり続けることができるようにします。そして、IDの認識の問題とクレームの特性の問題を切り離すという意味で、デジタルの世界は進化しなければなりません。そうすれば、すべてのID作業を意識する必要がなくなり、物理的な世界と同様の世界を実現することができます。

      さて、この話を現在の技術に照らし合わせて具体的に説明しましょう。Who-nessではレイヤーを分離する必要があります 今日、OpenID (Foundation) Japanのミーティングに参加してとても嬉しかったのですが、OpenID (Foundation Japan)のリーダーたちはこの問題を完全に認識していて、ID技術を実際のクレームプロバイダ技術から分離することで、認識と明確な印象の問題を特性の問題から分離する作業をしていました。そして、私たちはこのようなものを持っています。ここでは、DIDs、OpenID SIOP、FIDO2など多くのイニシアチブがあります。特徴としては、2つの現象があります。1つは認証されたクレデンシャル、もう1つは集約された分散型のクレームです。ここで重要なのは、すでにパーソナル・デジタル・トランスフォーメーションの犠牲者となっている人々に、10の異なるテクノロジーを解き放たないことです。私たち技術者は、これらの技術の収束を図る必要があります。例えば、OpenIDを使用しているときに得られる重要な認識と、FIDOを使用しているときに得られる認識は、一方で確立されれば他方でも確立されるべきであり、また、自己の一部であることから、これらの異なる自己認識の方法の間で自動的に共有されるべきです。自分らしさという点では、私たちは重要な革新を行ってきました。それは、認証器という概念です。Googleはこの認証器という概念を導入したことで、非常に良い仕事をしました。Googleは素晴らしい仕事をしましたが、これは非常に原始的なもので、イアンが指摘したように、私たちは自己のためにもっと高度な技術を持つ必要があります。

      そこで、私の結論を申し上げます。個人のデジタルトランスフォーメーションという形で、新幹線が私たちに向かって直進している。私たちはその到来を察知し、全体的なデジタルアイデンティティを進化させることで、その邪魔をしないようにする必要があります。OIDCは、今日ここで皆さんに祝っていただきましたが、最も有望な展開されたID技術であることは間違いなく、全体的なデジタル・アイデンティティにどのように適合させることができるか、試行錯誤する必要があります。そして、自己主権型アイデンティティ、OpenID Connect SIOP、FIDOは、個人のデジタル変革の問題を解決するために一緒に適合するように再考されるべきです。そうでなければ、事態を悪化させ、皆の時間とお金を無駄にするだけです。そのためには、かなり慎重に考えなければなりません。いくつか例を挙げましたが、長くなりすぎましたので、例は後でスライドを見たい方のために残しておきます。それでは、ありがとうございました。 


      ワクチン接種証明のVerifiable Credentialsを覗いてみる

      $
      0
      0

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


      20日にデジタル庁がリリースしたワクチン接種証明アプリが話題ですね。内容的にはSMART Health Cardの仕様に沿った証明データが出てきているという話だったので中身を紐解いてみようかと思います。何しろSMART Health Cardの中身はW3CのVerifiable Credentials(VC)なので。



      参考1)

      ・海外用:ICAO VDS-NCとSMART Health Cards(SHC)

      ・国内用:SMART Health Card(SHC)のみ

              https://www.digital.go.jp/policies/vaccinecert/faq_06 より


      参考2)

      This document describes how clinical information, modeled in FHIR, can be presented in a form based on W3C Verifiable Credentials (VC).

              https://spec.smarthealth.cards/credential-modeling/より



      ちなみに今年のWWDCで発表された通りiOS15のHealthアプリはSMART Health Cardをネイティブで扱えるようになっているので、実はこの接種証明アプリがなくても直接iPhoneのWalletに接種証明を入れることもできます。今はマイナンバーカードを使った本人確認〜接種証明の発行までをワンストップで実行させるには今回のようなアプリの形になっている方が扱いやすいとは思いますが、今回対象外になった自治体の住民や新旧の姓を併記にしているような方達はセルフサービスでの発行ではなく窓口等でQR発行〜iPhoneのWalletへの読み込みができるようになると便利だと思います。

      ちなみに現在も接種証明アプリで表示したQRコードを他のiPhoneで読み込むとWalletへ接種証明を入れることもできます。どこぞの記事には他人の接種証明が入れれちゃうのは問題だ、、みたいな意見も書かれていましたが、本来的には接種証明と本人確認は別の話だと思いますし、どっちにしても検証側が本人確認+接種確認をセットでやるのが筋だと思うので、なんだかなぁ、と思ってみてます。




      ちなみに、海外版のQRを解くとちゃんと英字氏名も入っているのですが、Walletに入れるとofficialではなくusualのtypeになっているname属性の値(日本語)が使われてしまうのがちょっと残念ですね。海外で見せた時に読めないだろう、、、という。


      ということで中身を読んでみます。

      1. 国内用と海外用

      先のFAQを見ると国内用と海外用があることがわかりますし、アプリを使うと国内用、海外用のどちらか、あるいは両方を発行することができます。国内用ではマイナンバーカードでの本人確認、海外用では加えてパスポートの確認が必要です。(ICAO用ですね。SMART Health Card版ではパスポート情報は不要なので)

      今回はVerifiable Credentialsを採用しているSMART Health Cardを解いていこうと思うので、国内用、もしくは海外用でもSMART Health Card版(QRコードを出すところで「SHC」を選択)を使います。


      2. QRコードを単純に読んでみる

      アプリにQRコードを画像ファイルとしてダウンロードさせる機能があるのでダウンロードして入っている文字列を読み出してみます。

      この辺りのサイトを使うとMacでもできるので便利です。


      shc:/〜という形でnumericなデータが見えます。

      これは仕様を読むと、JWS Compact SerializationでエンコードしたレコードをQRにエンコードする際はChunkをdecimalで表現した文字列を作ることになっているようです。具体的にはOrd(c)-45をすることでBase64UrlEncodeされたJWSの各文字を数値に変換しています。

      ということで、逆に文字列に戻してあげるにはJWSchars.map(num => String.fromCharCode(parseInt(num, 10) + 45)).join('');と言った感じで+45をして文字コードにしてあげればいいってことです。

      うまく繋げばいつもの「eyJ〜」が見えてきますので、decodeしてあげましょう。


      3. payloadはinflateRawする

      ここまで来れば単純にjwt.ioとかでdecodeすれば済むかな、と思ったらpayloadがバケバケでした。headerをよくみると"zip": "DEF"とあるのでpayloadがdeflateされてますね。

      これも仕様をみるとサイズを小さくするためにraw deflateがかかっているようです。仕方がないのでzlibなどを使ってinflateRawしてあげます。これでようやくまともに読めるpayloadができるのでtoString()して文字列としてJSONを取得してあげましょう。

      こんな感じでとれました。

      {"iss": "https://vc.vrs.digital.go.jp/issuer", "nbf": 1639958323.321147, "vc": {"type": ["https://smarthealth.cards#health-card", "https://smarthealth.cards#immunization", "https://smarthealth.cards#covid19"], "credentialSubject": {"fhirVersion": "4.0.1", "fhirBundle": {"resourceType": "Bundle", "type": "collection", "entry": [{"fullUrl": "resource:0", "resource": {"resourceType": "Patient", "name": [{"use": "usual", "family": "\u5bcc\u58eb\u69ae", "given": ["\u5c1a\u5bdb"]}, {"use": "official", "family": "NAOHIRO", "given": ["FUJIE"]}], "birthDate": "1974-09-28"}}, {"fullUrl": "resource:1", "resource": {"resourceType": "Immunization", "status": "completed", "vaccineCode": {"coding": [{"system": "http://hl7.org/fhir/sid/cvx", "code": "207"}]}, "patient": {"reference": "resource:0"}, "occurrenceDateTime": "2021-07-20", "performer": [{"actor": {"display": "MHLW_Gov_of_JAPAN"}}], "lotNumber": "3003190"}}, {"fullUrl": "resource:2", "resource": {"resourceType": "Immunization", "status": "completed", "vaccineCode": {"coding": [{"system": "http://hl7.org/fhir/sid/cvx", "code": "207"}]}, "patient": {"reference": "resource:0"}, "occurrenceDateTime": "2021-08-17", "performer": [{"actor": {"display": "MHLW_Gov_of_JAPAN"}}], "lotNumber": "3004734"}}]}}}}

      あとは整形してあげればOKなので、じっくり中身を見れるようになります。ちなみにコードを書けばいいんでしょうけど面倒なのでこの辺りのツールを使ってみやすくしてます。


      4. じっくり覗き込む

      とりあえず整形したpayloadがこれです。


      {
      "iss": "https://vc.vrs.digital.go.jp/issuer",
      "nbf": 1639958323.321147,
      "vc": {
      "type": [
      "https://smarthealth.cards#health-card",
      "https://smarthealth.cards#immunization",
      "https://smarthealth.cards#covid19"
      ],
      "credentialSubject": {
      "fhirVersion": "4.0.1",
      "fhirBundle": {
      "resourceType": "Bundle",
      "type": "collection",
      "entry": [
      {
      "fullUrl": "resource:0",
      "resource": {
      "resourceType": "Patient",
      "name": [
      {
      "use": "usual",
      "family": "富士榮",
      "given": [
      "尚寛"
      ]
      },
      {
      "use": "official",
      "family": "NAOHIRO",
      "given": [
      "FUJIE"
      ]
      }
      ],
      "birthDate": "1974-09-28"
      }
      },
      {
      "fullUrl": "resource:1",
      "resource": {
      "resourceType": "Immunization",
      "status": "completed",
      "vaccineCode": {
      "coding": [
      {
      "system": "http://hl7.org/fhir/sid/cvx",
      "code": "207"
      }
      ]
      },
      "patient": {
      "reference": "resource:0"
      },
      "occurrenceDateTime": "2021-07-20",
      "performer": [
      {
      "actor": {
      "display": "MHLW_Gov_of_JAPAN"
      }
      }
      ],
      "lotNumber": "3003190"
      }
      },
      {
      "fullUrl": "resource:2",
      "resource": {
      "resourceType": "Immunization",
      "status": "completed",
      "vaccineCode": {
      "coding": [
      {
      "system": "http://hl7.org/fhir/sid/cvx",
      "code": "207"
      }
      ]
      },
      "patient": {
      "reference": "resource:0"
      },
      "occurrenceDateTime": "2021-08-17",
      "performer": [
      {
      "actor": {
      "display": "MHLW_Gov_of_JAPAN"
      }
      }
      ],
      "lotNumber": "3004734"
      }
      }
      ]
      }
      }
      }
      }


      5. 見えてくること

      なるほど、ということで読んでいくと以下のことがわかります。

      • Verifiable Credentialsですね
      • CredentialTypeは3種類
        • https://smarthealth.cards#health-card" 
        • "https://smarthealth.cards#immunization"
        • "https://smarthealth.cards#covid19"
      • CredentialSubjectにはFHIRの仕様でデータが入っている
      • resource:0がpatient情報、つまり接種を受けた人の情報(と言っても名前と生年月日)
      • resource:1/2がImmunization情報、つまり接種情報の1回目と2回目
      • vaccineCodeがワクチンの種類
        • https://build.fhir.org/valueset-vaccine-code.htmlをみると、207は「SARS-COV-2 (COVID-19) vaccine, mRNA, spike protein, LNP, preservative free, 100 mcg/0.5mL dose」とあるのでCOVID-19のワクチンっぽい。
        • しかしFHIRのバージョンが4.0.1とCredentialSubjectには書いてあるけど、4.0.1のvaccineCodeにはCOVID-19の定義がないのは間に合ってないってことなのかな?上記のコードは4.6.0のもの。4.0.1のvaccineCodeはこちら
      • performerは「MHLW_Gov_of_JAPAN」とあるので日本の厚生労働省
      • lotNumberがワクチンのロットですね。ちなみに鉄粉が入ってたっていう件、私はビンゴでした・・・


      と、ざっくりですがQRコードからJWSを復元、decodeしてみました、という話でした。

      他にもJWSの署名を深堀をしたり、と興味は尽きない接種証明アプリですが、総じてこの短期間で使いやすいアプリが出てきたっていうのは素晴らしいことだな、と思っています。(個人の感想)




      分散型IDに関する10の所感(2022年2月版)

      $
      0
      0

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


      なんだかんだでuPortを触ったり現Azure Active Directory Verifiable Credentialsの前身を触ったり、最近だと数カ所で実証実験プロジェクトを立ち上げたり、MS主催のDecentralized Identity Hackathonで入賞してみたり、と分散型IDに関わり始めて5年くらい経っていたりしますので、現時点で分かったことをメモしておこうかと思います。(往々にして数年後に見返すとう〜ん、となるやつだけど気にしないことにする)

      ※そういう意味では2019年の#didconでその時点でわかっていることをある程度まとめて発表してからおよそ3年も経つんですね・・・


      また機会があればdidconでも開催してじっくりお話させていただこうと思うので思うがままに書いた乱文ですが、こんな感じかと。(いうまでもありませんが、完全に私見です。私が関与している各種団体や事業者には一切関係ありませんので悪しからず)

      1. まだ意外と誤解されているが分散型「アイデンティティ」ではない
      • DIDはDecentralized "Identifiers"でありDecentralized "Identity"ではない。
      • なぜならIdentity=Set of attribute(ISO/IEC 24760-1 2019)なのでDecentralized "Identity"という話であればOpenID ConnectのDistributed Claimsの方がよっぽど分散されている。
      • では、何が分散されているのか?というと識別子(Identifier)と関連するメタデータ(Document)が分散台帳等の上(これも特にブロックチェーンと明確に規定されているわけではなく、現に全然分散されていないDIDもある)にデプロイされることで単一事業者等への依存度をさげられたり、関連して相対的にではありますが可用性などを気にする必要性が少なくなったり、というレベルの話。
      • というか、W3Cが規定しているのはDecentralized "Identifiers"だし、決めているのは識別子とメタデータ(DID Document)の書き方くらい。

    1. 自己主権型アイデンティティは幻想?
      • そもそもデータに関する主権ってなに?という話で、先にも書いた通り目的語が不明確な中でDecentralizedが分権型なのか、分散型なのか、非中央集権型なのかもぼやけている中で何を持って自己主権なのか?というレベル。
      • パブリック/パーミッションレスな分散台帳に識別子(Identifier)と署名検証に使う公開鍵を含むメタデータ(DID Document)を公開することで特定の事業者が当該のエンティティに関するデジタル上での生殺与奪に関するコントロールしずらくなる、ということを言いたいんだ、ことはわかるんですが、それが果たして「自己主権」に繋がるのか?と言われるとうーむ、という話。
      • もう一つはVerifiable Credentialsの持つポータビリティという性質の話。後でも触れるがDIDをうまく使うことでIdPとRPの結合度を下げることは確かに可能で、結果としてVerifiable CredentialsをWalletと言われるスマートフォン等で動作するソフトウェアの中に格納して個人が持ち運ぶことも可能、という意味ではIdPからの独立性=自分で自分のアイデンティティをコントロールしている感を醸成しやすいという点は認めることはできる。
      • 結局のところ、唯一言えるのは自己主権型アイデンティティというのは思想であり、テクノロジとは切り離して考えるべきだ、ということ。たしかに現状のFederationを考えると相対的に分散台帳と紐づいたDIDと関連する鍵によって署名されたVerifable Credentialsは事業者の「支配」から逃れられている気にさせてくれる。
      • ちなみにこれは最も重要な点かも知れないが、DIDが「did:メソッド名:固有の識別子」という形式をとっている以上、メソッドを跨いでDIDや署名済みのVCを持ち運ぶ(引っ越す)ことは事実上不可能である点は見逃してはいけないと思う。

    2. Verifiable Credentialsが本命?
      • 今年度私も少しだけお手伝いさせていただいている内閣官房Trusted Web推進協議会のホワイトペーパーにも記載の通り、暗黙的な信頼から検証に基づくExplicitな信頼へという流れはDXの要になると思われる。まさにDon't trust, Verifyという言葉が全てを物語っている。
      • ただ、ここで解決しておかないといけないのはSAMLやOpenID ConnectのAssertionへのデジタル署名との違い。確かにCOVID-19のワクチン証明にVerifiable Credentialsを使ったことに新しさはあるけど、実態はデジタル庁の自己署名を打っただけのJSONなので、耐改竄性という意味においてはSAML AssertionやOpenID Connectのid_tokenと何ら変わらない。(もちろんFHIRの標準化されたSchemaをPayloadに使うという意味においてアプリケーションレイヤでの相互運用まで踏み込んだ点では非常に重要なアプローチだとは思う)
      • では、DIDとセットにする意味は?という話だが、実際問題としてメリットはゼロではない。どういうことかというと、署名検証をするための公開鍵をjwks_uriなどで公開しているケースに比べて、こんなメリットがある。
        • 事業者がIdPの可用性をそれほど考えなくて良い(IdPが落ちていても分散台帳上にDID Documentを公開してしまえば、コンロトーラビリティは下がるが相対的に可用性は向上することが多い)
        • OPがシャットダウンされた時、ユーザが署名付きクレデンシャルの真正性を証明できなくなる、という事態はなくなる
      • とはいえ、よくある話として署名アルゴリズムの危殆化の話は当然あるので、(相対的に単一事業者の都合が可用性に与える影響度合いが少ないと言える)分散台帳に公開鍵を置いているからと言って半永久的にVerifiiable Credentialsの署名を信頼できるかというとそうではなく、実運用では少なくとも数年に一度はVCの再発行は必要になると思われる。そうなるとIdPの事業継続性の観点でVCが優位というロジックは非常に限定的(つまり、少なくともIdPが潰れても数年間は資格証明が可能というレベル)だし、いわゆるソーシャル・インクルージョンの文脈で語られる国家というIdPによるネグレクトに対する銀の玉にはなりそうにもない。

    3. VC発行者に関する信頼は難しい問題
      • VCの発行に際して発行者は自身のDIDにに紐づく秘密鍵で署名するわけなので、そのDIDは誰なのか?信頼できるのか?という点が重要になってくる。
      • 実世界のビジネスモデルを考えるとDNSの持つ分散ガバナンスモデルに依拠するのが落とし所、という形でwell-known did-configurationがMSでもMattrでも実装されているが、DID/VCのモデルの外に依存している段階で分散とか分権とかいうキーワードは虚しく感じられるのは自分だけではないはず。
      • そして、結局は一番怪しいのがDIDからDID DocumentをLookupするためのResolverの信頼性。もちろんUniversal Resolverを含めオープンな実装は透明性という意味である程度信頼はできるとは思うが、結局はDriverの実装者と実インスタンスを動かしている事業者の誠実さを「信頼」するしかないのが現状。

    4. いくらVerifiableだったところで信頼されるとは限らない
      • そもそもTrust FrameworkってITの世界でクローズできるものではない。
      • 実際、いくらデジタル署名されたデータセットは改竄されにくい、と言ったところで人間はヒューリスティックな生き物で「見たことがある紙やプラスチックの物理的な身分証明書」を対面で提示されることにはかなわない。
      • これはDXの本質的な話で、Digitization〜Digitalizationなど段階を定義するのは良いが、現実論としてDigitizationとDigitalizationの間には大きな溝があると思う。みんなPDFとかExcelが大好きだし、最後の手段で紙に戻せば業務継続できると思っている段階で、最初から紙を前提としないDigitalizationの段階へは永遠に進めないと思う。
      • そういう意味ではVerifiableという特性をフルに活かすことのできるユースケースをなるべく早く見つけることが最大のミッションなのかも知れない。この辺りは先にも触れたTrusted Web推進協議会が大きな役割を果たすことが期待される。

    5. KYCというか本人確認・身元確認との相性はそれほど良くはない
      • 結局、Identity Proofingの本質はNIST SP800-63Aでいうところの、
        • Resolution
        • Validation
        • Verification
      • というステップによって構成されており、この中でVCが役に立つのはValidation(提出したエビデンスの真正性検証)。でも良く考えるとValidationの本質はオーソリティへの照会(この辺りは身元確認の「元」という文字にも現れている)なので、Evidenceが改竄されていないことの証明だけでは不十分。
      • 確かにRevokeに関するスペック(Status List 2021)も標準化が進んできているので有効性確認はできるようになるとは思われるが、Evidence発行元におけるKYCプロセスの信頼性まで担保できるわけではないし、オーソリティの信頼性の方がEvidence自体の耐改竄性よりも重要な世界。
      • また、Verification(Evidenceに記載のエンティティとEvidence持参のエンティティの同一性確認)ができるわけではない
      • となると、身元確認ではなくOpenBadgeがやっているように資格証明程度に使うのが現実的だと思われる。

    6. 結局はIdPとRPの結合度を下げることが可能、というのが最大のメリット?
      • こうなるとOpenBadgeではダメなの?という話はあるが現状のOpenBadgeのほとんどがSigned型ではなくHosted型(Issuerへの問い合わせにより真正性・有効性を検証する方式)であることを考えると、システム間の結合度を考えると一定の優位性はある状態(少なくともSigned型が普及するまでは)
      • つまり、結局のところシステム間(OPとRPの間)の結合度をさげるためのもの、という使い方が現状ではベストなのでは?と思われる。
      • 事実、去年のIIWでのユースケースに関するディスカッションをしている時に私が話した、大学のID基盤の管理負荷(ライセンス・インフラのサイジング・可用性)を下げることができるのでは?というのが一番響いたっぽい。(少なくともVittorioあたりには)

    7. 標準化の実際はどうなっているのか?
      • まだまだカオスに見える。Hyperledger勢がDecentralized Identity FoundationとかTrust over IP Foundationとかで推しているDIDcommや、OpenID FoundationでやっているSIOP v2OIDC4VPとか。
      • そもそも論、VCにJSON-LDを使うのかJSONで行くのかも議論が尽きないポイント。
      • そんな中、いろんなベンダがビジネスとして立ち上がってきており微妙な段階の仕様を実装してサンプルコードとかを公開するので、世の中の開発者が真似をしてさらにカオスな状態が出来上がり、標準化とは?という世界が出来上がりつつある。

    8. ゼロ知識証明(ZKP)、選択的開示(Selective Disclosure)が本命?
      • そもそもゼロ知識証明に関してはMSが買収したuProveとかIBMのIdeMixとか昔から研究されてきている領域だけどまだまだ実用化には遠いのが現状。(そういえば10年以上前にuProveのテストインプリがされたWindows Identity FoundationのPrivate Previewのテストをやっていたのが懐かしい)
      • またZKPとSelective Disclosureはごっちゃに語られることも多いけど、結局のところ必要なのはSelective Disclosure。この辺はBBS+とか頑張ってるがまだまだ課題はあり(隠せる範囲が限定される、など)、早稲田の佐古先生とかIIJの山本さんが拡張提案をしていたりするのでこの辺りは要ウォッチ。
      • よく言われる物理世界ではできなくてデジタルの世界でできるようになるといいよね、と言われるバーに入る時の年齢確認に免許証を出すと年齢以外の情報までガードマンに知られちゃう、という話への対応はこの辺りのテクノロジの成熟と実装に期待はされている。ただ、本当にガードマンに年齢以外に名前を知られて困るのか?という話はあるので、ユースケースについてはもっと議論しないとダメだと思う。

    9. 結局何か世の中の課題を解決できたのか?
      • よく言われるものとして、
        • プライバシー
        • 検証可能性
      • があるが、上記を見ている結局そこまで解決に至っているとはいえない。
      • それよりも、上記に書いた通りOPとRPの間の結合度を下げることによる管理面やインフラ的なコスト削減が一番のメリットになるのでは?


      と、色々書きましたがテクノロジーとしては非常に面白く今後世界を変える可能性のあるものだと信じているので引き続き研究していきたいと思います。

      分散型ID関係のコミュニティ立ち上げ

      $
      0
      0

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


      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(仮)」を立ち上げることにしました。


      と言っても現時点ではDiscordの板が存在しているくらいなので、あまりコンテンツもありませんし、アクティブな活動も予定されているわけではありませんが、まずはここにエンジニアの皆さんには集まっていただき、なんでも情報交換ができる様な場所を作れればな、、と思います。

      ということでぜひご参加ください。

      https://discord.gg/nn53BRRz


      あ、参考までに先の勉強会で使った資料も貼っておきます。






      ようやくAzure ADのデータが日本のデータセンターに

      $
      0
      0

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

      最近アクティビティが減っていますが分散型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://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/announcing-a-new-azure-ad-part-of-microsoft-entra-region-in/ba-p/2967453


      ざっくりいうと、

      • 新規に日本リージョンに作ったテナントは日本データセンターに(対象コンポーネントはauthentication, core directory storage, and premium features storage)
      • 以前に日本リージョンに作ったテナントのマイグレーションは今後の発表を待て

      ということです。

      なお、コンポーネント単位のデータ配置場所は「https://aka.ms/aaddatamap」で確認することができます。

      「AAD Directory Data & Management」や「Authentication」など対象となっているサービスを選択すると「大阪、東京、埼玉(笑)」と出ます。



      では、自分のテナントのデータの配置場所がどこになっているのか?はどうやって確認するのかですが、2つ方法があります。

      一つ目は単純にポータルからディレクトリのプロパティを見る方法です。

      ■10月に新しく作ったテナント

       リージョン(国または地域):Japan

       データの場所:Japan datacenters


      ■昔作ったテナント

       国または地域(リージョン):Japan

       データの場所:Asia, United States, Europe datacenters


      ※余談ですが何年か前に古巣バハレーンに作ったテナントのデータの場所はEUになってました。



      もう一つの方法はアクセストークンの中のClaimを見る方法です。

      アプリケーションでリージョンを絞りたい場合などはこちらを使うことができそうです。

      こちらが日本データセンターにデータがあるテナントのアクセストークンをjwt.ioでデコードしたものです。

      tenant_region_scopeというClaimに"JPR"という値が入っています。


      それに対してこちらが古いテナント(まだ海外にデータがレプリケーションされている)のものです。



      自治体とか金融機関とか医療関係などデータの置き場所に縛りのあるシナリオではこの辺りをうまく活用していくと良いでしょう。





      Auth0 labのVerifiable Credentialsを試してみる

      $
      0
      0

      こんにちは、富士榮です


      これまで当BlogでもVerifiable Credentials周りは色々と触ってきましたが、今回はAuth0ラボで公開しているサービスを触ってみます。

      こんな感じでCredentialを作れるサービスです。



      参考)これまで触れてきたDID/Verifiable Credentials関係のポストの一部

      ※まぁ、古くはConsensysのuPortなんてのをガリガリ触っていた時期もあるんですが。。。


      ということで一通り触ってみましょう。

      注)その名の通りラボなのでプロダクションで使うのはやめましょう。

      ■Auth0ラボのセットアップ

      まずはAuth0のラボ環境を作ります。通常のAuth0環境とはことなり、別のテナントを作る必要があります。


      にアクセスするとログインが求められるのでアカウントを作るか、自前のAuth0のアカウントでログインしましょう。

      ■Verifiable Credentialsのテンプレートを作成

      左側のナビゲーションメニューから[Credentials]をクリックするとTemplateを定義する画面が開きます。
      適当にクレデンシャルの名前などを決めていきます。

      一旦はここまでで、残りの見た目(Branding)などは後で設定します。

      ■Issuance Flowを定義

      次はCredentialを発行する際の属性のマッピングなどを定義します。Microsoft Entraの場合はRulesで定義しましたが、Auth0の場合は[Actions]で定義します。
      [Actions]から[Flows]を開くとテンプレートとしてVerifiable Credential Issuanceがあるので選択します。

      カスタムで適当に属性のマッピングなどを定義します。この辺は当たり前ですがいつものAuth0です。
      もちろん、ここで定義したapp_metadataはユーザの属性と一致させる必要がありますので、後でユーザを作成するときに属性を追加するのを忘れないようにします。

      最終的にこんな感じにFlowが定義されていればOKです。

      ■DCRの有効化

      Walletをクライアントとして登録する必要があるのですが初めからclient_idが払い出せるような世界じゃないのでDCR(Dynamic Client Registration)を有効にしておきます。
      ※テナント全体の設定に関わる話なので、慎重に

      ナビゲーションから[Settings]、[Advanced]を開くと[OIDC Dynamic Application Registration]があるので有効にします。

      ■認証定義で3rd Party Clientsを有効化

      3rd Party Clientsからの認証要求を有効化することでWalletの様に1st Partyではないアプリケーションからの認証要求に対応できる様にします。
      これもいつもの[Authentication]から任意のConnection(今回は面倒なのでDatabase Connectionを使いました)を開き、設定内の[Enable for third party clients]を有効にします。

      ■ユーザの作成と属性の定義

      先ほどFlowを定義した際にも述べましたが属性のマッピングを行うにはユーザに当該の属性がないといけません。
      なので、ユーザを作成し、app_metadataに必要となる属性値を定義しておきます。
      今回はこんな感じで定義しています。

      ■Credentialの定義を完成させる
      最初にやってもよかったんですが、[Credentials]メニューから先ほど作成したTemplateの見た目の部分にあたる[Branding]を設定します。
      と言ってもロゴや背景画像を指定するだけですが。

      ■いざ、発行

      ここまでで設定はおしまいなので、発行してみましょう。
      テスト用にブラウザで動くWalletが組み込まれているので、[Credentials]からTemplateを開いたところにある[Try Credential]をクリックするとすぐに使えます。

      起動するとRequest Credentialボタンが出てくるのでクリックして発行を要求します。
      ログインが求められますので、先ほど作成したユーザを使ってログインします。
      属性提供に関する認可が走ります。

      Credentialが表示されるので、Add CredentialでWalletにCredentialが格納されます。

      ■次は検証

      CredentialがWalletに入ったら次は提示(Presentation)から検証ですね。
      こちらもラボが用意されているので非常に簡単です。
      Wallet内のCredentialをクリックすると[Try Presentation Flow]というボタンが出てくるのでクリックするだけです。
      クリックするとテスト用のVerifierが起動してくるのでQRコードの下にある[Click here to continue]をクリックするとブラウザ版のWalletへPresentation Requestが行われます。
      提示するCredentialを選択して[Present credential]をクリックします。

      Verifiable Presentation/Credentialがテストサイトに渡されるので中身が見えます。



      と、ここまでです。
      非常に簡単です。


      VPやVCを軽くみましたが、ld-proofなんですね。
      Microsoft Authenticatorとの互換性は今のところなさそうです。もうちょいカスタマイズすれば色々とやれそうなので、引き続き触ってみようかと思います。
      なんにせよ、こういう形で選択肢が増えてくるのは良いことですね!










      発行済みVerifiable Credentialsの状態確認を行うStatus List 2021の仕様と動作

      $
      0
      0

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

      今日はちょっとマニアックなところを。(完全に自分向けのメモです)


      Microsoft Entra Verified IDは発行済みのVerifiable Credentialsの状態(有効・取り消し済み)を管理するためにDecentralized Identity Foundation(DIF)のStatus List 2021とIdentity Hubという仕様を使っています。

      ちなみにその後Identity Hubはdecentralized web nodeという仕様になっているので、もうIdentity Hubの仕様はすでに古いものとなっています。

      Decentralized Web Nodeの仕様


      基本的にやりたいことはとしては、

      • 発行されたVerifiable Credentialの状態をHolderやVerifierは確認したい
      • ただ、Issuerに状態を問い合わせるのでは従来の集中モデルと変わらずプライバシー保護の観点などからも好ましくない
      ということなので、Issuerに問い合わせしなくてもVerifiable Credentialの有効状態を確認できる必要があります。

      ということでStatusList2021CredentialというタイプのVerifiable Credentialを発行し、IssuerのIdentity Hubに発行、他のノード等からIssuerが把握することなく閲覧が可能な状態を実現します。
      なお、スケーラビリティへの考慮から発行済みVerifiable Credentialsのリストをなるべくコンパクトに保持する必要があり、ビット配列で状態を保持する形の仕様となっています。


      今回はHolderやVerifier(主にはこちらが確認することが多いとは思いますが)などVerifiable Credentialを受け取ったエンティティがどのように有効性確認を行うのか?について触れたいと思います。(あくまで現時点でのMicrosoft Entra Verified IDでの実装をベースにしています)

      ■大まかな流れ

      大まかにはこんな流れです。
      1. Verifiable Credentialを受け取る
      2. 受け取ったVC内のCredentialStatusを取得(主に以下2つの値が重要)
      • statusListIndex
      • statusListCredential
    10. Issuer DIDのDID DocumentからIdentity HubのserviceEndpointを取得
    11. 2で取得したstatusListCredentilalからIdentity HubへPOSTすべきBodyを生成、Identity Hubへ投げ込む
    12. Identity HubからstatusList2021CredentialというTypeのVCが返ってくるのでencodedListを取得
    13. 2でとっておいたstatusListIndexでencodedListのオフセットを確認し、ビットが立っていたら取り消し済み、倒れていたら有効として判断

    14. ■実際に取得してみる

      まずは、VCからCredentialStatusの取得です。これは単純にJWTをパースすればOKです。
      {
      "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"
      },
          (以下省略)


      大事なのはstatusListIndex、statusListCredentialなかでもqueriesの値です。
      queriesはbase64urlエンコードされたjsonなのでデコードすると後からIdentity Hubへ投げ込む値が出てきます。
      [
      {
      "method": "CollectionsQuery",
      "schema": "https://w3id.org/vc-status-list-2021/v1",
      "objectId": "6fa4e682-f427-41cf-b0e5-59179d66fea3"
      }
      ]


      では、このデータをIdentity Hubに投げ込んでいきます。
      まずはIdentity Hubのエンドポイントを取得する必要があります。statusListCredentialを見ると当該のDIDのserviceの種類がIdentityHubとなっているところにqueriesの値を投げ込むべし、ということが書いてあり、MSの仕様ではIdentityHubへ聞きに行く必要があるということが指し示されているからです。
      ということでIssuer DIDをResolveします。これまでもこのBlogで触れてきたuniversal resolverを使ってもいいですし、Microsoftが用意しているdiscoveryエンドポイントを使ってもいいでしょう。今回はMicrosoftのものを使いました。
      https://discover.did.msidentity.com/1.0/identifiers/{IssuerのDID}
      でGETするとDID Documentが返ってきます。
      {
      "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}"
      ]
      }
      }
      ],
      (以下省略)

      この中のIdentityHubのserviceEndpointの値を取得します。Entra Verified IDの場合、https://hub.did.msidentity.com/v1.0/{Azure ADのテナントID}という構造になっていますので、あらかじめわかっている場合はわざわざresolveしなくてもいいかもしれません。

      このエンドポイントに先ほど取得したqueriesの値を含むjsonをPOSTすることでstatusList2021Credentialが取得できます。

      まずはPOSTデータの作成です。
      構造としてはこんな感じになっています。
      {
      "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はuuid-v4形式の値を指定します。単なるリクエストとレスポンスを紐づけるための識別子なので値はなんでもOKです。
      targetはissuerのDIDを指定します。
      messagesの中のdescriptorに先ほど取得したqueriesの値をセットします。

      ということでPOSTすると以下のレスポンスが返ってきます。
      {
      "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"
      }
      ]
      }
      ]
      }

      大事なのはdataの部分です。
      この値はbase64エンコードされたVerifiable CredentialsなのでデコードするといつものeyJ...が出てきます。もちろんこのjwtの署名検証はするとして、中身を確認していきます。
      {
      "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
      }

      大事なのはencodedListです。
      この値はbase64でエンコードされgzipされたビット配列なのでデコードし、確認したいVCのstatusListIndexの値のオフセットの部分のビットの状態を確認します。

      例えば、以下のような状態になっている場合は上から下に向けて1-2-4-8-...という形で桁が上がっていくのでこの例だと7番目だけがActive、あとは取り消し済みなのでencodedListは2進数でいうと「...110111111」という形で対応するIndexにあたるビットが立ちます。

      ここまでわかればあとは簡単ですね。
      statusListIndexに指定された値(上の例だと5)に該当するオフセットの部分をmaskしてANDをとれば当該ビットが立っているのかどうかがわかり、当該のVCの状態が把握できます。


      ということで今回はStatus List 2021の仕様とMSの実装について触れました。
      (実際はMSのAPIの中でよろしくやってくれるので自前でコードを書く必要はないんですけどね)






      SBT/DID/VCを紐解いてみる

      $
      0
      0

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


      "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とは?

      イーサリアムの提唱者のヴィタリック氏が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になっているわけでもないので、あくまで理念として捉えておくのが良いかと思います。


      ■DID/VCとの共通点・相違点

      もちろん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の衆人環視のアプローチによるレピュテーションベースの信頼性向上の仕組みを構築することは当然可能だといえます。


      ■DID/VCとの共存?

      ヴィタリックも論文の中でVCについても触れており、SBTがプライバシーの課題に対する解決策を見つけるまでは補完関係になると言っています。

      特徴として、

      • SBT:全公開されるので機微なクレデンシャルには向かない
      • VC:コミュニティリカバリの仕組みがない(要は一部の事業者に依拠する)

      など挙げられています。

      また、各ソウル(DID)の信頼性を向上するという意味合いにおいても、

      • SBT:Issuer/Holder/Verifierの区分けがなく、VCモデルの弱点であるHolderの信頼性向上ができる可能性がある
      • VC:特にIssuerの信頼性はDNSなど他のガバナンスとのバインディングにより向上できる仕組みがすでに実装されてきている

      ということも言えますので、うまくSBTの理念をDID/VCの世界の中に持ち込んでいくと面白い世界観が実現できる可能性は十分にありそうです。

      論文内ではVCはコミュニティベース、レピュテーションベースの信頼性向上の仕組みを持っていないので、ソーシャルレンディングや無担保のアパート賃貸契約などのユースケースには対応できない、という話もありましたが、うまく補完しつつシナリオ毎に使い所を分類していけると良いのではないかと感じています。

      ただ、先にも書きましたが現時点においてSBTはあくまで理念・概念にしかすぎないのが現実だと思うので、もう少し実装に踏み込んめるとより議論を深められるな、と思っています。


      最後におまけです。

      2023年3月1日〜3日にIIWのスピンオフイベントがタイであるようです。アジアでもこの手の議論が盛り上がってきていると思うので、可能な方は参加されてはいかがでしょうか?

      https://identitywoman.net/save-the-date-apac-digital-identity-unconference-march-1-3-2023/









      LINEログインの2要素認証の強制とamrクレーム

      $
      0
      0

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

      ものすごく久しぶりに書いている気がしますが、本当は4月ごろに書きたかったネタです。


      簡単にいうと、

      「LINEログイン(Webログイン)で2要素認証を要求するかどうかLINEアプリ側で設定できるようになりました。」
      という話です。

      アナウンス(4月26日付け)

      そして、今回は
      「LINEログイン(Webログイン)で2要素認証を要求するかどうかを管理者がコンソール側で設定できるようになりました。」
      というアナウンスがありました。

      アナウンス(6月28日付け)

      まぁ、ここまではいいんですが実際2要素認証をした場合としなかった場合でid_token(特にamr=Authentication Method Reference Values。要は認証手段)がどう変わるのか?がアプリケーション開発者側の関心事項だと思うので確認しました。

      結果、「2要素認証しても何も値が変わらない」ので非常に残念なんですが一応記録として残しておきます。

      設定方法(コンソールで強制する設定)

      LINE開発者コンソールからLINEログインを開くと2要素認証を要求する、というトグルスイッチがあります。現在初期値はOFFですが7月下旬ごろから初期値がONになるそうです。

      この設定を入れると、Webログインをする際に2要素認証(実際はスマホのLINEアプリ側で画面に表示される4桁の数字を打ち込む)が求められます。

      ちなみに、LINEアプリ側でも設定ができるので、先のコンソール側の設定とアプリ側の設定によって挙動が変わります。

      ドキュメントにはこのように関係性が整理されています。まぁ、違和感はありません。


      で、amrはどうなるのか?

      本題ですが、そもそもLINEログインで想定されている認証手段は
      • パスワード
      • QRコード
      • シングルサインオン
      • 自動ログイン(スマホのみ)
      の4種類です。

      それぞれについてamrの値が以下の通り設定されています。
      • パスワード:pwd
      • QRコード:lineqr
      • シングルサインオン:linesso
      • 自動ログイン(スマホのみ):lineautologin
      今回は自動ログイン以外のWebシナリオで2要素認証を強制する機能なのでlineqrとかlinessoがIANAに登録されているのか?(いやされていない)という話は置いておいて、RFC8176的には「mfa」とか素敵な値が返ってくることを期待するんですが、結果何も変わらずpwd/lineqr/linesso(まぁSSOの場合は2要素認証は求められないって仕様なのでいいとして)がそのまま返ってきてしまいました、というオチです。

      ということでLINEログイン(Webログイン)を組み込むアプリケーション開発者の皆さんはLINEログイン側で2要素認証が行われているかどうかを判別する手段は今のところ提供されていないので、センシティブな処理を行う場合は独自でセキュリティ強化の対策を行う必要がまだまだありそうです。

      ちょっとLINEさんにはフィードバックしておいた方が良さそうかな、と思います。


      Viewing all 769 articles
      Browse latest View live