PlayStationでパスキーを使う(実機編)
パスキーでログインを実装する(検証編)
こんにちは、富士榮です。
前回の続きです。前回はログイン処理の前段部分まで実装できたので今回はcredential.get()の結果の検証を行います。
その前に、これまでのポストはこちらです。
- パスキーの実装をし始めてみる
- パスキー登録APIのオプションを読み解く
- さまざまな認証器でパスキー登録APIの返却値を確認する
- パスキー登録APIのレスポンスを解析する
- パスキーの登録レスポンスの検証を行う
- パスキーの登録を行う
- 登録済みのパスキーを削除する(MacOS)
- パスキーでログインを実装する(クレデンシャルの取得編)
- challengeの検証
- originの検証
- credentialIdをキーに保存済みの公開鍵をDBから取得
- verificationDataの生成
- 公開鍵とsignatureを使ってverificationDataの署名を検証
- 鍵の変換
- パスキー登録の時にレスポンスから取得できるPublicKeyはDER形式なのでcoseに変換する必要があります
- 変換した鍵の中身を使って以下のBufferを連結して検証用の鍵を作ります
- 0x04
- 鍵のx
- 鍵のy
- VerificationData(検証対象とするデータ)の生成
- 以下のBufferを連結して検証対象のデータを生成します
- 0x00
- rpIdHash(登録時にも使ったrpIdの検証用のHashと同じ値)
- clientDataHash(clientDataJSONのSHA256ハッシュ値)
- credentialId
- publicKey
- response
- nagivator.credential.get()の結果取得できるpublicKeyCredentialをtoJSON()したオブジェクトをそのまま渡します
- expectedChallenge
- sessionに保存してあるchallengeを取り出してセットします
- expectedOrigin
- アクセスしているサイトのoriginをセットします。以前解説した通りngrokを使っている関係でschemeは工夫しています
- expectedRPID
- ホスト名をつかっています
- authenticator
- credentialIdをキーにデータベースを検索し取得した公開鍵と署名回数のデータを含むオブジェクトを生成します(JSONBinに保存しているのでレスポンスの中に公開鍵、署名回数が含まれます)
まあ、もちろん前提として本来は登録時にCredential IDが重複していないことをチェック、かつユーザIDとの紐づけた上で登録する、というロジックを入れておかないと安全にはならないのでプロダクションで実装する人は注意しましょう。
なぜSAMLの脆弱性は今でも報告されるのか。そしてOIDCやVCは大丈夫なのか
こんにちは、富士榮です。
故Craig Burtonが”SAML is Dead”という名言を放ってから永らく経つわけですが、まだまだ現役のSAMLには今でもたまに脆弱性のレポートが出てきます。
* SAML is Dead
- 決してSAMLが悪いとか使えない、という意味ではない。これからのアイデンティティシステムはRESTfulなもの(OpenID ConnectやOAuthなど)を使う方が良い、と言う意味。
- 参考
昨日もSilver SAML Attackに関するレポートが出ていました。
非常にざっくり要約すると、以下のようなことが書かれています。
- 例としてEntra IDを挙げている
- Entra IDではSAML Responseへの署名を行う秘密鍵として外部で生成した鍵を利用することができる(BYOK)
- この鍵が漏洩するなどして不正に利用されるとSAML Responseの偽造ができてしまう
- 署名に使う鍵はIDシステムの内部で発行したものを使った方が良い
脆弱性の原因
- 署名・検証の不備を防ぐ
- 通信過程における攻撃者の関与を防ぐ
デジタル署名の前提
正規化の問題
- 空白値のトリミング
- <attribute name="email">test@example.jp</attribute>
- と
- <attribute name="email"> test@example.jp </attribute>
- を同一のものとして扱うか
- コメントの取り扱い
- <!-- これはコメントです -->
- <attribute name="email">test@example.jp</attribute>
- と
- <attribute name="email">test@example.jp</attribute>
- を同一のものとして扱うか
OIDCやVCではどうなのか?
- RDF Dataset Canonicalization
- Dangerous flaws when using URDNA-2015 to digitally sign JSON-LD
OAuth2.0 Security Best Current Practiceを読んでみる(6)
こんにちは、富士榮です。
すこし空きましたがこちらも続けていきます。
引き続き攻撃パターンと緩和策です。前回はリソースサーバでのアクセストークンの漏洩まで行きましたので続き10個目/18個の盗まれたアクセストークンの悪用から行きたいと思います。
攻撃パターンと緩和策
- 盗まれたアクセストークンの悪用
- これはすでに手遅れ?そもそも攻撃なのか?という感じもしますが、万一アクセストークンが盗まれてしまったとしても被害を最小限に食い止める努力は必要です
- 基本は送信者制限(Sender Constraint Token)と対象者制限(Audience Restriction)をすべきであるっていう話です
- 送信者制限(Sender Constraint Token)はその名前の通り、特定の送信者から送信されたアクセストークンのみをリソースサーバが受け付けるようにする、ということです。これはいわゆるべアラ(Bearer)トークンとは対称となる概念ですね
- 参考)Bearer Tokenとは?
- 方式としてはmTLS(RFC8705)とDPoP(RFC9449)があります
- どちらの方式にしても鍵を使ったトークンとのバインディングをするので当たり前ですが秘密鍵の保護は大切です
- 対象者制限(Audience Restriction)もその名前の通り、特定のリソースサーバでのみアクセストークンが利用できるように制限を行います
- こちらもアクセストークンが万一漏洩したとしても影響範囲を最小化するための対策です
- 対象となるリソースサーバを表現するためにはURLなどを利用し、アクセストークン要求時のURLと実際のリソースサーバのURLの値が異なることを検知することによりフィッシング等で作成されたアクセストークンが利用されることを防ぎます
- リソースを指定するにはRFC8707のresourceパラメータを使ったり、scopeにリソースに関する情報を埋め込むことも可能です
- そしてこちらもmTLS(RFC8705)による対策も有効です
- なお、対象者制限付きのアクセストークンを使うと、リソースサーバ単位で特化したアクセストークンを生成することができるので、機能的にもプライバシーの面でもメリットがあります。
- なお、追加の議論として認可サーバがアクセストークンをどこであれば安全に利用できるのか?という情報を提供することもできますが注意しなければならないことが指摘されています
- 一つはメタデータで公開する方法ですが、既知のリソースサーバの情報を公開してしまうことになりますし、メタデータの標準ではありません
- もう一つはトークンレスポンスの中でリソースサーバのURIを合わせて送信するパターンがありますが、正規のリソースサーバへのレスポンスならそれでいいですが、偽造されたリソースサーバへ正規のリソースサーバのURIを送っても何の検証も期待できない面で微妙です
- オープンリダイレクト
- クライアント、認可サーバの両方の構成要素がオープンリダイレクトを引き起こしてしまう可能性があるので注意が必要です
- クライアントがアクセス元となっている画面やページを記憶しておいてトークン取得後にコールバックURIから元のページへ戻す、という実装は一般的ですが、このリダイレクト機能の実装を行う際にオープンリダイレクトを許可してしまう実装にならないように注意する必要があります
- 認可サーバは仕組み上リダイレクトを行うので、こちらも実装する上でオープンリダイレクトにならないように注意が必要です
- 基本的にはRFC6749で正しいredirect_uriのみを受け付けてオープンリダイレクトを行わないことがMUSTとして規定されていますが、正しいredirect_uriを使った攻撃パターンも存在するので十分に注意が必要です
- 例えば、動的クライアント登録を行う際の攻撃パターンとしてこのようなものが紹介されています
- 無効なスコープを指定するなどしてフィッシングサイト等にリダイレクトさせるように誘導(エラーの際にどこに戻すのか?が結構重要なポイントになりますね。変なリクエストが来たからと言って指定されたredirect_uriに戻しちゃうとこう言うことが起きるのかと)
- 有効な認可リクエストを送信、この際にredirect_uriは攻撃者の制御の元にあるURLを利用する。ユーザ認証の後、属性提供同意画面でユーザが拒否をしたとしてもredirect_uri(フィッシングサイト)へ戻される
- この状態でprompt=noneでサイレントログインをするとフィッシングサイトへリダイレクトされてしまう
- 難しい問題だと思いますが、ユーザをリダイレクトする前にちゃんとユーザを認証する、redirect_uriをちゃんと信頼できるかどうか検証する、など考えないといけません
- 307 リダイレクト
- 通常のリダイレクトはGETリクエストのみについてリダイレクトする302を使うと思いますが、代わりに307を使ってしまうとPOSTリクエストについてもリダイレクトしてしまいます。
- 通常認可サーバに対するリクエストを受けるとユーザは認証行為を行うわけですが、その際クレデンシャル情報をPOSTすることになることが多いと思います。ここで307を使ってしまうと意図せずにクレデンシャル情報が別のサーバへ転送されてしまうので307を使うべきではありません
VC WalletのVC発行エンドポイントへの対応を見てみる
こんにちは、富士榮です。
日本でも日本以外でもVerifiable Credentialsが流行っていて(私の周りだけ?)、色々な事業者がIssuanceのデモやウォレットのデモを公開しているので定期的に巡回をしているのですが、先日ようやくImplementer's Draft 1に向けて第一歩を踏み出したOpenID for Verifiable Credential IssuanceのBreaking Changesに対応はまだまだ進んでいないのが実情だなぁ、というあたりの雑談です。
今回手元にあったのでウォレットとVC発行サイトとして、
- Auth0 Lab
- walt.id
Credential発行時のカスタムスキームの変更
-10
- introduced differentiation between Credential Issuer and Authorization Server
- relaxed Client identification requirements for Pre-Authorized Code Grant Type
- renamed issuance initiation endpoint to Credential Offer Endpoint
- added
grants
structure to Credential offer
11.1. Client Metadata
This specification defines the following new Client Metadata parameter in addition to [RFC7591] for Wallets acting as OAuth client:
initiate_issuance_endpoint
: OPTIONAL. URL of the issuance initation endpoint of a Wallet.If the Credential Issuer is unable to perform discovery of the Issuance Initiation Endpoint URL, the following claimed URL is used:
openid-initiate-issuance://
.
10.1. Client Metadata
This specification defines the following new Client Metadata parameter in addition to [RFC7591] for Wallets acting as OAuth client:
credential_offer_endpoint
: OPTIONAL. URL of the issuance initation endpoint of a Wallet.If the Credential Issuer is unable to perform discovery of the Credential Offer Endpoint URL, the following claimed URL is used:
openid-credential-offer://
.
Auth0 labs
openid-initiate-issuance://?issuer=https%3A%2F%2Fっxxxx.auth0lab.com&credential_type=Auth0LabMemberCredential
walt.id
openid-initiate-issuance://?issuer=https%3A%2F%2Fjff.walt.id%2Fissuer-api%2Fdefault%2Foidc%2F&credential_type=OpenBadgeCredential&pre-authorized_code=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJlN2NlM2M5NS0yMTkwLTQxMGItYmI5MS03MzRkOGY5ZGIzNjIiLCJwcmUtYXV0aG9yaXplZCI6dHJ1ZX0.J7--G169U0x61zOoPSbWUESMDO3_YfBsSvgUiHwT7ZQ&user_pin_required=false
では、Auth0 labとwalt.idは相互運用できるのか
openid-vc://?request_uri=https://verifiedid.did.msidentity.com/v1.0/tenants/2c62f1a6-ff50-4764-96a9-0196ebb1bfff/verifiableCredentials/issuanceRequests/d75e8cb7-e79c-443e-81fd-590536b96b34
Trusted Web推進協議会ユースケース報告会がありました
こんにちは、富士榮です。
先週の29日(木)と今週4日(月)の2日間にわたり内閣官房Trusted Web推進協議会のユースケース事業者による最終報告会がありました。
すでに終了していますが、録画や資料は公開されると思うので見逃した方は是非見てみてください。Verifiable Credentialsを含む検証可能なテクノロジやトラストに係るガバナンスのあり方など実際のユースケースに照らし合わせて、かつ実際のモノを作って実験をしているのでとても参考になります。
報告会URL
https://www.toppan.com/ja/joho/social/trusted_web2023_koubo.html#lastreport
以下、プログラムです(上記ページより)
プログラム概要
2月29日(木)
9:55~10:00 | 開会挨拶 | 事務局 |
10:00~11:00 | 報告 | 株式会社電通国際情報サービス(「KYC/KYBに基づいたトラストのある取引」を促進する新しい仕組み) |
11:00~12:00 | 報告 | Institution for a Global Society株式会社(国際間の教育拡充と労働市場の流動性を高める信頼ネットワーク構築~お金の問題なく学び自らの可能性を広げられる世界へ~) |
12:00~13:00 | 休憩 | |
13:00~14:00 | 報告 | 株式会社PitPa(海外人材還流におけるクロスボーダー型個人情報流通システム) |
14:00~15:00 | 報告 | みずほリサーチ&テクノロジーズ株式会社(ものづくりのサプライチェーンにおける製品含有化学物質情報等の確実な伝達を可能とするChemical Management Platform(CMP)) |
15:00~16:00 | 報告 | SBIホールディングス株式会社(事業所IDとそのデジタル認証基盤) |
16:00~17:00 | 報告 | Originator Profile 技術研究組合(Trusted Web Advertising System with OP) |
3月4日(月)
10:00~11:00 | 報告 | 株式会社DataSign(ウォレットによるアイデンティティ管理とオンラインコミュニケーション) |
11:00~12:00 | 報告 | 富士通Japan株式会社(大学技術職員の活躍に向けたスキルの見える化:スキルの質保証と主体的情報開示の試行) |
12:00~13:00 | 休憩 | |
13:00~14:00 | 報告 | シミック株式会社(臨床試験及び医療現場における信頼性及び応用可能性の高い情報流通システム(該当分野:医療・ヘルスケア) |
14:00~15:00 | 報告 | 株式会社ORPHE(下肢運動器疾患患者と医師、研究者間の信用できる歩行データ認証・流通システム) |
15:00~16:00 | 報告 | 一般社団法人情報サービス産業協会(補助金事業を題材とした法人向け行政手続DX社会基盤化のプレ検討) |
16:00~17:00 | 報告 | 大日本印刷株式会社(共助アプリにおけるプラットフォームを超えたユーザートラストの共有) |
17:00~17:05 | 閉会挨拶 | 事務局 |
私はユースケース担当委員もやっていたので、4日(月)の午後に発表のあった、シミックさん、ORPHEさん、情報サービス産業協会さんの3事業者さんのメンタリングを1年かけて担当してきました。
今回の最終報告会でも簡単にコメントをしたので軽くご紹介しておきます。(詳しくは今後公開される動画をみてください)
シミック株式会社(臨床試験及び医療現場における信頼性及び応用可能性の高い情報流通システム)
ヘルスケアのユースケースです。臨床試験に参加する人が身につけているウェアラブルデバイスから上がってくるデータを医療機関および製薬企業へ同意を持って共有していく、という話です。さらにその際にデータが途中で改竄されていないことを検証可能にする、そしてデータ連携先となる医療機関や製薬企業の正当性についても検証可能にしていくということを目指しています。FitbitなどのウェラブルデバイスにKeyChainのコアを組み込んでデータへの署名をしていくという仕組みで実装しています。
私がコメントしたのはこんなところです。- PHRの観点では同意管理が重要な中、従来は個別でなんとなくな管理DBを作ってきたことを考えるとユニバーサルな仕組みとして応用可能性があり非常に大きな一歩となり得ると思う
- 今後スケールしていくためには、以下の3点が大切である
- より多くのウェアラブルデバイスベンダの巻き込み
- より多くの医療機関、製薬企業の巻き込み
- 個人の巻き込み
- デバイスベンダを巻き込むにはインセンティブ設計とオープンネスが必要なので、治験に利用できるという認定などの制度設計との平仄合わせが必要になるのと、KeyChain以外の実装でも互換性を持ちつつ実装できる方法の検討が必要になりそうである
- 個人の巻き込みの観点ではCGMのようにデバイスの普及とセルフメディケーションと医療費控除への繋げていくなどの仕組みも必要になりそうである
あまり当日は時間がなかったので技術面ではツッコミませんでしたが、技術標準へのフィードバックもこれらの実験から得られると良いと思います。
株式会社ORPHE(下肢運動器疾患患者と医師、研究者間の信用できる歩行データ認証・流通システム)
こちらもヘルスケアのユースケースです。シミックさんのケースとは共通点が多いのでこの2社には協力して実証をすすめていただいていました。こちらは靴にセンサーをつけて歩行情報などをとっていくというシナリオでした。
同じく、こちらのユースケースへの私のコメントはこんな感じでした。
- 個人に対するインセンティブ設計が必要
- ポイ活などとうまく連携して患者向けだけではなく健常者に対しても提供することで予防医療などにも繋げられる可能性があるのではないか
- 現在の個人へのインセンティブはNFTの付与としているが、同意撤回を行うとポイントの返礼を行うモデルとなっている。これは同意解除にペナルティがある様に感じられる可能性があるので慎重に設計が必要ではないか
- 医療機関に対するインセンティブ設計
- 英国と日本の医療制度の比較が紹介されたのですが、英国における利用報酬は当該医療機関に登録された患者の頭数がベースとなる人頭報酬制度、日本の場合は診療行為に対するポイントをベースとして報酬制度となっていることから、人頭報酬となっている方が医師からすると患者が健康であればあるほど登録者数に比べて診療行為の負荷が減らせる=利益効率が良いというインセンティブも作れる可能性があるので、その辺りの制度設計も今後参考にできると良い
- UXに関して
- これはこのユースケースに限った話ではないのですが、Walletを使うモデルだとどうしても事業者のアプリやWebサービスとWalletのインタラクションが発生、どうして別の2つのモノを合わせて使わないといけないのか?を個人が受け入れられないケースがあると思います
- まさにLaws of IdentityのJustifiable Partyって話だと思いますが、ユーザから見て本当に必要なのかが明確にわからない登場人物がインタラクションの中に入ってきてしまうのでUI/UXの面でうまく説明もしくはシームレスな遷移など工夫が必要だと思います
一般社団法人情報サービス産業協会(補助金事業を題材とした法人向け行政手続DX社会基盤化のプレ検討)
- コミュニティについて
- 事業スキームとしてコミュニティ形成が大切かつこのモデルになるとG2B文脈においても金融機関や携帯キャリアなどのKYC/KYB提供事業者をコミュニティの一員として迎え入れる必要が出てきます
- 一方で金融機関や携帯キャリアなどからするとなぜこのコミュニティに参加しなければならないのか?儲かるのか?が関心事となるはずなので、彼らにとってのビジネスの可能性をどうやって示せるのか?は重要なポイントになるはずです
- そのためにもまずは行政サービスがファーストペンギンになって、その後でこのスキームは民間サービスでも利活用できるんだ、ということを広げていくムーブメントが必要になってくるんだと思います
- Walletについて
- どうしてもWalletというと個人のスマホに入ったアプリケーションを想起させてしまうので、法人Walletは別の言い方を含めて考えた方がよさそうです
- 個人の場合は発行と提示を切り離すことによるプライバシーインパクトの低減などWalletを使うベネフィットは語りやすいのですが、法人の場合は単にポータルとAPIでいいんじゃない?という意見も出てくると思います
mDL(モバイル運転免許証)の実装もそろそろ
- mDocのオンラインデバッガーです。(jwt.ioみたいなモノ)
- そして発行・提示などに使えるライブラリです。
MOSIPもVerifiable Credentials関連モジュールを組み込んでいるみたいです
こんにちは、富士榮です。
昨日、某ニュースを見ていたらMOSIPの解説記事が目につきました。
そういえばざっくりしか知らないなぁ、と思ったので読んでいたのですが、どうやら最近InjiというVerifiable Credentials関連のモジュールの組み込みをしているんですね。
記事
MOSIP, the Unneglectable Force in the Global South
MOSIPのアーキテクチャ図(記事より)
記事の中ではこう記載されています。MOSIP has recently added a Verifiable Credentials module Inji, which supports the issuance of Verifiable Credentials, a digital wallet tool for verification, and is looking to offer tools and services for trust and governance. It is still unclear how this module interacts with the MOSIP architecture. But we look forward to learning more about it at MOSIP CONNECT.
で、Injiです。
Key componentsとしてこれらが紹介されていますが、まだWalletしかリリースされていないようです。
Inji Mobile Wallet: A secure, trustworthy, dependable, and decentralized mobile Verifiable Credentials wallet. It allows users to download, manage, share, and verify verifiable credentials.
Inji Web: An easy-to-use web portal that makes credentials accessible to everyone. It enables users to download, print, store, and share verifiable credentials physically. [Available starting March 2024 release]
Inji Certify (issuance): A platform to issue credentials of any type in multiple formats. It allows issuers to create, sign, issue, bind, and store/hold verifiable credentials. [Available starting March 2024 release]
Inji Verify: Tools and utilities for consuming and verifying credentials. [Available starting March 2024 release]
Inji Infra: Tools and utilities for revocation, ledger, status, resolution, and federation of verifiable credentials. [Future Wishlist]
Inji Govern: Frameworks to define policies, schemas, assurance, and parties in the context of verifiable credentials. [Future Wishlist]
現状、使うには登録フォームから申し込む必要があるようです。
アフリカや東南アジアの国々などインド発でOSSということもありMOSIPに注目しているところも多そうなので、Walletを含め普及が一気に進むとしてらグローバルサウスから、なのかもしれませんね。
統合認証シンポジウム(佐賀)に参加しています
IAL2/AAL2のロードマップを作ろう:学認のサポート:佐藤先生(東京大学・学認)
オープンアクセスとは・・
このような状況への対処とインターネットの普及を受けて学術情報をインターネットから無料で入手でき、誰でも制約なくアクセスできるようにするというオープンアクセスの発想が1990年代に生まれた
学認対応IdPホスティングサービス実証実験とそこから得られた課題と対応:清水先生(NII)
京都大学におけるOrthrosの活用に向けて:中村先生(京都大学)
京都大学で進めている研究DXの取り組みの推進においては「サービス主導型選択的多要素認証システム」がテーマになっているということです。これは重要な示唆ですが、大学におけるID管理がますます重要になってきている、ということが挙げられています。やはり研究データは非常に重要なもので国家レベルの機密情報に当たるものもあるわけなので、研究者の本人確認〜ID保証(IAL/AAL)が非常に重要になってきているということです。
公開鍵暗号方式に基づく認証機能の分離:大神さん(LINEヤフー)
参考)PKaaSデモ
次にLINEヤフーさんのパスワードレス認証の取り組みについて紹介がありました。SMS認証も合わせると2017年からパスワードレス認証の仕組みを提供しているので、かなり早いうちから対応を進めていました。さすがです。
- IdPがFIDOに関する機能を実装すること
- IdPを運用する上で必要なこと
実装方式は2つあるそうです。リダイレクトするかバックエンドでAPIを呼び出す方法です。
リダイレクトの場合のoriginはPKaaSになるんでしょうか。そうなるtお大学IdP側のフィッシング対策にはならなさそうですので、どちらの方式で実装するかは考えたほうがよさそうですねぇ。
ハイブリッドクラウド環境における認証基盤とクライアント端末の運用:石丸さん(名古屋工業大学)
しかし、この辺りはあるある過ぎて・・・私は過去に3日間同期完了まで待っていたことがあります。。。
検証可能な資格情報によるデジタル学生証・職員証の検討:伊東先生(九州大学)
Shibboleth IdPにおけるFIDO2認証対応 事例報告:大谷先生(佐賀大学)
OpenID Foundationの提供するテストスイートの開発者(Javaプログラマ)の募集が出ています
EUのDigital Identity Walletのリファレンス実装が公開されています
こんにちは、富士榮です。
各国でデジタル・アイデンティティ・ウォレット(DIW)の検討や実装が進んでいますが、先行して検討が進んでいるEUの実装やアーキテクチャ・リファレンス・フレームワーク(ARF)を参考にすることが多いと思います。
ARFはこちら
The European Digital Identity Wallet Architecture and Reference Framework
今回はドキュメントではなく、Digital Identity Wallet並びに関連するモジュールがgithubで公開されている、という話です。ビルドすればWalletが作れるのでみなさんも試してみると面白いと思います。
こんな感じで動くようです。
こちらで公開されています。
https://github.com/eu-digital-identity-wallet/.github/blob/main/profile/reference-implementation.md
公開されているのは、以下のモジュール群です。
- Wallet Core(Android) and Wallet Kit(iOS) Coordinator Libraries
- Wallet Core(Android)
- Wallet Kit(iOS)
- Proximity Sharing iOS Libraries
- mDoc Security(iOS)
- mDoc Data Transfer(iOS)
- mDoc Data Model(iOS)
- Proximity Sharing Android Libraries
- mDoc Data Transfer(Android)
- Remote Presentation iOS Libraries
- Presentation Exchange(iOS)
- SIOPv2 and OpenID4VP protocols(iOS)
- SD-JWT(iOS)
- Remote Presentation Android Libraries
- Presentation Exchange(Android)
- SIOPv2 and OpenID4VP protocols(Android)
- SD-JWT(Android)
- Issuing iOS Libraries
- OpenId4VCI(iOS)
- Issuing Android Libraries
- OpenId4VCI(Android)
- Wallet Data Storage and Cryptographic Management iOS Libraries
- mDoc Document Storage (iOS)
- Wallet Data Storage and Cryptographic Management Android Libraries
- mDoc Document Storage (Android)
- Wallet UI App and demo App for Android and iOS
- UI / Demo App (Android)
- UI / Demo App (iOS)
- Verifier Apps and Services
- Web Verifier
- Restful API (web-services)
- Issuing Apps and Services
- OpenId4VCI issuer (Python)
- OpenId4VCI issuer (Kotlin)
結構膨大ですね。
日本でもDataSignさんが進めているOWND ProjectなどオープンソースでWalletなどの実装を公開する動きが出てきていますし、開発者のみなさんには良いことだと思います。
OWND Project
自己主権型アイデンティティは本当か?情報銀行からの学びはあるのか?
DataSignさんのニュースリリース
情報銀行「paspit」サービス終了のお知らせ
結果、IT連盟の通常認定がゼロになっています。
ちなみにP認定はまだありますが、そもそもP認定は「「情報銀行」サービス開始に先立って立案した計画、運営・実行体制が認定基準に適合しているサービスであることを認定するものです。サービス開始後において運営・実行、改善を図り、『通常認定』の取得が条件となります(P認定の更新は不可)。」という定義なのでサービスが開始されていない(もしくはサービスを開始する前の検討段階)のものなので、実質サービスとして提供されているものではありません。なので本当にゼロ件です。
自己主権とユーザの責任
- 自己主権の一番の難しさは結果的にユーザに責任を押し付けることになること
- つまり、ユーザは誰に情報を提示して良いのかを自身の責任で判断しないといけない
果たしてユーザは責任をとれるのか
と言うことでどんな対応ができるのか考えてみる
- ID連携に比較してIdPへのCall home問題はなくなるのでIdPの可用性を含む全集中度合いは下げられる(別の切り口だが)
- Walletプロバイダが本当に認定済みVerifierに対してVCを提示したかどうかはわからないようにWalletを作ることはできるはず
- ID連携におけるIdP万能という状態からは少し前進できている気はする
- 多分、次のVC関連のビジネスはWalletプロバイダが本当の意味での情報銀行(提示先の審査による安心の提供)としての機能を提供することなのかも知れない(どこまで利用者からお金を取れるかは未知数だけど)
パスキーの実験に使ったコードをgithubにあげました
こんにちは、富士榮です。
そういえばパスキーの実験をしていた頃のコードを公開するのを忘れていた気がするので公開しておこうと思います。
これまでのパスとでやったことはこちらです。
- パスキーの実装をし始めてみる
- パスキー登録APIのオプションを読み解く
- さまざまな認証器でパスキー登録APIの返却値を確認する
- パスキー登録APIのレスポンスを解析する
- パスキーの登録レスポンスの検証を行う
- パスキーの登録を行う
- 登録済みのパスキーを削除する(MacOS)
- パスキーでログインを実装する(クレデンシャルの取得編)
- パスキーでログインを実装する(検証編)
OpenID Foundatioon Hybrid Workshop@Googleオフィス(マウンテンビュー)
OpenID for Verifiable Credential IssuanceのImplementer's Draftの投票が開始されています
こんにちは、富士榮です。
先日ポストした、OpenID for Verifiable Credential IssuanceのImplementer's Draftの投票が始まっています。
Notice of Vote for Proposed Implementer’s Draft of OpenID for Verifiable Credential Issuance
個人でもOpenID Foundationのメンバになれますので(50ドルかかりますが)、ぜひ登録して投票してください。
SIDI Hubの2024の戦略が発表されました
こんにちは、富士榮です。
先日のOpenID Summit Tokyoやその前日に開催されたOpenID Foundation Hybrid WorkshopでOIDF Executive DirectoryのGail Hodgesのキーノートで触れられたSIDI Hub(Sustainable & Interoperable Digital Identity Hub)の今後のプランと今年のアクションアイテムが公開され、2024/3/31までフィードバックを募集しています。
SIDI HubのWebページのトップからダウンロードできるようになっています。
ちょっと中身をみていきましょう。
SIDI Hubが解決を目指す課題とは?
SIDI Hubの名前の通り、デジタルアイデンティティって全然相互運用できないよね、ということを最大の課題として設定しています。
以下、Deeplでの機械翻訳です。
人と企業は国境を越える。将来、人々は、通貨交換を期待するのと同様に、国境を越えて日常生活でデジタル・ アイデンティティを使用したいと思うようになるだろう。残念ながら、多くの問題が国境を越えた相互運用性の障害となっている:
- 数十のデジタル・アイデンティティ・エコシステムがその管轄区域内でサイロ化されている。
- OECD のデジタル ID 勧告には、国境を越えた利用を可能にすることが盛り込まれているが、 38 カ国の加盟国がどのように実現できるかについての技術的または政策的なロードマップはない。
- どの国、地域、標準化団体、非営利団体、民間団体、多国間に も国境を越えた相互運用性を実現する権限がない。
- 単一の標準が「すべてを支配」する可能性は低いため、技術スタック間のデジタル ID 相互運用性は技術的には可能であるが、達成および維持は非常に困難である。
- 悪質な行為者が脆弱なインフラ(AIディープフェイク、サイバー犯罪、COVID-19)を利用するため、不作為による機会費用が発生し、人々やビジネスは高いレベルの摩擦に直面する。
- ポリシーを解釈し、製品や実装で簡単に実施する仕組みがなければ、ビジネス・コンプライアンス・コストは増大し続ける。
- デジタル・アイデンティティが果たすであろう重大な役割を理解している人は、アイデンティティ・コミュニティ以外にはほとんどいないため、明確で透明性の高いコミュニケーションが重要である(誤った情報を避けることも同様)。
ということでSIDI Hubの目的は?
クロスボーダーで使えるデジタルアイデンティティを実現するために必要なものを定義しましょう、ということです。なぜSIDI Hubがこんなことをやるの?
なぜなら、SIDI Hubは、
(1) デジタル ID インフラ、標準、および政策に責任を持つ (2) SIDI ハブに価値を見出す、グローバルなエコシステム全体 からの利害関係者のコミュニティ
ワークストリームおよびワークショップにおける SIDI ハブの参加者は、共有されたロードマップ、 解決すべきギャップ、および改善策を含む、国境を越えた相互運用性の「良い姿」を具体 化するのに役立つ。
我々は、この課題に対する共通のコミットメント、国内主権と国内法および国際法の尊重、参加組織の活動の尊重、そして共通の文化(コンセンサス、包括的、透明性、健全な議論など)を持っている。
SIDIの協力は、組織がその使命に照らしてインパクトをもたらすための「泳ぐ車線」を明確にする助けにもなる。
法人統治機関標準化団体オープンソースコードプロバイダ市民権団体NGO多国間組織コンサルティング団体ベンダー
ではなく、
SIDI Hubは、政府やその他のエコシステム参加者が何をしなければならないかを指示することはできません。
何をして、何をしないのか?
- ギャップ分析
- SIDI Hunの目的に向かって推進するための活動
- チャンピオンユースケースの選定
- 標準化団体へのアプローチ
- 各団体が策定している標準への働きかけ
- デプロイメント
- オープンな相互運用性試験の実施の働きかけ
- 条件を満たすオープンソースにフォーカスを当てる
- ポリシー
- トラストフレームワーク間のマッピングを行う
- オペレーション
- 会合の開催
- フィードバックの反映
- 他の動きとの整合性をとる
やらないこと:
- 以下のような口出しはしない、ということです
- 政府に対してどのような法律を策定しなければならないか
- 非営利団体がどのような決定を下さなければならないか
- 標準化団体がどのように仕様を変更しなければならないか
誰が参加するの?
- 国連やワールドバンクのような多国間組織
- EUや個々の国々の政府機関
- 非営利団体
- 標準化団体
- 学術機関
結局何をやるの?
Identiverse 2024のアジェンダが公開されています
Data Sharing Using Verifiable Credentials in the Agricultural Sector
Enabling a Trusted Ecosystem for the US Pharmacy Supply Chain
Untangling the Tangled Web of Digital Identity Online Presentation
Digital Identity, the G20, and the SIDI Hub Survey
Lessons Learned: Nationwide eID Recovery With Remote Identity Proofing
Counselors in the Modern Era: Advancing Identity Management
Securing the Foundations of Verifiable Credential Ecosystems
Auth0の管理画面へのログインにパスキーを使うと少しハマる件
こんにちは、富士榮です。
そういえばAuth0(Okta CIC)の管理画面へのログインにパスキーなどが使えるので使ってみたいと思います。
ちなみにちょっとだけ癖があります。簡単に書くと、
- パスキー追加をメニューから実施する場合はplatform認証器は選べない
- USBキーやOTPなど多要素認証を追加し利用すると「このデバイスでのログインの高速化」を目的としてplatform認証器の登録を促される
- リカバリはリカバリーコードを利用する
- どうやらパスキーとしてはUSBなど外部キーを前提に設計されている
- デバイス登録を目的にplatform認証器登録も使えるが同期される前提はなさそう
という感じです。最初からplatform認証器が登録できればいいのに。ちょっと実装が古いのかな。
さて、始める前に基本的な話を。IDaaSを使ってID基盤を構築するときに忘れてはいけないのはIDaaS自体の認証強化とアクセス制限です。
- 管理者アカウントの分離(共有ユーザの排除)
- 管理権限の適正化
- 認証強化(多要素認証)
- ※API実行ユーザも忘れずに!
ということで追加してみます。WebAuthn with FIDO Security Keysをクリックしてみましょう。(なお、ポップアップがブロックされているとエラーになりますので、許可してください)
外部IdP利用時にRP側"でも"多要素認証を行うべきか
まずは技術的な話
- IdPによって返すacr/amrが異なる
- IdPによっては返ってこないこともある
そもそも論として、なぜ外部IdPと連携するのか?
Entra IDの新しい条件付きアクセスを試す(デバイスコードフロー編)
- デバイスコードフロー
- 認証の転送
- 全てのユーザが
- デバイスコードフロー用のテストアプリにアクセスしようとした場合
- 認証フローが「デバイスコードフロー」だったら
- アクセスをブロックする