openid / openid/OpenID4VP

Credential format and supported algorithm negotiation

Open
#136 10 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

discuss if we do this
Dominant language
Shell
Stars
112
Forks
38
Avg merge
12d 19h
Merged PRs (30d)
4

Description

As raised on the DCP WG call on the 26th of March, currently the text in OpenID4VP is as follows.

The formats supported by a Verifier may be set up using the metadata parameter vp_formats (see Section 9.1). The Wallet MUST ignore any format property inside a presentation_definition object if that format was not included in the vp_formats property of the metadata.

In essence this establishes that the client metadata takes precedent over the formats element in the presentation definition. HAIP also further re-enforces this with the following text

The presentation of a SD-JWT VC is requested by adding an object named vc+sd-jwt to the format object of an input_descriptor. The object is empty.

I think there is a desire to now instead use the format feature in P.E instead of client metadata. I would prefer we strengthen the language in OpenID4VP to make it clear that the format property of the presentation definition should never be used and instead use only client metadata for this negotiation. Supporting doing the negotiation around this information in two places is likely to create significant confusion.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the cited OpenID4VP Section 9.1 text and the HAIP passage about the vc+sd-jwt format. Review how vp_formats and presentation_definition formats are described, then determine the agreed single negotiation mechanism with the working group. Done means the relevant normative wording clearly reflects that decision.

Written by the indexing model from the issue text.

Assessment

Domain
authentication, documentation, security
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.