Joseph Heenan
Joseph Heenan
In the wallet invocation section ( https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-7 ) this is one of the options: > no specific authorization_endpoint, user scanning a QR code with Authorization Request using a manually opened...
Clarify `aud` values that should be accepted in `private_key_jwt` at the token (and other) endpoints
There's some unfortunate history around the `aud` value that you use in `private_key_jwt` client authentication assertions. [RFC7523](https://datatracker.ietf.org/doc/html/rfc7523#section-3) says: ``` The JWT MUST contain an "aud" (audience) claim containing a value...
The "Examples with Credentials in Various Formats" section should be renamed as it contains normative text, e.g. the names of the Credential format identifiers.
The browser API appendix says: > The `client_id` and `client_id_scheme` MUST be omitted in unsigned requests defined in (#unsigned_request). The Wallet determines the Client Identifier from the origin as asserted...
There are two outstanding questions around `expected_origins` in the browser API ( https://github.com/openid/OpenID4VP/pull/155 ): 1. https://github.com/openid/OpenID4VP/pull/155/files#r1640368803 - Kristina asked if using `expected_origins` in unsigned requests could provide some security benefits...
Add further details of how errors are returned from Browser API including a example error response
As per @awoie comment here https://github.com/openid/OpenID4VP/pull/155/files#r1652002661: > It would make sense to add an error response example as well. and @marcoscaceres comment here https://github.com/openid/OpenID4VP/pull/155/files#r1660602655: > Errors should probably result in...
This is mostly ok, but we probably want to discuss more how one gets back a `DigitalCredential` instance, then how one gets the data out of it. Hi @timcappalli !...
As per https://github.com/openid/OpenID4VP/pull/155/files#r1653319017 there are some plantuml diagrams added in the browser API PR that are not incorporated into the specification. We would like those diagrams to be incorporated into...
`id` in the reasons object is currently defined as: > REQUIRED. A string value that specifies the reason within the scope of a particular response. I don't understand what this...
https://openid.net/specs/authorization-api-1_0-01.html#section-6.2.3 defines a 'reasons' object that's put inside a field called 'context'. It looks a bit confusing. (e.g. putting it inside a field called 'reasons' would look simpler, or perhaps...