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.