0040 XLS-40d: Decentralized Identity on XRPL

[aanchal4]

Updated spec: XLS-40 Decentralized Identity

An older version of the spec follows.

    
Title:        Decentralized Identity on XRP Ledger
Revision:     3 (2023-07-06)

Author: Aanchal Malhotra
Affiliation: Ripple

1. Abstract

Self-sovereign identity, defined as a lifetime portable digital identity that does not depend on any centralized authority, requires a new class of identifier that fulfills the following four requirements: persistence, global resolvability, cryptographic verifiability, and decentralization. World Wide Web Consortium (W3C) standardized Decentralized Identifiers (DIDs) are a new type of identifier that enable verifiable, self-sovereign digital identity and are designed to be compatible with any distributed ledger or network. In the context of digital identities, W3C's standards for DIDs and Verifiable Credentials (VCs) are rapidly gaining traction, especially in blockchain-related domains. In this document we propose to implement native support for W3C DIDs on XRP Ledger.

To this end, we specify the following on XRPL:

• A new DID method that describes:
  • The format for XRP ledger DID, and
  • Defines how XRP ledger DIDs are generated
• How to do CRUD operations on XRP ledger DIDs

This specification conforms to the requirements specified in the DID v1.0 specification currently recommended by the W3C Credentials Community Group.

2. Principles & Goals

2.1. Principles

This proposal chooses to recommend W3C DID identity standard to satisfy the following first principles:

• Decentralized: Requires no central issuing agency and functions effectively in Decentralized Finance.

• Persistent and Portable: Inherently persistent and long-lived, not requiring the continued operation of any underlying organization and portable between different applications.

• Cryptographically Verifiable: Based on cryptographic proofs rather than out-of-band trust.

• Universally Resolvable and Interoperable: Open to any solution that recognizes the common W3C DID standards and requires no one specific software vendor implementation.

2.2. Goals & Non-Goals

• This document aims to define DID identifier format for XRP ledger conformant to W3C DID standards that can be created and owned by any XRPL account holder, and specify definitions for DID methods to create, read, update and delete DID (data) that can be implemented by any service, wallet, or application.

• This proposal is NOT intended as a competing decentralized identity standard; it aims to leverage existing (and emerging) decentralized identity standard proposed by W3C.

• The proposal is motivated to enable individual users to create, and manage their decentralized identifiers while having complete control over the private keys and contents of the identity object.

3. New On-Ledger Objects and Transactions

We propose one new ledger object and two new transaction types.

• DID is a new ledger object that is unique to an XRPL account and may contain a reference to, or the hash of, or the W3C DID document itself associated with the corresponding DID.
• DIDSet is a new transaction type used to perform the following two operations:
  • Create the new ledger object DID with URI, and/or Data fields, thus adding the required reserve towards the account that initiated the transaction.
  • Update the mutable URI and Data fields of the DID object.
• DIDDelete is a new transaction type used to delete the DID object, thus reducing the reserve requirement towards the account that created the object.

4. XRPL Decentralized Identifier (DID) Specification

In this section we specify the implementation details of W3C DID standard that are specific to XRP Ledger.

4.1. The DID Object

We propose a new ledger object called DID that holds references to or data associated with a single DID. The DID object is created and updated using the DIDSet transaction and is deleted using the DIDDelete transaction.

4.1.1. Object Fields

DID object may have the following required and optional fields.

Field Name	Required?	JSON Type	Internal Type
LedgerEntryType	✔️	string	UINT16

Identifies the type of ledger object. The proposal recommends the value 0x0049 as the reserved entry type.

---

Field Name	Required?	JSON Type	Internal Type
URI		string	BLOB

Specifies a Universal Resource Identifier, a.k.a. URI that points to the corresponding DID document. This field could be an HTTP(S) URL or IPFS URI. The URI field is NOT checked for validity, but the field is limited to a maximum length of 256 bytes. This is a mutable field.

---

Field Name	Required?	JSON Type	Internal Type
Data		string	BLOB

Data specifies the arbitrary data associated with this object. The Data field is NOT checked for validity, but the field is limited to a maximum length of 256 bytes. e.g.

