It's not exactly clear to me what that means. Near the end of the interim meeting on Monday there was a specific discussion that resulted in a TODO item to draft a 4.5.1 subsection. That's what I've done here and I believe it captures the intent discussed at the meeting. I've written a small proposal for specific text to be included in the core specification and described the subsequent changes (simplifications actually) that would follow in companion specification.
I've made a specific and actionable proposal. I'm happy to discuss the merits of the proposal and if the WG should accept it or not. If you feel that your proposal of a separate document is more appropriate, I'd suggest you actually write such a document and describe how it impacts existing drafts so that it can be reviewed and discussed. My understanding (Chairs, correct me if I'm wrong) is that such a document would need to be accepted as a working group item in order to be referenced from draft-ietf-oauth-v2 or used/referenced by draft-ietf-oauth-saml2. On Wed, May 25, 2011 at 11:07 AM, Anthony Nadalin <tony...@microsoft.com> wrote: > In our case they are tightly bound as the assertions (same assertion) will be > used for authentication and also to grant authorization as this is what was > in scope with WRAP, so not addressing the assertion authentication is an > issue for us and I assume others also. > > -----Original Message----- > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > Sent: Wednesday, May 25, 2011 6:54 AM > To: Anthony Nadalin > Cc: oauth > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 > subsection on assertions > > That is another way to approach it and I understand there has been some talk > about that lately. While there are admittedly some commonalities between > assertion based grants and an HTTP parameter based client authentication > extension point, I personally think that > lumping them together is unnecessarily confusing. It is also a more > significant change and it seems like, at this point in the process, it might > be better to aim for more concise and targeted changes. > > > On Tue, May 24, 2011 at 1:01 PM, Anthony Nadalin <tony...@microsoft.com> > wrote: >> I think that this will be better moved into a separate document on >> assertions (were both authorization and authentication are talked >> about) and not to include in 4.5.1 but would like to see a reference >> in 4.5.1 to the new document >> >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Brian Campbell >> Sent: Tuesday, May 24, 2011 7:25 AM >> To: oauth >> Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 >> subsection on assertions >> >> One of the action items out of yesterday's meeting was to draft some text >> for a section 4.5.1 in core that defined the optional but recommended use of >> an "assertion" parameter for extension grants where the use of a single >> parameter to carry the grant/assertion was possible. Below is a first cut >> at some proposed text that hopefully avoids some of the awkwardness that EHL >> described in previous attempts to introduce such a parameter. Comments or >> edits or editorial improvements are, of course, welcome. But I think this >> hopefully captures the intent of what was discussed yesterday (and before). >> >> If we get some consensus to make this change, I think a couple of other >> actions are implied. >> >> - The IANA assertion parameter registration request >> (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4 >> .1) should be removed from the SAML draft and put into >> http://tools.ietf.org/html/draft-ietf-oauth-v2 >> >> - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec >> will change the parameter it uses from jwt to assertion and drop the >> registration request for jwt >> (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4. >> 1) >> >> >> --- proposed text for sections 4.5 & 4.5.1 --- >> >> 4.5. Extensions >> >> The client uses an extension grant type by specifying the grant type >> using an absolute URI (defined by the authorization server) as the >> value of the "grant_type" parameter of the token endpoint, and by >> adding any additional parameters necessary. >> >> If the access token request is valid and authorized, the >> authorization server issues an access token and optional refresh >> token as described in Section 5.1. If the request failed client >> authentication or is invalid, the authorization server returns an >> error response as described in Section 5.2. >> >> 4.5.1 Assertion Based Extension Grants >> >> If the value of the extension grant can be serialized into a single >> parameter, as is case with a number of assertion formats, it is >> RECOMMENDED that that a parameter named "assertion" be used to >> carry the value. >> >> assertion >> REQUIRED. The assertion. The format and encoding of the >> assertion is defined by the authorization server or >> extension specification. >> >> For example, to request an access token using a SAML 2.0 assertion >> grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client >> makes the following HTTP request using transport-layer security >> (line >> breaks are for display purposes only): >> >> POST /token HTTP/1.1 >> Host: server.example.com >> Content-Type: application/x-www-form-urlencoded >> >> grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F >> bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM >> [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> > > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth