Asymmetry between credential and deferred credential endpoints

[nklomp]

Currently the credentials and deferred credentials endpoint are having a bit of an asymmetrical implementation.

The distinction between whether it is deferred or not is based on the HTTP response code 202 vs 200 and the response body of the credential endpoint. When deferred the transaction_id from the response needs to be used to post that value with the access token to the deferred endpoint, which in turn needs to be looked up from the metadata.

Then the deferred endpoint is returning the same response as the credential endpoint when the credential is available. If not available a 400 bad request with error issuance_pending. Given it is pretty normal to query the deferred endpoint whilst the credential is not available yet, it is odd to return an error for that. It also is not symmetrical with how the normal endpoint indicates that it will be a deferred flow by returning a 202. Returning a 202 when the issuance is still pending in the deferred endpoint makes sense. If you would go down that route the handling from a wallets perspective is the same for both endpoints.

However then it would also raise the question mentioned in #6 and #18 about the need for a separate endpoint for deferred credentials to begin with.

I see benefits from just having one endpoint for both direct and deferred issuance.

• No need to signal deferred issuance support in the server metadata perse, as the endpoint is the same and it will be the issuer anyway that returns the 200 or 202 in current spec. A wallet currently does not know up front anyway whether the issuer will return a 202 or 200 and/or whether that is for all credentials or for some, so the only need for the deferred endpoint is to look it up when a 202 is returned (it would have made sense to simply return that URL in the 202 response, allowing for more flexibility). An issuer does not need to implement deferred, by simply making sure it only directly returns credentials with a 200 response.
• Simplified logic for the wallet as it simply keeps posting to the same endpoint as long as a 202 is being returned. If a 200 is returned you are getting the credential.
• The issuer could update the c_nonce, making sure the wallet updates its proof
• Instead of having the interval value in the 400 error response for issuance_pending, simply return that in the 202, allowing for the issuer to increase this value over time (could also be done in current spec with issuance_pending to be clear)

The drawback of course is that you actually have 2 different requests for the same endpoint. One being the initial request, the other being the deferred request with the transaction_id. Given the endpoints are not following REST conventions anyway this drawback is a non-issue if you ask me.