Clarification needed for login_hint, login_hint_token and id_token_hint

[shilpa-padgaonkar]

Problem description The CIBA specs state that : "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 the profile docs, only the login_hint option has been mentioned so far. This could mean any of the below 2 interpretations:

1. Camara profile only allows the client to use login_hint
2. Camara profile allows all 3 options but has only elaborated on the format of login_hint within the profile. The format of for eg. a login_hint_token is up to the implementers to decide.

Expected action A clarification on which is the right interpretation should be added in PR121

Additional context FAPI

[palmerabollo]

Thanks, Shilpa. My understanding is that there was a consensus on using option 1.

I think the sentence "This CAMARA document makes the login_hint parameter REQUIRED if CIBA is used" leaves no option for other values (since you cannot send multiple values). But it is a good idea to make it more explicit if we think it can be a source of misinterpretations/interoperability issues.

[AxelNennker]

I think that some Camara APIs have no options here and they must use login_hint because there is no way they can have an id_token. Then naturally that API has to use login_hint and Camara should clarify the format of the tel or ip in login_hint.

I think that the restriction to login_hint in general is too restrictive. If the client has an id_token then that id_token was created by the AZ and the format of tel and ip are the one that the AZ created. So, by definition the AZ can also read the format of tel and ip. id_token_hint is a much more secure way of conveying sub because of the above reasoning. The AZ can check the signature of the id_token, therefore proof that was not tempered with and take the sub from the id_token knowing that it, the AZ, did issue the id_token itself.

CIBA writes in https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.14

An expired ID Token therefore could still be considered valid as an id_token_hint so an OP should, for some reasonable period, accept id_token_hints with an expiration time that has passed.

I would RECOMMEND that clients use id_token_hint IF they have an id_token. No harm done for Camara clients that do not have id_token - like in an user onboarding scenario.

[mhfoo]

@AxelNennker

The following is my understanding:

In CAMARA, the operator does not authenticate the end user, the backend application (the API Consumer) is responsible to authenticate the end user first (by their own method), before starting the CIBA flow with the operators for the purpose of invoking the CAMARA APIs.

[AxelNennker]

In CAMARA, the operator does not authenticate the end user, the backend application (the API Consumer) is responsible to authenticate the end user first (by their own method), before starting the CIBA flow with the operators for the purpose of invoking the CAMARA APIs.

CAMARA is more than CIBA.

Some APIs and use cases might require user consent to be collected by the operator and then the operator must authenticate the end user.

If consumption device and authentication device are the same, then CIBA might even be the wrong choice of protocol. (For some definition of "wrong").

What this issue is asking: Why should Camara should restrict itself to login_hint and forbid e.g. id_token_hint. If the client has got an id_token, then it is a better choice of "hint" because the AZ can verify that the id_token was created by itself, because the AZ has signed it.

The format of login_hint should be standardardized in Camara, but why should the other hints s be forbidden?

[jpengar]

Expected action A clarification on which is the right interpretation should be added in https://github.com/camaraproject/IdentityAndConsentManagement/pull/121

The original goal of this issue was to clarify and close the content of PR #121 regarding login_hint, login_hint_token and id_token_hint. IMHO, in the context of PR #121, as mentioned by @palmerabollo, we should only document option 1 (_Camara profile only allows the client to use loginhint), which is the one for which there was consensus. So the current PR content is already fine. We may be able to close this issue then.

I think the sentence "This CAMARA document makes the login_hint parameter REQUIRED if CIBA is used" leaves no option for other values (since you cannot send multiple values). But it is a good idea to make it more explicit if we think it can be a source of misinterpretations/interoperability issues.

Agreed, if we think the current sentence is unclear, we can rephrase it.

@AxelNennker Regarding the use of id_token as a hint (id_token_hint), your technical proposal is absolutely fine and standard. But the main concern for me is whether we/CAMARA should add a new implementation requirement for all operators (CAMARA compliant) to support id_token_hint when login_hint will be supported any way. All operators would have to support and implement it without an explicit requirement to do so.

[AxelNennker]

So the current PR content is already fine. We may be able to close this issue then.

Any objections to closing this?