Missing Discovery Metadata for login_hint types and login_hint_token type: backchannel_endpoint_login_hint_token_values_supported

Note this ticket has also been raised on the FAPI WG for Discussion.

I’d like to request registration of the following values in the IANA "OAuth Authorization Server Metadata" registry of [IANA.OAuth.Parameters] established by [RFC8414].

Metadata Name: backchannel_endpoint_login_hint_token_values_supported
Metadata Description: Supported CIBA login hint token structures.
Change Controller: OpenID Foundation MODRNA Working Group - openid-specs-mobile-profile@lists.openid.net
- Or OIDF Core given multiple different jurisdictions will need to have this registry updated.

I’d like to request registration of the following client metadata definitions in the IANA "OAuth Dynamic Client Registration Metadata" registry of [IANA.OAuth.Parameters] established by [RFC7591]:

Client Metadata Name: backchannel_endpoint_login_hint_token_values
Client Metadata Description: The support CIBA login hint token values that the client will use to initiate CIBA requests.
Change Controller: OpenID Foundation MODRNA Working Group - openid-specs-mobile-profile@lists.openid.net
- Or OIDF Core given multiple different jurisdictions will need to have this registry updated.

‌

I have a need to introduce OIDC discovery metadata to enable authorisation servers to advertise the types of login_hints and login_hint_token structures supported by an AS for CIBA flows.

In Brazil, which will be one of the first Open Banking ecosystems to adopt CIBA at scale there is a need to support up to 5 different login_hint_tokens.

Whilst the specifications leave the content of the structures up to each implementation I need a way of advertising and registering these types on the OIDC discovery document and would like to do so without introducing specific discovery metadata element for Brazil.

Ideally FAPI, MODRNA or CORE WG would introduce a discovery metadata element for CIBA potentially called

backchannel_endpoint_login_hint_token_values_supported where different jurisdictions could then register their tokens against. Given that multiple jurisdictions will have need of the same metadata property i believe the OIDF is best placed to register this claim. Different jurisdictions can then register their token types against this metadata registry

I would ideally like to quickly achieve consensus on the name of this metadata property as this will need to be rolled out by Brazil AS’s before year end.

‌

Comments (8)