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

[Brian Campbell]

I created https://bitbucket.org/openid/connect/issue/968 so as not to lose
track of this.

I'd think it should probably be a MUST.  But the spec should at least be
consistent with itself.

On Tue, Apr 7, 2015 at 10:38 AM, George Fletcher <gffletch at aol.com> wrote:

>  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>
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150407/7a95f198/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150407/7a95f198/attachment-0001.html>