CIBA: hint and hint_type

Issue #123 resolved
Takahiko Kawasaki created an issue

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).

Comments (4)

  1. 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.

  2. 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

  3. 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
  4. Log in to comment