• It could contain the DID document itself (See Appendix for a sample DID document), or
• It could be the hash of the DID document in the location referenced by the URI field, or
• It could also contain the public attestations of identity credentials associated with the DID.

This is a mutable field.

Note:

• Either URI or Data field MUST be present to create and update the DID object.
• Both URI and Data fields MUST be absent to delete the DID object.

4.1.2. The DID Object ID Format

DID object may contain data associated with the XRPL account's identity. This requires the DID to be:

• Unique in the XRPL namespace, and
• Uniquely associated with the XRPL account.

We compute the DID object ID, a.k.a., DIDID as the SHA-512Half of the following values, concatenated in order:

• The DID space key (0x0049)
• The Account ID

4.1.3. Reserve Requirements

TBD

4.2. XRP Ledger DID Method Specification

In this section, we describe the DID method specification that conforms to the requirements specified in the DID specification currently published by the W3C Credentials Community Group. For more information about DIDs and DID method specifications, refer to the DID Primer.

4.2.1. XRP Ledger DID Scheme

The DID format as defined by W3C is as follows:

"did:" method-name ":" method-specific-idstring

We propose the following format for DIDs on XRPL:

"did:xrpl": network-id: xrpl-specific-idstring

The components specific to the XRPL network are the following:

• method-name: The "xrpl" namestring specifies that this is a DID for XRP Ledger.
  A DID that uses this method MUST begin with the following prefix: did:xrpl. Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix, is specified below.

• method-specific-idstring is formed by network-id and xrpl-specific-idstring

  • network-id: network-id is a chain ID which is an identifier of XRP ledger networks. It specifies the underlying network instance where the DID is stored. Per XLS-37d specification, in XRPL Protocol Chains the Network ID should match the chosen peer port.

• xrpl-specific-idstring is generated as described in the next section.

4.2.2. XRPL-specific-idstring Generation Method

XRPL DID MUST be unique within the XRPL network.

xrpl-specific-idstring is the AccountID or the hex of master public key of the DID object's account. See this for more details on XRPL public keys.

Example:
A valid DID for an XRPL network may be

did:xrpl:1:rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh

or

did:xrpl:1:0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020

The above DIDs are case-insensitive and will resolve to the same DID object.

5. CRUD Operations

In this section we outline the following four CRUD operations for did:xrpl method.

• Create
• Read
• Update
• Delete

5.1. DIDSet Transaction

The proposal introduces a new transaction type: DIDSet that can be used to:

• Create a new DID object,
• Update the existing DID object.

5.1.1 Example DIDSet JSON

{
  "TransactionType": "DIDSet",
  "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
  "Fee": "10",
  "Sequence": 391,
  "URI": "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi",
  "Data": ,
  "SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
  ...

  }

Create

If the DID object associated with the Account does not exist,

• If both URI and Data fields are not present in the transaction, then transaction fails.
• Otherwise, a successful DIDSet transaction creates a new DID object with the following object ID:

SHA-512Half of the following values, concatenated in order:

• The DID space key (0x0049)
• The Account ID of the Account, i.e. rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh

DID associated with this object is:

did:xrpl:1:rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh

or

did:xrpl:1:0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020

Implicit DID document

Some minimalistic use cases might only need signatures and simple authorization tokens, but don't need support for multiple keys or devices, complex organizational hierarchies and other advanced rights management features.

To lower the entry level, we do not always require registering a DID by publishing a reference to or the DID Document on the ledger. If there's no explicitly registered DID found on the ledger then an implicit document is used instead as a default. Any update on this implicit document requires registering the DID object and applied changes on the ledger to be valid.

For example, the implicit DID Document of did:xrpl:1:0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020 enables only a single key 0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020 to authorize changes on the DID document or sign credentials in the name of the DID.

Update

If the DID object associated with the Account exists,

• If URI and Data fields are not present, then transaction fails.
• Otherwise, a successful DIDSet transaction updates this object.

5.1.2. Transaction-specific fields

Field Name	Required?	JSON Type	Internal Type
TransactionType	✔️	string	UINT16

