こんにちは、富士榮です。
先月Public Reviewが行われていたOpenID FederationのImplementer's Draft 4ですが、昨日から投票期間が始まっています。
Public Reviewの際のポスト
https://idmlab.eidentity.jp/2024/06/openid-federation-implementers-draft4.html
投票の告知
https://openid.net/notice-of-vote-for-proposed-fourth-implementers-draft-of-openid-federation/
投票期間は7/17〜7/24ですので、米国OpenID Foundationの会員の方は投票しましょう。
 |
| MyDataのページより |
こんにちは、富士榮です。
先日書いた通り、DIF（Decentralized Identity Foundation）がDWN（Decentralized Web Node）に関するイベントを日本時間の19日のAM1時からやりました。
 |
| DWNの説明図（DIFより） |
こんにちは、富士榮です。
先月から読んできたW3C Verifiable Credential Overviewが少しだけ更新されています。
2024年6月13日版から2024年7月6日版への更新です。
ざっと変化点を。
3.2 Serialization in JSON
Example1:
@Contextに指定されているボキャブラリーが
"https://www.example.org/vocabs/alumni"
から、ネームスペース
"https://www.w3.org/ns/credentials/examples/v2"
へ変更されています。これは以降のExampleでも同様です。
同じくExample4では$idの値が、
"https://example.com/schemas/email.json"
から、
"https://university.example/schemas/credential.json"
へ変更されています。
Example 6: A Simple Credential in JWT (unencoded)では前のバージョンではJOSEのサンプルだけだったのがCredential本体、JOSE、COSEの3つがタブで選択表示できるようになっています。だた、現状ではCredential部分しか書かれていないのでそのうちJOSEとCOSEのサンプルも書かれると思います。
Example 8: the Core Example Secured with ECDSAの部分は、ECDSAだけのサンプルだったのがEdDSAのサンプルが追加されています。こちらもExample 6と同様にCredential本体、ECDSA、EdDSAでタブに分かれていますが、まだCredential本体部分しか記載がありません。
最後にExample 12にComplete Exampleという形でVerifiable Credential with a Reference to a Credential Schema and to a Status ListがCredential本体、ECDSA、EdDSA、BBS、JOSE、SD-JWT、COSEのそれぞれでのサンプルが追記されようとしています。（同じくCredential部分しか書かれていない）
うん、まだまだ更新がかかるんだと思います。
こんにちは、富士榮です。
世の中、ウォレットで溢れてきている今日この頃ですが皆さんお好みのウォレットは見つけられているのでしょうか？そしてそのウォレットで自分が使いたいサービスを使えているんでしょうか？さらにそのウォレットは信じて大丈夫なんでしょうか？
という話は置いておいて、一言でウォレットと言ってもいわゆるweb3的なウォレットもあればVerifiable CredentialsやmDocの様なアイデンティティ・ウォレットも存在するわけです。
今回は、皆さん大好きHackMDへのログインにウォレット（MetaMaskとかのweb3ウォレット）が使えるので使ってみただけのポストです。
セットアップは簡単で何らかの方法でログインした後でプロファイルのページからログイン方法を選択するだけです。
そして、なぜかウォレットログインを選択しようとするとパスワードの登録を求められるのでパスワードを設定するところからスタートです。何だか時代に逆行しているのか最先端をいっているのかよくわからなくなってきます。
私は素直？にMetaMaskを選びましたが。
とっても簡単です。
ちなみにプラグインがブラウザに入っていない時はQRコードでスマホ側のウォレットを呼び出すこともできます。
この辺のUXはパスキーやVCとも共通ですね。一部ブラウザAPIがVCにも対応しようとしていますが、APIの共通化がもっと進むとUXの一貫性も保たれる様になると思うので、よりよくなりますね。
Table 8. Methods, credentials, ZKP and blockchain in years.
| Method | Paper | Year | Credential type | ZKP | Blockchain |
|---|---|---|---|---|---|
| Hash-based | [54] | 2007 | Digital credential | ||
| [55] | 2008 | Digital credential | |||
| [56] | 2010 | Digital credential | ✓ | ||
| [61] | 2017 | ABC | |||
| [50] | 2019 | Digital credential | ✓ | ||
| [52] | 2022 | VC | ✓ | ||
| [63] | 2022 | Digital credential | ✓ | ✓ | |
| [64] | 2023 | VC | ✓ | ||
| [62] | 2023 | Digital credential | ✓ | ||
| [57] | 2023 | SBT | ✓ | ||
| Signature-based | [69] | 2008 | AC | ✓ | |
| [67] | 2009 | Digital credential | |||
| [72] | 2015 | AC | ✓ | ||
| [68] | 2019 | ABC | ✓ | ||
| [70] | 2020 | AC | ✓ | ||
| [71] | 2022 | VC | ✓ | ✓ | |
| [74] | 2023 | ABC | ✓ | ||
| [79] | 2023 | AC | ✓ | ||
| [77] | 2023 | ABC | ✓ | ✓ | |
| [75] | 2023 | AC | ✓ | ||
| ZKP | [82] | 2019 | ABC | ✓ | ✓ |
| [83] | 2021 | VC | ✓ | ✓ | |
| ZKP & Signature-based | [87] | 2013 | AC | ✓ | |
| [78] | 2018 | ABC | ✓ | ✓ | |
| [88] | 2021 | PABC | ✓ | ||
| [89] | 2022 | ABC | ✓ | ||
| ZKP & Hash-based | [85] | 2023 | VC | ✓ | ✓ |
| [86] | 2023 | AC | ✓ | ✓ | |
| Signature-based & Hash-based | [90] | 2020 | VC | ✓ | |
| [91] | 2022 | VC | ✓ |
Table 9. Comparison of different credential types.
| Type | Algorithma | ZKPa | Blockchaina | Examples | Maturity | Encoding | Characteristics |
|---|---|---|---|---|---|---|---|
| Digital credential | Hash | / | / | XML, JSON, PDF, blockchain-based formats, cryptographic tokens, smart contracts | Electronic versions of paper credentials. Any form of digital certification. Easily shareable, verifiable online and can improve administrative efficiency. Focused on transparency and traceability. More general and not inherently designed for privacy enhancement, unless otherwise specified. | ||
| AC | Signature | ✓ | / | JSON, XML, cryptographic tokens | Designed for anonymity of user. Enhances privacy and security by preventing user tracking and profiling. Complex in implementation. Misuse in avoiding accountability possible. ZKP enhancements and signatures can be computationally intensive. Extended versions more commonly used in practice. | ||
| ABC | Signature | ✓ | Idemix, U-prove | IBM, Microsoft, ABC4Trust, PrimeLife | JSON, XML, cryptographic tokens | Extension of ACs focused on attributes. Offers fine granularity over attributes disclosed. Increases user control and enhances privacy. Can be less efficient in terms of computation and storage. Flexibility requires strict policy enforcement mechanisms. Implemented and standardized through extensive work on it. | |
| PABC | ZKP & Signature | ✓ | / | / | JSON, cryptographic proofs | Privacy enhancement of ABCs through the use of ZKPs. Maximizes privacy by ensuring minimal data exposure. Increases complexity and computational costs are higher. Lack of standardizations and practical usage. | |
| SBT | Hash | ✓ | / | / | Smart contracts, token metadata | Lack of standardization and practical usage. Reliable and immutable proof of attributes. Depends on blockchain which can cause scalability issues. Non-transferability enhances security but causes lack of flexibility and is restrictive. | |
| VC | All | ✓ | ✓ | HyperLedger AnonCreds SD-JWT, Multiple wallets | W3C VC | JSON, JSON-LD, JWT, JWP | Standardized format. Credentials can be independently verified (without direct access to the issuer). Highly interoperable and secure. Enhances trust and reduces fraud. Complex in implementation. Needs widespread adoption of the standard. |
Starting with just three airports, Delhi, Bengaluru, and Varanasi, Digi Yatra has expanded its footprint across major airports in the country, including Mumbai, Hyderabad, Pune and Kolkata. Currently operational at 14 airports, very soon Digi Yatra plans to expand to an additional 15 airports.
3つの空港から始まって現在14の空港で利用でき、もうすぐ15番目の空港でも使えるようにする予定らしいです。
By adopting Digi Yatra, passengers have been able to cut down on airport entry time from 15-20 seconds to around 5 seconds.
これまで15-20秒かかっていた空港への入場が5秒で済むようになったとのこと。20秒ならいいじゃんって思ってしまいますが、インドくらいの人口のところだとものすごい効果なのかもしれません。
まぁ、日本でも顔認証ゲートは導入されているので、VCベースかどうかは置いておいて、この流れは世界へ広がっていくんでしょうね。
羽田の顔認証ゲート
https://tokyo-haneda.com/site_resource/flight/pdf/how_to_use_Face_Express_en.pdf
ちなみにあまり詳しい技術情報は書いてありませんが、Digi YatraのCEOの方がFinancial Expressに寄稿した記事には分散Ledgerを使ったDIDとVCによる自己主権型アイデンティティのソリューションである、と書いています。
どうしてもTravel Passというとe-Passport系の話に頭が入ってしまいますが、空港での顧客体験の向上、というキーワードでも色々と適用できそうな場面はありそうですね。
 |
