CIBA hint validation clarification

[Brian Campbell]

§7.2 of CIBA draft in bitbucket and §4.2 of the published version have the following text regarding validating the provided hint in the authentication request.

    The OpenID Provider MUST validate the hint provided (login_hint, login_token_hint or id_token_hint).
    e.g.: If a signature is provided it MUST be checked. If a validity date is provided it MUST be checked.
    If the hint is not valid or if the OP is not able to determine the user then an error should be returned to the Client as per section Authentication Error Response.

Such validation doesn't really make sense for login_hint so it should probably be omitted for the MUST here. Perhaps it could by said elsewhere that if the login_hint value isn't recognized by the AS/OP then return an error. But I think the requirements for checking each different hint type should be have separate treatment in the draft.

For id_token_hint in particular this validation requirement is very problematic as an ID Token is issued for a different context to a different audience and typically with a shortish validity period. Whereas a CIBA client might reasonably want to use an ID Token received days or weeks or more ago as an id_token_hint value. Such an ID Token would be expired and not have the AS/OP as an audience. It's possible that, due to key rotation, the AS/OP doesn't even have access to the the keys to check the signature. OIDC core kind of touches on the issue by saying the AS need not be listed as an audience of the ID Token when used as an id_token_hint value. The id_token_hint from OIDC core isn't the most clearly defined parameter to begin with and while CIBA defers to OIDC for it's definition the usage is somewhat different. But potentially more important to a CIBA flow. As it is, consistent, interoperable, or useful treatment of id_token_hint seems unlikely. I believe that the id_token_hint should be considered simply a hint only and that it should not be validated.

Validating the login_hint_token does make sense as it is presumably issued for this purpose. That requirement should just be stated separately from the other hints.

I just noticed that the text quoted above uses login_token_hint while the rest of the document uses login_hint_token, which should be fixed.

It would also be nice for implementations and profiles other than MODRNA that want to use CIBA, if the login_hint_token was defined more generally as a JWT that's content identifies the end user whom to authenticate in the background rather than deferring to OpenID Connect MODRNA Authentication Profile 1.0. I think, after reading the login_hint_token text from that profile, that the login_hint_token can be a plain old JWT. But I think its use in CIBA would be easier to understand if the text in CIBA said something to the effect that it is a JWT/token used to pass a hint about the user into the authentication process and then point to the MODRNA profile as one example of such.

http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20180709/001195.html

[Dave Tonge]

Thanks Brian. Agree with all these points.

With regards to the id_token_hint I believe that for many CIBA implementations this needs to be more than a hint and does require some validation. The common (and perhaps only) use case will be that it is an id_token issued by an OP to an RP that the RP uses to send back to the same OP, i.e. validation should be:

• iss must be the issuer value of the OP
• aud must be the client_id of the RP, i.e. must match the authenticated client at the backchannel authentication endpoint
• iat should be within an agreed time-limit, i.e. the OP could state that it only accepts id_tokens issued within the last 3 months. It is unreasonable for an OP to be expected to accept historical id_tokens indefinitely.

I agree there is an issue with key rotation, however I think that OP implementations will need to work around this and store previously rotated keys for a fixed time period, e.g. the 3 months mentioned above.

With regards to the login_hint_token, I agree that a more general definition would be beneficial. Specific profiles of CIBA could optionally define specific claims that can be in the token, but the core spec should not.

[Dave Tonge]

Thinking about this some more if the subject identifier issued by the OP is a pairwise identifier then the id_token_hint wouldn't require validation. Rather the OP would just have to ensure that the sub claim contained a pairwise identifier that had been issued to the authenticated client, i.e. possession of an id_token and possession of a pairwise identifier are of equal value.

[Brian Campbell]

I think it gets very tricky to define the validation rules for a token being used out of context like this. Which is why I'm suggesting that it be unvalidated hint only that's used just as a blob of info to identify a user from a prior interaction. But I also know that's controversial. One way or the other, at a minimum the different hint types need distinct treatment in the draft.

[Brian Campbell]

On the 9/24 MODRNA call there was some discussion and support around something like security considerations or suggestions/guidelines for what could/should be validated in an id_token_hint.

[Dave Tonge]

https://bitbucket.org/openid/mobile/pull-requests/27/update-text-around-validating-hints/diff

[Dave Tonge]

We discussed having some general rules around processing login_hint_tokens:

• The shouldn't be expired / not valid yet
• They should have the correct audience

We shouldn't require them to be encrypted and we shouldn't require them to have an expiry.

[Jörg Connotte]

wrt to Brian's comments on the payload of the login_hint_token: We invented login_hint_token as a very specific form of an id_token_hint to be used between discovery service and OIDP. I don't think we should reuse it for other purposes. I agree that validation of the various hint's should be specified separately. Especially login_hint in it's basic form cannot really be validated.

[Dave Tonge]

I'll close this issue and open a new one for adding specific validation requirements for id_token_hints into the mobile profile

[Brian Campbell]

pull request #38 has some changes/additions to the text that I'd ask be considered

[Dave Tonge]

Hi Brian - I like your proposed wording, I think it gets across the issue really well.

[Brian Campbell]

Thanks Dave. I'm going to merge pull request #38 then

[Takahiko Kawasaki]

I'm sorry for making a comment to this resolved issue. The description of Section 15 in draft-06 says as follows.

Given these restrictions, implementers may consider not verifying the signature at all and only accepting ID Tokens with pairwise subject identifiers as hints.

This may be interpreted like "implementations that don't verify signature at all should not support id_token_hint if they don't support pairwise subject type."

However, is this note necessary?

To verify id_token_hint is to verify the end-user authentication which was performed in the past. The purpose of a verifiable token (i.e. ID token) is to use the authentication information without redoing end-user authentication. However, an implementation of the backchannel authentication endpoint will perform end-user authentication again after receiving id_token_hint and extracting the value of the sub claim from it. If end-user authentication is about to be performed again, is it necessary to verify the end-user authentication performed in the past (i.e. id_token_hint)?

IMHO, it is better to simplify the role of id_token_hint to "a token which conveys the value of the sub claim" because end-user authentication will be performed again. Hints are information to identify the subject of the end-user by and they are not information to authenticate the end-user by. Therefore, the role of hints can be simplified.

[Brian Campbell]

There has been an expressed desire from the WG to use (or be able to use) the id_token_hint to verify that end-user authentication has occurred in the past and was conveyed to the given client. The idea is that such verification helps protect against unsolicited spam/phishing attempts initiating out-of-band authentication of a user trying to trick them into authenticating a transaction they didn't start or to harass or fatigue the user with many authentication requests.

I've always thought id_token_hints are kind of a PITA but the usage here is meant to do more than 'convey the value of the xxx claim', which can be done with the other hints.