Indicates the new transaction type DIDSet. The integer value is 40.

---

Field Name	Required?	JSON Type	Internal Type
Account	✔️	string	AccountID

Indicates the account which initiates the DIDSet transaction. This account MUST be a funded account on ledger.

---

Field Name	Required?	JSON Type	Internal Type
Fee	✔️	number	Amount

Indicates the fee that the account submitting this transaction is willing to pay.

---

Field Name	Required?	JSON Type	Internal Type
URI		string	BLOB

Indicates the URI field for this object.

---

Field Name	Required?	JSON Type	Internal Type
Data		string	BLOB

Indicates the Data field for this object.

---

Field Name	Required?	JSON Type	Internal Type
SigningPubKey	✔️	string	BLOB

Indicates the public key used to create this signature.

5.2. Read

The initial step in utilizing a DID for any application involves resolving the DID to access the underlying DID Document. This resolution process unveils the cryptographic material and service endpoints linked to the specific DID.

In the case of XRPL DID, the read operation facilitates the resolution to the associated DID object. Upon successful resolution, applications can retrieve and utilize the relevant URI and/or Data fields contained within the DID object:

Given the input DID for an account, follow these steps:

• Retrieve the xrpl-specific-idstring of the DID.

• If the xrpl-specific-idstring represents a public key:

  • Compute the Account ID using the method described here.

• Retrieve the contents of the corresponding DID object in its raw format using the XRPL's account_objects command. Use the account field to specify the Account ID to retrieve all objects owned by that account, including DID object in the raw ledger format. Or optionally use the type field to filter the results by ledger_entry type, i.e. DID to retrieve the contents of just the DID object.

Example

Given the DID did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn, do the following:

• Retrieve rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn
• Perform the account_objects method request to retrieve the contents of DID object:

{
    "method": "account_objects",
    "params": [
        {
            "account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
            "ledger_index": "validated",
            "type": "DID"
        }
    ]
}

A sample response to the above query might look like this:

200 OK
{
    "result": {
        "account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
        "account_objects": [
            {
                "URI":"ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"
            }
        ],
        "validated": true
    }
}

Upon receiving this response, an IPFS address (CAS) can be retrieved from the URI field. This address can then be resolved to retrieve the corresponding DID Document.

📓 It is recommended that the applications implementing this method extend it to enable DID document fetching from the retrieved URI.

5.3. DIDDelete Transaction

XRP ledger DID object owner or controller MAY want to delete the object. For this, we introduce a new transaction type called DIDDelete. A successful transaction will remove the ledger object and reduce the reserve requirement of the owner account.

5.3.1. Example DIDDelete JSON

{
    "TransactionType": "DIDDelete", 
    "Account": "rp4pqYgrTAtdPHuZd1ZQWxrzx45jxYcZex",
    "Fee": "12",
    "Sequence": 391,
    "SigningPubKey":"0293A815C095DBA82FAC597A6BB9D338674DB93168156D84D18417AD509FFF5904",
    "TxnSignature":"3044022011E9A7EE3C7AE9D202848390522E6840F7F3ED098CD13E...",
    ...
}

A successful DIDDelete transaction deletes the DID object corresponding to the Account

5.3.2. Transaction-Specific Fields

Field Name	Required?	JSON Type	Internal Type
TransactionType	✔️	string	UINT16

Indicates the new transaction type DIDDelete. The integer value is 41.

---

Field Name	Required?	JSON Type	Internal Type
Account	✔️	string	AccountID

Indicates the account that initiated the transaction.

---

Field Name	Required?	JSON Type	Internal Type
Fee	✔️	string	Amount

Indicates the fee that the account is willing to pay for this transaction.

---

Field Name	Required?	JSON Type	Internal Type
SigningPubKey	✔️	string	BLOB

Indicates the public key used to create this signature.

6. Privacy and Security Considerations

There are several security and privacy considerations that implementers would want to take into consideration when implementing this specification.

6.1. Key Management

The entity which controls the private key associated with the DID object, i.e. the XRPL Account also effectively controls the reference to the DID Document which the DID resolves to. Thus great care should be taken to ensure that the private key is kept private. Methods for ensuring key privacy are outside the scope of this document.

