Decoded 2023で寄せられた質問への回答
参加者から寄せられた質問
データはどこに保存されていますか？
ほとんどのデータはユーザーのデバイスにローカルに保存されます。アカウント関係（IDGraph）は信頼された実行環境に保存され、ID所有者の秘密鍵がそれを開くリクエストに含まれている場合にのみアクセスできます。現在、すべてのSGXノードはLitentryの管理下にあり、悪意のあるノードによる攻撃のリスクを最小限に抑えています。
VCはどこに保存されますか？
VC レジストリは、検証可能なクレデンシャル管理パレット（VCMP）上のオンチェーンかつパブリックなストレージであり、クレデンシャルを検証できるように VC インデックス <> VC ハッシュを維持します。VCMP には、VC インデックスと VC ハッシュからのマップのみが含まれ、VC コンテンツの妥当性をチェックするために使用されます。VCが生成されると、Parachain VCMPの外部関数vc_issuedが呼び出され（パラメータの1つは生成されたVCで、ユーザーのシールド鍵で暗号化されている。同時に、VCMPはVCレジストリに新しいレコードを挿入します。キーはvc_indexで、値はvc_contextです（これにはsubject、vc_hash、vc_statusが含まれる）。デフォルトのvc_statusはactiveです。
レジストリはVCのすべての内容を保存するわけではありません。むしろ、ユーザーのプライバシーを確実に保護するために、 VCのインデックスとコンテキストだけを保存します。レジストリは、発行されたクレデンシャルのリストまたはディレクトリを管理します。レジストリには通常、VC サブジェクト（クレデンシャルが発行された個人）、VC ステータス（アク ティブ、失効、期限切れなど）、および VC ハッシュが含まれます。この情報にはベリファイアがアクセスでき、保持者が提示したクレデンシャルの真正性と妥当性を検証可能です。
ローカルに格納されるデータは？
ローカルがユーザのブラウザを指す場合、この例では主に、受信した VC、ID、およびシールド・キーのようなキャッシュされたデータです。
ローカルがローカルの Litentry を指す場合、ユーザ・シールド・キーと IDGraph は TEE 内に保存され、事前にプログラムされたロジック（enclave）だけがアクセスできます。VCは現在、イベントとしてパラチェインの履歴の一部であり、暗号化されています。
IDHubには何が保存されていますか？
IDHubは、ユーザーが本人確認プロセスを開始するためにLitentry Parachainに要求するチャレンジコードを保存します。
最悪のシナリオは？データ漏洩？ユーザーがアクセスできなくなること？
最悪のシナリオの1つは、TEEの設計に抜け穴があり、データが流出することにあります。ユーザーのアカウント関係が漏洩してしまうのです。このような事態を避けるために、私たちはいくつかの対策を実施しています。たとえば、TEEのバージョンを定期的かつタイムリーに更新したり、SGXを自社で運用したり、安全で拡張性のある他のプライバシーソリューションを積極的に探したりしています。
別のコンピューターから同じアカウントにログインしたい場合はどうすればよいですか？同じウォレットアドレスと同じパスワードを使いますが、生成されるVCは同じですか？
現時点では、一元化された同期サービスはありません。しかし、この制限は次回のメジャー・プロジェクトのアップデートで対処される予定です。次のアップデートでは、以下の機能が追加されます：
- ウォレットの秘密鍵を所有している限り、古いシールドキーを照会できます。
- インデクサの支援により、旧シールド鍵を使用して以前の検証可能な証明書（VC）をダウンロードすることができます。
独自のアサーションを作成できますか？
まだできませんが、積極的に取り組んでいます。チームは現在、クレデンシャルに使用されている現在のスキーマとは対照的に、アサーションを記述するために特別に設計された言語/スキーマを開発中です。この言語／スキーマにより、自己定義アサーションを信頼された実行環境（Trusted Execution Environment：TEE）で読み取り可能な形式に変換できるようになります。
さらに、新しいアサーションの組み込みをサポートする包括的なワークフローを確立しています。このワークフローは、新しいデータ・メトリクスの統合と利用可能なデータ・プロバイダの活用を包含して、新しいアサーションをシステムに組み込むためのシームレスなプロセスを保証します。
これらのVCはどこで役に立つのでしょうか。現在、パートナーはいますか？
パートナー向けのVCの使用例がいくつかあります：
- 暗号の経験とプロジェクトの貢献度に基づくオーディエンスの選択とセグメンテーション
- オーディエンスやコミュニティ参加者をセグメントするためのカスタム「プロフィール」と「スコア」の作成
- 信用スコアと担保不足の融資やその他の評判ベースの利点のための資格
NFT、dApps、その他のアプリへのプライベートかつセキュアなIDデータインジェクション - NFT、アクセス、その他のID特典のロックを解除するオンチェーン履歴書および認証情報
他のアイデンティティ・プロバイダが作成しているのと同じVCか？それらのVCは相互運用可能か？KILTのVCを読み取ることができるか？
現時点では、VCの検証は手動でしか行えませんが、誰でも独自にVCを検証できる包括的なソリューションの開発に積極的に取り組んでいます。このソリューションは、検証プロセスを合理化し、VCの相互運用性を確保することを目的としています。このソリューションが利用可能になるまでは、VCは完全には相互運用できないかもしれません。
私が作成している（polkadot decodedに参加している）VCはpoapのように感じます。何が違うのでしょうか？
ひとつの違いは、実装の柔軟性にあります。POAPのNFTに比べ、VCとそのW3Cデータモデルは非常に汎用的です。オンチェーン・データ、オフチェーン・データ、その他を含むさまざまなタイプのデータのコンテナとして考えることができます。VCの実装は非常に柔軟で、インターフェースやプリセットのAPIに従う必要はなく、独自のAPIを記述するだけでよくなります。
その上、VCの保有者はどのVCを提示するか、あるいはVCの一部だけを提示するかを簡単に選択できるため、VCはプライバシーをよりきめ細かく制御することができます。例えば、ある大学の学士号を証明するVCの保有者は、VCから部分的な情報を抽出し、どの大学に進学したかを開示することなく卒業を証明することができます。POAPはデフォルトではこの機能を持っていないが、ゼロ知識証明を利用することで、同様のプライバシー向上効果を達成できる可能性があります。
TEEはどこにあるのか？物理的？VM？
TEEデバイスはベアメタルで、TEEはSGXノードのセキュアなエリアにあります。2015年秋からSkylake Intel CPUに搭載された新しい命令セットであるIntel SGX（Software Guard Extension）を使用しています。サイドチェーンのすべてのノードがSGXをサポートしている必要があります。
TEEの信頼性という点では何に依存していますか？依存関係とは何ですか？
SGXが提供する保護メカニズムについて議論する際には、インテルが信頼できるサードパーティとして機能するという前提を認めることが極めて重要です。現時点では、ハードウェアにバックドアの可能性はなく、インテルはリモート認証プロセスにおいて誠実で妥協のない参加者として動作するという仮定の下で運用されています。
IDHubからサードパーティパートナー（dApp）へのVCの受け渡しの安全性は？
IDHubから生成された検証可能なクレデンシャル（VC）をサードパーティと共有するには、現在、ユーザーはIDHubからVCをダウンロードし、その後、好みのサードパーティサービスプロバイダにアップロードする必要があります。現在のところ、第三者間でVCを直接転送する方法はありません。
自分のブランドに合わせてページをカスタマイズすることはできますか？- ユーザーを外部のプラットフォームに送りたくないのですが。
まだできませんが、私たちのチームは、より多くのカスタマイズを可能にするために、この方向に向かって取り組んでいます。
0Authとの関係は？
OAuthは、ソーシャルメディアのログイン認証情報のようなアイデンティティの所有権を検証し、その検証に基づいて他のサービスへのアクセスを許可するための一元的な方法として機能します。
将来的には、Twitterアカウントで公開することなく、OAuthを利用してTwitterの本人確認を行うことを検討する可能性があります。しかし、私たちが開発している分散型プロトコルは、OAuthと概念的な類似点しか共有していないことに注意することが重要です。技術的な観点からは、両者は大きく異なります。これらの類似点は主に、様々なリソースへのアクセスを許可するために使用できる検証可能なクレデンシャル（VC）を通して、発言を証明することに関係しています。私たちの分散型プロトコルのユースケースは、この特定のシナリオを超えて広がっていることを強調する価値があります。
なぜNovaウォレットで何もしていないのですか？
VCをNovaウォレットに統合することは間違いなく可能です。実際、私たちにはこの分野に精通した専門グループがあり、将来的なコラボレーションのための貴重なリソースとなるでしょう。
KILTとの違いは何ですか？
KILTは分散型クレデンシャルを発行・検証するためのプロトコルであり、Litentryは分散型IDアグリゲータで、ユーザーが複数のネットワークにまたがってIDをリンク・管理できるようにするものです。
私たちはどちらもクレデンシャルの発行と検証を含むアイデンティティ・ソリューションを提供していますが、Litentryは、サービス・プロバイダーがプライバシーを保護した方法でターゲット・オーディエンスを見つけるのに役立つスコア・コンピューティングのベースとして、クレデンシャルを活用することに重点を置いています。Litentryでは、IDグラフの保存とIDデータの集約プロセス全体は、LitentryネットワークのTEEサイドチェーンによって実装され、ユーザーのプライバシーを強化します。
Litentry ParachainはスマートコントラクトPalletを実行していますか？
まだですが、これに向けて研究を進めています。
Decodedの皆さん、示唆に富む質問をありがとうございました！貴重な洞察を集め、Litentryに関連する様々なトピックを取り上げる素晴らしい機会となりました。
Litentryは今後も進化を続け、新たな道を模索していきますが、自己主権的でプライバシーを保護するアイデンティティ・ソリューションで個人をエンパワーするというビジョンに全力を注いでいきます。Litentryのエコシステムにおける今後のアップデートとエキサイティングな進歩にご期待ください！
Litentryについて
Litentryは、複数のネットワークにまたがるユーザーIDの連携を可能にする分散型IDアグリゲーターです。DIDインデックスプロトコルとSubstrateが構築した、分散型DID検証ブロックチェーンを特徴とします。分散型で相互運用可能なIDアグリゲーションサービスを提供し、DIDメカニズムの複雑さを軽減して利便性を向上させます。Litentryは、ユーザーが自身のIDを管理し、使用するdAppsが、異なるブロックチェーン間でユーザーのDIDデータをリアルタイムに取得するための安全な手段を提供します。
Litentryの各リンクをフォローして最新情報を入手しましょう！
