‍

At idOS, we’ve been closely monitoring the development of XLS-70d, one of the best proposals to ever come to the XRP Ledger. This proposal aims to enable the Credentials feature, which provides a straightforward, W3C-aligned framework for handling on-chain authorization.

‍

One of the most useful aspects of Credentials is how they are not just idle records: the way this new feature extends the existing Deposit Authorization capabilities creates a truly innovative primitive for regulated DeFi, whereby Credentials can be easily used for compliant, automatic on-chain authorization.

‍

For a while now, an XRPL account can optionally enable Deposit Authorization to allow incoming value transactions from only those accounts it chose to preauthorize in an allowlist. Maintaining this allowlist is a manual process requiring frequent intervention. The greatest power of Credentials is automating Deposit Authorization: instead of needing to approve individual accounts ad-hoc, incoming transactions can be automatically authorized based on one or more Credentials the sender is required to have.

‍

This article is idOS technical contribution to the XRPL community. As our Consortium partner, we are excited to see XRPL introducing a primitives that allows identity to play a central role in the ecosystem. This is mostly geared to XRPL members, but has implications for other ecosystems' design choices around identity provisioning.

‍

Overview: idOS + XRPL

idOS is the identity layer of web3. It enables users to store their data privately in a self-sovereign way, and share access with individuals and businesses across the internet with a simple wallet signature. idOS is an open-source, composable and chain-agnostic protocol, made up of two key components:
‍

1. A compliant dStorage Network of Nodes, managed by node operators that store end-to-end user-encrypted data, usually in the form of W3C Verifiable Credentials.
2. An Access Management Protocol, allowing users to manage their own data and grant/revoke access to third parties like web3 apps and regulated services like fiat on/off-ramps, embedded crypto bank accounts and crypto credit/debit card providers.
   ‍

What is idOS? | idOS Documentation (V1)

‍

idOS is working on an XRPL integration that leverages both the new Credential object and the extension to XRPL’s deposit authorization feature.

We combine these with simple semantics to deliver an easy and reliable DX for Dapps, enabling them to use a set-and-forget approach to control incoming value transfers, allowing them to authorize only those where:

• the sender holds a Credential meeting the Dapp’s compliance requirements;
• and the Dapp has been given the right to retrieve the underlying Credential data (a common requirement within most regulatory frameworks).

‍

Is KYC becoming a gate-keeping function for XRPL with the introduction of identity?

Adding credentials as a way to not require minimum deposits is another optionality that users might find more convenient but do not have to use. Adding identity and KYC credentials as an attestation on chain allows everyone that requires KYC anyway, to built and use it in a composable and open way. Payment infrastructure does require identification to be in place, having it on-chain puts it in a transparent realm where it's up to builders to include multiple choices of different vendors and – most importantly – allow users to take up self-custody of their own data and not have it stored in central honeypots. One might still not like that fact that or how KYC is being done today, but arguably having a transparent and composable open source system on-chain is strictly better compared to the current status quo.

idOS Credentials for transaction authorization

The goal of this integration is to allow XRPL Dapps (such as they are) to use the idOS for user authorization. In the interest of openness, we share below a developer-focused overview of our approach.

‍

XRPL Credentials tl;dr:

‍

‍

‍

XLS-70d introduces the Credential object meant to represent a W3C Verifiable Credential on-chain (naturally with no PII), and its related transaction types CredentialCreate,CredentialAccept and CredentialDelete.

Each Credential object references a Subject (the XRPL account that owns it) Issuer (the XRPL account that attests to it).

Critically, due to XLS-70d’s extension to deposit authorization, Credential's enable permissioned DeFi out of the box (something we’re still figuring out on EVMs): idOS Credentials, through their XRPL Credential representations, can be easily used for on-chain authorization.

‍

Setting up deposit authorization

Suppose a Dapp wants to enable deposit authorization so that it can only receive value from accounts that have passed KYC.

To do this, this Dapp can enable deposit authorization by configuring the upgraded DepositPreaut object to preauthorize transactions from senders holding a KYC  Credential from an issuer it trusts, e.g. SumSub:
‍

DepositPreauth {
AccountId: rDapp
AuthorizeCredentials: [
{ Issuer: rSumSub, CredentialType: KYC }
]
}

‍
Once this is done, all value transfers to rDapp will fail unless sent by accounts that are the Subject of a Credential of type KYC issued by SumSub (identified by their rSumSub account).

Alice has such an account, rAlice. Her identity has already been verified by SumSub, and now she owns the following Credential, which she already accepted using CredentialAccept:

‍

Credential 1 {
Issuer: rSumSub
CredentialType: KYC
Subject: rAlice
URI: <idOS Credential ID>
}

‍

Now, if Alice wants to send XRP to rDapp with a Payment transaction, she must make sure to reference this Credential within the transaction payload:
‍

Transaction {
TransactionType: Payment
Account: rAlice
Destination: rDapp
CredentialIDs: [ 1 ]
}

‍

‍

This transaction will successfully pass authorization because:

• there exists a Credential with ID = 1;
• which fits the preauthorized criteria (Issuer = rSumSub, CredentialType = KYC);
  and is owned by rAlice (she is its Subject ).
• and is owned by rAlice (she is its Subject ).

‍

‍

The validity of this Credential can be trusted by any Dapp trusting SumSub because of how CredentialCreate is designed: a Credential with a given Issuer can only be created by said Issuer using CredentialCreate.

Note that, for this Credential to be usable in this context of deposit preauthorization, Alice must first signal their acceptance for it to be considered valid, which she does using a CredentialAccept transaction.

