‍

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) and an `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 `rAlice` of 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 `rDapp` has 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.

‍