101Coder101
101Coder101
Although being a non-normative overview, section "3.2. Cross Device Flow" mentions that the actual Authorization Request contains just a Request URI according to RFC 9101. This appears misleading, as RFC...
The `client_id` is said to be mandatory (section "5.2. Existing Parameters"), yet Appendix "A.2. Request" mentions it MUST be omitted in unsigned requests without giving any further information. This appears...
The document structure is somewhat misleading and/or not initially clear to a reader. As examples, I can name the following: - Section "3. Overview" mentions the cross-device flows having one...
Oversight in section "8.5. Error Response" in the definition of `invalid_request`: The second bullet incorrectly states three options for the authorization request. This may not be the only instance of...
The existing parameter `response_mode` only references that it is defined in RFC 6749, yet this parameter tells the wallet where/how to send the `vp_token` back to the verifier. This is...
The attack illustrated in the below message sequence chart shows the beginning of a normal flow between a victim and the credential issuer. During this flow, the adversary only becomes...
An adversary may request their own credentials from legitimate credential issuers. This requires him to be able to get an authorization code (or pre-authorized code in the respective protocol flow)...
The specification mentions the following: > The flow defined in this specification begins as the Credential Issuer generates a Credential Offer for certain Credential(s) and communicates it to the Wallet,...
After receiving a presentation, the verifier sends back a 200 response according to "[8.2. ](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-8.2)[Response Mode "direct_post"](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-response-mode-direct_post)": > If the Response URI has successfully processed the Authorization Response or Authorization...