2024年7月20日土曜日

DIFがDWNサービスを開発者向けに無償提供!

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


先日書いた通り、DIF(Decentralized Identity Foundation)がDWN(Decentralized Web Node)に関するイベントを日本時間の19日のAM1時からやりました。

DWNの説明図(DIFより)


その中で大きな発表がありました。
The Decentralized Identity Foundation (DIF) today announced a Free Managed Decentralized Web Node service for developers, operated by DIF leveraging Google Cloud technology. 

そう、Universal Resolverに続いてDWNもDIFが無料で開発者向けに提供を始めました!

ざっくり概要です。
  • Google Cloud上で提供される
  • DID一つにつき1GBのストレージが用意される
  • 7/17-19でベルリンで開催中のWeAreDeveloper World Congress 2024でDanielとMarkusが発表する
こちらのサイトで使い始められるようです。TBDのAPIでWeb5アプリが作れるぞ、という建て付けになっていますね。

触らないといけないものが増えすぎて時間が取れていませんが、余裕ができたらもう少し深掘りしてみようと思います。


2024年7月19日金曜日

MyData Japanカンファレンスに見るアイデンティティのモデル

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

一昨日はMyData Japanカンファレンスに行ってきました。
OpenIDファウンデーションジャパンも後援させていただいています。

イベントページ

界隈の人たちはみんないたんじゃないかな?という位、自分がフォローしている人のタイムラインを見ていれば行かなくても済むくらいの盛況でした(謎)。

もちろん午前中のデジタルアイデンティティ関連のセッションを中心に見たわけですが改めてMyDataが整理しているアイデンティティモデルはよくできているな〜と思ったのでその部分だけ。
詳しくは崎村さんのブログで資料も公開されていますので。

崎村さんの資料では日本語になっていますが、原典のMyDataの説明では以下の図で解説されています。

MyDataのページより


これが程よい抽象化レベルで非常にわかりやすいし、汎用的だなぁ、と改めて。

MyDataのページによるとそれぞれのアクターは以下の役割を持つ、と定義されています。
  • PERSON
    • An individual that manages the use of their own personal data, for their own purposes, and maintains relationships with other individuals, services or organisations.
  • DATA SOURCE
    • A data source collects and processes personal data which the other roles (including Persons) may wish to access and use.
  • DATA USING SERVICE
    • A data using service can be authorised to fetch and use personal data from one or more data sources.
  • PERSONAL DATA OPERATOR
    • A Personal Data Operator enables individuals to securely access, manage and use their personal data, as well as to control the flow of personal data with, and between, data sources and data using services. Individuals can be their own operator. In other cases, operators are not using the information itself, but enabling connectivity and secure sharing of data between the other roles in the ecosystem.
(DeepLで翻訳)
  • PERSON
    • 自身の個人情報を自身の目的のために管理し、他の個人、サービス、組織との関係維持を行う個人。
  • データソース
    • データソースは、他の役割(Personを含む)がアクセスし、使用したいと思う可能性のある個人情報を収集し、処理します。
  • データ利用サービス
    • データ利用サービスは、1つまたは複数のデータソースから個人情報を取得し、使用することを許可される場合があります。
  • 個人データオペレーター
    • 個人データオペレーターは、個人が自身の個人データに安全にアクセスし、管理し、使用できるようにするとともに、データソースとデータ使用サービスとの間で、またデータソース間での個人データの流れを制御できるようにします。個人が自身のオペレーターになることもできます。その他の場合、オペレーターは情報そのものは使用せず、エコシステム内の他の役割との間でデータの接続と安全な共有を可能にします。
例えばOpenID Connectなどのフェデレーションモデルでは、Personが利用者、データソースがIdentity Provider、データ利用サービスがRelying Party、Verifiable CredentialsのモデルだとデータソースであるIssuerとデータ利用サービスであるVerifierの間にWalletが入るわけです。
そして、最も重要なポイントは個人データオペレーターの存在です。
フェデレーションのモデルにおいてはIdentity Providerが個人データオペレーターを兼ねることになりますし、典型的なVerifiable Credentialsの利用モデルにおいてはWalletプロバイダが個人データオペレーターになったりするわけです。

結局のところ個人データを誰かが扱うことになるので、自己主権型アイデンティティを実現するにはこの個人データオペレーターを個人が完全に制御できる状態を作る必要が出てくるわけです。Walletがあれば自己主権ってわけじゃないぞ、というのがよくわかりますね。結局はWalletプロバイダに頼ってしまうわけです。

だからガバナンスが大事になるわけですね。

この辺りが通常のアイデンティティモデルの図にはあまり出てこないので、改めてこの図を見ると理解が深まるんじゃないかな、と思いました。

2024年7月18日木曜日

OpenID Federation Implementer's Draft 4の投票が開始されました

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

先月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の会員の方は投票しましょう。


2024年7月17日水曜日

プラスチック製品のリサイクルへのDigital Product PassportとVerifiable Credentialsの適用

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

昨日のアスリートの健康情報に続きプラスチック製品のリサイクルへの適用の事例の話です。


ご存知の通りEUでは諸々の排出量規制が厳しく、リサイクルも注力されている分野の一つです。

今週2024/7/18に既存のEcodesign Directive 2009/125/ECに変わる規制としてESPR(Ecodesign for Sustainable Products Regulation)が施行される予定ですが、その中には「Digital Product Passport」というものがあります。

どういうものか上記ESPRのサイトに記載があります。

The ESPR will introduce a Digital Product Passport (DPP), a digital identity card for products, components, and materials, which will store relevant information to support products’ sustainability, promote their circularity and strengthen legal compliance. 

This information will be accessible electronically, making it easier for consumers, manufacturers, and authorities to make more informed decisions related to sustainability, circularity and regulatory compliance. It will allow custom authorities to perform automatic checks on the existence and authenticity of the DPPs of imported products.

Information to be included in the DPP will be identified by the Commission, in close consultation with all relevant stakeholders, and will depend on the specific product in question. This information can include:

  • Product’s technical performance
  • Materials and their origins
  • Repair activities
  • Recycling capabilities
  • Lifecycle environmental impacts

ESPRは、製品、部品、原材料のデジタルIDカードであるデジタル製品パスポート(DPP)を導入します。DPPには、製品の持続可能性をサポートし、循環利用を促進し、法的コンプライアンスを強化するための関連情報が保存されます。

この情報は電子的にアクセスできるため、消費者、メーカー、当局が、持続可能性、循環型経済、法規制遵守に関するより情報に基づいた意思決定を容易にします。また、輸入製品のDPPの存在と真正性を、税関当局が自動的に確認できるようになります。

DPPに記載される情報は、欧州委員会がすべての関係者と緊密に協議した上で決定し、対象となる特定の製品によって異なります。この情報には、次のようなものが含まれます。

  • 製品の技術的性能
  • 材料とその原産地
  • 修理活動
  • リサイクル能力
  • ライフサイクルにおける環境への影響

要するにモノを対象としたデジタルIDカードであるデジタル・プロダクト・パスポート(DPP)はリサイクルを含むモノのトレーサビリティを担保するためのものになるようです。

モノのIDということでGS1を思い出すと思いますが、やはり既にGS1ヨーロッパがリリースを出していますね。

https://gs1.eu/activities/digital-product-passport/

GS1ヨーロッパのページより

全ての製品のデジタルIDを付与することで環境への影響などを含めトレーサビリティを実現していくことで規制への対応をしていく、という話ですね。

既に一部の企業がAgro2Circularと連携してプラスチック製品のリサイクル分野でのDPP適用の実験なども行っているようです。

https://www.linkedin.com/pulse/piloting-digital-product-passport-plastic-recycling-dominique-guinard-sdu4e/

IOTAを使っているみたいです。




GS1標準スキーマをうまく使いつつデータ表現はVCみたいですね。



今後、日本においてもEUとの貿易を考えるとトレーサビリティ文脈でVCを利活用するケースも必要になってくるのかも知れませんね。






2024年7月16日火曜日

結局VCは何に使えるのか?アスリートの健康情報への適用例

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

もうすぐパリ五輪ですね。あまりスポーツに興味はありませんが。


Trusted Web推進協議会の実証事業でも色々とユースケースを集めて実証をしたわけですが、結局のところVerifiable Credentialsって何にでも使えてしまうところがあり、かつユースケースごとに微妙に要件が異なるわけで、結局何に使えるの??みたいにぼやけてしまいがちです。


これもその一つではありますが、Indicio社がアスリートの健康情報の保護にVerifiable Credentialsを使う、というユースケースについて書いています。

Indicio社のBlogより引用

https://indicio.tech/better-athlete-health-data-protection-through-verifiable-credentials/

アスリートがつけるウェアラブルデバイスから取得できるデータをVerifiable Credentialsを使って検証可能な状態でやり取りしましょう、という話で、以下の利点があると記載されています。

1. チーム、大学、医療提供者、およびこのデータを保存していたすべての人の責任が免除されます。

