[Openid-specs-ab] Two issues on id_token_hint [2]

Roland Hedberg roland.hedberg at umu.se
Mon Nov 24 09:16:35 UTC 2014


> 23 nov 2014 kl. 17:55 skrev John Bradley <ve7jtb at ve7jtb.com>:
> 
> The id_token hint was intended to indicate that the user had a previous session at the RP. 
> 
> If the identifier is a PPID it must be rejected or this might be used to correlate identities. 

This to me is a serious issue.

> I had always imagined that the client_id would need to be in the audience. 

Likewise, but from that doesn’t follow that it’s the only one.
So, the OP that issued to IdToken may have done it for a set of RPs.
Each one allowed to use the IdToken.
Should that usage extend to usage of the IdToken as an id_token_hint or is that solely for
the RP that interacted with the OP.

> We should discuss if rejecting it is a SHOULD or MUST. 

And expanding on what I wrote above if the id_token_hint should be rejected not just for RPs not in the
audience of the IdToken but for any RP that wasn’t involved in the original session.

> Sent from my iPhone
> 
>> On Nov 22, 2014, at 3:34 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>> 
>> I've certainly always assumed that the RP using the id_token_hint was the one that received the ID Token.  But you're right, we didn't write that down.
>> 
>> That said, there's nothing preventing an ID Token being used as the hint by another RP if it's given by one to the other, but it's kind of weird.  For one thing, the send RP would have a different audience than the one in the ID Token.  That sounds more like an attack scenario than a useful scenario.  Maybe we should talk about this on the working group list.
>> 
>>               -- Mike
>> 
>> -----Original Message-----
>> From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Roland Hedberg
>> Sent: Saturday, November 22, 2014 12:01 AM
>> To: openid-specs-ab at lists.openid.net
>> Subject: [Openid-specs-ab] Two issues on id_token_hint [2]
>> 
>> In the core spec it’s said about id_token_hint:
>> ”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."
>> 
>> This doesn’t explicitly state that the ID Token had to be issued to the Client using it as an id_token_hint.
>> 
>> If that is the case then we should write something to the effect that the Client has to be listed as one of the audiences (aud and/or azp ?) of the IdToken it uses as an id_token_hint.
>> 
>> Given that aud is a list, the Client will anyway be one possible user of the ID Token as an id_token_hint.
>> 
>> If I’m correct up to now, we have a number of possible outcomes as to the sub value of the new IdToken.
>> All, assuming that the original authentication is still valid.
>> 
>> I can see the following outcomes:
>> 1) If both uses redirect_uri’s that is appear in the same sector_identifier_uri then the sub should be the same
>> 
>> 2) If both have registered subject_type = public, then they should also be the same
>> 
>> 3) all other permutations should lead to the sub values not being the same.
>> 
>> Correct ?
>> 
>> How have people implemented this ?
>> 
>> — Roland
>> 
>> ”Being able to think like a child is an important attribute of being an adult” - Eddie Izzard
>> 
>> _______________________________________________
>> 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 list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab

— Roland

”Being able to think like a child is an important attribute of being an adult” - Eddie Izzard



More information about the Openid-specs-ab mailing list