| 赤：義務化されている国 青：任意取得の国 |
Central Population Register (CPR) is a nine digit (all numeric) identification number which is also called as personal number issued for all the residents living in Bahrain. In order to use basic or any services, carry out financial transactions one must have CPR.
中央人口登録（CPR）は、バーレーン在住のすべての住民に発行される9桁（すべて数字）の識別番号で、個人番号とも呼ばれます。基本的なサービスやその他のサービスを利用したり、金融取引を行うには、CPRが必要です。
一方で任意取得にカテゴライズされている日本はこんな感じです。
An Individual Number Card is issued to citizens of Japan as well as legal residents. It was introduced in 2016 and replaces the Juki-Card.
マイナンバーカードは、日本国民および永住権保持者に発行されます。2016年に導入され、住基カードを置き換えます。
なるほど。
こういうデータがまとまっていると色々とインサイトが得られるので面白いですね。
 |
| AWSの事例サイトより |
This innovation has significantly reduced processing and waiting times at various airport checkpoints, with processing times at entry gates dropping from an average of 15 seconds to approximately 5 seconds, while also improving processing times at other checkpoints. It also enhances the passenger experience by eliminating the need for manual ID and travel document checks.
搭乗ゲートで15秒とか20秒は掛かり過ぎじゃ？？と思ったり。
そして中身はCognito＋顔認証＋Aadhaarみたいです。
DYF designed and developed the Digi Yatra mobile app on Amazon Web Services (AWS), using Amazon Cognito, a secure, frictionless customer identity and access management service that scales to authenticate passengers with an access token. This feature signs in users by sending them an SMS message through Amazon Simple Notification Service (Amazon SNS) with a one-time verification code. Following this step, passengers are required to utilize their Aadhaar, a 12-digit unique identification number, for an Aadhaar ID validation process. This can be done by using either direct Aadhaar validation or the Digi Locker Aadhaar e-Know Your Customer (KYC) document. Once the e-KYC document is received, the face biometric is extracted by the Digi Yatra App and the passenger is prompted to take and upload a selfie. This selfie image is matched with the e-KYC reference face, and the ID credentials are created. The sign-in process triggers functions on AWS Lambda, a serverless, event-driven compute service that manages generation and verification of the user’s verifiable credentials. Khadakbhavi states, “The system operates as a paperless, contactless solution, where the passenger's face effectively transforms into the boarding pass. The selfie serves as the single token throughout the entire boarding journey.”
DYFは、Amazon Cognitoという、乗客の認証にアクセストークンを使用する、安全でスムーズな顧客IDおよびアクセス管理サービスを使用して、Amazon Web Services（AWS）上でDigi Yatraモバイルアプリを設計・開発しました。この機能は、Amazon Simple Notification Service（Amazon SNS）を通じてSMSメッセージにワンタイム検証コードを送信することでユーザーをサインインさせます。この手順の後、乗客は Aadhaar ID 検証プロセスに 12 桁の固有の識別番号である Aadhaar を使用する必要があります。これは、直接 Aadhaar 検証または Digi Locker Aadhaar e-Know Your Customer (KYC) 文書を使用して行うことができます。e-KYC 文書を受信すると、Digi Yatra アプリによって顔認証情報が抽出され、乗客は自撮り写真を撮影してアップロードするよう指示されます。この自撮り画像は e-KYC の参照用顔写真と照合され、ID 認証情報が作成されます。サインインプロセスは、AWS Lambda の機能を起動します。AWS Lambda は、サーバーレスでイベント駆動型のコンピューティングサービスであり、ユーザーの検証可能な認証情報の生成と検証を管理します。Khadakbhavi 氏は、「このシステムは、乗客の顔写真が搭乗券に変わる、ペーパーレスで非接触型のソリューションとして動作します。自撮り写真は、搭乗手続きのすべての行程で唯一のトークンとして機能します。
なるほど。よくあるサインアップ時にKYCしてIDドキュメントの顔写真と自撮り写真の比較、それ以降は自撮り写真をベースにサービス利用時の顔認証を行うってパターンですね。
At the airport, travelers simply open the app and scan the QR code at the airport entry e-gate. Instantly, the app retrieves their credentials, including face biometric and boarding pass data. Their live face is then captured and matched with the shared ID face, while the validation of the travel document itself occurs seamlessly in the background with the airline Departure Control System.”
空港では、旅行者はアプリを起動し、空港入口の電子ゲートでQRコードをスキャンするだけです。すると、顔認証データや搭乗券データを含む旅行者の認証情報が即座にアプリに取得されます。次に、旅行者の顔が撮影され、共有されたIDの顔と照合されます。旅行書類自体の検証は、航空会社の出発管理システムによりバックグラウンドでシームレスに行われます。
航空会社側で持っている予約情報などをアプリへ読み込む際に一緒に顔情報もサーバサイドが持っているものとその場の利用者の顔情報の照合をする感じですね。まぁ特徴点だけでしょうけど。サーバサイドに生体情報を持つことの是非は国にもよるんでしょうが便利ではあるんだろうなぁ。。
しかし、自己主権型っていうのを止めれば？くらいに集中管理型のシステムですよねw
ウェブサイトは、さまざまな方法でモバイル ウォレット アプリに認証情報をリクエストできます。 カスタム URL ハンドラや QR コードのスキャンなど、新しいメカニズムを取り入れています。この 使用すると、サイトが Google Cloud 内のデジタル認証情報から ID 情報を 使用してウォレット アカウントを作成できます。Kubernetes は、 複数の認証情報形式に対応（例: ISO mDoc や W3C による検証可能な） 複数のウォレット アプリを使用できるようにします。この API には エコシステム全体でセンシティブ アイデンティティが悪用されるリスクを軽減するメカニズム 情報です。
- Granular control over data sharing — necessary attributes are proven without being revealed;
- Enhanced privacy — sensitive information does not need to be revealed, which reduces the risk of data exposure and lowers the chances of identity theft and fraud since the actual information is not disclosed, just proven;
- Increased trust — allowing the user to control the revealed or proven data, the level of trust increases among users;
- Post-quantum security — certain methods are resistant to quantum attacks;
- Compliance and regulatory adherence — using ZKP compliance and identity can be proved without compromising personal data privacy, as demanded by GDPR or CCPA.
データ共有のきめ細かい管理 — 必要な属性は公開されることなく証明される。
プライバシー保護の強化 — 機密情報を公開する必要がないため、データ漏洩のリスクが軽減され、実際の情報が開示されるのではなく証明されるだけなので、個人情報の盗難や詐欺に遭う可能性も低くなります。
信頼性の向上 — 公開または証明されたデータをユーザーが管理できるため、ユーザー間の信頼度が高まります。
ポスト量子セキュリティ — 特定の方法は量子攻撃に耐性があります。
コンプライアンスと規制遵守 — ZKPコンプライアンスとIDを使用することで、GDPRやCCPAで要求されているように、個人情報のプライバシーを損なうことなく証明することができます。
- Complexity — creation and verification with ZKPs can be computationally intensive, which is a problem for systems not optimized for such operations;
- Issues of understanding — designing systems that use ZKPs correctly requires cryptographic expertise, which can be a barrier to widespread adoption;
- Scalability — since ZKPs are computationally intensive, scaling them for large scaling applications remains a challenge;
- Interoperability — integration of ZKP within existing infrastructure is often complex;
- Trusted setup and auditing — some methods require a trusted setup phase;
- Privacy vs. regulation — a balance must be achieved for when ZKP is needed and when it is not.
- 複雑性 — ZKP を用いた作成と検証には膨大な計算処理が必要となり、そのような処理に最適化されていないシステムにとっては問題となります。
- 理解の問題 — ZKPを正しく使用するシステムの設計には暗号化の専門知識が必要であり、これが普及の妨げとなる可能性がある。
- スケーラビリティ — ZKPは計算負荷が高いので、大規模なスケーリングアプリケーションへの適用は依然として課題となっています。
- 相互運用性 — 既存のインフラストラクチャに ZKP を統合することは、しばしば複雑である。
- 信頼性の高い設定と監査 — 信頼性の高い設定段階を必要とする方法もあります。
- プライバシーと規制 — ZKPが必要とされる場合とそうでない場合について、バランスを取る必要があります。
This specification defines the OpenID Federation entity types for digital wallet architectures.
この仕様は、デジタルウォレットアーキテクチャ用の OpenID Federationエンティティタイプを定義します。
As digital wallets become increasingly deployed for managing identity credentials, establishing an architecture for trusted communication is required to allow each participant in the ecosystem to evaluate other participants' compliance with mutual trust frameworks and accomplish secure and trusted transactions.This specification defines how to use OpenID Federation 1.0 [OpenID.Federation] to enhance the security and interoperability of wallet ecosystems, facilitating trust establishment among the parties and enabling secure metadata exchange and policy application across large scale deployments.This specification also outlines the general architecture of a federated trust infrastructure for wallet ecosystems, identifying participant roles and defining metadata used for those roles. In particular, it defines the metadata for the roles of Wallet Provider and Wallet Relying Party.Additionally, this specification provides practical examples of how to apply policies for typical use cases within wallet ecosystems. Finally, it offers guidance on defining trust marks for use within wallet ecosystems.
デジタルウォレットがID証明書の管理にますます普及するにつれ、エコシステム内の各参加者が相互信頼フレームワークへの他の参加者の準拠を評価し、安全で信頼性の高いトランザクションを実現できるように、信頼性の高い通信のためのアーキテクチャを確立することが必要となります。
この仕様では、OpenID Federation 1.0 [OpenID.Federation] を使用して、ウォレットエコシステムのセキュリティと相互運用性を強化する方法を定義しています。これにより、関係者の間で信頼関係を構築し、大規模な展開においても安全なメタデータ交換とポリシーの適用が可能になります。
この仕様ではまた、ウォレットエコシステム向けの統合された信頼インフラストラクチャの一般的なアーキテクチャの概要を示し、参加者の役割を特定し、それらの役割で使用されるメタデータを定義しています。特に、ウォレットプロバイダーとウォレット依存者の役割のメタデータを定義しています。
さらに、この仕様では、ウォレットエコシステム内の典型的な使用事例に対するポリシーの適用方法の実用例も提供しています。最後に、ウォレットエコシステム内で使用する信頼マークの定義に関する指針も提示しています。
まだまだIssuer/Holder/Verifierの3パーティモデルにおけるエンティティの信頼性に関するモデルは成熟しているとはいえない状況なので、各所でさまざまな検討が進んでいます。例えば、Verifiable CredentialへIssuerが署名することで改竄されていないことを確認することはできても、当該のIssuerが本当に信頼できるIssuerなのかはX.509の認証局へのトラストに依拠することなってしまっていいのか？だとか、Walletプロバイダをどうやって信頼するのか？という議論で認定モデルを作ったり、など国ごとの事情にもよりますが色々な検討があります。
これはもちろんVCエコシステムの中だけではなくFederationにおいてもTrust Frameworkの議論〜策定が進んできた歴史があるので、VCモデルにおいても最終的には同じようなところに帰結する可能性は高いと思います。ただ、当然Federationとは異なる考慮ポイントもあるので、このような議論が空中戦ではなく仕様をベースに語られるのはとても良いことですね。
時間を見て続きも読んでいきたいと思います。
こんにちは、富士榮です。
昨日はDIF Japanの第1回Meetupでした。
参考）以前のポスト
会場は他のMeetupも混ぜこぜで大混乱でしたが盛況だったと思います。
 |