6.2. DID Document Public Profile

The DID document or other data associated with the XRPL DID's URI and.or Data fields can contain any content, though it is recommended that it conforms to the W3C DID Document and Verifiable Credentials (VC) specification. As anchored DIDs on XRPL can be resolved by anyone, care should be taken to only update to resolve DID Documents which DO NOT expose any sensitive personal information, or information which one may not wish to be public. DID documents should be limited to verification methods and service endpoints, and should not store any personal information.

6.3. IPFS and Canonicity

IPFS allows anyone to store content publicly on the nodes in a distributed network. A common misconception is that anyone can edit content, however the content-addressability of IPFS means that this new edited content will have a different address to the original. While any entity can copy a DID Document anchored with an XRPL account's URI, they cannot change the document that a DID resolves to via the XRPL account_objects resolution unless they control the private key which created the corresponding DID object.

For more, see § 10. Privacy Considerations in did-core.

7. Reference Implementations

TBD

8. Appendices

Appendix 1. DID Document

A DID is associated with a DID document. A DID document contains the necessary information to cryptographically verify the identity of the DID subject. W3C defines the core properties in a DID document, that describe relationships between the DID subject and the value of the property. For example, a DID document could contain cryptographic public keys such that the DID subject can use it to authenticate itself and proves its association with the DID. Usually, a DID document can be serialized to JSON representation or JSON-LD representation (see [DIDs v1.0]).

Applications may choose one of the following for the DID document associated with a DID:

• Store a reference on the ledger in the URI field of DID object to the DID document stored in one or more parts on other decentralized storage networks such as IPFS or STORJ.
• Store a minimal DID document in the Data field of the DID object.
• Specify a minimal implicit DID document generated from the DID and other available public information.

While not normative, a sample XRPL DID Document MAY look like:

{
  	"@context"   : "https://w3id.org/did/v1",
  	"id"         : "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
 	"publicKey"  : [ 
		 		{
   	        		"id" :  "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn #keys-1",
    	       		"type" :  ["CryptographicKey", "EcdsaKoblitzPublicKey"],
    	       		"curve" :  "secp256k1",
   	           		"expires" :  15674657,
    	       		"publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882…."
  				} ]
}

W3C defines the core properties in a DID document, that describe relationships between the DID subject and the value of the property.

Appendix 2. Universal Resolver

A Universal Resolver is an identifier resolver that works with any decentralized identifier system, including W3C DIDs. Refer here. A driver for XRPL DID method resolution will be added to universal resolver configurations to make it publicly accessible.

[ximinez]

A few thoughts:

1. The table for ControllerAccount under DIDTokenCreate is malformed and not displaying as a table.
2. The field DIDToken.ControllerAccount is marked as required. That seems redundant and wasteful of space for accounts which create their own DIDToken. A simple change would be to specify that if the ControllerAccount field is absent, treat the Account as controller.
3. The ControllerAuthProof can be provided and work with any of the transaction types. While the controllers need to have some degree of trust in the account submitting the transaction, a malicious submitter could turn, say, an update into a delete. They would probably only get one chance to do that, but it might be worth it for a high-value target. I suggest an Operation field be added to the ControllerAuthProof that species create, update, or delete.
4. Speaking of an Operation field, the three new transaction types are almost completely redundant (particularly DIDTokenCreate and DIDTokenUpdate. I'm picturing a lot of unnecessarily duplicated code in the implementation (or some worker functions). What if instead of three transactions, we specify one transaction, DIDTokenSet (similar to AccountSet and TrustSet) that performs the appropriate action based on Operation? This could simplify the implementation significantly. In fact, the three Operations could be reduced to two: set, and delete. set would create the object if it doesn't already exist, and update it if it does.

[aanchal4]

Thanks Ed!

1. That was supposed to be a comment. It did not render correctly. Will fix it.
2. That makes sense.
3. An update requires URI field whereas a delete MUST not have one. One can not swap delete for an update or vice-versa. Nor can any transaction be replayed. I don't see why we would need an Operation field for this reason.
4. We can combine Create and Update operations .

[politicaljabo]

Great work.

[ZhangxiangHu-Ripple]

Why not directly store the owner's public key and the controller's public key in the DIDToken object? In the current design, if I want to verify a user's DID, I need to call the resolver to get the URI first, then use the URI to retrieve the public key. This would introduce additional costs and delays.

[aanchal4]

The proposal recommends to add support for widely accepted standards based Decentralized Identifier (DID) creation and CRUD methods on XRPL. This proposal chooses W3C DID and DID document standards to be supported on XRPL. Note that following a standards-based approach is critical for:

• Interoperability: DID owner’s can use identity data (DID document and VCs) associated with their DIDs across services.),
• Developers to use open-source tools such as Universal Resolver that implement W3C standards for DID creation and CRUD operations for all blockchains that support those standards. Here is the list. We will add support for XRPL DID DID and CRUD operations to DID-method registry and to Universal Resolver as well.

