Issuance of transaction_ids

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2043

Original Reporter: danielfett

The following points are not clearly defined in the spec right now:

(A) In a batch (deferred) issuance, will there be one transaction_id for all deferred credentials or will it be the same for all?

(B) How is the transaction_id or are the transaction_ids returned? There is the following example in the spec:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
   "credential_responses":[
      {
         "transaction_id":"8xLOxBtZp8"
      },
      {
         "format":"jwt_vc_json",
         "credential":"YXNkZnNhZGZkamZqZGFza23....29tZTIzMjMyMzIzMjMy"
      }
   ],
   "c_nonce":"fGFF7UkhLa",
   "c_nonce_expires_in":86400
} 

This shows one transaction_id per credential; in case there are many deferred credentials, will it be the same for all credentials (repeated, say, 100 times for 100 credentials) or will there be different ones?

(C) How is the wallet supposed to hit the deferred credential endpoint and what will be returned from the endpoint? See also https://bitbucket.org/openid/connect/issues/1759/no-need-for-credential-endpoint-when-we

[tlodderstedt]

The deferred credential request takes a single transaction id and results in one (or no) credential being issued.

Request

Host: server.example.com Content-Type: application/json Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW

{ "transaction_id":"8xLOxBtZp8" }

Response

HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store

{ "format": "jwt_vc_json", "credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L" }

So there MUST be one transaction id for every credential that shall be issued. Otherwise, the issuer cannot resolve the credential the wallet is requesting.

[danielfett]

Then that should be made a little bit more explicit in the text.

Question C remains.

[tlodderstedt]

re C): the wallet determines the deferred credential using the deferred_credential_endpoint metadata parameter and sends a POST request as defined in section 9.1. with the access token in the header and transaction_id as body parameter.

The response is the same as for the normal credential endpoint. I think this is stated in section 9.2. What is missing?

[Sakurann]

maybe misunderstanding here is that currently there is no option to do Deferred Batch Issuance? If a wallet sends a batch request, but the issuer cannot issue right away, request fails and no transaction_ids are returned.. This decision was made to simplify batch issuance and its success/error conditions. When using credential endpoint, the wallet will have to make as many deferred credential requests as transaction_id it received from the credential endpoint.

[jogu]

I think some of these points are no longer relevant now that the batch endpoint has been removed, however I think some of the same issues still apply when multiple proofs are provided to the credential endpoint to get batches for unlinkability.

In particular the deferred credential response I believe needs to be able to return credentials as well as credential.

[tlodderstedt]

I think the deferred credential response should have been extended to support batches in the same way as the credential response when the batch option was introduced there. Let's do it now.

[paulbastian]

In particular the deferred credential response I believe needs to be able to return credentials as well as credential.

I think that's the only thing to be done for this issue as we removed the batch credential endpoint.