2. アスリートは情報を完全に管理できます。情報を見る必要がある関係者と情報を共有することはできますが、データの所有者に問い合わせる必要があり、所有者はデータのすべてを共有するか、特定の部分だけを共有するかを選択できます。

3. すべてのデータが 1 つの便利な場所にまとめられているため、要求されたときに情報のすべてのソースを追跡する必要がありません。

4. データはソースと同じくらい信頼できると想定できます。データに変更があった場合、分散型台帳に表示され、認証情報が「破られる」ため、ユーザーは発行元との二重チェックや検証に時間を費やす必要がありません。

5. データは、アスリートのエージェントなどの信頼できるパートナーと簡単に共有でき、必要に応じてアスリートに代わってデータを共有できます。


Trusted Webの実証事業でORPHEさんがやっておられたシューズの事例とかシミックさんがやっておられた治験データの事例に近いシナリオですね。


まぁ、データセキュリティに関する話なのでどの分野でも適用可能って言われたらそこまでですが、こうやって事例を増やしていくと見えてくるものもあると思うので、どんどんやっていけると良いですね。

2024年7月15日月曜日

選択的開示に関するReview論文を読む(2)

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

引き続き選択的開示に関する調査論文を読んでいきます。
Selective disclosure in digital credentials: A review

まさに選択的開示(笑)※拾い物です


本文に入っていきます。
最初のポイントは、「選択的情報開示の形態と種類、実現方法」についてです。

まず、選択的開示の方法として以下の3種類が挙げられています。
  1. アトミック・クレデンシャル
  2. 選択的開示署名
  3. ハッシュ値

アトミック・クレデンシャル

非常にシンプルな方法です。一つのクレデンシャルに一つのクレームのみを含むようにする手法です。
例えば、選択的開示可能なマイナンバーカードのクレデンシャルを作ろうと思ったら、名前・住所・生年月日・性別をそれぞれ別のクレデンシャルにしてしまって、必要に応じて提示するクレデンシャル自体を分ける、ということですね。

選択的開示署名

ネイティブに選択的開示をサポートしている署名形式を用いる手法です。CL署名とかBBS+なんかはこちらでしょうね。

ハッシュ値

全てのクレームを含むクレデンシャルを発行するものの値をハッシュ化する手法です。SD-JWTはこちらですね。論文中ではハッシュの方法論についても比較をしつつ解説していますので、こちらも参考になります。


他にもZKPについても語られており、ZKPとハッシュ値の組み合わせなど複合手法についても分析が行われています。


アトミック・クレデンシャルについては置いておくとして、選択的開示署名とハッシュ値の2点については方式が一覧化されています。

論文中に出てくる順番とは異なりますが、引用しておきます。

選択的開示署名の方式の概要

Table 5. Overview of signature-based methods.

ArticleAlgorithmComplexityPerformanceSuitabilityKey sizeaSignature sizea
[69]CL signatureHigh due to the use of interactive ZKP of signaturesRelatively slow due to the complex arithmeticSuitable for systems that require anonymity features256 bytesCan be in kilobytes
[67]ECDLREP functionModerate complexityEfficient due to the properties of elliptic curvesSuitable for systems where performance and compact signatures are required32 bytes64 bytes
[72]URS (SPS signatures)Moderate to high (depends on specific construction)Efficient in protocols that need to maintain structure of the message
(ZKP)
Used in advanced systems where preserving message is crucial32 bytesCan be in kilobytes
[68]Edwards curveLow in context of other elliptic curves due to the simpler formulasFaster calculation and better securityCommonly used in systems like EdDSA32 bytes64 bytes
[70]BLS signatureHigh due to the use of pairing based cryptographySignature generation is slower, verification can be fast and aggregation can be done effectivelyParticularly useful where aggregation of signatures is needed48 bytes96 bytes
[71]BBS+ signatureHigh due to the use of pairing based cryptographySimilar to BLS, but with more flexible signatures and message managementSuitable for multi-message systems96 bytes112 bytes
[74]Aggregate signatures with randomizable tagsHigh due to integration of randomizable tagsEfficient in scenarios where aggregation and randomization are needed simultaneouslySuitable for systems where reusability of signatures without linkability is needed32 bytesCan be in kilobytes
[79]Redactable signaturesHigh due to the modifying or redacting of signaturesTypically slower due to the additional data management requirements.Ideal for systems where document integrity is important, especially with authorized edits.32 bytesCan be in kilobytes
[77]Unlinkable redactable signature schemesVery high due to the combination of unlinkability with redactionMore complex and slowerIdeal for highly sensitive environments redaction2048 bitsCan be in kilobytes
[75]Tag-based aggregatable mercurial signaturesExtremely high with the combination of mercurial signatures and tag aggregationSlowerSuited for systems with complex workflows2048 bytes5056 bytes
a