Per W3C DID standard, DID must resolve to a DID document. DID document is a standard format to store cryptographic keys, service end-points and other non-sensitive public information necessary to verify DID. It may also contain different keys for different services, etc. For details see here. In the proposal, there are two ways DID controller can choose to associate their DID with a DID document:

• Retrievable via a URI reference (useful for off-ledger services)
• Host it directly in the Data field (useful for ledger transactors)

The retrieved standard DID document can be used by services across (blockchain or non-blockchain) ecosystems that follow DID and DID document standards. Tools such as Universal resolver that implement DIDs per W3C standards require a DID doc. Identity-based application developers can easily use these tools without having to implement DIDs for each blockchain.

So it is possible to store a public key in the DIDToken object, but then the XRPL users and developers will lose all the benefits of a standards-based approach.

That is, a DID controller may choose not to follow DID documents and VC standards for data associated with DIDs (and it might work for specific use-cases), it is highly recommended to follow standards to reap the maximum benefits of this proposal.

[adrianhopebailie]

While this indirection seems inefficient I think it is the correct choice.

It definitely makes this design nice and clean.

The DID Document might define multiple keys for various purposes (e.g. authentication, signing etc) and it is likely that in most cases the entity that controls the account on XRPL (DID controller) shouldn't be using the same keys for signing transactions on the ledger.

[toshiyotmoto]

There are many Decentralized Identity patent applications. Since this proposal is the composure of years of work / knowledge, the XRPL Foundation needs to submit any prior art, including this proposal, along with any notes, communications, exhibits, or any other form of publicly available information that existed prior to the filing date of any decentralized identity pending patent applications.

Prior art serves to establish the state of existing knowledge and technology in a given field, which is crucial in determining whether an invention is novel and non-obvious, which is required in obtaining a patent. In essence, a party cannot be granted a patent if their claims incorporate elements of domain knowledge (this proposal) that predate any patent or patent application.

Here are a few patent applications the Foundation needs to consider submitting prior art for:

https://patents.google.com/patent/US20210272106A1
https://patents.google.com/patent/US20220215132A1
https://patents.google.com/patent/US20220067717A1
https://patents.google.com/patent/US20230050540A1
https://patents.google.com/patent/US20230046965A1
https://patents.google.com/patent/US20230059739A1
https://patents.google.com/patent/US20230054924A1
https://patents.google.com/patent/US20230058448A1

[toshiyotmoto]

It seems trivial, but certain CEO's are making claims https://prnt.sc/JwKVM5zPy24U

If specific influential individuals are making false allegations, then the Foundation's legal counsel needs to address the concerns and matters related to Tort Law expeditiously.

[crtag]

Well, due diligence has to be made at the time of architectural/design decisions, but I highly doubt patents in space of standards can be enacted.
https://www.w3.org/Consortium/Legal/IPR-FAQ-20000620

[rlp18pharmd]

I'm not a copyright/patent attorney by any stretch of the imagination but the DiD design and configuration would be specific to that of the XRPL right? If I'm correct, the Mettalicus DiD link you provided above references a completely different blockchain architecture from that of the XRPL. I'm just trying to wrap my head around how an XRPL DiD protocol would infringe upon the copyrights of a completely different network/blockchain DiD protocol/platform. Especially, if the underlying blockchains are different and the DiD configuration/design requirements would be different as well.

