```suggestion <reference anchor="IANA.Hash.Algorithms]" target="https://www.iana.org/assignments/named-information/named-information.xhtml"> <front> <title>Named Information Hash Algorithm</title> <author> <organization>IANA</organization> </author> </front> </reference> ``` per this comment https://github.com/openid/OpenID4VP/pull/197/files#diff-3118c9756a1d7b361bb53af8bd9d65666476a27cfeeced56c47a5dccc38eac55R291

```suggestion ``` per prior comments

It seems entirely inappropriate for these to URNs to be in an IETF OAuth namespace.

```suggestion This section registers the following media type [@RFC2046] ```

I suggest to put all these names in backticks to ensure they are formatted properly

I am extremely unsure about this. First of all, these values are not defined as URIs in the spec. and I don't think the intent of the section was to define these parameters normatively... and if we are registering these, we should also register `https://train.trust-scheme.de/info`.

for the same reasons given in vp_token registration, this can be token endpoint as well. same for other errors in this section other than `invalid_request_uri_method`

this is a parameter defined in SIOP v2 and not openid4vp ```suggestion ```

since this is an an authorization request parameter, is it possible to move it above vp_token and presentation_submission parameters? to have them in one place? same for response_uri and expected_origins below

this does not sound right. I know OpenID4VP spec officially sits in Connect WG now, but once it goes final, it gets moved to DCP WG. Practically, this should be DCP WG

Technically, can also be token response. That is why OpenID4VP spec uses a term `response` and not `authorization response`, because the flow is not limited to one request-response flow, but could also be used in authorization code flow. same for `presentation_submission` parameter below. ```suggestion * Parameter Usage Location: authorization response or token response ```