On Mon, Dec 27, 2010 at 2:49 PM, Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for your note, Breno. I know that we'd started to think about this case as well. For delegation, the key is that the principal named in the token can be different than the principal being delegated to. We'd thought of explicitly representing this via claims. Here's an example cribbed from a discussion about a calendar sharing scenario, which while not identical to your scenario, gets the idea across:<br>
<br>
Plaxo sends an access token request to <a href="http://foo.com" target="_blank">foo.com</a>'s STS asking for a token with the audience of <a href="http://calendar.live.com" target="_blank">calendar.live.com</a> with the claim that the bearer of the token has the right to exercise <a href="mailto:mike@foo.com" target="_blank">mike@foo.com</a>'s rights in the area of calendar free/busy time. The delegate-to principal in the issued token is Plaxo's calendar service. <a href="http://foo.com" target="_blank">foo.com</a>'s STS issues a token to Plaxo of the form:<br>
{<br>
"iss":"<a href="https://foo.com" target="_blank">https://foo.com</a>",<br>
"aud":"<a href="http://calendar.live.com" target="_blank">http://calendar.live.com</a>",<br>
"prn":"mailto:<a href="mailto:mike@foo.com" target="_blank">mike@foo.com</a>",<br>
"ctx":"urn:adatum.com:calendar:freebusy",<br>
"dto":<br>
{<br>
"prn":"<a href="https://calendar.plaxo.com" target="_blank">https://calendar.plaxo.com</a>"<br>
}<br>
}<br>
<br>
Your thoughts?<br></blockquote><div><br></div><div>the dto->prn link is maybe one too many levels of indirection?</div><div><br></div><div>There are three potential principals at play here:</div><div><br></div><div>- who issued the token: the issuer</div>
<div>- who gets the token (i.e., who will be using it): the client</div><div>- who is the token for (the protected resource that will be accessed with the token): the audience</div><div><br></div><div>In the 3-party case (OpenID Connect) case, client and audience tend to be the same (the token is handed to "client" code in the browser, which uses it to authenticate to the "client" web server), so we can fold this field into one. In the 4-party case, client and audience can be different.</div>
<div><br></div><div>To confuse things even more, you have a field called "principal" in your example (mailto:<a href="mailto:mike@foo.com" target="_blank">mike@foo.com</a>) that isn't any of those three principals. That field just further narrows down the audience (or "scope") of the token: it's not all the data at the audience that this token grants access to - just some of it (the data belonging to <a href="mailto:mike@foo.com">mike@foo.com</a>). In your example, you want to narrow this down even further - the token shouldn't get access to all of Mike's data, just his calendar data. And not even all his calendar data - just his free/busy information. But that's just a way of more narrowly restricting the audience (or scope) of the token.</div>
<div><br></div><div>So how about something like this:</div><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">{<br>
"iss":"<a href="https://foo.com">https://foo.com</a>",<br> "client": "<a href="https://calendar.plaxo.com">https://calendar.plaxo.com</a>",</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "> "usr":"mailto:<a href="mailto:mike@foo.com">mike@foo.com</a>",<br>
"aud":"<a href="http://calendar.live.com/freebusy">http://calendar.live.com/freebusy</a>",<br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">}<br>
</span></div><div><br></div>
<div>Dirk.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- Mike<br>
<br>
-----Original Message-----<br>
From: Breno de Medeiros [mailto:<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>]<br>
Sent: Tuesday, December 21, 2010 3:18 PM<br>
To: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>; Mike Jones<br>
Subject: Re: 3-party vs 4-party in JWT<br>
<br>
+<a href="mailto:michael.jones@microsoft.com" target="_blank">michael.jones@microsoft.com</a> (had the wrong Mike the first time<br>
around, thanks to auto-complete).<br>
<br>
On Tue, Dec 21, 2010 at 15:12, Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>> wrote:<br>
> Mike, I have a question for you about the 'aud' field. This has to do<br>
> with 3-party auth scenarios versus 4-party ones.<br>
><br>
> In a 3-party auth scenario, the requester is the same as the audience;<br>
> e.g., a client web app requests a token from a web server to access<br>
> data for a particular user. There's no question here that 'aud' refers<br>
> to the client web app and no further information is needed to evaluate<br>
> this token.<br>
><br>
> However, in a 4-party or delegated auth scenario, the requester is,<br>
> say, a mobile app, requesting a token/grant from a web server for a<br>
> particular user at a client web app that the mobile app accesses. The<br>
> web server here is acting as an 'authorization server' for a number of<br>
> 'federated' client web apps and enabling mobile apps to auth against<br>
> these client web apps as well.<br>
><br>
> In the 4-party auth or delegated scenario, the audience is the client<br>
> web app (presumably), which is a different party from the party to<br>
> whom the token was issued (here, a mobile app).<br>
><br>
> Do you have a formed idea on how JWT tokens should handle the 4-party<br>
> auth case (as both mobile/client apps and web federations are common<br>
> use cases, their combination leading to the need to address 4-party<br>
> use cases is a given).<br>
><br>
> --<br>
> --Breno<br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
--Breno<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</font></blockquote></div><br>