[Openid-specs-mobile-profile] id_token_hint and login_hint

[Connotte, Joerg]

Thoughts about the id_token_hint and login_hint

>From the OpenID Connect specification:
id_token_hint
OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.
If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value.

login_hint
OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.

My interpretation:
The id_token_hint covers trevisting a specific Authorization Server which performed a login for this user previously. In case of Mobile Connect this will be a MNO or MVNO. Thus the "iss" parameter identifies the MNO direktly so no discovery is needed to re-login the user. On the other hand the "sub" parameter carries the unique id identifying the user to the MNO. If a Mobile Connect client uses the id_token as a hint for a login the identification step (e.g. asking the user for his MSISDN) can be omitted the the actual authentication can be initiated immediately. As the id_token was signed by the MNO the information can be considered trustworthy.

The login_hint is during a first time visit of a specific Authorization Server. However the structure of the login_hint is not specified so the client may need to know something about the Authorization Server to guess the most probable format of the login_hint. It is recommended that the hint matches the value for discovery. In Mobile Connect this is most probably the MSISDN. But it may be possible that the Authorization Server doesn't recognize the MSISDN as a login_hint. In that case the user will have to be prompted for identification again.

So login_hint can only give a rather unreliable hint about the identity of the user whereas the id_token_hint is very precise and usually reliable. I think we should recommend that developers should make use of the id_token_hint.

BR
Jörg