CIBA: hint and hint_type
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:
- make it easy for implementations to ensure that multiple hints are not included in a backchannel authentication request,
- get flexibility in defining and adding hint types,
- avoid adding a new request parameter every time a new hint type is invented in the future, and
- 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)
-
-
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
-
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
-
- changed status to resolved
- Log in to comment
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.