Subject: [OAUTH-WG] Status update

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Jun 2010 14:36:16 -0700

With the exception of extensibility, I consider draft -08 to be feature complete. This means that the draft contains all the features and components needed and other then editorial work is close to finished. I plan to finish work on the -09 draft by Mon or Tue next week which will include the extensibility text, additional editorial work, and resolution of the proposal to simplify the end-user authorization endpoint. At that point, I intend to ask for an interim last-call on the normative language (i.e. the implementation details).

Note that this last-call isn't really a WG last call. The spec can change after that. But it will be a useful milestone to figure out if the draft's implementation details are stable and can be considered complete.

All of this of course requires the approval of the chairs.

EHL

---

From: Nat <[email-masked]>
Date: Fri, 18 Jun 2010 08:42:21 +0900

What about the 'request_url' indirection (without sig and enc)?

On 2010/06/18, at 6:36, Eran Hammer-Lahav <[email-masked]> wrote:

> With the exception of extensibility, I consider draft -08 to be  
> feature complete. This means that the draft contains all the  
> features and components needed and other then editorial work is  
> close to finished. I plan to finish work on the -09 draft by Mon or  
> Tue next week which will include the extensibility text, additional  
> editorial work, and resolution of the proposal to simplify the end- 
> user authorization endpoint. At that point, I intend to ask for an  
> interim last-call on the normative language (i.e. the implementation  
> details).
>
>
>
> Note that this last-call isn’t really a WG last call. The spec can c 
> hange after that. But it will be a useful milestone to figure out if 
>  the draft’s implementation details are stable and can be considered 
>  complete.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Jun 2010 17:22:45 -0700

Not sure what you are referring to.

EHL

> -----Original Message-----
> From: Nat [mailto:[email-masked]]
> Sent: Thursday, June 17, 2010 4:42 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Status update
> 
> > feature complete. This means that the draft contains all the features
> > and components needed and other then editorial work is close to
> > finished. I plan to finish work on the -09 draft by Mon or Tue next
> > week which will include the extensibility text, additional editorial
> > work, and resolution of the proposal to simplify the end- user
> > authorization endpoint. At that point, I intend to ask for an interim
> > last-call on the normative language (i.e. the implementation details).
> >
> >
> >
> > Note that this last-call isn't really a WG last call. The spec can c
> > the draft's implementation details are stable and can be considered
> > complete.
> >
> >
> >

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 18 Jun 2010 10:11:52 +0900

I was wondering when you suggested to write an I-D about the request
by reference (which started as mobile WebApp flow), you wanted it for
the IPR reason or meant that it should be separate from the core. To
cover both case, I have submit the I-D
http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ "Request
by Reference ver.1.0 for OAuth 2.0". I was referring to the subset of
it, namely the introduction of "request_url" as the reference
parameter for the request parameters to be "included."

=nat @ Tokyo via iPhone

On 2010/06/18, at 9:22, Eran Hammer-Lahav <[email-masked]> wrote:

>>> features

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Jun 2010 18:22:07 -0700

I don't care about IPR.

I asked for it to be submitted as I-D because for now, I think we have consensus to move it forward in that form. We can always merge it into core, but for now, it is not part of core. Don't worry about this too much at this moment. What you need to do is get consensus that the proposal in the I-D is solid and has wide support. Then try to merge it in.

EHL

> From: Nat Sakimura [mailto:[email-masked]]
> Sent: Thursday, June 17, 2010 6:12 PM
> To: Eran Hammer-Lahav
> I was wondering when you suggested to write an I-D about the request by
> reference (which started as mobile WebApp flow), you wanted it for the IPR
> reason or meant that it should be separate from the core. To cover both
> case, I have submit the I-D http://datatracker.ietf.org/doc/draft-sakimura-
> oauth-requrl/ "Request by Reference ver.1.0 for OAuth 2.0". I was referring
> to the subset of it, namely the introduction of "request_url" as the reference

---

From: Rob Richards <[email-masked]>
Date: Mon, 21 Jun 2010 07:54:29 -0400

I still think that the issue of running both 1.0 and 2.0 on an resource 
endpoint needs to be addressed in the spec. It is unrealistic to think 
that a provider currently running 1.0 can just do a complete cutover to 
2.0 and shut down 1.0 access, or providers arbitrarily making the 
decision what constitutes 1.0 and what constitutes 2.0. Personally I 
think that an oauth_version parameter should be required for the 
resource endpoint as it will definitely allow version to be determined 
and prevent this potential problem from any future versions as well. 
Others think that just by checking for non-existance of parameters would 
work, though it is only best guess at that point because it could be a 
1.0 call requiring a 400 error to be returned. In either case, this 
really needs to be addressed in the spec so that all providers are doing 
the check in the exact same way to avoid ambiguity.

Rob

Eran Hammer-Lahav wrote:
> work, and resolution of the proposal to simplify the end-user 
> Note that this last-call isn’t really a WG last call. The spec can 
> change after that. But it will be a useful milestone to figure out if

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 21 Jun 2010 10:10:06 -0400

Another newbie question: what is the technical reason for NOT including
an oauth protocol version number?

Including protocol versions numbering is the norm in most/all IETF protocols.
Also exchange types, cipher types, etc. etc.

/thomas/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Rob Richards [[email-masked]]
Sent: Monday, June 21, 2010 7:54 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Status update

Rob

---

From: Dick Hardt <[email-masked]>
Date: Mon, 21 Jun 2010 07:22:26 -0700

Good point that version checking be clearly included in the spec.

On 2010-06-21, at 4:54 AM, Rob Richards wrote:

> I still think that the issue of running both 1.0 and 2.0 on an resource endpoint needs to be addressed in the spec. It is unrealistic to think that a provider currently running 1.0 can just do a complete cutover to 2.0 and shut down 1.0 access, or providers arbitrarily making the decision what constitutes 1.0 and what constitutes 2.0. Personally I think that an oauth_version parameter should be required for the resource endpoint as it will definitely allow version to be determined and prevent this potential problem from any future versions as well. Others think that just by checking for non-existance of parameters would work, though it is only best guess at that point because it could be a 1.0 call requiring a 400 error to be returned. In either case, this really needs to be addressed in the spec so that all providers are doing the check in the exact same way to avoid ambiguity.
> 
> Rob
> 
> Eran Hammer-Lahav wrote:
>> 
>> Note that this last-call isn’t really a WG last call. The spec can change after that. But it will be a useful milestone to figure out if the draft’s implementation details are stable and can be considered complete.
>>