Paul Bastian
Paul Bastian
It should be discussed to mandate the JAR-encoded Authorization Request according to RFC9101 and restrict usage of URL- encoded Authorization Request from RFC6749 as 1. they do not offer integrity...
There is no fully fledged example containing a JARM-encrypted Authorization Response, which would be helpful to validate implementations. Right now we only have [this](https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-6.3.1-3)
For the actual Authorization Request there are currently three main options: 1. passing as URL with encoded parameters 2. passing a request object as value 3. passing a request object...
Right now, the specification says: > This specification assumes that a Verifiable Credential is always presented with a cryptographic proof of possession which can be a Verifiable Presentation. This would...
In the context of eIDAS 2, we require a Wallet/Issuer Trust Evidence, basically a key attestation made by the Wallet Provider ensuring that keys used for keybinding really reside in...
Imagine a basic scenario where a Wallet wants to request multiple Credentials with different Credential Datasets, e.g. multiple ePrescriptions. The challenge is how a Wallet knows how many Credential Requests...
Text around `cnf` parameter is not very clear to me. Is the support for `cnf` mandatory or the presense of the claim?
Do we have benefits of enforcing https://datatracker.ietf.org/doc/html/rfc9449#name-authorization-code-binding- ?
Closes #355 Closes #368 - [x] link to the point in the spec where this is being used - [x] add metadata - [x] discuss if we need cnf claim...
Partly solves #151 Remove the `claims`parameter from Credential Request for Credential Formats that support selective Disclosure anyway as this: - is a potential privacy leak to the Credential Issuer -...