CIBA - OpenID Provider Metadata
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.
Comments (8)
-
-
reporter 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?
-
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 ingrant_types_supported
for AS metadata andgrant_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 ingrant_types[_supported]
only for Ping and Poll modes. There are other metadata parameters that indicate support for CIBA in general likebackchannel_token_delivery_modes_supported
andbackchannel_authentication_endpoint
for the AS/OP andbackchannel_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.
-
reporter 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.
-
-
assigned issue to
- changed milestone to CIBA Implementer's Draft
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"
-
assigned issue to
-
Pull request
#60attempts to tidy up the text around OP metadata -
L216
suppoert -> support
-
- changed status to resolved
- Log in to comment
An interesting thing is that OIDC Discovery says the default value of
grant_types_supported
is["authorizatin_code", "implicit"]
althoughimplicit
will never be used as a value of thegrant_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
.