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

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 3 Aug 2009 14:22:28 -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
> ---------------------------------+-------------------------------------
> -----
>  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/>
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

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

Sorry. Wrong list. Outlook decided to change the destination.

EHL

> From: Eran Hammer-Lahav
> Sent: Monday, August 03, 2009 2:22 PM
> To: [email-masked] Group
> Subject: RE: [OAUTH-WG] [oauth] #4: Error Codes
> 
> 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
>