- edited description
CIBA's Backchannel Authentication Endpoint definition and metadata registration
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
Comments (9)
-
reporter -
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 withOpenID Connect Discovery
? Would the endpoint need to be registered as a metadata parameter for both? -
reporter 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 haveOpenID 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
-
-
assigned issue to
-
assigned issue to
-
PR https://bitbucket.org/openid/mobile/pull-requests/16/backchannel-authentication-endpoint/diff attempts to address this.
-
looks good to me
-
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.
-
reporter That's a good point @jeps but not strickly related to this ticket or pull request #16 so I created a new issue
#88to track it. -
- changed status to resolved
merged pull request #16
- Log in to comment