Backchannel authentication endpoint is not an extension of authorization endpoint

Issue #98 resolved
Takahiko Kawasaki created an issue

"3. Authentication Request" in "OpenID Connect MODRNA Authentication Profile 1.0" starts with a paragraph shown below.

MODRNA supports all request parameters as specified in OpenID Connect Core 3.1.2.1 [OpenID.Core].

However, some parameters in OIDC Core 3.1.2.1 are apparently meaningless/impossible to support at a backchannel authentication endpoint. For example, redirect_uri, response_mode, display and ui_locales.

Some request parameters have the same names, but a backchannel authentication endpoint should be treated as an utterly different thing from an authorization endpoint.

So, the first paragraph of "3. Authentication Request" should be modified or completely removed. It would be better to list all request parameters for a backchannel authentication endpoint explicitly even if it may sound redundant than to say "MODRNA supports all request parameters as specified in OpenID Connect Core 3.1.2.1."

Comments (6)

  1. Brian Campbell

    Yes, agree that the backchannel authentication endpoint should be treated as an utterly different thing from an authorization endpoint. Recent work on CIBA (pull request #18, for example) has tried to make that distinction more clearly as they were previously intermixed in misleading or confusing ways.

    I think that CIBA's section "7.1. Authentication Request" should be updated to fully define the parameter values inline there and not reference back to "OpenID Connect MODRNA Authentication Profile 1.0" or "[OpenID.Core]" for them. That should further reduce ambiguity about the request to the backchannel authentication endpoint being anything but its own different and independent endpoint with its own different and independent request format.

  2. Brian Campbell

    But, as far as I know, "OpenID Connect MODRNA Authentication Profile 1.0" is a redirect based flow that is a profile/extension of OpenID Connect and does use the authorization endpoint. So that document probably shouldn't be changed for this.

  3. Brian Campbell

    pull request #33 has proposed changes to address this by defining login_hint_token, id_token_hint, login_hint, & binding_message directly in the Authentication Request section rather than referencing (sometimes erroneously) MODRNA Authentication or OIDC Core for them

  4. Brian Campbell

    merged pull request #33 to define login_hint_token, id_token_hint, login_hint, & binding_message directly in CIBA's Authentication Request section rather than referencing (sometimes erroneously) MODRNA Authentication or OIDC Core for them

  5. Log in to comment