What are the protocol identifier naming rules?

[timcappalli]

As we've learned with OID4VP, there are variations of request types (signed vs unsigned) [#185, openid/OpenID4VP/issues/326], and there will be future versions of the protocol.

As the protocol identifier is essentially "typing" the data payload for downstream parties, we need to support a richer protocol identifier beyond a string.

This proposal is to make protocol identifier a URN. For example:

• Signed Requests in OpenID for Verifiable Presentations v1.0: urn:openid:spec:openid4vp:v1.0:signed
• Unsigned Requests in OpenID for Verifiable Presentations v1.0: urn:openid:spec:openid4vp:v1.0:unsigned
• OpenID for Verifiable Credential Issuance v1.0: urn:openid:spec:openid4vci:v1.0:<blah>

(for VCI, should the type be the two different flows (authz code and preauthz code)?)

These identifiers would still be defined in their respective specifications, but high level requirements would be defined here, including requiring this type of identifier for registry inclusion.

[timcappalli]

Important "min bar" details seem to be:

• protocol name
• protocol version
• payload variants

[hlozi]

ISO/IEC 18013-7 defined a protocol identifier as “org.iso.mdoc” for the protocol outlined in annex C.

[timcappalli]

ISO/IEC 18013-7 defined a protocol identifier as “org.iso.mdoc” for the protocol outlined in annex C.

That identifier wouldn't meet the criteria as it doesn't specify a version, which is one of the core reasons we introduced this.

[Sakurann]

Important "min bar" details seem to be:

• protocol name
• protocol version
• payload variants

what is the justification for this min bar?

based on the discussion in DCP WG, I really don't think protocol version and payload variants need to be in the identifier. https://github.com/openid/OpenID4VP/pull/381/files#r1924246284

[timcappalli]

what is the justification for this min bar?

This was discussed in both the DC API calls and the DCP WG in OIDF and these 3 were the result of those discussions. The min bar is the boundary where a request structure can deviate at the top level.

E.g. a signed and unsigned request have different top level members, and a major version change could introduce further differences.

[marcoscaceres]

From the DC API call on Wed Jan 22:

• it's an opaque string (avoid URLs, URNs, structured/parsable things)
• uniquely identifiable
• consider versioning if needed
• consider variance, if you really need it
• try to be consistent

But all that matters is that it's an opaque string on the W3C side... or, at least, that should be the guidance that the W3C gives on minting identifiers.

[leecam]

Adding my suggestion from the call:

"The protocol name should uniquely define the set of required parameters and/or behavior that a wallet implementation needs to support to successfully handle the request. If the set of required parameters or behavior is updated in a way which would require a wallet to also require an update to remain functional, the protocol should be given a new name."

[bc-pi]

Adding my suggestion from the call:

"The protocol name should uniquely define the set of required parameters and/or behavior that a wallet implementation needs to support to successfully handle the request. If the set of required parameters or behavior is updated in a way which would require a wallet to also require an update to remain functional, the protocol should be given a new name."

Lee's suggestion seems very reasonable.

[bc-pi]

Adding my suggestion from the call:
"The protocol name should uniquely define the set of required parameters and/or behavior that a wallet implementation needs to support to successfully handle the request. If the set of required parameters or behavior is updated in a way which would require a wallet to also require an update to remain functional, the protocol should be given a new name."

Lee's suggestion seems very reasonable.

But is more related to #185 or #58. The latter has an open PR #157 that currently has the text "Avoid using version numbers in the protocol identifier."

[timcappalli]

Adding my suggestion from the call:

"The protocol name should uniquely define the set of required parameters and/or behavior that a wallet implementation needs to support to successfully handle the request. If the set of required parameters or behavior is updated in a way which would require a wallet to also require an update to remain functional, the protocol should be given a new name."

I think we will need to add an example. I don't think someone who picks up the spec for the first time will have the context to understand what that means in practice.

[timcappalli]

2025-01-25 call:

• Lee's text overall looks good
• agreement that including an example would help understanding

[marcoscaceres]

The protocol identifiers should be representable as (Web IDL) enum values and should thus adhere to both the TAG's guidance for such strings and to the WebIDL spec's guidance on enum values:

"It is strongly suggested that enumeration values be all lowercase, and that multiple words be separated using dashes or not be separated at all, unless there is a specific reason to use another value naming scheme. For example, an enumeration value that indicates an object should be created could be named "createobject" or "create-object". Consider related uses of enumeration values when deciding whether to dash-separate or not separate enumeration value words so that similar APIs are consistent."

And from the TAG's guidance:

Enumeration values Lowercase, dash-delimited