Re: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

[Mike Jones <[e-mail]>]

Typo.  The first sentence below should have started "There was a DISCUSS on the *bearer* spec"...

-----Original Message-----
From: Mike Jones 
Sent: Wednesday, May 09, 2012 3:41 PM
To: 'Eran Hammer'; Hannes Tschofenig; [e-mail] WG
Subject: RE: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

There was a DISCUSS on the core spec asking us to cite the character set restrictions for scope and error values in the core spec, rather than defining them in the bearer spec.  It turns out that I could not do that as the core spec is currently written, because the character set restrictions are not present in the core spec.  If they are added to the core spec, I can satisfy the bearer DISCUSS by doing so.  If the restrictions are not added, I cannot.

This consensus call is part of resolving this DISCUSS, which affects both specs.

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Eran Hammer
Sent: Wednesday, May 09, 2012 3:35 PM
To: Hannes Tschofenig; [e-mail] WG
Subject: Re: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

I am confused by the process here.

The IESG review raised a LONG list of discuss items for the core specification. I was able to successfully address all but three remaining issues:

1. Lack of ABNF - I will do it myself this week since no one else bothered to offer their help.
2. Registry rules - waiting for this to be cleared; have addressed the issue but didn't hear back yet.
3. Comment on not allowing a fragment in redirection and endpoint URIs - waiting for text or item closed.

Every other issue for this document has been closed.

This WG cannot just go back after WG LC, IETF LC, and IESG review and make changes. This work is done, and any change made at this point must be for the sole purpose of addressing a discuss item. There are no discuss items for *this* document related to errors. They have all been raised in detail, addressed, and closed!

As for this survey - 

While I am still very much opposed to adding the protected resource registry function to the core specification, this new issue clearly demonstrate that this is not simply a matter of adding another error location.

The core spec currently provides full guidance and definition for error extensibility. Extending the registry's scope means the need for non-trivial new text that:

* explains the process of adding new errors for endpoints not defined by this specification,
* finds a common ground for value restrictions beyond what is already listed,
* guide authors of future HTTP authentication schemes meant for use with OAuth (e.g. MAC) for their requirements for using the error registry, and
* address the very likely scenario of the same error code carrying different meanings in different endpoints, or an extension that adds a location to a code already defined elsewhere - something very likely to happen if you cross the two very different domains (OAuth endpoints, Protected resource endpoints). This requires changing the entire structure of the registry to create separate records for each code/location pair.

Any change to the core specification MUST address all these items. This is absolutely NOT a matter of simply adding another location or throwing some extra ABNF. Adding such new text will require another IETF LC and another IESG review - which are completely unjustified based on where the document is in its IESG review process.

The point of IESG review is to close issues with minimal changes, not take it as an opportunity to sneak new functionality into the document. And it's not like this WG has not debated these items before, and made consensus calls on them.

Not adding the protected resource location to the registry was the result of intense negotiation both on the list and by the design committee. What was the point of asking a few of us to spend hours on the phone debating these issues and reaching a conclusion if it's another popularity contest now. We had FULL consensus by the design committee NOT to add the bearer errors to the core specification, and this recommendation was fully supported by the WG and documented in the issues tracker.

These WG surveys are an insult to proper process.

EH




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Hannes Tschofenig
> Sent: Wednesday, May 09, 2012 3:07 PM
> To: [e-mail] WG
> Subject: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer 
> Spec
> 
> Hi all,
> 
> another issue that came up in Sean's IESG review was about the 
> encoding of the error / error_description / error_uri in the base and 
> in the bearer specification.
> 
> As mentioned in my earlier mail about the registry for the error codes 
> there are three error fields defined in the two specification and the 
> error / error_description / error_uri fields are allowed to appear in 
> different parts of an HTTP message.
> Depending on where they show up different encoding restrictions apply.
> 
> For the core specification these error fields may appear in the
> * body of the HTTP message (encoded in JSON)
> * parameters to the query component of the redirection URI (using the
>   "application/x-www-form-urlencoded" format)
> 
> For the bearer specification these error fields appear in the HTTP header.
> Consequently, http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19
> says 'values for the "error" and "error_description" attributes MUST 
> NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.'
> 
> Now, here is the question. While these errors are essentially copied 
> over from one spec to the other the different encoding restrictions 
> make them different. Do we want different encodings of errors in the two documents?
> 
> So, I see two options:
> 
> 1) Leave the encoding as it is. This means the encoding of the error / 
> error_description / error_uri in the two specifications is different.
> 
> 2) Harmonize the encoding between the two specifications by 
> incorporating the restrictions from the bearer specification into the base specification.
> 
> Please indicate your preference by the end of next week (18th May 2012).
> 
> Ciao
> Hannes
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth