Facilitating Submission of Referenced Claims with Integrity Support using multipart/form-data

[jruizaranguren]

Problem Statement

Certain scenarios necessitate the inclusion of sizable file-based claims within credentials, to be presented during verification. Examples of such claims include scanned documents, subject portraits conforming to ISO 18013-5, and various biometric records.

Verifiers may demand such claims to support situations where legacy processes intersect with digital credential procedures. This is especially relevant for Biometrics-based Holder Binding, as outlined in the OIDC4VP terminology section.

The current definition of OIDC4VP allows for the presentation of these claims within the VP token, either through a redirect call or encoded as application/x-www-form-urlencoded when Response Mode is set to direct_post. However, these options pose challenges when handling large-sized claims, a concern addressed in multiple discussions (see references below).

Proposal

To address the challenge of managing large claims, I propose enabling the content type multipart/form-data for the submission of Authorization Response in the direct_post Response Mode.

By doing so, various mechanisms can be employed to efficiently reference and submit files from verifiable credentials. Different parts of the multipart content can be utilized for the presentation_submission, vp_token, and additional evidence, ensuring referential integrity extracted from credentials in the vp_token using hashlinks, SRI, or other means. The filenames of each part can be linked to identifiers in the credentials.

This would enable a convenient and efficient to manage claims consisting in large sized files both in issuance and presentation, facilitating different means to retrieve and store such files.

References

• Integrity of related resources in W3C VCDM 2.0. Example:

"credentialSubject": {
  "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "image": {
    "id": "https://university.example.org/images/58473",
    "digestSRI": "sha384-ZfAwuJmMgoX3s86L7x9XSPi3AEbiz6S/5SyGHJPCxWHs5NEth/c5S9QoS1zZft+J",
    "mediaType": "application/svg+xml",
  },
  ...
}

• W3C subresource integrity
• W3C VCDM implementation guide, referencing credentials and evidence recommendations
• Proposal of VCDM confidence method at W3C-ccg group
• Anchored Resources and Hashlinks for VCs discussion
• Discussion on embedded attachments in Openid for Identity Assurance. Example:

"attachments": [
    {
        "desc": "Front of id document",
        "digest": {
        "alg": "sha-256",
        "value": "qC1zE5AfxylOFLrCnOIURXJUvnZwSFe5uUj8t6hdQVM="
    },
    "url": "https://example.com/attachments/pGL9yz4hZQ",
    "access_token": "ksj3n283dke",
    "expires_in": 30
    }
]

• Related discussion with portrait images in OIDC4VCI issue
• Distributed claims in OIDC-core
• Discussion on identifier binding and submission of evidence by web of trust
• Hashlinks
• Multipart/form-data

[Sakurann]

I think the challenge you are describing is sending large size data in the response? even if the media type defined for authorization response is application/x-www-form-urlencoded, it is an HTTP POST request so you should be able to send sizeable file-based claims you are talking about.

if the actual problem statement is the ability to send "attachments" alongside credentials, we can define a new parameter attachements that can be sent alongside vp_token=...&attachements=...

[jruizaranguren]

Thanks @Sakurann for your reply.

you should be able to send sizeable file-based claims you are talking about.

Agree, it can be effective in many cases. However, I also perceive a potential for optimization if we enable the transmission of large binary claims encoded as items in multipart/form-data. This approach would streamline processing as media types would be explicitly declared in the request, facilitating the decoding of non-textual content. A related issue for date claims.

Do you anticipate any confusion arising from enabling this form of content negotiation?

if the actual problem statement is the ability to send "attachments"

I think this would open interesting use cases and enable an extensibility point, but that was not the scope of this specific issue.

[jogu]

@jruizaranguren I notice this is your first submission and I'm not clear what your real name or company association is. Please can you confirm if you've signed the OIDF contribution agreement, https://openid.net/intellectual-property/contribution-license-agreement/ ?

Would it be correct to summarise this whole issue as:

It would be nice not to have to base64url encode binary data like images (and hence the suggestion to use multipart/form-data which would avoid this)

I think this would be a significant extra complication. It would be interesting to know if any other implementors see the need for this feature.

[jruizaranguren]

Please can you confirm if you've signed the OIDF contribution agreement

@jogu, I confirm. I use to assist to DCP meetings on thursdays.