[Openid-specs-ab] 3-party vs 4-party in JWT

[Mike Jones]

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:

Plaxo sends an access token request to foo.com's STS asking for a token with the audience of calendar.live.com with the claim that the bearer of the token has the right to exercise mike at foo.com's rights in the area of calendar free/busy time.  The delegate-to principal in the issued token is Plaxo's calendar service.  foo.com's STS issues a token to Plaxo of the form:
{
  "iss":"https://foo.com",
  "aud":"http://calendar.live.com",
  "prn":"mailto:mike at foo.com",
  "ctx":"urn:adatum.com:calendar:freebusy",
  "dto":
    {
      "prn":"https://calendar.plaxo.com"
    }
}

Your thoughts?

				-- Mike

-----Original Message-----
From: Breno de Medeiros [mailto:breno at google.com] 
Sent: Tuesday, December 21, 2010 3:18 PM
To: openid-specs-ab at lists.openid.net; Mike Jones
Subject: Re: 3-party vs 4-party in JWT

+michael.jones at microsoft.com (had the wrong Mike the first time
around, thanks to auto-complete).

On Tue, Dec 21, 2010 at 15:12, Breno de Medeiros <breno at google.com> wrote:
> Mike, I have a question for you about the 'aud' field.  This has to do 
> with 3-party auth scenarios versus 4-party ones.
>
> In a 3-party auth scenario, the requester is the same as the audience; 
> e.g., a client web app requests a token from a web server to access 
> data for a particular user. There's no question here that 'aud' refers 
> to the client web app and no further information is needed to evaluate 
> this token.
>
> However, in a 4-party or delegated auth scenario, the requester is, 
> say, a mobile app, requesting a token/grant from a web server for a 
> particular user at a client web app that the mobile app accesses. The 
> web server here is acting as an 'authorization server' for a number of 
> 'federated' client web apps and enabling mobile apps to auth against 
> these client web apps as well.
>
> In the 4-party auth or delegated scenario, the audience is the client 
> web app (presumably), which is a different party from the party to 
> whom the token was issued (here, a mobile app).
>
> Do you have a formed idea on how JWT tokens should handle the 4-party 
> auth case (as both mobile/client apps and web federations are common 
> use cases, their combination leading to the need to address 4-party 
> use cases is a given).
>
> --
> --Breno
>



--
--Breno