[Openid-specs-ab] Issue #1524: Is it OpenID Connect Core when Authorization Request is sent to the OP without using redirects via a user agent? (openid/connect)

[Kristina Yasuda]

New issue 1524: Is it OpenID Connect Core when Authorization Request is sent to the OP without using redirects via a user agent?
https://bitbucket.org/openid/connect/issues/1524/is-it-openid-connect-core-when

Kristina Yasuda:

The context is how OpenID Connect is used in ISO/IEC 18013-5 \(mDL\) specification. When the End-User is authenticated and has authorized RP getting the mDL data, RP receives an mDL token from the End-User’s application. RP than sends that mDL token to the OP in the Authorization Request, but without redirects nor any user agent involvement, because there is no need for the user interaction using the frontchannel.

There were suggestions this resembles CIBA because the Authorization Request is sent directly from the RP to the OP, but CIBA would require the Issuer to talk to the user for authentication, after receiving the Authorization Request from the reader, which is not happening in 18013-5 OpenID Connect either. If any, this is closer to a \`login\_hint\` mechanism that allows OP to skip a user interaction when it can identify an existing session for the user identified using \`login\_hint\` received from the RP.

 We had a similar requirement in [OpenID for Verifiable Credential Issuance](https://openid.net/specs/openid-connect-4-verifiable-credential-issuance-1_0.html#name-pre-authorized-code-flow) specification, to enable a use-case when the user has provided consent and authorization prior to the beginning of the flow. We defined pre\_authorized\_code \(equivalent to the token that mDL holder sends to the reader\) that RP can send directly to the Token Endpoint, though it is not recommended from the security perspective – since preauthorized code is not sender constraint. 

I think there are two options:

1. Adopt a model similar to OpenID for Credential Issuance and merge WebAPI and OpenID Connect options in 18013-5. Reader will be able to take mDL token directly to the Token Endpoint of the Issuer.
2. Explicitly state that OpenID Connect in 18013-5 is an extension to OpenID Connect Core, where RP can send the Authorization Response directly to the Authorization Endpoint of the Issuer. 

OpenID Connect has already been extended beyond using only browsers as user agents in App-to-App use-cases. Would it be acceptable to extend OpenID Connect Core to enable no-redirect-between-RP-and-OP usecase..?