| 写真は三井さんのポストから拝借 |
個別プレゼンはそこそこで大半がパネルディスカッションという形式でしたが、結果的に色々な（勝手な）意見を出し合うことができて個人的には楽しい時間を過ごせたと思います。
ディスカッションのテーマの一つとして「生成AIとデジタルトラストとDID/VC技術が果たす役割」というものがあったので、最近考えていることを。（昨日聞いておられた方はお話しした内容そのままですが）
あくまで個人的見解ですが、以下の2点に強く違和感を感じています。
 |
| デジタル庁の資料より |
社会保険労務士は独学での取得が可能です。試験は法律に関する知識が問われますが、独学用の教材が豊富にあり、独学で合格を目指す受験者も多くいます。
その他の資格（医師、歯科医師、看護師、保健師、助産師、理学療法士、作業療法士、視能訓練士、義肢装具士、臨床検査技師、臨床工学技士、診療放射線技師、衛生検査技師、死体解剖、医師臨床研修修了者、歯科医師臨床研修修了者、医師少数区域経験認定医、薬剤師、言語聴覚士、歯科衛生士、歯科技工士、救急救命士、管理栄養士、あん摩マッサージ指圧師、はり師、きゅう師）に関しては、必ず指定の教育課程や実習が必要であり、独学のみで取得することはできません。これらの資格は専門の学校やプログラムを修了しないと受験資格が得られないため、独学での取得は不可能です。
介護福祉士は、一定の実務経験を持つ者であれば独学で受験が可能です。実務経験が必要なため、完全な独学とは言いにくいですが、必要な知識を独学で学ぶことは可能です。
税理士試験は独学での受験が可能です。ただし、非常に難易度が高く、多くの受験者が専門学校や通信講座を利用しているのが現状です。試験に合格するには5科目に合格する必要があり、受験科目ごとに独学で学習することが可能です。
保育士試験は独学での受験が可能ですが、試験範囲が広く、実技試験も含まれるため、独学のみでの取得は難易度が高いです。とはいえ、教材や過去問集を利用すれば、独学で合格することも可能です。
まぁ、国家資格なので当然ではありますが、mDoc目当てで資格取得するのはやめておきます。
こんにちは、富士榮です。
パスキー便利ですよね。これまでもパスキー推しのトーンでポストを書いてきましたが、一方でX（旧Twitter）ではうまく使えない、動かない、などの声がリテラシーの高い層からも聞こえてくるのも事実です。
そんな中、IDProが「I’ll Pass (for now) on Passkeys」という記事を先日公開しています。
https://idpro.org/passing-on-passkeys/
 |
