which credential Issuers are you open to trusting;
how long, if at all, you need to retain access to user data;
whether you’re going to be using Passporting.
Signature and encryption keys
🛑 DANGER 🛑
Make sure you don't lose access to either secret keys. Otherwise, you won't be able to authenticate or decrypt credential contents. The idOS team won't be able to help you.
You'll need:
recipientEncryptionPrivateKey: base64-encoded nacl.BoxKeyPair secret key. It'll be used to decode the credential copies that the owners (users) share with you by creating access grants.
see Encryption for more information
consumerSigner: this can be a NEAR KeyPair, or an ethers.Wallet. This will be used to sign RPC calls to the idOS nodes.
see Signatures for more information
A frontend
Your frontend (web or native app), as your user’s touch point, is where you’ll:
confirm that the user is in idOS;
find whether the user has an adequate credential;
request an access grant to user credentials.
A backend
Your backend (private server) is where you’ll:
retrieve user credentials you’ve been granted access to;
and their dependencies with pnpm (or your package manager of choice)
Usage
[ frontend ] Importing and initializing
[ backend ] Importing and initializing
[ frontend ] Connecting your user's wallet
Connect your user's wallet however you do it today, for example:
[ frontend ] Checking if you user has an idOS profile
Get your user's address from the signer above and confirm they have an idOS profile. If not, redirect them to your Issuer. If you have an IDV integration, you can yourself be the issuer. See the Issuer Guide for more information.
[ frontend ] Setting signer
Pass your user’s signer to the SDK, so it knows where to send signature requests to.
[ frontend ] Checking for existing access grant
Access Grants queries can also be paginated:
Optionally, you can double check that the existing access grant matches your requirements. You do this on your backend.
If you don’t have an access grant, you can proceed to filtering the user’s credentials and requesting one or more access grants.
[ frontend ] Filtering credentials
Credential filtering is done by calling the method filterCredentials from the idOSClient and passing the filtering requirements:
[ frontend ] Requesting access grant
The simplest way to do this is to ask the user to create and insert an access grant for you.
Alternatively, you can ask for a delegated access grant, which the user creates:
and you then insert after sending it to your backend:
Using passporting
TODO: missing code examples for passporting:
ask for credential duplicate (C1.2) separately and before asking for AG
get hash from C1.2 and use it on dAG request
send dAG to own backend, which proxy sends to OE1's passporting server
[ backend ] Retrieving and verifying credential
If you're using passporting:
If you need a helper to verify that the W3C VC is something you want to trust, here's an example:
const filteredCredentials: idOSCredential[] = await idOSClient.filterCredentials({acceptedIssuers: [{
authPublicKey // the accepted issuer auth public key to filter credentials by
}];
// OPTIONAL. A list of public notes fields of a credential that should be picked or omitted.
publicNotesFieldFilters: {
pick: {};
omit: {};
};
// OPTIONAL. A list of private fields of a credential that should be picked or omitted.
privateFieldFilters: {
pick: {};
omit: {};
})
await idOSClient.requestDAGMessage({
dag_owner_wallet_identifier, // This is the user
dag_grantee_wallet_identifier, // This is you, the consumer
dag_data_id,
dag_locked_until, // Unix timestamp. According to your compliance officer's instructions.
});
await idOSConsumer.verifyW3CVC(credential, {
allowedIssuers: ["https://kyc-provider.example.com/idos"],
allowedKeys: ["z6Mkqm5JuLvBcHkbQogDXz5p5ppTY4DF5FLhoRd2VM9NaKp5"],
documentLoader, // If you need to specify your own.
});