Add version and request type to protocol identifier for DC API #381
Conversation
awoie
requested review from
jogu,
tlodderstedt,
timcappalli,
c2bo,
paulbastian,
Sakurann,
leecam and
hlozi
|
Is there any issue with setting the value to |
| @@ -1958,7 +1958,14 @@ And lastly, as part of the request, the Wallet is provided with information abou | |||
|
|
|||
| ## Protocol | |||
|
|
|||
| To use OpenID4VP over the DC API, the value of the exchange protocol used with the Digital Credentials API (DC API), is `openid4vp`. | |||
| To use OpenID4VP with the Digital Credentials API (DC API), the exchange protocol value has the following format: `urn:openid:protocol:oid4vp:<version>:<request-type>`. The `<version>` field adheres to semantic versioning, and `<request-type>` explicitly specifies the type of request. This approach eliminates the need for wallets to perform implicit parameter matching to accurately identify the version and the expected request and response parameters. | |||
There was a problem hiding this comment.
| To use OpenID4VP with the Digital Credentials API (DC API), the exchange protocol value has the following format: `urn:openid:protocol:oid4vp:<version>:<request-type>`. The `<version>` field adheres to semantic versioning, and `<request-type>` explicitly specifies the type of request. This approach eliminates the need for wallets to perform implicit parameter matching to accurately identify the version and the expected request and response parameters. | |
| To use OpenID4VP with the Digital Credentials API (DC API), the exchange protocol value has the following format: `urn:openid:protocol:openid4vp:<version>:<request-type>`. The `<version>` field adheres to semantic versioning, and `<request-type>` explicitly specifies the type of request. This approach eliminates the need for wallets to perform implicit parameter matching to accurately identify the version and the expected request and response parameters. |
There was a problem hiding this comment.
If there are no requirements, I would use the shortest version possible, e.g., urn:openid4vp:1.0:signed, urn:openid4vp:1.0:unsigned. What do you think @c2bo @timcappalli ?
There was a problem hiding this comment.
Fine with dropping "protocol" but I believe keeping the org name is common practice. If length is the concern, maybe just use "oidf"? So it would be urn:oidf:openid4vp:1.0:signed.
@selfissued should weigh in here.
There was a problem hiding this comment.
I am happy with either one.
Adding the oidf seems to be a bit cleaner in terms of namespacing, but I don't think it's likely to encounter a naming clash here, so I guess urn:openid4vp:1.0:signed would be fine as well if we need/want to optimize for size?
There was a problem hiding this comment.
so there is some OIDF precedent. CIBA defines a URN-based grant type that includes both the organization and the type (in this case params): urn:openid:params:grant-type:ciba. There's also urn:openid:params:jwt:claim:auth_req_id and urn:openid:params:jwt:claim:rt_hash.
So if we wanted to be consistent with other OIDF specs, I think we'd want it to be urn:openid:protocol:openid4vp:1.0:signed.
@selfissued @ve7jtb any comments on this?
| * Unsigned requests: `urn:openid:protocol:oid4vp:1.0:unsigned` | ||
| * Signed requests: `urn:openid:protocol:oid4vp:1.0:signed` |
There was a problem hiding this comment.
| * Unsigned requests: `urn:openid:protocol:oid4vp:1.0:unsigned` | |
| * Signed requests: `urn:openid:protocol:oid4vp:1.0:signed` | |
| * Unsigned requests: `urn:openid:protocol:openid4vp:1.0:unsigned` | |
| * Signed requests: `urn:openid:protocol:openid4vp:1.0:signed` |
This PR adds version and request type to the protocol identifier for DC API.
Fixes #326, fixes #363