| IDProの記事より |
もちろん、IDProとしても著者個人の意見である旨を断った上で記事を掲載していますが、ある方面からの見え方としては正しいこともあるので把握しておくことは大切だと思います。
なお、別途書こうと思いますが、後日Dean Saxeが同じくIDProに反論（？）記事も書いているのでそれはそれで面白いです。
今回は「今の所、パスキーはやめとくわ」っていう著者の主張を見ていきましょう。
主な理由として、以下を挙げています。
Passkeys did seem like an initial positive middle ground, however the confusing marketing, implementation limitations, sometimes lack of transparency and interoperability has so far, undermined their potential to be a truly great improvement on current password and MFA options.
パスキーは、初期のポジティブな中間的な選択肢のように思えたが、マーケティングの混乱、実装の限界、時折見られる透明性の欠如、相互運用性により、パスワードやMFAのオプションを真に大きく改善する可能性は、今のところ損なわれている。
特に透明性の欠如の部分ではProtonのブログを引用しています。
https://proton.me/blog/big-tech-passkey
Protonのブログは若干の誤認識がありそうですが、簡単にいうと結局GoogleとAppleが牛耳ってるじゃん、Synched Passkeyの鍵の同期もAppleワールドの中ではできるけど自分で好きにExportしてWindowsでも使えるようになってないじゃないか、という主張がされています。
同じようにGoogleはChromeを使っている限りはパスキーの同期はできるけどFireFoxを使ったらダメじゃん、ということで相互運用性や透明性について課題があると主張がなされています。
うーん、全体にそこじゃない感じしかしませんが。
私が観測している範囲だと、パスキーが使えないっていう主張のほとんどは一部は上記の2点に関連するところはあるものの、実際はパスキーを設定させるまでのユーザ導線が難しすぎる、とか、機種変更やサービス側の機能Updateが発生した場合に過去に設定したパスキーが見つからないとか、詰む、などサービス側の問題な気がしているんですが。。。
こんにちは、富士榮です。
結局「パスキーはパスすべきなのか？」という話です。
昨日のポストでDean SaxeがIDProに反論記事を書いているということを書きましたが、今日はそちらを見ていきましょう。
Don’t Pass on Passkeys
https://idpro.org/dont-pass-on-passkeys/
 |
| IDProのポストより |
昨日取り上げたポストでは、結局認証器ベンダや同期ファブリックを運営しているベンダと鍵を共有することになる、とか、異なるベンダのプラットフォームを跨いでの鍵の同期や再利用ができないことが指摘されていました。
今回のDeanのポストではそれらの指摘に対して以下のように反論しています。
こんにちは、富士榮です。
（先日のJNSAの動画のポストをしましたが、このポストを投稿したつもりで書いていました。6月に投稿しようと思って下書き状態で残っていた、というオチなので今更投稿します）
JNSAのデジタルアイデンティティWGでは毎年アイデンティティに関する複数のテーマを決めて、サブグループで議論をしています。
昨年は特権ID管理に関するサブグループが成果物作成を一生懸命進めており、今回JNSAのホームページで公開されました。
https://www.jnsa.org/result/digitalidentity/2024/index.html
ガイドは
