I believe the new assertion draft covers it and this change can be sidelined as long as the new draft has WG support to move forward.
On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > In light of the new assertion draft, do we still want to make this change? > EHL > From: Brian Campbell <bcampb...@pingidentity.com> > Date: Tue, 24 May 2011 07:25:12 -0700 > To: oauth <oauth@ietf.org> > 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
