CIBA's Backchannel Authentication Endpoint definition and metadata registration

[Brian Campbell]

CIBA introduces a new endpoint sometimes called Backchannel Authentication Endpoint and sometimes called bc-authorize (also kinda implying that bc-authorize should be the actual path, which is something that shouldn't be dictated by spec). The new endpoint should be introduced/described in the spec with a consistent name and then define and register a new Authorization Server Metadata parameter for it that allows the AS to determine the endpoint URI and publish it in metadata. The OAuth 2.0 Device Flow does this with its Device Authorization Endpoint (in https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10#section-2 and https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10#section-4 and https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10#section-7.3) which is similar in many respects to CIBA's new endpoint and is a good pattern to follow.

http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20180702/001192.html

[Dave Tonge]

I fully agree with this. The bc-authorize path should only appear in examples.

@b_d_c a quick question, how does the OAuth 2.0 Authorization Server Metadata spec interact with OpenID Connect Discovery? Would the endpoint need to be registered as a metadata parameter for both?

[Brian Campbell]

I'm not sure it's documented well anywhere but my understanding is that the intention was to share the registry created by OAuth 2.0 Authorization Server Metadata (now RFC 8414) and to have OpenID Connect Discovery register its parameters after the fact. That registry does finally now exist https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata so I guess the Connect WG needs to follow up on getting those registration requests in.

But as far as CIBA is concerned, the endpoint only needs to be registered as a metadata parameter in the one place at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata

[Brian Campbell]

PR https://bitbucket.org/openid/mobile/pull-requests/16/backchannel-authentication-endpoint/diff attempts to address this.

[Dave Tonge]

looks good to me

[Petteri Stenius]

Looks good to me too.

One minor thing: I think the convention set by RFC8414 is use "_supported" suffixes on certain parameter names. If we follow this convention then the name of backchannel_token_delivery_modes parameter should probably be backchannel_token_delivery_modes_supported.

[Brian Campbell]

That's a good point @jeps but not strickly related to this ticket or pull request #16 so I created a new issue #88 to track it.

[Brian Campbell]

merged pull request #16