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

> Just a couple points of clarification Yes, thanks, Brian, for correcting the stuff I mischaracterized, in writing my note too quickly. Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

age- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 > > On Thu, Jun 30, 2011 at 2:39 PM, Barry

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

a -00 doc. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 On Thu

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

On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba wrote: > > This document is intended to replace the SAML and Bearer Token > documents, and those two will then be "profiles", defining specific > assertion mechanisms. Just a couple points of clarification This doc is not related to the Bearer Token d

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

Chuck Mortimore wrote: > 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 This document is intende

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

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://tool

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

Thanks Thomas - it's good to hear that it's on the right tracktook 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

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

: [OAUTH-WG] New Assertion Draft for review 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>

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

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 uniqu

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

Thanks Chuck. Adding context, this document moves the common parts of the SAML Profile and the JWT Profile to a common assertions spec. The token-type specific pa