Subject: [OAUTH-WG] New Assertion Draft for review

From: Chuck Mortimore <[email-masked]>
Date: Sat, 18 Jun 2011 12:42:25 -0700

A number of us in the community have been working on a general model for the use of Assertions in OAuth2 for both client authentication, as well as authorization grants.  We've reached general consensus on a doc that I've published as a draft:

http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt

Feedback and discussion welcome!

Thanks

-cmort

---

From: Mike Jones <[email-masked]>
Date: Sat, 18 Jun 2011 20:08:08 +0000

Thanks Chuck.  Adding context, this document moves the common parts of the SAML Profile<http://trac.tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04> and the JWT Profile<http://trac.tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00> to a common assertions spec.  The token-type specific parts will then become profiles of this common doc.

Thanks for spearheading this, Chuck!

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chuck Mortimore
Sent: Saturday, June 18, 2011 12:42 PM
To: [email-masked]
Subject: [OAUTH-WG] New Assertion Draft for review

Thanks

-cmort

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 20 Jun 2011 14:31:20 -0400

Chuck,

This is a good draft. Real progress.  I wish we had this draft before the WG spent so much time in IETF-Prague arguing about the assertions text.

Just a short question.  Section 5.1 states that the principal identity SHOULD be the client_id (for the OAuth client):

   Principal  A unique identifier for the subject of the assertion.
      When using assertions for client authentication, the Principal
      SHOULD be the client_id of the OAuth client.  When using
      assertions as an authorization grant, the Principal MUST identify
      an authorized accessor for whom the access token is being
      requested (typically the resource owner, or an authorized
      delegate).

Why is this a "SHOULD"?  (I would think this is a "MUST).

In Section 6.1 "The Principal MUST identify an authorized accessor". In Section 6.3  "The Principal MUST identify an authorized accessor...".

PS. More broadly, I'm thinking not only of a model where the OAuth-client gets an assertion from the STS/IdP server, but also of a situation in where the human-user (resource owner) specifically names the Subject (the OAuth Client) in a multi-hop delegation case.

More questions later.

Thanks.

/thomas/

__________________________
> Sent: Saturday, June 18, 2011 3:42 PM
> To: [email-masked]
> A number of us in the community have been working on a general model
> for the use of Assertions in OAuth2 for both client authentication, as
> well as authorization grants.  We've reached general consensus on a doc
> that I've published as a draft:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 20 Jun 2011 18:46:05 +0000

This also moves the client_credentials authentication material out of the core and into a core companion specification.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Saturday, June 18, 2011 1:08 PM
To: Chuck Mortimore; [email-masked]
Subject: Re: [OAUTH-WG] New Assertion Draft for review

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Chuck Mortimore
Sent: Saturday, June 18, 2011 12:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] New Assertion Draft for review

Thanks

-cmort

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 20 Jun 2011 12:16:41 -0700

Thanks Thomas - it's good to hear that it's on the right track....took awhile to get both understanding and agreement.

There was a good deal of debate on SHOULD vs MUST for client_id in section 5.1.   The argument for SHOULD was generally that there are use-cases where the client_id provided as a parameter is enough, the client_id can be implied, or the assertion format may not easily allow for it.

As long as the Authorization Server can correlate the client with the keying material it uses for verification of the assertion then I think SHOULD is enough.   ( note, I started out on the other side of this argument )    The SAML and JWT profiles we expect can turn this to a MUST, but we want the general guidance to be a little less strict.

That's the thinking...

-cmort

On 6/20/11 11:31 AM, "Thomas Hardjono" <[email-masked]> wrote:

Chuck,

More questions later.

Thanks.

/thomas/

---

From: Brian Campbell <[email-masked]>
Date: Wed, 29 Jun 2011 16:06:35 -0600

Maybe this is already a known issue but it just occurred to me that
this draft probably needs to have an IANA Considerations section that
registers the parameters that it defines per registry defined in the
core OAuth spec [1] - assertion, client_assertion_type, &
client_assertion.

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-11.2

On Mon, Jun 20, 2011 at 1:16 PM, Chuck Mortimore
<[email-masked]> wrote:
>
> Thanks Thomas – it’s good to hear that it’s on the right track....took awhile to get both understanding and agreement.
>
> That’s the thinking...
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 30 Jun 2011 16:39:10 -0400

