Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Jul 2011 11:38:19 -0700

In light of the new assertion draft, do we still want to make this change?

EHL

From: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Date: Tue, 24 May 2011 07:25:12 -0700
To: oauth <[email-masked]<mailto:[email-masked]>>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Jul 2011 12:42:21 -0600

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 <[email-masked]> wrote:
> From: Brian Campbell <[email-masked]>
> To: oauth <[email-masked]>
> [email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Jul 2011 11:54:10 -0700

What about the example using SAML assertion?

From: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Date: Mon, 4 Jul 2011 11:42:21 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

On Mon, Jul 4, 2011 at 12:38 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
In light of the new assertion draft, do we still want to make this change?
EHL
From: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Date: Tue, 24 May 2011 07:25:12 -0700
To: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection
on assertions

--- proposed text for sections 4.5 & 4.5.1 ---
4.5. Extensions

---

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Jul 2011 13:26:31 -0600

Either way.  It could stay in there, if you want to show a concrete
example of an extension grant type.   Or it could be removed too -
draft-ietf-oauth-assertions and draft-ietf-oauth-saml2-bearer will
have plenty of examples.

On Mon, Jul 4, 2011 at 12:54 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> To: Eran Hammer-lahav <[email-masked]>
> Cc: oauth <[email-masked]>