[Openid-specs-ab] more than one hint in OIDC request

[Vladimir Dzhuvinov]

Hi Axel,

I think it will very much depend on the application / deployment. I 
don't know why the single hint requirement was chosen. Perhaps to keep 
the OP logic and / or the spec simple. RP-initiated logout allows two 
hints to be included in a request:

https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout

Is prompt (=none) a CIBA request parameter? According to my reading of 
the draft, it isn't. In addition to that, I'm not sure how safe it is 
for an OP to accept prompt=none in a CIBA flow. Say the OP issues the CD 
with a JWT after the first successful login, and the CD then takes that 
JWT as a login_hint_token or id_token_hint in a prompt=none CIBA 
request. Should the OP accept the CIBA request without any user 
interaction? With a prompt=none where the client is accessed via the 
user's the browser, there is always some initiating user interaction 
that triggers the request. If the client is on a different device and it 
sends a back-channel prompt=none request, the user is left completely 
oblivious. If that's intended, a refresh token seems like the honest 
approach.

> let the user enter their login identifier
Is this supposed to happen at the CD?


Vladimir

On 17/04/2024 14:56, Axel Nennker via Openid-specs-ab wrote:
>
> Hi,
>
> CIBA requires exactly ONE hint.
>
>   * Because in the CIBA flow, the OP does not have an interaction with
>     the end-user through the consumption device, it is REQUIRED that
>     the Client provides one (and only one) of the hints specified
>     above in the authentication request, that is "login_hint_token",
>     "id_token_hint" or "login_hint".
>
> In OIDC id_token_hint and login_hint are optional, but there is no 
> text on what the OP should do if there is more than one hint, and what 
> to do when the hints contradict each other.
>
> Options for prompt not none:
>
>  1. Id_token_hint takes precedent
>  2. Id_token_hint sub value and login_hint value are the same, than no
>     problem
>  3. Id_token_hint sub value and login_hint value contradict each
>     other, then return invalid_request
>  4. Id_token_hint sub value and login_hint value contradict each
>     other, then ignore both hints and let the user enter their login
>     identifier
>  5. If more than one hint is in the request, than return invalid_request
>  6. Write into the spec that the OP's behavior is unspecified, like in
>     the missing -"openid"-scope case
>  7. Some other claim in id_token_hint and login_hint match, than no
>     problem
>  8. Do not add clarifying text to the spec
>
> Options for prompt=none:
>
>  1. Basically the same option, except 4)
>
> In general the spec encourages the OP to be helpful. And hints are 
> only hints.
>
> So, I suggest adding:
>
> ```
>
> If `prompt=none` and there are both an id_token_hint and a login_hint 
> parameter in the request, then the id_token_hint takes precedent and 
> the login_hint parameter SHOULD be ignored. The authorization server 
> MUST not try to use the id_token followed by trying the login_hint or 
> vice versa.
>
> If there is no prompt parameter or its value is other then `none` and 
> there are both an id_token_hint and a login_hint parameter in the 
> request, then it is RECOMMENDED that the authorization server uses the 
> id_token_hint.
>
> ```
>
> What do you think?
>
> Kind regards
>
> Axel
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240420/45f265e2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240420/45f265e2/attachment.p7s>