Chuck Mortimore wrote:
> for the use of Assertions in OAuth2 for both client authentication, as well
> as authorization grants.  We’ve reached general consensus on a doc
> that I’ve published as a draft

This document is intended to replace the SAML and Bearer Token
documents, and those two will then be "profiles", defining specific
assertion mechanisms.  We would like to have them submit the
restructured doc as a working-group document before the 4 July
deadline, so we'd like to get any objections to this approach heard by
3 July.  I'm sorry for the very short notice, and you can blame that
solely on the chairs.  Chuck posted the draft about two weeks ago.

See http://tools.ietf.org/html/draft-mortimore-oauth-assertions

The editors can answer any questions you have about how the document
restructuring is being done.  We will approve
draft-ietf-oauth-assertions for submission as a working-group draft,
pending consideration of objections.  Again, please have a quick look
(it's short), and post objections by 3 July.  Thanks.

Barry, as chair

---

From: Brian Campbell <[email-masked]>
Date: Thu, 30 Jun 2011 15:11:10 -0600

On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba <[email-masked]> wrote:
> assertion mechanisms.

Just a couple points of clarification

This doc is not related to the Bearer Token document
(draft-ietf-oauth-v2-bearer-04) - that is about access tokens and this
series of docs is about assertions for grants (and now client
authentication).

This doc doesn't replace anything so much as it pulls common elements
out of the SAML assertion (draft-ietf-oauth-saml2-bearer) and JWT
assertion (draft-jones-oauth-jwt-bearer) documents.  Those docs (and
possibly others) then become profiles of this doc and get to reuse the
common pieces it provides.

This doc also reintroduces the abstract concept of client assertions
for client authentication using http parameters (client_assertion_type
and client_assertion).  Presumably the SAML and JWT assertion docs
will also be reworked to account for that.

>  We would like to have them submit the
> 3 July.

Barry, which docs to you need submitted by the 4th?  Just
draft-ietf-oauth-assertions?  Or draft-ietf-oauth-saml2-bearer and
draft-jones-oauth-jwt-bearer as well?

> I'm sorry for the very short notice, and you can blame that

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 Jun 2011 21:31:26 +0000

+1 on submitting this as a WG doc by the deadline on July 4th.

As background, http://www.ietf.org/meeting/cutoff-dates-2011.html:
.	2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool.
.	2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool

So because the assertions draft will be a -00 draft, it must be submitted by the 4th.  A new version of the SAML doc could still be submitted until the 11th, since it's not a -00 doc.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, June 30, 2011 2:11 PM
To: Barry Leiba
Cc: OAuth WG
Subject: Re: [OAUTH-WG] New Assertion Draft for review

This doc is not related to the Bearer Token document
(draft-ietf-oauth-v2-bearer-04) - that is about access tokens and this series of docs is about assertions for grants (and now client authentication).

This doc doesn't replace anything so much as it pulls common elements out of the SAML assertion (draft-ietf-oauth-saml2-bearer) and JWT assertion (draft-jones-oauth-jwt-bearer) documents.  Those docs (and possibly others) then become profiles of this doc and get to reuse the common pieces it provides.

This doc also reintroduces the abstract concept of client assertions for client authentication using http parameters (client_assertion_type and client_assertion).  Presumably the SAML and JWT assertion docs will also be reworked to account for that.

>  We would like to have them submit the restructured doc as a 
> working-group document before the 4 July deadline, so we'd like to get 
> any objections to this approach heard by
> 3 July.

Barry, which docs to you need submitted by the 4th?  Just draft-ietf-oauth-assertions?  Or draft-ietf-oauth-saml2-bearer and draft-jones-oauth-jwt-bearer as well?

> I'm sorry for the very short notice, and you can blame that solely on 
> the chairs.  Chuck posted the draft about two weeks ago.
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 30 Jun 2011 15:40:00 -0600

+1 from me as well on submitting this as a WG doc.  And thanks, Mike,
for clarifying the dates.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 30 Jun 2011 18:34:02 -0400

> Just a couple points of clarification

Yes, thanks, Brian, for correcting the stuff I mischaracterized, in
writing my note too quickly.

Barry