[Openid-specs-ab] Issue #1790: Add more context about the value that Token Endpoint brings in pre-authorized code grant (openid/connect)

[Kristina Yasuda]

New issue 1790: Add more context about the value that Token Endpoint brings in pre-authorized code grant
https://bitbucket.org/openid/connect/issues/1790/add-more-context-about-the-value-that

Kristina Yasuda:

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](https://hackmd.io/efrqSbUJSPKpOhJI8PwLvA?view)\), 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.\). 
* 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.
    
* much easier for a Credential Endpoint to support multiple grants. I might be wrong, but majority of Credential Endpoints would support both authorization code grant and pre-auth code grant, which means credential endpoint would consume access token in authorization code grant - why not simplify the design of a Credential Endpoint by makinf it also consume pre-authorized code..

I think the main point I am trying to mae 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…