CIBA: hint and hint_type

[Takahiko Kawasaki]

This may be too late to suggest, but I'm feeling that hint and hint_type request parameters would be better than having a different request parameter per hint type.

The current spec has three request parameters, login_hint_token, id_token_hint and login_hint. They represent hints and they must not coexist in a backchannel authentication request.

My suggestion is to abolish the three request parameters and define new hint and hint_type request parameters as follows:

name	description
hint	An arbitrary string. Its format depends on hint_type.
hint_type	id_token, etc.

By adopting this style, we can:

1. make it easy for implementations to ensure that multiple hints are not included in a backchannel authentication request,
2. get flexibility in defining and adding hint types,
3. avoid adding a new request parameter every time a new hint type is invented in the future, and
4. move detailed hint-type-specific descriptions to other section or to other separate spec documents.

See also my comment added to Issue #71 (CIBA hint validation clarification).

[Brian Campbell]

I must admit that I find the three hint request parameters to be somewhat awkward. But could only pick so many things to focus on when assuming the co-editor role and didn't think it was awkward enough to warrant changes. I do think there are some nice things about a hint/hint_type approach but also some considerations like what the hint type values actually are and if some registry needs to be established. Checking that only a single hint is included is not really that hard. And I don't anticipate needing new hint types. Ultimately, I don't think that the benefits of this style are sufficient to justify making a change. Particularity at the current late stage of things.

[Dave Tonge]

I agree with Brian - I don't think the benefits of this are that great to warrant making the change. Its worth noting that id_token_hint and login_hint are both from OIDC Core

[Dave Tonge]

We discussed this on the call and decided that we will keep the existing behaviour for the following reasons:

• it better reflects the front-channel
• it doesn't need a registry
• login_hint and login_hint_token are fairly generic and therefore there is already extensibility built into the spec