For interacting with an OIDC credential issuer, we need to know the OIDC base URL of the issuer service. The SSIKit tries to resolve the OIDC discovery document relative to that base URL like this:
<base URL>/.well-known/openid-configuration
For this example, let's use our demo issuance service published on:
First let's get some information about the credentials, the issuer provides, and possibly, which types of credentials we must present, in order to obtain the issued credentials.
Output
The issuer lists the supported credential types, as well as required VPs, which are None in our demo service.
To initiate a credential issuance session, we have to push an authorization request to the issuer service, containing information about which credential we want to get issued, and a possibly required verifiable presentation:
For more options of the auth subcommand, type
ssikit oidc ci auth --help
Let's break up the above command:
-i [...]: Set the issuer base URL
-n [...]: A nonce we define, for the issuer to sign the id_token in a later step
-r [...]: Set a dummy redirect address, as we just need to copy the final redirection URL from the browser lateron.
-c [...]: Credential type of credential to be issued, like given by issuer metadata supported_credentials
Output
Let's now follow the instructions the CLI printed, and open that link in the browser: https://issuer.walt.id/issuer-api/oidc/fulfillPAR?[...]
, to proceed to the issuer portal and continue with the credential issuance session.
After completing the issuance session in the issuer web portal, we continue with the token request, as instructed by above command output.
Once we completed the issuance session on the issuer web portal, we get redirected to the dummy address we specified, like we can see in this screenshot:
We copy that URL from the browser and fetch the id_token and access_token from the issuer like so:
For more options of the token subcommand, type
ssikit oidc ci token --help
Breakdown of above command:
-i [...]: Set the issuer base URL
-r [...]: The redirection URL copied from the browser, including the authorization code parameter, generated by the issuer portal.
Output
Let's break down the important bits of the token response:
access_token: The token which we need to request the credentials
id_token: ID token, which should have been signed by the issuer, respecting the nonce challenge we defined previously in the auth subcommand.
c_nonce: The nonce challenge we need to use, to sign the DID ownership proof in the credential request.
expires_in: expiration period (seconds), after which the token will become invalid.
Let's now proceed with the credential request, like instructed by the command output.
Once we retrieved the access_token, we can fetch the actual credential from the issuer. This command can be repeated for each credential schema type we requested in the auth subcommand previously.
For more options of the credential subcommand, type
ssikit oidc ci credential --help
Breakdown of above command:
-i [...]: Set the issuer base URL
-m OIDC: Follow the OIDC standard (default)
-t [...]: The access_token we received previously
-n [...]: The nonce used for signing the DID ownership proof
-d [...]: The DID for which the credential should be issued (we have to proof DID ownership!)
-c [...]: Credential type of credential to be issued, like given by issuer metadata supported_credentials
--save: We instruct the CLI to save the received credential to the credential store
Output
As we can see, we received the VerifiableID credential for the DID subject we specified and the credential was stored.