How should we go about issuance?

[samuelgoto]

We deliberately left issuance aside while we were trying to figure out presentation, so kicking this issue off just to make sure it doesn't fall through the cracks :)

As thing start to settle with presentation, we should starting thinking how to go about issuance. There are a lot of things and a lot of considerations, so we'll likely want to break this into smaller steps, but kicking this off just to get the ball rolling.

[OR13]

In presentations, the verifier wants to select claims for the holder to disclose and be protected against replays with nonces / pops.

In issuance, the issuer wants to be assured the holder controls a key, and has consented to the claims that will be bound to that key... The holder wants to know which media types are supported, and what credential types are supported.

So there is some symmetry around proof of possession, media types, and credential schemas / types (known structures).

There is also: https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html

Are you asking what are the essential parameters a browser API would need to collect in order to submit an issuance request to some backend?

What is the threat model you have in mind for issuance?

Is it necessary for the holder to encrypt their pop key or other credential information to the issuer?

Should the browser or OS be able to observe specific claims or credential types, or should they just see an encrypted request for issuance?

[timcappalli]

I've been thinking about issuance in the Web Platform API as very similar to a presentation (pass the OID4VCI request to the app platform), except that there isn't really a response back through the web platform outside of some form of "ack". We should think about what that "ack" actually contains (e.g. what would an issuer's web frontend need/want).

Much of the complexity lives in the app platforms wallet selector.

[samuelgoto]

Ok, here is something to get the discussion started. WDYT?

// Prompts the user to select a wallet to have the digital credential issued, and sends the request to the wallet
// Throws an exception if the user denied the request or didn't have an accepting wallet installed indistinguishably
const credential = await navigator.credentials.create({
  digital: {
    protocol: "openid4vci",
    data: {
      // the openid4vci request body, omitted for brevity
    },
  }
});
// TODO(goto): should we use the navigator.credentials.store(new DigitalCredential()) instead of create()?

[timcappalli]

@samuelgoto what's the reasoning for .store? The ultimate result is the creation of a digital credential in an external container. I think it should be .create, similar to WebAuthn.

[samuelgoto]

@samuelgoto what's the reasoning for .store? The ultimate result is the creation of a digital credential in an external container. I think it should be .create, similar to WebAuthn.

Are you referring to this TODO that I left [1]? The code snippet I proposed uses create() rather than store(), right?

[1]

// TODO(goto): should we use the navigator.credentials.store(new DigitalCredential()) instead of create()?

[timcappalli]

Sorry, looks like I saw an earlier version before it was edited.