Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes

From: "oauth issue tracker" <[email-masked]>
Date: Mon, 03 Aug 2009 07:24:30 -0000

#4: Error Codes
---------------------------------+------------------------------------------
 Reporter:  [email-masked]  |        Owner:     
     Type:  defect               |       Status:  new
 Priority:  critical             |    Milestone:     
Component:  authentication       |      Version:     
 Severity:  Active WG Document   |   Resolution:     
 Keywords:                       |  
---------------------------------+------------------------------------------

Comment(by [email-masked]):

 My first question is what would happen to the ProblemReporting proposal -
 does it get republished as a standards-track I-D or will it stay an
 extension at oauth.net. I guess it would have to be a standards-track I-D
 if we want to be able to make normative references to it..?

 As for the proposal itself I've got some minor comments:

 - The text

 "Other values of oauth_problem MUST NOT be used. However, a Consumer
 SHOULD be prepared to receive other values, from a Service Provider that
 implements a future version of problem reporting."

 This feels inconsistent to me - isn't it better to apply the robustness
 principle and only say that "Consumers MUST be prepared to receive other
 values as Service Provders may implement later versions of this
 specification, however Consumers MUST silently ignore parameters they do
 not understand."

 In that spirit the oauth_parameters_rejected parameter might need to
 become oauth_parameters_ignored.

 - A range of values in oauth_acceptable_versions feels like a bad idea -
 who knows what type of strings will be thought appropriate for oauth
 versions in the future and comparison may not me meaningful. Just use a
 comma-separated list - we really shouldn't be defining that many version
 to make this a problem :-)

 - oauth_acceptable_timestamps: How could a sender (the use of
 sender/receiver gets confusing in the text btw) ever make use of that
 value? Is it to adjust the clock or just pick a timestamp in the range? I
 may just have misunderstood things...

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/oauth/trac/ticket/4#comment:1>
oauth <http://tools.ietf.org/oauth/>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 3 Aug 2009 14:24:06 -0700

We will need to write a new proposal which can be based on the problem reporting extension. But it will be part of the core spec(s). I don't think we need to have it as an I-D. It is just a good reference (for the WG) to existing work in the space.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of oauth issue tracker
> Sent: Monday, August 03, 2009 12:25 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes
> 
> #4: Error Codes
> ---------------------------------+------------------------------------
> ---------------------------------+-
> -----
> ---------------------------------+------------------------------------
> ---------------------------------+-
> -----
> 
>  My first question is what would happen to the ProblemReporting 
> proposal -  does it get republished as a standards-track I-D or will 
> it stay an  extension at oauth.net. I guess it would have to be a 
> standards-track I-D  if we want to be able to make normative 
> references to it..?
> 
> SHOULD be prepared to receive other values, from a Service Provider 
> that  implements a future version of problem reporting."
> 
>  This feels inconsistent to me - isn't it better to apply the 
> robustness  principle and only say that "Consumers MUST be prepared to 
> receive other  values as Service Provders may implement later versions 
> of this  specification, however Consumers MUST silently ignore 
> parameters they do  not understand."
> 
>  - A range of values in oauth_acceptable_versions feels like a bad 
> idea
> -
> versions in the future and comparison may not me meaningful. Just use 
> a  comma-separated list - we really shouldn't be defining that many 
> version  to make this a problem :-)
> 
> value? Is it to adjust the clock or just pick a timestamp in the 
> range? I  may just have misunderstood things...
> 
> --
> Ticket URL:
> <https://trac.tools.ietf.org/wg/oauth/trac/ticket/4#comment:1>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Leif Johansson <[email-masked]>
Date: Wed, 5 Aug 2009 09:32:17 +0200

On Monday 03 August 2009 23.24.06 Eran Hammer-Lahav wrote:
> We will need to write a new proposal which can be based on the problem
> reporting extension. But it will be part of the core spec(s). I don't think
> we need to have it as an I-D. It is just a good reference (for the WG) to
> existing work in the space.
>

The core specification can be multiple documents... but I agree that 
writing a new I-D based on this work is probably a good way forward.
Keeping things in separate docs helps when you have multiple authors
and we can always merge all aspects if the core spec into a single
doc later should we want to (although I'm not sure we do).

	Cheers Leif