Ambiguity in Access Token request specification

[tomdaffurn]

We are using the Pre-Authorized Code Flow defined in OID4VCI. It builds upon OAuth 2.0 RFC6749.

However there seem to be some conflicts in the parameters to the Access Token Request:

1. code / pre-authorized_code field

RFC6749 says code is required, and must come from the Authorization Endpoint. We don't use that endpoint because Pre-Authorized Code Flow explicitly removes that step. So we have no value to use in the field.

OID4VCI says it complies fully with RFC6749, and addtionally has pre-authorized_code required. It appears to be for this same purpose as code.

2. grant_type value

RFC6749 says grant_type MUST be "authorization_code". OID4VCI introduces a new grant type "pre-authorized_code" which must be used in a Pre-Authorized Code flow. Does the new type supersede the RFC6769 requirement?

[decentralgabe]

Yes, it does supersede the requirement from RFC6769.

[KendallWeihe]

This is relevant to the PR I have open here https://github.com/TBD54566975/known-customer-credential/pull/12

Specifically you can see what I have in the Token Request table here https://github.com/TBD54566975/known-customer-credential/tree/kendallw/credential-iss-metadata?tab=readme-ov-file#token-request

• grant_type with the comment MUST be urn:ietf:params:oauth:grant-type:pre-authorized_code
• pre-authorized_code (without a code field, but also added a TODO below the table for when we support the auth flow)

[decentralgabe]

@selfissued do you believe that the OID4VCI spec text should be updated to make this clearer?

[selfissued]

It's already the case that OAuth 2.0 [RFC 6749] has an extension point that allows other grant types to be defined and used. The pre-authorized flow grant uses this extension point. So I don't see any conflicts.

If any of you believe that clarification language could help, I'd be glad to review it before proposing an issue on the OpenID4VCI spec.