Joseph Heenan

https://github.com/openid/OpenID4VCI/pull/391 I think fixes many of the issues with the deferred endpoint currently - if you could review it that would be great @nklomp ! We did discuss at one...

The discussion about this requirement appears to be proceeding on https://github.com/openid/OpenID4VCI/issues/360 I hence suggest we close this issue and continue in #360. If anyone objects please say otherwise we'll close...

As per above comment, closing in favour of https://github.com/openid/OpenID4VCI/issues/360 - let's continue the discussion there!

On point 2: The OAuth WG seems to have standardised on the issuer value to be used for aud in client authentication assertion JWT (but also requires other values to...

@David-Chadwick your comment doesn't appear to be related to the subject of this ticket, which is about whether we create a scheme for the issuer metadata or not. Credential schemas...

@selfissued The majority of those arguments also apply to providing examples in specifications though, and examples are highly valuable. We should examine the pros/cons rather than just considering the cons....

I think this is generally a good change to make given the limitations of existing OAuth servers, I do wonder if we actually need to add this as a 3rd...

If I understood this discussion correctly then I think this issue overlaps a lot with https://github.com/openid/OpenID4VCI/issues/342

I am struggling to see why it would be advantageous to define the token endpoint differently from how it is defined in RFC6749. I think it is pretty well understood...

> this charset parameter only explicitly indicates how to encode the characters in it Unfortunately it doesn't, the charset parameter has no defined meaning for this mime type.