Depends on the chosen primitive.


ハッシュ方式の概要

Table 4. Overview of hash-based methods.

ArticleAlgorithmComplexityPerformanceSuitabilityStatic/DynamicSize/Overhead
[54]
[55]
[61]
[57]
Hash commitmentsGenerally low because it involves one hashing operation per attribute
Depends on size of credential and on hashing function used
Fast processing and verificationStatic datasets where integrity is more important than confidentiality or structured proofs.Static dataSimple proofs
Large in size
All hashes or disclosed messages are sent
[56]Polynomial commitmentHigher than regular commitments Depends on selected polynomialsSlower due to the mathematical operations required for committing and verifying attributesIdeal for applications that require structured proof (ZKP systems)Static dataComplex proofs with higher computation costs
Disclosed data + calculated commitment are shared
[50]
[52]
HMAC (keyed-hash message authentication code)Low because it is similar to hash commitments
Requires key management
Efficient but slower than regular hash due to the key-based operationsUseful for authentication in insecure environments
Ensures data integrity and authenticity
Static dataSimple proofs Large in size
Added overhead due to key management
[62]Merkle treeBuilding O(n) Updates or proofs O(log n)Efficient for large datasets Allows partial verificationUseful for application where efficient, incremental updates and verifications are neededDynamic dataProof size grows slower than the dataset
𝑂(log𝑛)
[64]Merkle B-tree with ECHigher than standard Merkle tree due to multiple child nodes and added overhead of ECEC can increase tree construction and update time
Faster access for non-sequential data operations
Useful for systems where updates are frequent and there is a requirement for securityDynamic dataProof size grows slower than the dataset
𝑂(log𝑛)
[63]Merkle B-tree with encryptionSimilar to standard Merkle Tree with added overhead of encryption (complexity depends on algorithm)Encrypting can increase time for tree construction, update and verificationUseful for systems where enhanced privacy is neededDynamic dataProof size grows slower than the dataset
𝑂(log𝑛)



いやぁ、ものすごく参考になりますね。





2024年7月14日日曜日

選択的開示に関するReview論文を読む

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

サラエボ大学、マリボル大学の研究者の方々が書かれた選択的開示に関するReview論文が発行されているので読んでいます。

論文中の選択的情報開示の概念の説明図より



Selective disclosure in digital credentials: A review

Digital credentials represent digital versions of physical credentials. They are the cornerstone of digital identity on the Internet. In order to enhance privacy, different authors implement selective disclosure in digital credentials, allowing users to disclose only the claims or attributes they want. This paper gives an overview of the most influential articles for selective disclosure, a chronology of the evolution of the methods, and a list of strategies and approaches to the problem. We identify the categories of approaches and their advantages and disadvantages. In addition, we recognize research gaps and open challenges and provide potential future directions.

デジタル証明書は、物理的な証明書のデジタル版です。これらは、インターネット上のデジタルIDの基盤です。プライバシーを強化するために、さまざまな著者がデジタル証明書に選択的開示を導入し、ユーザーが開示したいクレームや属性のみを公開できるようにしています。本論文では、選択的開示に関する最も影響力のある論文の概要、手法の進化に関する年表、およびこの問題に対する戦略とアプローチの一覧を示します。また、アプローチのカテゴリーとその利点と欠点を特定します。さらに、研究におけるギャップや未解決の問題点を認識し、今後の方向性についても提案する。 


選択的開示(Selective Disclosure)がメインテーマではありますが、デジタルクレデンシャルそのものについても突っ込んだ言及がされていて面白いです。

Intro部分から飛ばしていて面白いです。

Unfortunately, this term is still used confusingly in different fields of computer science, computer security and cryptography because it is still evolving. A simple password is sometimes considered a digital credential; other times, a signed certificate is a digital credential.

 残念ながら、この用語はコンピュータサイエンス、コンピュータセキュリティ、暗号化のさまざまな分野において、まだ発展途上であるため、依然として混乱を招くように使用されています。単純なパスワードがデジタル認証と見なされることもあれば、署名付き証明書がデジタル認証と見なされることもあります。

クレデンシャルという言葉は確かにまだまだ混乱していますねぇ。