[toshiyotmoto]

Consider individual components such as computers, routers, switches, and cables. The components themselves are not patentable (novel); however, imagine that a network engineer develops a unique and innovative network architecture that optimizes data transmission between the components in a new way. This could involve a novel routing algorithm, an inventive method for load balancing, or an advanced security protocol that enhances the overall performance, reliability, and security of the computer network, which is patentable (given no prior art exists).

In this scenario, the overall system or architecture – the specific arrangement, interaction, and communication between the non-patentable components – could potentially be patentable, as it represents a novel and inventive solution in the field of computer networks. The patent would cover the unique design and configuration of the network system, rather than the individual components themselves.

In said US17/190,320 patent application, look at the figures and you will see very generic language used (blockchain, api, user profile, etc) which is a broad scope. Patent attorneys rarely pigeon hole themselves into a scope that is too limited. I could go through all the nuances of patentability, but its quite complex. I am NOT implying there are any infringements with any of the patents or applications. All I'm saying is everyone is chasing the same rabbit, and its smart business to have a patent attorney review any architecture to ensure there is no potential liabilities before deploying. Now, if any patent or patent application contains concepts, architectures, workflows that predate when the patent was applied for, then that is prior art and could invalidate a patent or prevent it from being granted - which is the whole purpose of the patent pending stage.

It is highly probable all these patents and applications employ W3C standards; however, it's the unique combination, system, workflow, or architecture that could be patentable.

[Silkjaer]

Just to clarify, this proposal is put forward by Ripple, and is yet only a standards draft, and not implemented nor live on any networks. But with concerns like these, the contributor need to make sure it does not infringe any patents before an implementation can be merged into code.

[toshiyotmoto]

Has anyone read CanDID: Can-Do Decentralized Identity with Legacy Compatibility, Sybil-Resistance,
and Accountability https://eprint.iacr.org/2020/934.pdf

[shortthefomo]

The URI field much like the URI field on NFT's today should be a required field.

[shortthefomo]

Can any explanation around why the URI be empty be provided?

[mvadari]

In the current version of the spec, you must either have the URI field or the Data field.

[FlorianBouron]

Awesome job!

[shortthefomo]

The other issue here is this suffers the same lookup issue as to who the owner is like the current NFT standard. Requiring extra tooling for indexes that live off the XRPL. It would be desirable to look up the owner of the DiD via the ledger it's self proving the DiD identifier.

[mvadari]

This should no longer be an issue with the current version of the spec.

[tequdev]

How did the specification regarding Account Roles go away?

[ckeshava]

Hello, I have a few questions.

1. Key-rotation: Individuals/organizations would like to periodically refresh their private/public keys for better security. Can we accomplish that with this DID proposal? Would that be useful?
   I know that this can be accomplished with special cryptographic primitives or a new transaction type that updates the publicKey associated with a DID.

On a broader note in the XRPL architecture, I know that ephemeral and masterPublic keys are used in the manifests. Are users provided any way to rotate their keys for account management?

