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

[Dirk Balfanz]

On Mon, Dec 27, 2010 at 2:49 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:

> 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?
>

the dto->prn link is maybe one too many levels of indirection?

There are three potential principals at play here:

- who issued the token: the issuer
- who gets the token (i.e., who will be using it): the client
- who is the token for (the protected resource that will be accessed with
the token): the audience

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.

To confuse things even more, you have a field called "principal" in your
example (mailto:mike at foo.com) 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 mike at foo.com). 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.

So how about something like this:

{
 "iss":"https://foo.com",
 "client": "https://calendar.plaxo.com",
 "usr":"mailto:mike at foo.com",
 "aud":"http://calendar.live.com/freebusy",
}

Dirk.



>
>                                -- 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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101228/4bfc6449/attachment.html>