Adding a version to the protocol identifier, and making it a URN

[timcappalli]

The W3C Digital Credentials API specification will have a registry. In this registry, protocols will be normatively mapped to their respective specifications.

In the API itself, the protocol identifier is passed in the request as the protocol field, currently: openid4vp.

In #326, we've been discussing how two types of requests (signed vs unsigned) may want to have different protocol identifiers, as the top level contents of the request differ significantly. So having a type appended to the identifier can help (ex: openid4vp-signed).

One thing that is missing is the protocol version. When we inevitably end up with different versions of the specification, the protocol identifier needs to accurately represent the request payload. One can imagine sending two versions of the same request in the event the user only has a wallet that speaks an older version of the protocol.

To support both a version number (this issue) and request type (#326), I've proposed that the DC API use URNs for protocol identifiers: WICG/digital-credentials/issues/191.

Example for a signed request v1.0: urn:openid:spec:openid4vp:v1.0:signed.

[timcappalli]

Adding the questions from yesterday's discussion here to gather additional feedback:

1. Should version number be in the protocol identifier? (y/n)
2. What specificity should the version number be? (major, minor / just major)
3. Should the request type (e.g. signed or unsigned) be included in the protocol identifier (y/n)
4. What format should the protocol identifier be? ( urn, unstructured string)

[timcappalli]

On the 2025-01-22 and 2025-01-25 Digital Credentials API calls, consensus was reached that:

• the protocol identifier does not have to be a URN
• the protocol identifier should (SHOULD vs MUST is still up for debate) change if the the set of required parameters and/or behavior of the wallet implementation needs to change to support the protocol version

Does that change the proposal in PR #381? @awoie @Sakurann

/cc @leecam @marcoscaceres

[awoie]

On the 2025-01-22 and 2025-01-25 Digital Credentials API calls, consensus was reached that:

• the protocol identifier does not have to be a URN
• the protocol identifier should (SHOULD vs MUST is still up for debate) change if the the set of required parameters and/or behavior of the wallet implementation needs to change to support the protocol version

Does that change the proposal in PR #381? @awoie @Sakurann

/cc @leecam @marcoscaceres

IMO, the proposed solution still meets this requirement while also introducing an additional requirement: the protocol identifier must be a URN. I’ve updated the proposal to remove the minor version from the protocol identifier. Note that the signed/unsigned distinction remains part of the protocol identifier, but I’m open to removing it if @hlozi objects to keeping it.