Create a variation on Issuer Kit for use by the BC Wallet team in issuing the VP credential during wallet installation and setup
swcurran opened this issue · comments
We would like to have a way to issue a cornerstone credential (Verified Person - VP, for BC) during the installation and setup of a wallet. The user experience we'd like to see is demonstrated in these wireframes. We anticpate either evolving Issuer Kit (this repo) or creating a new repo that implements the pretty simple service that issues the needed credential.
The service can be seen in the "secure custom browser session" seen floating in/above the BC Wallet.
The flow we are expecting is something like this -- please adjust where this is not right:
- The wallet is configured to know the Public DID and URL of the service
- The service is Aries and OIDC enabled, and is an issuer of a defined credential
- On clicking the "Go to the BC Digital ID website", the wallet uses the DID Exchange "Implicit Invitation" flow to request a connection using the Public DID of the service (we're assuming that the Wallet resolves the DID, but that could be done as part of the wallet configuration).
- The service gets the request and caches it for later use. No response is sent until the authentication (next step) completes.
- The URL of the website is opened in a secure custom browser session (within the Wallet app), with the ThreadID of the DID Exchange protocol started by the Wallet passed in securely.
- We're assuming via the HTTP header vs. as a query parameter.
- Question -- would it be worth the extra security of having the Wallet pass the signature of the ThreadID based on the VerKey offered in the connection request?
- On the website there is some text and a button to start an OIDC Authentication flow.
- This is intended to be to the Services Card, but I think we don't need to have the Services Card for the flow -- it could be any IdP -- e.g. GitHub.
- On completion of the OIDC flow -- display a screen showing the ongoing progress of the rest of the flow
- On authentication failure, send a Problem Report to end the DID Exchange protocol instance and go straight to the "Return to Wallet" button
- Take the data from the token, and use that to populate the VC to be issued (simple for now -- we'll need a mapping later)
- Complete the DID Exchange connection, and issue the credential on the same connection.
- Display the "Return to Wallet" button, on click -- close the secure custom browser session
- It would be nice to pass back the status of the flow to the Wallet -- not sure what is possible.
This first instance of this service should be quick'n'dirty -- enough to prove it works, enough so that the BC Wallet developers can implement the Wallet side of the exchange, and enough so that the IDIM folks have an example of what they are likely to be building for realsy. However, it's possible we might decide to use this as the foundation of a common service that others can use.
Considerations
Applicability for other Wallet Makers
As this is done, consider if/how generic we can make this so it can be used by other Wallet publishers. What if BC wanted to allow other Wallet makers to use this service for a wallet that is available in many jurisdictions? For example, the new wallet owner indicates where they live, and the wallet has a full set of "cornerstone credential" issuers, determines the right one for the new user and directs the user to go through the flow for that jurisdiction (e.g. has the Public DID and URL for that jurisdiction).
A similar, or perhaps simpler version of this flow could be triggered from within the wallet, perhaps from an advanced Action Menu item type. A wallet owner requests a menu from a trusted service. One of the items might be "Get a Lawyer Credential". When selected, the service sends back the public DID/URL for the Lawyer Credential Issuer service, and a similar flow is repeated -- perhaps using an OIDC flow, or perhaps only using a DIDComm connection and authentication via proof request flow.
@andrewwhitehead @jljordan42 -- per our discussion this afternoon.
@cvarjao -- the idea of this work is to give the Wallet team a service they can use to develop the Wallet parts of the VP issuing flow we've been talking about.
An image from IDIM that shows the proposed flow:
