Subject: [OAUTH-WG] Draft -19

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 25 Jul 2011 01:06:38 -0700

Draft 19 includes all the feedback received for -18:

* Closes issues 15-19
* Moved client profiles to section 2.1 from 10
* New text for 'Code Injection and Input Validation'
* A few minor editorial clarifications

There are two open issues (20, 21) which are minor editorial requests, and the request being discussed on the list to change the public/private client type terminology to something else.

I consider draft -19 to be ready for WGLC immediately.

Thanks,

EHL

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Jul 2011 08:20:36 -0400

> Draft 19 includes all the feedback received for -18:

BTW, the diff is here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt

/psa

---

From: Lucy Lynch <[email-masked]>
Date: Mon, 25 Jul 2011 06:46:28 -0700 (PDT)

> http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt

clarifying question on section 10.1 -

I'm reading this as suggested handling for the Client URI portion
of a redirection endpoint - is that correct?

> /psa
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 25 Jul 2011 14:24:09 +0000

A few editorial points about references:
  - the draft is referencing an old draft of the bearer token spec (-04), rather than the current version (-06),
  - the draft is referencing an old draft  of the SAML bearer spec (-03), rather than the current version (-04),
  - the draft is not referencing the assertions spec draft-ietf-oauth-assertions-00, which would make sense in Section 4.5 (Extensions)

Also, the example in 4.5 should be updated to match the current SAML bearer spec:

   grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F
   bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
   [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-

                                                            Thanks,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, July 25, 2011 1:07 AM
To: OAuth WG
Subject: [OAUTH-WG] Draft -19

* Closes issues 15-19

Thanks,

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 25 Jul 2011 08:54:03 -0700

Yeah, I'm not going to waste time trying to keep these in sync for now. This will all be done once before IETF LC and then with the RFC editor.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Monday, July 25, 2011 7:24 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Draft -19

                                                            Thanks,
                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Eran Hammer-Lahav
Sent: Monday, July 25, 2011 1:07 AM
To: OAuth WG
Subject: [OAUTH-WG] Draft -19

* Closes issues 15-19

Thanks,

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 25 Jul 2011 08:38:47 -0700

The term Redirection URI describes the URI provided by the client throughout the document. The additional parameters added later by the authorization server are part of the redirection request but not the URI provided by the client.

EHL

> -----Original Message-----
> From: Lucy Lynch [mailto:[email-masked]]
> Sent: Monday, July 25, 2011 6:46 AM
> To: Peter Saint-Andre
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Draft -19
> 
> I'm reading this as suggested handling for the Client URI portion of a
> redirection endpoint - is that correct?
> 
> > /psa

---

From: Lucy Lynch <[email-masked]>
Date: Mon, 25 Jul 2011 10:11:16 -0700 (PDT)

On Mon, 25 Jul 2011, Eran Hammer-Lahav wrote:

> The term Redirection URI describes the URI provided by the client 
> throughout the document. The additional parameters added later by the 
> authorization server are part of the redirection request but not the URI 
> provided by the client.

Thanks -