Add more context about the value that Token Endpoint brings in pre-authorized code grant

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1790

Original Reporter: KristinaYasuda

Talking to the current/potential implementors, a question, “why not send pre-authorized code directly to the Credential Endpoint?“ keeps popping up. Sure, one can design an OAuth 2.0 Token Exchange style “credential issuance“ (thought experiment here), but I strongly believe in the flexibility and extensibility that Token Endpoint brings. Below are few bullet points why - would love feedback/discussion if the WG agrees with the reasoning and if I am missing something:

• Different function, different endpoint. Without Token Endpoint, Credential Endpoint will have to take care of all of the security aspects of the protocol flow (ie User authentication, Client authentication, validation of a pre-authorized code, validation of user_pin, etc.), instead of being focused on validating a proof for holder binding and issuing a credential (ie getting the user data, signing it, etc.).

• increased security when Wallet needs to be accessed at the Credential Endpoint, since Access Token can be made sender-constrained and be refreshed. Pre-authorized code that can be communicated to the wallet via the means that can be intercepted, such as email, physical mail, QR code, etc. is insecure and unreliable when Access Token can be made sender-constraint, or can be refreshed using a Refresh Token. This is especially important in the following scenarios where user consent to issue multiple credentials in three scenarios is communicated via a pre-authorized code:

  • in a multiformat world we are in, Credential Endpoint is highly likely to support issuance of multiple formats (ISO mDL, SD-JWT, JSON-LD VC, OpenBadges, etc.).
  • to achieve Verifier unlinkability without ZKPs/advanced crypto, Credentials are issued with the same data, but bound to varying user identifiers to enable pairwise identifiers per Verifiers.
  • for some credentials, like ISO mDL, Issuer’s signature has to be renewed regardless of the validity of the data (ie licence expiration date), in which case, credential has to be resigned periodically.

• Credential Endpoint should not care the grant type, when issuing VCs. I might be wrong, but majority of implementations would need both authorization code grant and pre-auth code grant. Without access token in a pre-auth grant, credential endpoint would have to consume access token in authorization code grant - architecture becomes much simpler if Credential Endpoint just have to consume an access token.

I think the main point I am trying to make is that pre-authorized code is not a security token that is not suitable to protect an API (Credential Endpoint), but I might need help using correct terms…

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

“Credential endpoint should not care about the grant type”

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

SIOP call: the suggested action is to "add a text in the spec clarifying the value, without mentioning an option to send pre-auth code directly to the credential endpoint"

[Sakurann]

I think issue answered a question on why token endpoint very well, and there has been less questions on this topic. closing for now.