[Openid-specs-mobile-profile] login_hint_token format.

Lodderstedt, Torsten t.lodderstedt at telekom.de
Thu Dec 3 17:24:28 UTC 2015

Hi John,

the semantics differs significantly in that the OP must ensure the identity passed in the id_token_hint is authenticated by the transaction whereas login_hint_token is just this, an hint. The result of the authentication transaction may another identity.

Can we relax the semantics of this parameter? I think it could be useful for other use cases as well, e.g. if a RP wants to preset the identity to a certain PPID (but does not want to enforce this particular identity).

best regards,

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von John Bradley
Gesendet: Donnerstag, 3. Dezember 2015 16:20
An: Openid-specs-mobile-profile
Betreff: [Openid-specs-mobile-profile] login_hint_token format.

One possibility if we were to mandate the format to be encrypted JWT would be to use the existing id_token_hint parameter.

We would have the discovery service produce an encrypted (pseudo) id_token with no “sub” and the extra claims.
This is almost exactly what we have, but have been thinking that it would fit because it is not produced by the IdP.

On one hand using a different parameter name has little expense, on the other having two of something almost the same may be more confusing to developers.

The IdP already needs to support receiving encrypted id_tokens/JWT as the value of the parameter, so it would decrypt it and then look at the issuer to check the signature.
If the issuer is itself it is an id_token, if the issuer is the discovery service then it would know to take the extra parameter as the hint, rater then the sub.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20151203/015da3cd/attachment.html>

More information about the Openid-specs-mobile-profile mailing list