2. Multiple identities:
   If an account needs to hold multiple identities, how would one go about doing that? Do we have any equivalent for "also-known-as" field? (https://www.w3.org/TR/did-core/#also-known-as)

The DIDID appears to be tightly bound to the Account ID, hence it appears that multiple identities is not feasible for a single account.

[aanchal4]

1. I'm unsure about the specific question you have regarding key rotation. Is your Q related to the rotation of the master public key of the ledger? Nevertheless, I'll make an attempt to provide an explanation. Within the XRPL context, it's feasible to disable the master key, but rotation is not a supported feature. However, the regular key can be rotated periodically. The DID URI is a function of AccountID or master public key, serving the purpose of ensuring resolution through a blockchain. Implementing DID support does not bring about any alterations to the existing account management procedures on the XRPL platform. It's worth noting that DIDs can be linked to multiple keys (resolvable through DID URI). Given that modifications can be made to the public keys associated with the DID, changing the regular key will also lead to a corresponding adjustment in the DID reference.

2. DID is unique for an Account. DID is a URI that can be resolved to a DID document. DID document may contain as many "also-known-as" fields to associate multiple URIs to the master DID.

[ckeshava]

yes, my question was about rotation of master public keys. Thanks for your answers.

[intelliot]

There is no need to rotate the master key because it has no important privileges over a regular key or a signer list. Key rotation is fully supported by the XRPL already, by assigning a regular key (or signer list) and then disabling the master key.

[ckeshava]

3. Right-to-forget: As per several privacy laws (GDPR, HIPAA, etc) across the globe, users should be able to permanently delete the data from a system. Hypothetically, if a user places "Personal Identifiable Information" in the data field of the DID object and needs to delete it at a later point of time, is that possible? Even if the DID object is deleted, such data can always be viewed in the previous ledgers.
   (I know that this is a general critique of blockchains, given that they maintain provenance)

[shortthefomo]

The DiD is simply a URI it does not save anything. The referenced URI would have the data. It would be up to the implementation(s) of the interface where this data is stored and how/if can be removed.

[ckeshava]

Yes, I understand that. I'm talking about the Data field, which is 256 bytes in length. If that field is used to hold the Subject or any sensitive data, it is stored on all the validators forever. The Data field is un-deletable.

[mvadari]

The Data field is not un-deleteable, that field can also be deleted.

[aanchal4]

Data field is under the control of the account/DID & it is public knowledge that blockchain data is immutable. It is not supposed to contain PII. It is supposed to contain publicly accessible attestations. While the ledger cannot prevent individuals from including their PII, this isn't an unprecedented issue. Similar to how any PII could be included in the memo field and remain permanent.

[ckeshava]

hmm, I see

[ckeshava]

Yes, but it would preserve the Data field in all the previous ledgers, I'm concerned that goes against the spirit of privacy laws. Regards, Keshava

…

On Fri, Aug 18, 2023 at 6:03 AM Mayukha Vadari ***@***.***> wrote: The Data field is not un-deleteable, that field can also be deleted. — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/XRPLF/XRPL-Standards/discussions/100*discussioncomment-6761378__;Iw!!PZTMFYE!7eRN9eSY5wmMLTO1c8i5_XZWjCBCmg2hlqPPYH39Zi7VtMeVN49VfZXQSPd-kPNkn_zv0frXxATtDAk5bHb_AGWXgQ$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AFB4TNK6JWPNDJPUNXA2TZTXV5RZTANCNFSM6AAAAAAWNVYYHQ__;!!PZTMFYE!7eRN9eSY5wmMLTO1c8i5_XZWjCBCmg2hlqPPYH39Zi7VtMeVN49VfZXQSPd-kPNkn_zv0frXxATtDAk5bHYID-HRtw$> . You are receiving this because you commented.Message ID: ***@***.***>

[adrianhopebailie]

Hey @aanchal4 this is excellent, thanks for putting it together.

I started playing around with designing a DID method for XRPL a few years ago but limited my design to not requiring any new ledger objects. This is much cleaner and I think could be incredibly powerful.

I think it would be really useful to document some use cases for this where the account owner is an individual but also where the account owner is a business.

E.g. Consider the case of key rotation raised in an earlier comment. A business could publish a DID Document that contains all their public keys used for attestation, authorization etc and then bind that to their account on XRPL using a key that is mostly kept in cold storage. The private signing and auth keys can be stored in an HSM or similar and used for day-to-day operations like signing API requests or issuing verifiable claims.

Another interesting thought is considering this as a way for individuals to effectively be their own Certificate Authority where their master key on XRPL is the root of their own PKI.

[intelliot]

note: as of today, this spec needs some updates

[aanchal4]

Refer to PR #136

[ThierryThevenet]

@aanchal4 Hello, any update about the possibility to have a driver for the universal resolver ?
We plan to use xrp DID method for VC issuance (for jwt_vc_json) with OIDC4VC and our wallets https://altme.io

[mvadari]

I have a WIP here: https://github.com/mvadari/xrpl-did-resolver
Far from complete, let me know if you have any feedback 🙂