An asynchronous issuance

[filip26]

Hi,
it might be out of the scope of this spec, it's not a microservice, but asynchronous issuing is crucial in order to enable:

• an approval process - a process that might involve collecting additional information, checks, and even human involvement
• optimal infrastructure utilization - e.g. a queue of requests scheduled to be processed on an issuer's terms

To keep this spec simple, perhaps, simply allowing to return 202 Accepted code without specifying any further details, leaving the further interaction details on an implementer for now, could be enough to keep the issuance interface being used for advanced use-cases without a need to introduce a proprietary endpoint on issuer's side.

[dlongley]

I'm going to guess/assume that this issue is primarily about workflows/exchanges. The reason for this is that if they aren't being used for delivery of a credential, then whether an additional process is required can be handled by the coordinator in any way whatsoever prior to making calls to the issuer API. So, we should focus this consideration on workflows/exchanges.

Now, for workflows/exchanges, the current design has some primitives in it already that are thought to cover this sort of situation and others like it. In particular, a VC API exchange does not require any VCs to be returned (issued) when it terminates and it can return a redirectUrl to continue the interaction. I can't link directly to this, but see these sections for redirectUrl:

https://w3c-ccg.github.io/vc-api/#participate-in-an-exchange
https://w3c-ccg.github.io/vc-api/#workflows-and-exchanges

Therefore, the thought is that, for a process that requires additional interaction / approval prior to issuance the exchange would return a redirectUrl to send a user back to a coordinator website where it can tell the user that their request has been accepted and that they will be notified (by some coordinator+user-determined means) when they can return to be issued any VC(s). In theory, these primitives should enable a number of more complex / interesting flows to be built without having to specialize further.

[jrhender]

@filip26 thanks for making the issue. I agree that asynchronous issuance is an important use case.

@dlongley I think that your suggestion to use redirectUrl makes sense. My suggestion for the GET Exchange Response used the redirectUrl feature and my use case for the suggestion is asynchronous issuance.
@dlongley a follow up question for you:
In the sequence you described with a redirectUrl and the user being notified to return to be issued VCs, do you envision the issuance being a separate exchange? In other words, do you see there being a first exchange that resulted in the redirectUrl and then, at some later time, a new exchange being started for the credential?

[dlongley]

@jrhender,

In the sequence you described with a redirectUrl and the user being notified to return to be issued VCs, do you envision the issuance being a separate exchange? In other words, do you see there being a first exchange that resulted in the redirectUrl and then, at some later time, a new exchange being started for the credential?

Yes, I believe there would be separate exchanges.

[msporny]

The group discussed this on the 2025-01-07 telecon:

@PatStLouis noted that proof set / proof chain might need to gather different signatures before issuing to wallet -- there might be a significant delay in collecting proofs. @dlongley noted that specialized behaviour that includes async processes, you can do so with coordinator-specific behaviour and you can use redirect URL -- start exchange, get info from user/wallet, response from exchange can be redirect URL that takes them back to coordinator URL to do new exchange at appropriate time. Coordinator website can provide an arbitrary interface w/ notifications through arbitrary channels, which can then notify individual once credential is ready. Can construct and put together whatever you'd like, as complex as you'd want to (could lose users due to UX if waiting too long). @jrhender noted that he could see the perspective (async can be done outside of spec, spec doesn't preclude functionality) -- same is true for steps/branching -- coordinator has logic for different steps -- consistency in design? What are the different philosophies? @dlongley considering how much complexity a digital wallet needs to implement -- users expected to go to web, go to coordinator and interact. User has digital wallet, how many different things do digital wallet need to interact w/ VC API -- indeterminate VPRs/VPs/redirect URLs -- wallets need to implement all of that. Additional complexity built into VC API, new concepts for digital wallet needs to understand, authorization token, metadata endpoint, get credential, etc... new primitive/construction, wallet has to implement that. Are all wallets going to implement both features -- if we're able to make async issuing work it's fine to integrate, but if it makes it more complex, wallet implementations might suffer (more complexity).

@PatStLouis noted that common problem -- how can issuer contact holder later -- make request for VC -- like background check -- how does that use case happen? How does individual get notification? DID Comm-like persistent connection between two parties -- credential request sent between two parties. DID Comm connection is a bridge between individuals -- how would that fit in VC API model? @dlongley noted one design goal was to not reinvent things that already exist, even if we want to use them in credential flow. Just invent the new primitives to do what we need to w/ credentials while depending on existing Web/Internet features for other things. Avoid Not Invented Here, invent minimum number of building blocks... there are many types of notification mechanisms that exist today, where should line be drawn, what are the expectations? VC API relies on Web Platform for those features (based on HTTP and Web Platform whenever we can). Expectation that Coordinators can build websites and depend on those for async flows.

Flow could work like this: Go to website, provide credential, do background check (website asks you how you want to be contacted once your credential is ready), 24-72 hours passes, website contacts individual based on their preferred contact mechanism, then a second exchange happens.

VC API design expectation is that interactions are fairly short, longer interactions leverage web platform for richer and more long-lived experiences. Don't want to re-invent things that exist for async communication. We want to avoid re-inventing a worse version of async communication.

A PR should be raised to explain that the VC API is designed for more short-lived interactions while more long-lived interactions depend on features that exist in the Web Platform or other ecosystems that already have asynchronous communication mechanisms (SMS/RCS, Email, phone communication, etc.).

[filip26]

The question I keep asking is: what’s the justification for implementing this API, aside from passing the W3C test suite? Keeping it simple sounds like a valid argument, but what if it ultimately adds little to no value?