[Openid-specs-ab] inconsistent treatment of id_token_hint?

[George Fletcher]

Aren't there two possible cases?

1. The RP wants the AS to authenticate the current user. The RP passes a 
id_token_hint using the last id_token it has for that cookied browser. 
However, the RP doesn't really care who is logging in, it's just trying 
to be helpful because in most cases it really is the same user. In this 
kind of a scenario, the SHOULD makes sense, as the RP is fine if the AS 
sends back a different user than the id_token_hint.

2. The RP wants the AS to authenticate ONLY the user identified by the 
id_token_hint. In this case the AS MUST return an error if the user's 
are different.

I'm fine moving all responses to MUST and making use case #1 just incur 
a few more redirects before the user gets logged in.

Thanks,
George

On 4/7/15 11:25 AM, John Bradley wrote:
> Well it MUST be consistent.
>
> I think it was MUST in both places then there was a discussion that it 
> is the responsibility of the client to check the sub in the returned 
> id_token, so it may be better in some cases to have the IdP respond 
> with a positive response for a diffrent sub rather than an error.
>
> Saying both would be the worst of both worlds.
>
> If we are certain that RP really validate the sub in prompt=none cases 
> then SHOULD is fine.   If clients are sloppy with that then having it 
> a MUST is better as it will stop clients from mistakenly thinking that 
> a positive response is fro the same user.
>
> I think I was the one arguing for MUST at the time, but I tend to be 
> conservative.
>
> We must have missed the other reference when it was changed to SHOULD.
>
> John B.
>> On Apr 7, 2015, at 8:10 AM, Brian Campbell 
>> <bcampbell at pingidentity.com <mailto:bcampbell at pingidentity.com>> wrote:
>>
>> Core has two mentions of id_token_hint (not counting self issued and 
>> IANA registration), which are quoted below. It seems that one says 
>> that an error SHOULD be returned if the end-user identified by the 
>> id_token_hint isn't the current user while the other says an error 
>> MUST be returned.
>>
>> Is this an oversight that should maybe be fixed in errata v.next?
>>
>> Or is there something more subtle or intentional here?
>>
>>
>> http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
>>
>>     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. 
>>
>>
>> http://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation
>>
>> If the sub (subject) Claim is requested with a specific value for the 
>> ID Token, the *Authorization Server MUST only send a positive 
>> response if the End-User identified by that sub value has an active 
>> session with the Authorization Server or has been Authenticated as a 
>> result of the request. The Authorization Server MUST NOT reply with 
>> an ID Token or Access Token for a different user,* even if they have 
>> an active session with the Authorization Server. Such a request can 
>> be made either using an id_token_hint parameter or by requesting a 
>> specific Claim Value as described in Section 5.5.1 
>> <http://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests>, 
>> if the claims parameter is supported by the implementation.
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net 
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-- 
George Fletcher <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150407/f374e1fc/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150407/f374e1fc/attachment-0001.html>