Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add version and request type to protocol identifier for DC API #381

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add version and request type to protocol identifier for DC API #381

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d472f38
fix: add version and request type to protocol identifier
awoie Jan 10, 2025
8cb8eb7
fix: added normativity
awoie Jan 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Member

@timcappalli timcappalli Jan 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

@timcappalli timcappalli Jan 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


The value `1.0` MUST be used for the `<version>` field to indicate the request and response conform to this version of the specification. For `<request-type>`, unsigned requests, as defined in (#unsigned_request), MUST use `unsigned`, and signed requests, as defined in (#signed_request), MUST use `signed`.

The following exchange protocol values are defined by this specification:

* Unsigned requests: `urn:openid:protocol:oid4vp:1.0:unsigned`
* Signed requests: `urn:openid:protocol:oid4vp:1.0:signed`
Comment on lines +1967 to +1968
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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`

hlozi marked this conversation as resolved.
Show resolved Hide resolved

## Request {#dc_api_request}

Expand Down
Loading