Paul Bastian
Paul Bastian
I got Implementer feedback twice, that it is confusing, that `tx_code` is the parameter value for both: - the descriptor of the Transaction Code in the Credential Offer including the...
I think this is a great improvement to the spec. A few questions remain for me: - Could we use this to solve the questions whether the Wallet needs to...
I see a potential security issue as some parameters in the Credential Issuer Metadata may be self-asserted, in particular: `display`.`name`, `credentials_supported`.`display`.`name` and `credentials_supported`.`display`.`logo`. These values are today taken by Wallets...
Selective-Disclosure enabled credential formats give the inherent mechanism for data minimization. Therefore, the need to specify the claims that shall be in a credential (done in authorization_details) adds unnecessary complexity,...
OpenID4VP has a (small) section on how the Wallet shall be launched/invoked/started. At least copying the section would not seem like a bad idea to me. Especially section at https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-4.1-1...
> As I stated in the WG Call, I believe that `credential_configuration_id` is the better choice. In general, I have trouble understanding how OpenID4VCI works well without metadata, as the...
Within the eIDAS ecosystem, Wallet attestations are being discussed. One of the proposed mechanisms how to prove the authenticity of a Wallet and potential hardware keys is [Attestation-Based Client Authentication](https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/)....
Suggestion: Change the title in between releases to "OpenID for Verifiable Credential Issuance - editors draft"
In the current state, according to RFC9101, the Wallet must fetch the Request Object from `request_uri` without having any means to verify the identity and authenticity of the Verifier. The...