IdM実験室: 識別子

ラベル 識別子 の投稿を表示しています。すべての投稿を表示

2024年7月27日土曜日

[Auth0/Okta CIC]ログインに使う識別子にメールアドレス・ユーザ名・電話番号を使う

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

たまにはAuth0/Okta CICを。

Auth0/Okta CICはログインする時の識別子はデフォルトでメールアドレスになっています。

これをユーザ名や電話番号を使うように設定することもできます、という話です。

ドキュメントはこちらにありますので、実際に設定する場合は注意点を含めこちらをみてください。

https://auth0.com/docs/authenticate/database-connections/flexible-identifiers-and-attributes

設定は簡単です。

ユーザ名とパスワードでの認証するコネクター「Username-Password-Authentication」の設定を開きます。

この中にAttributesというタブがあるので開きます。

するとNew Attributes ConfigurationがあるのでActivateします。（デフォルトはEmailのみってことですね）

確認されますので、Proceedを選択して進めます。

すると「Add Attribute」というボタンがアクティブ化されます。

クリックすると識別子として利用する属性を選択するポップアップが出ます。ユーザ名もしくは電話番号が選択できるようになります。

ユーザ名を選択すると関連する設定を行うことができます。

- ユーザ名を識別子として使うかどうか

- ユーザ名を使ってサインアップすることを許可するか（オプションか必須か）
- ユーザプロファイルとしてユーザ名を要求するか

- ユーザ名の文字列の長さ

また、詳細設定ではメールアドレス形式でユーザ名を許可するかの設定もできます。（現時点では電話番号形式のユーザ名は使えません。まぁ、正直どういうシナリオで使うのか不明ですが）

設定を終えるとログイン画面の入力ボックスに「ユーザー名またはメールアドレス」という形で表示が変わります。

また、サインアップ画面でもメールアドレスに加えてユーザー名も要求されるようになります。

なお、電話番号の方も似たような設定を行います。

設定が終わるとログイン画面が「電話、ユーザー名、またはメール」という表示に変わります。

サインアップ時に電話番号も入力が求められるようになります。

システムを移行する時など、複数の形式の識別子が混在するケースもありますので、そういうケースでは使えそうな機能ですね。

一方で通常はあんまり複数の形式のログインIDを有効にしておくとユーザも混乱しそうなので、割り切りも必要だと思います。

2024年2月3日土曜日

OpenID Providerを作る）仮名に加えて匿名をサポートする

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

厳密にはOpenID Connectの仕様に定義されていませんが、以前実装したPairwise識別子（PPID）に加えて匿名の識別子（Transient Identifier）をサポートしたくなるシーンが存在するので、対応を入れていきたいと思います。

その前にこれまでのおさらいです。

識別子の種別、および仮名と匿名の違い

識別子は主体を一意に特定するために利用される属性（群）を表しますが、名寄せのリスクなどに応じてどのような値を返すべきかについて十分な考慮が必要です。

そもそも識別子には公開、仮名（かめい）、匿名の３種類が存在します。

区分	共有範囲	OpenID Connectでの区分	SAMLでの区分	解説
公開	全体	public	unspecifiedやemailaddress	全RPに対して共通の識別子を送出する
仮名	RP	pairwise	persistent	特定のRPに対して一意の識別子を送出する
匿名	なし	-	transient	毎回異なる識別子を送出する

上記の表に示した通り、全てのRPに対して同じ識別子の値を送出するpublicなタイプ、同一のRPに対しては毎回同じ値を送出するPairwiseがOpenID Connectにおいては定義されています。ただし、特定のケースにおいて同一識別子出会ったとしても毎回送出する識別子を別のものに変えたい、というケースも存在します。SAMLにおいてはこのケースを想定してnameid-formatとしてpersistent（いわゆる仮名であるPairwise）に加えてtransient（匿名）を定義していました。

ここで仮名と匿名の違いを正しく理解しておきましょう。

仮名：連続性がある。つまり外野から見ると誰だか分からないが、特定のRPから見ると一意に主体を識別できる
匿名：連続性がない。外野から見ても特定のRPから見ても一意に主体を識別することができない

この辺りはかなり昔にイベントでしゃべった資料が出てきたので貼り付けておきます。

ID連携における仮名 from Naohiro Fujie

実装してみる

前置きが長くなりましたが、実装してみましょう。

基本的にはpairwiseの中の種別として実装をしてみたいと思いますので、設定ファイルにスイッチを作っておき、指定されたオプションによって仮名か匿名かを決めていきたいと思います。

.envに識別子のタイプを指定できるようにします。

# 識別子の種別：PERSISTENT or TRANSIENT
IDENTIFIER_TYPE=TRANSIENT

次に識別子を生成するところのロジックを分岐させます。

oauth2/oauth.js

            // 識別子タイプの判定（Persistent or Transient）
            let PPID;
            switch(process.env.IDENTIFIER_TYPE){
                case "TRANSIENT":
                    // 魔界異なる識別子を生成する
                    PPID = crypto.randomUUID();
                    break;
                case "PERSISTENT":
                default:
                    // Pairwise識別子の生成
                    PPID = utils.createPPID(payload.local_identifier, req.query.redirect_uri);
            }

以上で完成です。

初回アクセスでの識別子（sub）の値

２回目のアクセス時の識別子（sub）の値

同じRPへのアクセスですがsubの値が変わっていることがわかります。

今回のコードを含めこちらに挙げてありますので参考にしてみてください。

2024年1月2日火曜日

did:webの課題をカバーするdid:websがパブリックレビューへ

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

