XRP LedgerのVerifiable Credentials機能
はじめに
この記事はXLS-70: Credentialsを紹介するものです。
オンチェーン認証情報
概要
XRPL DID(Digital Identifier) Amendment(XLS-40)は、ユーザがXRP Ledger上でデジタルIDを管理できるようにします。このAmendmentはオンチェーンのID管理をサポートし、オフチェーンの資格情報の使用を簡素化します。しかし、資格情報処理においてブロックチェーン技術の潜在能力を最大限に引き出すためには、オンチェーンのソリューションが必要です。
このドキュメントは、このギャップを埋めるための設計を提案します。XRP Ledger上での資格情報の発行、保存、検証を直接行う方法を概説し、ユーザのプライバシーのニーズもサポートします。
オンチェーンの認証は、XRPLエコシステム内のさまざまなプロセスを効率化できます。たとえば、金融機関はXRP Ledger上で認証を発行し、ユーザの身元とコンプライアンスを証明できます。これにより、異なるプラットフォーム間での繰り返しのKYC (Know Your Customer)が不要になり、よりスムーズなユーザ体験が促進されます。安全な認証管理を可能にすることで、この提案はXRPLエコシステム内での信頼に基づくアプリケーションの新たな波の可能性を解き放ちます。
1. 概要
この設計では、Credentialの作成、受け入れ、および削除をサポートします。また、既存のDeposit Authorization機能を拡張し、アカウントが特定のアカウントを許可リストに追加するだけでなく、特定の認証を持つアカウントも許可リストに追加できるようにします。
この提案は、直接支払いなど、Deposit Authorizationがサポートする領域に限定してサポートします。しかし、将来の提案では、AMMやレンディングプールなど、XRPLの他の部分での資格ゲーティングのサポートを追加することができます。
次の提案を行います。
- レジャーオブジェクト
Credentialの作成 - トランザクションタイプ
CredentialCreateの作成 - トランザクションタイプ
CredentialAcceptの作成 - トランザクションタイプ
CredentialDeleteの作成 - レジャーオブジェクト
DepositPreauthの変更 - トランザクションタイプ
DepositPreauthの変更 - Deposit Authorizationが影響を受ける他のトランザクションの変更
この機能には、Credentials Amendmentが必要です。
1.1. 背景: DIDと検証可能な資格情報 (Verifiable Credentials, VC)
検証可能な資格情報(Verifiable Credentials)(VC)は、W3C仕様によって定義されており、個人、組織、またはIoTデバイスなどの主体に関する情報を表現するための安全で改ざん防止の方法です。これらの資格情報は信頼できる主体によって発行され、発行者を直接関与させることなく、第三者によって検証されることができます。
DID(分散型ID)とVCの関係をより明確に理解するために、次の例を考えてみてください。DIDは、指紋や人の写真(その物理的特徴)に似た、エンティティの一意な識別子として機能します。それに対して、VCはそのDIDに関連付けられた検証可能な情報の一部として機能し、運転免許証やパスポートのようなものです。第三者がアイデンティティの主張を検証する必要がある場合、彼らはエンティティが提示したVCを調べ、それが対応するDIDと一致していることを確認できます(たとえば、運転免許証の写真と、それが本来属する人の物理的特徴を比較することのように)。
1.2. 用語
- 資格情報(Credential): 発行者によって行われた1つ以上の主張の表現。例えば、パスポートは、ある人が特定の国の住民であるという主張の表現です。
- 発行者(Issuer): 資格情報を作成(発行)するアカウント(発行元アカウント)。例えば、パスポートは国の政府によって発行されます。
- 対象(Subject): 資格情報が発行されるアカウント(発行先アカウント)。例えば、パスポートは特定の人に対して発行されます。
- 許可リスト(Allowlist): 特定のアクションを行うことが許可されているアカウントのリスト、または(動詞として使用される場合)そのリストにアカウントを追加する行為。
- 事前承認(Preauthorization): 基本的には許可リストと同じ。
注: これらの定義は、W3C検証可能な資格情報仕様に記載されている定義と直接一致しません。これらの用語は、この仕様の文脈でやや異なる方法で使用されます。
1.3. 基本フロー
この例のシナリオには、異なる役割を持つ三者が登場します。
- Verityは、法的遵守を確保するために、適切にKYCされたアカウントとだけやり取りしたい規制された事業者です。これにより、Verityは、どのアカウントが彼らとやり取りすることが許可されているか(承認されたか)を設定するため、承認者 または 検証者 となります。
- Isabelは、アカウントを審査し、アカウントが自分たちが主張する通りであることを証明する資格情報をオンチェーンで発行する資格情報発行者です。
- Aliceは、Verityとやり取りしたいユーザです。
このシナリオにおける認可フローは次のように機能します：
- Verityは、認可されたアカウントのみが彼女のアカウントとやり取りできるように設定します。彼女は、Isabelがアカウントを適切に審査し、それを証明する資格情報を発行することを信頼しているため、Isabelが発行した資格情報を受け入れるようにアカウントを設定します。
- Aliceは、Isabelにオフチェーンで内密にKYCドキュメントを提出します。
- IsabelはAliceの書類を審査し、Aliceの信頼性を証明する資格情報をオンチェーンで作成します。
- Aliceはその資格情報を受け入れ、有効にします。
- Aliceは今、Verityとやり取りしたり、資金を送ったりすることが可能になります。
重要なこととして、AliceがIsabelに送るKYCドキュメントには、Aliceの身元を確認するために必要な個人を特定できる情報やプライベート情報が含まれる可能性がありますが、この情報は決して公開されず、オンチェーンに保存されることもなく、Verityはそれを確認する必要がありません。また、Isabelを信頼する他の事業者は同じ資格情報を受け入れることができるため、Aliceは関わりたい全ての相手に対して繰り返し再確認する必要はありません。
2. レジャーオブジェクト: Credential
このレジャーオブジェクトは、資格情報のオンチェーン表現です。
このオブジェクトは、受け入れた対象者に応じて発行者または資格情報の対象者のいずれかの所有者準備金を1つ使用します。
Credentialオブジェクトは、SubjectとIssuerの所有者ディレクトリの両方に存在します(トラストラインやエスクローに似ています)。
2.1. フィールド
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
LedgerEntryType |
✔️ | 文字列 |
UInt16 |
レジャーオブジェクトのタイプ(Credential)。 |
Flags |
✔️ | 数値 |
UInt32 |
このオブジェクトに関連するフラグ値。 |
Subject |
✔️ | 文字列 |
AccountID |
資格情報が対象とするアカウント。 |
Issuer |
✔️ | 文字列 |
AccountID |
資格情報の発行者。 |
CredentialType |
✔️ | 文字列 |
Blob |
発行者からの資格情報のタイプを識別するための(16進エンコードされた)値。このフィールドは最大64バイトの長さに制限されています。 |
Expiration |
数値 |
UInt32 |
任意の資格情報の有効期限。 | |
URI |
文字列 |
Blob |
資格情報に関する追加データ(VCドキュメントへのリンクなど)。このフィールドは有効性のチェックを行わず、最大256バイトの長さに制限されています。 | |
SubjectNode |
✔️ | 文字列 |
UInt64 |
ディレクトリが複数ページで構成されている場合、このオブジェクトにリンクする対象の所有者ディレクトリのどのページを示すヒント。 |
IssuerNode |
✔️ | 文字列 |
UInt64 |
ディレクトリが複数ページで構成されている場合、このオブジェクトにリンクする発行者の所有者ディレクトリのどのページを示すヒント。 |
PreviousTxnID |
✔️ | 文字列 |
Hash256 |
このオブジェクトを最も最近変更したトランザクションの識別ハッシュ。 |
PreviousTxnLgrSeq |
✔️ | 数値 |
UInt32 |
このオブジェクトを最も最近変更したトランザクションを含むレジャーのインデックス。 |
2.1.1. オブジェクトID
このオブジェクトのIDは、Subject、Issuer、およびCredentialTypeフィールドを組み合わせ、Credentialオブジェクトのためのユニークなスペースキーと組み合わせたハッシュになります。
- Credentialのスペースキー (0x44)
- 対象者のAccount ID, Subject
- 発行者のAccount ID, Issuer
- 資格情報のタイプ, CredentialType
2.1.2. Flags
| フラグ名 | フラグ値 |
|---|---|
lsfAccepted |
0x00010000 |
lsfAcceptedフラグは、資格情報の対象が資格情報を受け入れたかどうかを示します。このフラグが無効になっている場合、発行者がこのレジャーエントリの準備金に責任を負います。フラグが有効になっている場合、代わりに資格情報の対象が準備金の責任を負います。このフラグはデフォルトで無効ですが、CredentialAcceptトランザクションの成功後に有効になります。
資格情報は、受け入れられるまで「有効」とみなされるべきではありません。
2.1.3. CredentialType
この値は、NFToken機能のTaxonに似ており、その値の意味は発行者によって決定されます。VCのクレームと同じである可能性がありますが、そのようなクレームのサブセットを表すこともできます。
最大長は64バイトであり、空の文字列であってはなりません。
2.2. アカウント削除
Credentialオブジェクトは削除ブロッカーではありません。
言い換えれば、SubjectまたはIssuerが自分のアカウントを削除すると、Credentialオブジェクトは自動的に削除されます(アカウントの削除を防ぐことはありません)。
3. トランザクション: CredentialCreate
このトランザクションはCredentialオブジェクトを作成します。発行者によって送信される必要があります。
3.1. フィールド
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
TransactionType |
✔️ | 文字列 |
UInt16 |
トランザクションタイプ(CredentialCreate)。 |
Account |
✔️ | 文字列 |
AccountID |
資格情報の発行者。 |
Subject |
✔️ | 文字列 |
AccountID |
資格情報の対象者。 |
CredentialType |
✔️ | 文字列 |
Blob |
発行者から資格情報のタイプを識別するための(16進数エンコードされた)値。 |
Expiration |
数値 |
UInt32 |
オプションの資格情報の有効期限。 | |
URI |
文字列 |
Blob |
資格情報に関する追加データ(VCドキュメントへのリンクなど)。 |
3.2. 失敗条件
-
Subjectのアカウントが存在しない。 -
Expirationの時間が過去となっている。 -
URIフィールドが空であるか、長すぎる(制限256バイト)。 -
CredentialTypeフィールドが空であるか、長すぎる(制限64バイト)。 - アカウントにオブジェクト所有するための十分な準備金がない。
- 同じ
Subject、Issuer、およびCredentialTypeを持つ重複した資格情報がすでに存在している。
3.3. トランザクションの変更
トランザクションが成功した場合
-
Credentialオブジェクトが作成されます。 -
Subject===Accountの場合(つまり、主体と発行者が同じアカウントである場合)、lsfAcceptedフラグが有効になります。
4. トランザクション: CredentialAccept
このトランザクションは、Accountに発行された資格情報を受け入れます(つまり、AccountがCredentialオブジェクトのSubjectです)。資格情報は、転送/受け入れられるまで有効とは見なされません。
4.1. フィールド
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
TransactionType |
✔️ | 文字列 |
UInt16 |
トランザクションタイプ(CredentialAccept)。 |
Account |
✔️ | 文字列 |
AccountID |
資格情報の対象。 |
Issuer |
✔️ | 文字列 |
AccountID |
資格情報の発行者。 |
CredentialType |
✔️ | 文字列 |
Blob |
発行者からのクレデンシャルの種類を識別するための（16進数でエンコードされた）値。 |
4.2. 失敗条件
-
Issuerのアカウントが存在しない。 - トランザクションのフィールドで説明されている有効な資格情報がない。
- 資格情報はすでに受け入れられている。
-
Accountにオブジェクトのための十分な準備金がない。 - 資格情報はすでに期限切れである。
4.3. 状態変更
トランザクションが成功した場合
-
Subject===Accountの場合(つまり、主体と発行者が同じアカウントである場合)、lsfAcceptedフラグが有効になります。 - 資格情報の
lsfAcceptedフラグがオンになります。 -
Credentialオブジェクトの準備金の負担は、発行者から対象者に移されます。
もしCredentialが期限切れであれば、そのオブジェクトは削除されます。
5. トランザクション: CredentialDelete
このトランザクションはCredentialオブジェクトを削除します。
次の者によって実行できます。
- 発行者(いつでも)。
- アカウント(いつでも)。
- 誰でも(有効期限が切れた後)。
Credentialを削除するということは、資格情報が受け入れられなくなることを意味します。
5.1. フィールド
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
TransactionType |
✔️ | 文字列 |
UInt16 |
トランザクションタイプ(CredentialDelete)。 |
Account |
✔️ | 文字列 |
AccountID |
トランザクションの提出者。 |
Subject |
文字列 |
AccountID |
資格情報の対象者。省略された場合、Accountが対象とみなされます。 |
|
Issuer |
文字列 |
AccountID |
資格情報の発行者。省略された場合、Accountが発行者とみなされます。 |
|
CredentialType |
✔️ | 文字列 |
Blob |
発行者からのクレデンシャルの種類を識別するための（16進数でエンコードされた）値。 |
注: アカウントが自分自身に発行した資格情報を削除する場合、SubjectまたはIssuerのいずれかのみを指定できますが、少なくとも1つは指定する必要があります。
5.2. 失敗条件
-
SubjectもIssuerも指定されていない。 -
Subject、Issuer、およびCredentialTypeフィールドで説明されている資格情報が存在しない。 -
Accountは発行者または対象者ではなく、有効期限も過ぎていない。
5.3. 状態の変更
トランザクションが成功した場合
-
Credentialオブジェクトは削除されます(両方の所有者ディレクトリから)。
6. レジャーオブジェクト: DepositPreauth
DepositPreauthオブジェクトは、1つのアカウントから別のアカウントへの事前承認を追跡します。このオブジェクトはすでにXRPL上に存在しますが、資格情報の事前承認もサポートするためにこの仕様の一部として拡張されています。
6.1. フィールド
参考までに、こちらがDepositPreauthオブジェクトの既存のフィールドです。
DepositPreauthオブジェクトの既存のフィールド
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
Account |
✔️ | 文字列 |
AccountID |
事前承認を与えたアカウント(事前承認された支払いの宛先)。 |
Authorize |
✔️ | 文字列 |
AccountID |
事前承認を受けたアカウント(事前承認された支払いの送信者)。 |
LedgerEntryType |
✔️ | 文字列 |
UInt16 |
値0x0070は、文字列"DepositPreauth"にマッピングされており、これはDepositPreauthオブジェクトであることを示します。 |
OwnerNode |
✔️ | 文字列 |
UInt64 |
このオブジェクトにリンクする送信者の所有者ディレクトリがどのページかを示すヒント。(ディレクトリが複数のページで構成されている場合。)注意: オブジェクトはそれを含む所有者ディレクトリへの直接リンクを含んでいません。なぜなら、その値はAccount.PreviousTxnIDから導き出すことができるからです。 |
PreviousTxnID |
✔️ | 文字列 |
Hash256 |
このオブジェクトを最も最近変更したトランザクションの識別ハッシュ。 |
PreviousTxnLgrSeq |
✔️ | 数値 |
UInt32 |
このオブジェクトを最も最近変更したトランザクションを含むレジャーのインデックス。 |
次の変更を行います。
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
Authorize |
文字列 |
AccountID |
このフィールドはすでに存在しますが、任意フィールドとなります。 | |
AuthorizeCredentials |
配列 |
STArray |
事前承認を受けた資格情報。(これらの資格情報を持つ任意のアカウントが事前承認された支払いを送信できます)。 |
有効なDepositPreauthオブジェクトは、AuthorizeフィールドまたはAuthorizeCredentialsフィールドの いずれか一方 を持っている必要があります。
6.1.1. オブジェクトID
このオブジェクトのIDは、AccountとAuthorizeフィールドのハッシュ(現在のように)か、AccountとAuthorizeCredentialsフィールドの内容を組み合わせたハッシュ、さらにDepositPreauthオブジェクトのユニークなスペースキーになります。このユニークなスペースキーは、アカウントベースのDepositPreauthオブジェクトと資格情報ベースのDepositPreauthオブジェクトで異なり、ハッシュ衝突の可能性を避けるためのものです。
- DepositPreauthのスペースキー (0x70)
- 認可元(事前承認支払の宛先)のAccount ID, Account
- 認可先(事前承認支払の送金元)のAccount ID, Authorize
- 資格情報のタイプ, CredentialType
または
- DepositPreauthCredentialのスペースキー (0x50)
- 認可元(事前承認支払の宛先)のAccount ID, Account
- AuthorizeCredentialsのハッシュ(
[hash(Issuer,URI), ...])
6.1.2. AuthorizeCredentials
このフィールドは、内部オブジェクトの配列です。これらの内部オブジェクトの内容が、受け入れられる資格情報を決定します。
リストに複数の資格情報が含まれている場合、それらの資格情報はすべて含める必要があります(実質的にAND条件で結合されます)。
資格情報のリストの最小サイズは1、最大サイズは8つです。
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
Issuer |
✔️ | 文字列 |
AccountID |
資格情報の発行者。 |
CredentialType |
✔️ | 文字列 |
Blob |
発行者からのクレデンシャルの種類を識別するための（16進数でエンコードされた）値。 |
7. トランザクション: DepositPreauth
このトランザクションは現在、DepositPreauthオブジェクトを作成および削除し、アカウントのホワイトリスト登録およびホワイトリスト解除を行います。
この仕様は、その機能を拡張して、資格情報のホワイトリスト登録およびホワイトリスト解除もサポートします。
7.1. フィールド
参考として、こちらにDepositPreauthトランザクションの既存のフィールドがあります:
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
Authorize |
文字列 |
AccountID |
送信者の事前承認を行うためのXRP Ledgerアドレス。 | |
Unauthorize |
文字列 |
AccountID |
事前承認を取り消すべき送信者のXRP Ledgerアドレス。 |
次の2つの新しいフィールドを追加します。
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
AuthorizeCredentials |
配列 |
STArray |
事前承認する資格情報。 | |
UnauthorizeCredentials |
配列 |
STArray |
事前承認を取り消すべき資格情報。 |
Authorize、Unauthorize、AuthorizeCredentials、およびUnauthorizeCredentialsのいずれか一つを含める必要があります。
7.1.1. AuthorizeCredentialsとUnauthorizeCredentials
これらのフィールドは、DepositPreauthオブジェクトのAuthorizeCredentialsフィールドに関するセクション6.1.2で概説されたのと同じルールに従います。
7.2. 失敗条件
-
DepositPreauthの既存の失敗条件は引き続き遵守されます。 -
Authorize、Unauthorize、AuthorizeCredentials、およびUnauthorizeCredentialsのいずれかまたは複数が含まれている(つまり、これらのフィールドのうち正確に1つが含まれている必要があります)。 - 資格情報の承認(AuthorizeCredentials)/非承認(UnauthorizeCredentials)の場合：
- 資格情報の発行者が存在しない。
- 配列が長すぎる(つまり、8つを超える資格情報が存在)。
- 配列が空(つまり、資格情報がない)。
- 提供されたリストに重複がある。
- トランザクションに
UnauthorizeCredentialsが含まれており、資格情報が現在承認されていない。 - トランザクションに
AuthorizeCredentialsが含まれており、資格情報がすでに承認されている。 - アカウントがオブジェクトのための十分な準備金を保有していない。
7.3. 状態の変更
-
Subject===Accountの場合(つまり、対象者と発行者が同じアカウントである場合)、lsfAcceptedフラグが有効になります。 -
DepositPreauthオブジェクトが作成または削除されます。
DepositPreauthオブジェクトは、資格情報のソートされたリストを保存します。
8. Deposit Authorizationによって影響を受けるトランザクション
8.1. フィールド
このフィールドが追加されるトランザクションは次のとおりです。
PaymentEscrowFinishPaymentChannelClaimAccountDelete
| フィールド名 | 必須？ | JSONタイプ | 内部タイプ | 説明 |
|---|---|---|---|---|
CredentialIDs |
配列 |
Vector256 |
トランザクションに添付する資格情報。 |
8.2. 失敗条件
- 任意の
CredentialIDsにおいて- オブジェクトが存在しない。
-
Credentialオブジェクトではない。 - 期限切れの
Credentialオブジェクトである。 - 受け入れられていない。
- トランザクションを送信している
Accountに発行された資格情報ではない。
-
CredentialIDsのグループは、宛先によって承認されていない。 -
CredentialIDsのリストに重複がある。
Deposit Authが有効になっているアカウントで、最低アカウント準備金要件（現在10XRP）以下または同等の残高がある場合、XRPによる支払いを受け取れるように、Deposit Authの設計には例外的な仕組みがすでに組み込まれています。これは、送金できないばかりかXRPを受け取れない状態に「陥る」ことを防ぐためです。この例外は、認証情報では追加サポートされません。つまり、この条件を満たす支払いが事前承認のない認証情報とともに送信された場合、そのトランザクションは失敗します（ただし、認証情報を削除すれば成功します）。
注: 認証情報が多すぎると、トランザクションは依然として失敗します。正確なリストを提供する必要があります。
注: (期限切れでない)認証情報が含まれている場合、トランザクションは成功しますが、アカウントのDeposit Authが有効になりません。
8.3. 状態の変更
- 認証情報が無効な場合、トランザクションは失敗します。
- 認証情報が期限切れの場合、その認証情報は削除されます。
- トランザクションが事前承認されている場合(アカウントまたは認証情報を介して)、トランザクションは成功します。
9. RPC: deposit_authorized
deposit_authorized RPCメソッドはすでにXRPLに存在します。ここでは、認証情報の承認もサポートするためのいくつかの変更を提案しています。
9.1. リクエストフィールド
| フィールド名 | 必須? | JSONタイプ | 説明 |
|---|---|---|---|
source_account |
✔️ | 文字列 |
可能な支払いの送信者。 |
destination_account |
✔️ | 文字列 |
可能な支払いの受取人。 |
ledger_hash |
文字列 |
使用するレジャーバージョンの32バイトの16進数文字列。 | |
ledger_index |
文字列または数値
|
使用するレジャーのレジャーインデックス、またはレジャーを自動的に選択するためのショートカット文字列。 |
次のフィールドを追加します。
| フィールド名 | 必須? | JSONタイプ | 説明 |
|---|---|---|---|
credentials |
配列 |
CredentialオブジェクトのオブジェクトIDのリスト。このフィールドが含まれている場合、送信者が資金を宛先に送信できるかどうかを分析する際に、資格情報が考慮されます。 |
9.2. レスポンスフィールド
| フィールド名 | 常に存在？ | JSONタイプ | 説明 |
|---|---|---|---|
deposit_authorized |
✔️ | 真偽値 |
指定された送信元アカウントが宛先アカウントに直接支払いを送信することを許可されているかどうか。真の場合、宛先アカウントは入金承認を必要としないか、送信元アカウントは事前承認されています。 |
destination_account |
✔️ | 文字列 |
リクエストで指定された宛先アカウント。 |
source_account |
✔️ | 文字列 |
リクエストで指定された送信元アカウント。 |
ledger_hash |
文字列 |
このレスポンスを生成するために使用されたレジャーの識別ハッシュ。 | |
ledger_index |
数値 |
このレスポンスを生成するために使用されたレジャーバージョンのレジャーインデックス。 | |
ledger_current_index |
数値 |
このレスポンスを生成するために使用された現在進行中のレジャーバージョンのレジャーインデックス。 | |
validated |
真偽値 |
真の場合、情報は検証済みのレジャーバージョンから来ています。 |
次のフィールドを追加します。
| フィールド名 | 必須? | JSONタイプ | 説明 |
|---|---|---|---|
credentials |
配列 |
CredentialオブジェクトのオブジェクトIDのリスト。このフィールドが含まれている場合、送信者が資金を宛先に送信できるかどうかを分析する際に、資格情報が考慮されます。 |
10. W3C仕様への準拠
この提案は、W3Cの検証可能な資格情報(VC)仕様との相互運用性を優先します。XRPLベースの検証可能な資格情報の既存の検証フローは、主要な方法として残ります。
-
DID解決: 検証者はDID ID(例:
did:xrpl:r....)からDIDドキュメントにアクセスします。このドキュメントはアカウントのDIDオブジェクトに保存されています。 - VCアクセス: DIDドキュメントは関連する検証可能な資格情報へのリンクを提供します。
- VC検証: アクセス権に基づいて、検証者は取得したVCを表示および検証できます。
ただし、この提案は任意の拡張を導入します。Credentialオブジェクト内のURIフィールドはVCを指すこともできます。このポインタは完全に任意であり、DID解決を使用したコア検証プロセスがXRPL資格情報検証の主要な方法であることに注意することが重要です。
資格を持つ人は誰でも、W3C VC仕様への準拠を高めるためにDIDオブジェクトを持つことが推奨されます。
オンチェーンのCredentialの発行者はVCの発行者と同じである必要はなく、オンチェーンオブジェクトはVCの発行者からのオンチェーン証明として機能することができます。
11. 不変条件
11.1. 準備金
lsfAcceptedフラグがオフの場合、準備金の負担は発行者にあり、資格は発行者の所有者ディレクトリにあるべきです。lsfAcceptedフラグがオンの場合、準備金の負担は対象者にあり、資格は対象者の所有者ディレクトリにあるべきです。
11.2. DepositPreauthオブジェクト
DepositPreauthレジャーオブジェクトは、常にAuthorizeフィールドまたはAuthorizeCredentialsフィールドのいずれか一方を持っています。
AuthorizeCredentialsフィールドが含まれている場合、配列には1から8の資格情報が含まれます。
12. 例
この例では、信頼できる発行者であるIsabelが、AliceがKYC済みであることを示す資格情報を発行しています。Verityは、Isabelが適切にKYC済みであると証明したアカウントとのみやり取りするようにアカウントを設定しています。
読みやすさのために、署名や公開鍵などの一般的な取引フィールドの一部は、この例から省略されています。
12.1. CredentialCreate
Isabelは、AliceのKYCステータスをオフチェーンで確認した後、Aliceのために資格情報を作成します。
{
TransactionType: "CredentialCreate",
Account: "rISABEL......",
Subject: "rALICE.......",
CredentialType: "4B5943", // "KYC" in hex
Expiration: 789004799, // the end of the year
URI: "isabel.com/credentials/kyc/alice" // This will be converted into hex
}
12.2. Credential オブジェクト
これはCredentialCreateトランザクションによって作成されたオブジェクトです。
{
LedgerEntryType: "Credential",
Flags: 0,
Subject: "rALICE.......",
Issuer: "rISABEL......",
CredentialType: "4B5943", // "KYC" in hex
Expiration: 789004799, // the end of the year
URI: "isabel.com/credentials/kyc/alice" // This will be converted into hex
}
12.3. CredentialAccept
Aliceは資格情報を受け入れ、それによって有効にします。
{
TransactionType: "CredentialAccept",
Account: "rALICE.......",
Issuer: "rISABEL......",
CredentialType: "4B5943"
}
12.4. DepositPreauth
Verityは、IsabelがKYCを行ったアカウントとだけやり取りするようにアカウントを設定します。
{
TransactionType: "DepositPreauth",
Account: "rVERITY......",
AuthorizeCredentials: [
{
Credential: {
Issuer: "rISABEL......",
CredentialType: "4B5943"
}
}
]
}
12.5. 支払い
このトランザクションは成功します。AliceがIsabelからの承認された資格情報を添付しているためです。
{
TransactionType: "Payment",
Account: "rALICE......",
Destination: "rVERITY......",
Amount: "10000000",
CredentialIDs: ["DD40031C6C21164E7673...17D467CEEE9"]
}
このトランザクションは失敗します。AliceがIsabelからの承認された資格情報を添付していないためです。これは、IDなしで空港のセキュリティを通過しようとすることに似ています。
{
TransactionType: "Payment",
Account: "rALICE......",
Destination: "rVERITY......",
Amount: "10000000"
}
このトランザクションは失敗します。添付された資格情報がBobのものでないためです。
{
TransactionType: "Payment",
Account: "rBOB......",
Destination: "rVERITY......",
Amount: "10000000",
CredentialIDs: ["DD40031C6C21164E7673...17D467CEEE9"]
}
このトランザクションは失敗します。BobはIsabelから有効な資格情報を持っていないためです。
{
TransactionType: "Payment",
Account: "rBOB......",
Destination: "rVERITY......",
Amount: "10000000"
}
このトランザクションは失敗します。BobはDepositPreauthを設定していないためです。
{
TransactionType: "Payment",
Account: "rALICE......",
Destination: "rBOB......",
Amount: "10000000",
CredentialIDs: ["DD40031C6C21164E7673...17D467CEEE9"]
}
13. セキュリティ
13.1. 信頼の前提条件
発行者が有効な資格情報のみを発行し、正当な理由なしに資格情報を削除しないことを信頼する必要があります。
13.2. データプライバシー
プライベートデータはオンチェーンに保存する必要はありません(例：すべてのKYCデータ)。実際のVCはオフチェーンに保存できます。URIフィールドのリンクに保存される可能性があります。
付録
付録A: FAQ
A.1: デポジット承認機能でのみ資格情報を使用する必要がありますか？オフチェーンの目的にも使用できますか？
資格情報は、DepositPreauthのためだけでなく、任意の目的で使用できます。
A.2: VCに資格情報を使用する必要がありますか、それとも他のことに使用できますか？
資格情報は、任意の目的で使用できます。推奨されるユースケースはVCですが、他にもたくさんのユースケースがあります。
A.3: 特定の発行者-Taxonの組み合わせとtfTransferableフラグがオフの状態でNFTを代わりに使用しないのはなぜですか？
NFTを代わりに使用することは、特定の形式に従う必要があるため、あまりエレガントではありません。オフレジャーのユースケースにはより適しているでしょうが、オンレジャーのものではありません。さらに、NFTは異なるニーズに応えます。例えば、NFTには有効期限がありません。
A.4: 発行者は自分自身のために資格情報を発行できますか？
はい。
A.5: 発行者は資格情報が作成された後にその詳細を編集できますか？
いいえ、削除して再作成する必要があります。これは、ライセンスやパスポートが期限切れになった場合に新しいカードを取得する必要があるのと似ています。ただし、Subject、Issuer、およびCredentialTypeが同じであれば、オブジェクトは以前と同じIDを持ち続けます。
A.6: なぜトランザクションにCredentialIDsフィールドを含める必要があるのですか？XRPLは私が有効な資格情報を持っているかどうかを自動的に判断できるべきではないですか？
XRPLがアカウントが持っている資格情報のリストだけを反復処理する方法はありません。アカウントオブジェクトの全リストを反復処理することしかできません。これは無限のオブジェクトのリストです(数百万のオブジェクトになる可能性があります)。受け入れられた資格情報のリストだけでも理論的には数百万のオブジェクトの長さになる可能性があります。システムが全リストを反復処理しなければならない場合、深刻なパフォーマンスの問題を引き起こす可能性があります。
資格情報IDを含める方がはるかに速いです。それが有効な資格情報であることを確認するのは簡単で、承認された資格情報であることを確認することもできます。
A.7: 資格情報発行者は自分のアカウントを削除できますか？
はい、ただし、彼らが作成した資格情報は削除されます。
A.8: 資格情報発行者はオンチェーンアカウントを持つ必要がありますか？
はい。
A.9: 発行者が発行した資格情報のリストを取得するにはどうすればよいですか？
account_objects RPCは、アカウントが関与(SubjectおよびIssuerの両方)しているすべてのCredentialオブジェクトのリストを返します。アカウントが発行したものだけのリストを取得するには、そのリストからアカウント===IssuerとしてCredentialをフィルタリングしてください。
A.10: アカウントに対して発行された資格情報のリストを取得するにはどうすればよいですか？
account_objects RPCは、アカウントが関与(SubjectおよびIssuerの両方)しているすべてのCredentialオブジェクトのリストを返します。アカウントが発行されたものだけのリストを取得するには、そのリストからアカウント===SubjectとしてCredentialをフィルタリングしてください。
A.11: AuthorizeCredentialsに保存されている資格情報のリストを編集できますか？
いいえ、DepositPreauthオブジェクトを削除し、新しいリストで再作成する必要があります。
A.12: AuthorizeCredentialsの資格情報のリストは、必ずANDで結合する必要がありますか？それとも、ORリストとして使用できますか(つまり、すべてではなく資格情報の1つだけを提供する)？それとも、何らかの複雑な組み合わせですか？
いいえ。DepositPreauthオブジェクトを別々に配置することで、資格情報をORできます。パフォーマンスの理由から、すべての資格情報を持っている必要がある場合、資格情報の検索ははるかに簡単です。そうでなければ、リスト全体を検索しなければなりません。さらに、この機能を使用する必要がある人々は、オブジェクトの準備金コストが高すぎるとは思わないでしょう。
A.13: なぜCredentialCreateとCredentialDeleteは別々のトランザクションなのですか？
それらを別々の操作にする方が簡単で明確です。
Discussion