Is it OpenID Connect Core when Authorization Request is sent to the OP without using redirects via a user agent?

[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 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..?

[Tobias Looker]

What is the usecase for sharing a presented mDL with an authorization server in this context?

[Kristina Yasuda]

mDL gets presented from the Issuer (OP) to the reader, the user is only sharing a token that the reader uses to retrieve authorization code from the OP

[Tom Jones]

it might be more accurate to say that a presentation is created from the mDL for the Verifier (RP) based on a request from the Verifier.

[Michael Jones]

As discussed on the 16-Jun-22 working group call, the flow described uses extensions beyond what’s defined by OpenID Connect Core.

As discussed in the following 16-Jun-22 SIOP Special Topics call, if ISO needs something from the OpenID Connect working group, we could consider taking on that work once we understand concretely what is needed.