batch issuance of mdocs

[Sakurann]

ISO 23220-3 currently defines the following BatchIssuance structure. there is a proposal to use the base64url-encoded representation of the CBOR-encoded BatchIssuance structure in the credential response. so, this would mean extending https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#appendix-A.2.4

BatchIssuance = {
    “docType” : DocType, ; Document type to be provisioned
    ? “dataElements”: NameSpacedData, ; new or updated data elements
    “instances”: [ +IssuerSignedDehydrated ], ; array of IssuerAuth, i.e. MSOs, and respective data
    ? “policy”: Policy ; information about usage policy of MSOs

Policy = {
    “one_time_use”: bool
}

Now, from here a personal opinion... I can see how this batch issuance structure could benefit frequent refresh of MSOs that have large portrait images. However, I don't support it since it adds a lot of protocol complexity, and changes processing logic for wallets - batch issuing sd-jwt is array of objects, but mdocs is array of one object. and believe that current mechanism of batch issue credentials should apply to mdocs too:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "credentials": [
    {
      "credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L"
    },
    {
      "credential": "YXNkZnNhZGZkamZqZGFza23....29tZTIzMjMyMzIzMjMy"
    }
  ],
  "notification_id": "3fwe98js"
}

[awoie]

IMO, it would be at least nice to have at least a way to indicate to the wallet that the credential endpoint can be used multiple times under the same authorization grant.

We could add an Issuer Metadata Parameter like this:

credential_refresh_supported: OPTIONAL. A boolean value indicating whether the Issuer allows multiple credential issuance requests under the same authorization grant. Default is true.

Example Metadata:

{
  "credential_refresh_supported": false
}

I'm not sure if the metadata endpoint is the right place to tell the wallet that credentials are one-time use but it could be the right place to tell the wallet they can request new credentials when they run out of credentials if they have a one-time use policy.

[GarethCOliver]

The primary reason for this structure is to prevent duplication of data in the request (most notable in cases like images and large batches)

I think we are better to have a flat structure, and provide a way to make use of JWE compression support (see: https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.3), which should be about as good while being much simpler (and work for other batched credentials).

The primary advantage of the mdoc dehydrated values is really if you can issue the data values once, and then do not need to include them at all on subsequent refreshes. It's neat (as likely you retrieve the new MSOs 100s of times without updating the data), but IMO in general it's not worth the complexity, and probably doesn't work well for formats outside of mdoc.

[jogu]

Discussed on today's WG call - would be good to get more input from implementors before making a decision.

If the response is compressed, the complexity of having the partial dehydrated structure may not help, but the full dehydrated structure may be useful in some use cases. In both cases of dehydration there's quite a lot of error-prone complexity for the wallet.

Consensus from this call is that the extra complexity is not worth putting into VCI and we should discuss with ISO whether it's really worth it.

[Sakurann]

WG discussion

• requirement is: how to batch issue large size credentials (like those that have a photo id)?
  • preferred option is to add guidance for JWE compression (what Gareth describes above: https://github.com/openid/OpenID4VCI/issues/480#issuecomment-2819632020) also because sd-jwt will have the same problem
  • could be separate structure like dehydrated, but that means credential response
• it's about both first-time issuance and refresh issuance
• some implementation experience for the exact mechanism that uses dehydration in batch credential response. assumption is that this dehydrated would not impact size much because
• @GarethCOliver will get us some numbers

[tplooker]

I agree that doing batch issuance as described in ISO 23220-3 is incredibly complex to support and probably not worth the value it would provide.

Its probably already obvious but we could perhaps make it clearer that even if we return multiple copies of a credential that multiple copies of the data element values dont have to be stored by the wallet. In essence the wallet could transform the credential response from the issuer to the ISO 23220-3 data structure for storage if it so wished.

[Sakurann]

WG discussion:

• do a PR with compression alg: https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.3 (OPTIONAL) and not hydrated option