Subject: Re: [Unbearable] Referred token binding IDs

From: =JeffH <[email-masked]>
Date: Fri, 25 Mar 2016 14:18:02 -0700

I wish to clarify just this one little point here..

 > I think the takeaway from this is when a federated token is created
 > and bound to a referred TBID, the provided TBID (that the user's
 > identity is bound to) and the referred TBID ...

..shouldn't the above rather read..

   I think the takeaway from this is when a federated token is created
   and bound to a referred TBID, the provided TBID and the referred
   TBID (that the user's identity is bound to) ...

..?

I am interpreting "user's identity is bound to" as being the ID Token (in
OIDC case) or SAML assertion (in SAML case) that the IDP generates (and
which needs to be bound to the correct TBID).

thanks,

=JeffH

---

From: Nick Harper <[email-masked]>
Date: Fri, 25 Mar 2016 14:24:53 -0700

I did intend for the parenthetical to follow "provided TBID", but I see how
I was not clear. My meaning is that the user's identity has already been
bound to the provided TBID, and we wish to bind it to the referred TBID.

That is, the client has a cookie (or cookies) for the IdP that are bound to
a TBID. When the IdP creates a federated token and binds it to a referred
TBID, it needs to verify that the provided TBID (which it knows already
belongs to the user) and the referred TBID belong to the same client.

On Fri, Mar 25, 2016 at 2:18 PM, =JeffH <[email-masked]>
wrote:

> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>