You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
.The text was updated successfully, but these errors were encountered: