JIT onboarding: Support "suggested wallet" parameter to CHAPI requests

[dmitrizagidulin]

An important component of CHAPI wallet operation will be "Just In Time" onboarding / wallet registration. We want the user to be able to go through the following workflow:

1. User encounters some UI (likely a button) that issues/verifies a credential or performs DIDAuth. (The user does not yet have a CHAPI wallet registered.)
2. User clicks on the button (for example, "[ Receive Credential ]").
3. the CHAPI UI displays "You do not have a wallet currently registered. But here is where you go to get one:"

To prevent the default wallet suggestion from having an unfair advantage, we can instead allow the requesting party (whichever app or web page is displaying the button that triggers the chapi get() or store()) to pass in one or more suggested wallet providers that the UI will suggest, in case the user does not have a wallet already.

So, here would be an example get() request:

const credentialQuery = {
  web: {
      VerifiablePresentation: {
          query: { ... },

          challenge: '3182bdea-63d9-11ea-b6de-3b7c1404d57f',

          domain: 'jobs.example.com',

          suggestedWallet: [ "chapi-demo-wallet.digitalbazaar.com", "some.other.wallet.com" ]
    }
  }
};
const webCredential = await navigator.credentials.get(credentialQuery);

In this example, the two URLs in the suggestedWallet parameter would be displayed in the "You don't have a wallet" CHAPI UI.

[dlongley]

We will want the web app manifests served by suggested domains to express the types of WebCredentials they support. So, for example, if the user has no credential handler available to handle a VerifiablePresentation WebCredential, the browser should fetch "https://chapi-demo-wallet.digitalbazaar.com/manifest.json". This manifest should express the supported WebCredential types.

We might also want this feature to be further generalized to all credential handlers, not just those that happen to support VerifiablePresentation. We may also not want this information included in what gets sent to a credential handler in the request/store event. This could mean making a suggestion at a higher level in the query -- perhaps an options parameter should be defined such that "options" cannot be used as a particular WebCredential type:

const credentialQuery = {
  web: {
    options: {
      recommendedCredentialHandlers: ["chapi-demo-wallet.digitalbazaar.com", "some.other.wallet.com"]
    },
    VerifiablePresentation: {
      query: { ... },
      challenge: '3182bdea-63d9-11ea-b6de-3b7c1404d57f',
      domain: 'jobs.example.com'
    },
    OIDC: { ... }
  },
};
const webCredential = await navigator.credentials.get(credentialQuery);

I think we need to more explicitly express a few use cases/flows to get a good idea of how we this feature should behave. It's more obvious for the cases where the site is requesting one particular type of WebCredential, but what if they accept multiple types? Under those circumstances, what if the user has no handlers for any of the types -- what would the UX be? Is there a simple enough way for the user to make a choice between recommended handlers? Should handlers be given the chance to render their own page to help the user make a choice?

[dlongley]

recommendedHandlerOrigins feature has landed, closing this.