Ensuring access to Credential data

While the mechanism described above protects the Dapp from unauthorized value transfers, it’s likely their regulatory requirements mandate them to ensure they have access to the actual KYC data underlying the Credential. In idOS terms, that means the Dapp needs to secure an Access Grant from the User, entitling them to retrieve the corresponding Credential from the idOS network.

To enable this, we propose using a second Credential to represent an Access Grant considered valid by the idOS network.

Once rAlice secures an on-chain Credential from SumSub and accepts it, any XRPL Dapp can ask her for an Access Grant. The process is as follows:

• the Dapp asks Alice to create a duplicate copy of the corresponding idOS Credential, re-encrypted to an encryption public key the Dapp provides;
• the Dapp uses CredentialCreate to write a new Credential on chain for rAlice, as its Issuer, and asks her to accept this credential using CredentialAccept:

‍

Credential 2 {
Issuer: rDapp
CredentialType: AG-KYC-SumSubAID-5Y
Subject: rAlice
}

‍

Note that this CredentialType of this new Credential follows a specific format. This provides the context for dApps to confidently set their deposit preauthorization criteria, and for the idOS network to observe and uphold the Access Grant. Let’s decode the example above:

‍

| Represents an Access Grant
|
|  | to a Credential of type KYC
|  |
|  |   | issued by SumSubAccountID
|  |   |
|  |   |               | locked for 5 years
|  |   |               |
|  |   |               |
|  |   |               |
v  v   v               v
AG-KYC-SumSubAccountID-5Y

‍

‍

Putting it all together

To guarantee access to data, the Dapp updates its transaction preauthorization criteria. To do this, they add a new item to their AuthorizeCredentials list:

‍

DepositPreauth {
AccountId: rDapp
AuthorizeCredentials: [
{ Issuer: rSumSub, CredentialType: KYC }
{ Issuer: rDapp,   CredentialType: AG-KYC-SumSubAID-5Y }
]
}

‍

Now that Alice’s account has both required Credentials, she can refer to them both in her transaction:

‍

Transaction {
 TransactionType: Payment
 Account: rAlice
 Destination: rDapp
 CredentialIDs: [ 1, 2 ]
}

‍

Since both Credentials Alice refers to match the preauthorized criteria, her transaction will succeed.

‍

‍

Upholding Access Grants

‍

XRPL Oracle: recording Access Grants

For this integration, idOS nodes will use an XRPL Oracle to source created Credential's that have been accepted with CredentialAccept, and store corresponding Access Grants internally.

Let’s follow from the examples above and suppose Alice has secured a KYC credential from SumSub and accepted an Access Grant created by the Dapp. She now has two Credential's on XRPL:

‍

Credential 1 {
Issuer: rSumSub
CredentialType: KYC
Subject: rAlice
URI: 123
}

‍

Credential 2 {
Issuer: rDapp
CredentialType: AG-KYC-SumSubAccountID-5Y
Subject: rAlice
}

‍

The idOS network monitors XRPL for new CredentialAccept events. When a new Credential with CredentialType matching AG-*-*-* issued by rDapp is accepted, our XRPL Oracle will record an Access Grant so that it can satisfy future retrieval requests.

Let’s see how this works. Keeping with the example above, AG-KYC-SumSubAccountID-5Y, we proceed as illustrated in the diagram below:

‍

‍

1. Detect CredentialAccept for a Credential:

• Note type: AG-KYC-SumSubAccountID-5Y
• Note issuer: rDapp

2. In XRPL, find a Credential owned by rAliceof type KYC issued by rSumSub

• Note its URI

‍3. Look in the idOS database for the Shared Credential that refers to an Original Credential with ID = URI and was inserted by Alice for rDapp

• Record an Access Grant for rDapp to that Shared Credential, locked for 5Y

‍

Retrieving idOS Credentials

Securing an Access Grant entitles a Dapp to retrieve its corresponding idOS Credentials. To do this, they must submit a signed request to the idOS network referring to the ID found in the URI field of the Credential they got an Access Grant for.

Let’s take this request as an example:

‍

idOS Original Credential ID: 123
Signer: rDapp

‍

Authentication & authorization

The idOS nodes will first authenticate the signer of this request by validating its signature, and conclude the signer is indeed rDapp.

To authorize the request, the idOS nodes must ensure that rDapphas an access grant to a Shared Credential whose original ID is 123.

When successful, this request is fulfilled with an encrypted idOS Credential.

‍

Credential decryption

Earlier, when Alice chose to create an Access Grant for the Dapp, it used the Dapp’s supplied encryption public key to encrypt the resulting Shared Credential before writing it to the idOS.

This encryption process uses NaCl’s crypto_box, a modern and proven cryptographic construct implementing x25519-xsalsa20-poly1305.

To decrypt this Shared Credential, the Dapp needs only to reverse the process using their corresponding encryption private key. This operation is supported by the idOS backend SDK, but it can also be done directly using NaCl / libsodium or any of their many available implementations such as PyNaCl or tweetnacl-js.

‍

What’s next

The Credentials Amendment, currently open for voting, will hopefully enable Credentials soon. By dramatically reducing the cost and complexity of regulatory compliance, it enables regulated industries to find a safe haven in XRPL.

The Credentials proposal showcases the versatility of XRPL at its best, and makes a strong statement of support, interoperability and openness for both permissionless and institutional DeFi within the same chain. By choosing to make Credentials an entirely optional features, XRPL ensures its permissionless DeFi ecosystem can keep blooming, while at the same time bringing about a long overdue wave of mass institutional adoption.

‍