CIBA - OpenID Provider Metadata

[Dave Tonge]

We received this via FAPI:

Why is [OpenID Provider Metadata] required ONLY for ones supporting ping and poll ? Why not for push ?

The text in question says:

OpenID Provider Metadata OPs supporting the ping or poll modes of CIBA SHOULD include the backchannel request grant type in the grant_types_supported field of their discovery metadata and SHOULD publish the supported token delivery modes for clients using CIBA.

I think we can tidy it up to make it clearer that its only ping/poll modes that require the grant_type, but that all CIBA implementations should have metadata.

[Takahiko Kawasaki]

An interesting thing is that OIDC Discovery says the default value of grant_types_supported is ["authorizatin_code", "implicit"] although implicit will never be used as a value of the grant_type request parameter of token requests.

It might be better to decide and mention explicitly whether a backchannel authentication request in "push" mode should be rejected or not when "backchannel_request" is not listed in grant_types_supported.

[Dave Tonge]

Yep this is a really interesting point. Its not just OIDD, but also https://tools.ietf.org/html/rfc8414 defines implicit to be included in this value.

However device flow doesn't mention adjusting grant_types_supported. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13#section-4 Even though it supports the equivalent of CIBA poll mode.

From my perspective it would seem clearer that grant_types_supported should be metadata about the grant types supported, NOT metadata about the grant types supported at the token endpoint. However maybe there is good rationale for the current approach. @b_d_c what are your thoughts?

[Brian Campbell]

My thoughts are that grant_types_supported is generally about the grant types supported at the token endpoint. implicit is and always has been a bit of an odd outlier in being a grant and not being a grant at the same time - it's use in grant_types_supported for AS metadata and grant_types for client metadata is indicative of that oddness and, I think, kind of a one-off to have some representation for the flow in metadata. I think it should remain a one-off and CIBA should use the URI in grant_types[_supported] only for Ping and Poll modes. There are other metadata parameters that indicate support for CIBA in general like backchannel_token_delivery_modes_supported and backchannel_authentication_endpoint for the AS/OP and backchannel_token_delivery_mode for the client.

The language could be tidied up some and maybe move the delivery mode stuff up front. But I don't believe any functional change is needed here.

[Dave Tonge]

I'd go with your suggestion then Brian. I do think we can make an editorial change to the language to make it clearer though.

[Brian Campbell]

The general consensus on the Jan 8th 2019 call http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20190107/001408.html was "Brian to propose text, editorial change"

[Brian Campbell]

Pull request #60 attempts to tidy up the text around OP metadata

[Takahiko Kawasaki]

L216

suppoert ->
support

[Brian Campbell]

85c19be