みなさん大好きなdidメソッドの話です。

結局did:webが結構使われてるけどdid:webって既存のwebサイトの管理方法（DNSとかCA）に依存しちゃうので分散型じゃないよね、という課題（？）をカバーするためにdid:websっていうのをToIP（Trust Over IP） Foundationのdid:webs Method Task Forceで検討して仕様策定している、ということのようです。

ToIP Foundationからのアナウンス
https://trustoverip.org/news/2023/12/15/announcing-public-review-of-the-didwebs-method-specification/

個人的には結局インターネット上でDIDを使うユースケースに限っていえば既存のインターネットの仕組みであるDNSのレジストラやHTTPSのCA局のポリシーやガバナンスを信頼する必要があるはずなので、そこまで分散型に拘る必要性は感じない派なのですが・・・

did:webにおける課題

did:webに限らずdid全般において言えることですが、結局did、Decentralized Identifiersはつまるところ識別子なのでどうやってメソッド内の名前空間におけるユニークネスを担保するのかがポイントになります。ユニークネスを担保するためには多くの場合においてレジストリ（Trusted Data Registry）を構築し重複レコードがないことを管理することが必要となります。その際の登録〜管理プロセスを特定の管理主体（群）を通して行うモデルが従来のDNSやCA局などが取ってきたモデルです。一方で衆人環視の元、あらかじめ合意されたコンセンサスアルゴリズムに則ってレジストリへの登録〜管理を行うモデルがいわゆるブロックチェーンベースのレジストリ管理のモデルです。

一方でOpenID ConnectにおけるSIOPv1（v2と区別する意味であえてv1とつけます）における自己発行の証明書のThumbprintを識別子として用いる、つまり証明書のエントロピーに全振りし特定のレジストリを用いないモデルも存在します。

この辺りは上記のToIPからのアナウンスにも記載されていますが、整理するとdidメソッドにおける識別子の管理方法は、

権威ある管理主体を利用する方式
ブロックチェーンを利用する方式
自己発行の証明書を利用する方式

に分類されるわけです。

前述の通りdid:webはdid:web:example.jp:users:taroの様にドメイン名を識別子に利用する上にDID Documentを取得するレジストリ（did.json）の正当性についてはHTTPSを用いるので1番めの権威ある管理主体を利用する方式に該当します。

しかしながら前述の通り、Decentralized Identifierというからには分散している方が良いのである、という主張も存在するわけで2番めのブロックチェーンを利用する方式なども依然として利用されている状態にあります。

この様なカオスがdidメソッドの乱立を招いてしまっているわけで、本ポストを書いている時点で186個もメソッドが登録されいる状態にありますし、もちろんW3Cのdidレジストリに登録せずにプライベートでdidを利用しているシステムも多数存在している状態となっています。

話を戻すと、分散型の必要性を主張するシナリオに対応するためにdid:webを拡張するのが今回のToIPのタスクフォースの対応だということになります。

did:websにおける対応

では、具体的にどの様な対応をしているのかを見ていきましょう。非常に単純です。

要するに従来のdid:webのDNS名前空間はそのまま利用し、最後に3番めの自己発行の識別子をくっつけることで対応しようという試みです。こんな感じの識別子ですね。

did:webs:example.jp:users（ここまではdid:web）:xxxxxxxx（自己発行の識別子）

この最後の自己発行識別子の部分については既にToIP FoundationのACDC（Authenticated Chained Data Container） Task Forceで議論しているので、こちらを使おうという話の様です。いわゆるGLEIFがvLEIで採用しているKERI（Key Event Receipt Infrastructure）の話ですね。この辺りはIIW（Internet Identity Workshop）でも毎回活発に議論されています。

私もACDCやKERIについてはあまり知らないのでこれ以上は突っ込みませんが、did:web+ACDC=did:websって考えておけば良いのかな、、というぐらいの理解です。

まぁ、冷静に考えると結局のところDNSやHTTPSへの依存は一定以上残るわけなので、そこまで分散型に拘るなら素直にブロックチェーンベースのdidメソッドを使えば良いのでは？と思いましたが。。いずれにしてもユースケース次第ですね（という逃げ口上）。

2022年2月27日日曜日

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

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

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

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

SSIとDIDで何を解決したいのか？（β版） from Naohiro Fujie

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

まだ意外と誤解されているが分散型「アイデンティティ」ではない

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）の書き方くらい。

自己主権型アイデンティティは幻想？

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

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によるネグレクトに対する銀の玉にはなりそうにもない。

VC発行者に関する信頼は難しい問題

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

いくらVerifiableだったところで信頼されるとは限らない

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

KYCというか本人確認・身元確認との相性はそれほど良くはない

結局、Identity Proofingの本質はNIST SP800-63Aでいうところの、

Resolution
Validation
Verification

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

結局はIdPとRPの結合度を下げることが可能、というのが最大のメリット？

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

標準化の実際はどうなっているのか？

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

ゼロ知識証明（ZKP）、選択的開示（Selective Disclosure）が本命？

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

結局何か世の中の課題を解決できたのか？

よく言われるものとして、

プライバシー
検証可能性

があるが、上記を見ている結局そこまで解決に至っているとはいえない。
それよりも、上記に書いた通りOPとRPの間の結合度を下げることによる管理面やインフラ的なコスト削減が一番のメリットになるのでは？

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

登録: 投稿 (Atom)

IdM実験室

2024年7月27日土曜日

[Auth0/Okta CIC]ログインに使う識別子にメールアドレス・ユーザ名・電話番号を使う