なお、本論文の中では、
  • 選択的情報開示の形態と種類、実現方法
  • デジタルクレデンシャルの種類による採用される方法の違い
  • ゼロ知識証明の利用の有無
  • ブロックチェーンの利用の有無
について論じています。

その前に、前提知識のセクションではこれまでの歴史や用語の解説がされているので、この部分だけでは読む価値は大いにありますので、この部分にフォーカスしていこうと思います。

ポイントはこのようなところかと思います。しかしU-ProveとIdemixとか懐かしい。
  • ブラインド署名プロトコル(David Chaumが1983年に発表、1985年に理論を実装)の発明がこの分野における第一歩であった
  • このプロトコルによりユーザは匿名性を維持しながら証明書の所有を証明したり、欲しい情報を開示することができる
  • この理論をベースにリンカビリティに焦点を当てたのがIvan Bjerre DamgardとStefan Brandsであり、後にMicrosoftが買収するU-Proveの基礎となるBrandsブラインド署名となった(秘密鍵証明書スキームを盛り込んで理論化した)
  • CamenishとLysyanskayaは匿名クレデンシャルためのプロトコル(CL署名)を発表した。その論文の中では匿名クレデンシャルの特徴として以下を定義、達成した
    • 匿名性:各ユーザはシステム内で匿名である
    • 追跡不可能性:ユーザによるクレデンシャルの利用を追跡できない
    • 偽造不可能性:クレデンシャルの偽造ができない
    • リンク不可能性:同じクレデンシャルを複数回利用することによってリンク可能になってはならない
  • 他にも追加の特徴として以下を挙げた
    • 譲渡不可
    • 選択的開示
    • 取り消し
    • 悪意あるユーザの識別
  • これらのスキームはIBMのIdentity Mixer(Idemix)の基本的な構造となっている
  • Dan Boneh、Ben Lynn、Hovav Shachamはバイリニア対と楕円曲線で構築されたグループ署名であるBLS署名を開発し、C. Gentryとともに複数のメッセージに対して複数の公開鍵で生成された複数の署名を1つの署名に集約するソリューションを提案した。この署名形式はイーサリアム・ブロックチェーンで採用されている
  • Dan Boneh、Xavier Boyen、Hovav Shachamはその後も匿名クレデンシャルの研究を続け、ペアリング・ベースの楕円曲線暗号をベースに構築されるグループ署名(BBS署名)を開発した。これはその後の改良を経てBBS+署名スキームと呼ばれている
  • その後、これらの理論はU-ProveやIdemixにより実装が進み進化していく
  • U-ProveはStefan Brandsが設計したブラインド署名をベースに実装され、Brandsによって設立されたCredentica社によって開発が進んだが、2008年にMicrosoftに買収される(Microsoftに買収された後、Preview版をもらって検証していたころが懐かしいです)
  • 一方でIBMのIdemixは2002年に発表されたCL署名スキームに基づく匿名クレデンシャルシステムである
  • U-ProveもIdemixもEUの資金提供を受けたABC4Trust(Attribute Based Credential for Trust)2010-2015に繋がった
  • このプロジェクトは異なるプライバシーABCシステムをフェデレーションして相互接続することを目的としており、ABCシステムの特徴は以下の通り定義された
    • プライバシーABCはエンティティに関する追加情報を開示することなくエンティティに関する異なる属性を選択的に認証する
    • プライバシーABCは保有者が必要最低限の情報を公開し証明することが可能である
  • これらの特徴をU-ProveおよびIdemixにより実現されたが、これ以外にも離散対数コミットメントを用いたHM12スキームや、オープンソースのYiviアプリ(IRMA/I Reveal My Attributes)も登場した(YiviアプリはIdemix ABCスキームに基づいている)
  • ブロックチェーン技術に進歩に伴い、Linux FoundationはHyperledgerを設立、IBMとHyperledge Fabricプロジェクトを共同で設立し、Idemixをインポートした
  • EvernymとSovrin Foundationは自己主権型アイデンティティプラットフォームの構築を目指すプロジェクトをLinux Foundationの寄付し、Hyperledger Indyが誕生する
  • Hyperledger Indyにおける最初の匿名クレデンシャルの実装はCL署名に、次の実装はBBS+署名に基づいている
  • 一方でVerifiable CredentialsについてはBBS+署名、CL署名、ハッシュマークルツリー、SD-JWT、AnonCredsなど匿名化に向けたいくつかのソリューションが提案されている状態である

ここまで読んだだけでもすごい情報量ですね。
非常に面白く読ませてもらっています。

続きはまた。