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

[Eran Hammer <[e-mail]>]

There was no such discuss on the core specification.

The only open discuss on the core specification related to character sets is to translate the EXISTING prose into ABNF which will not have any implementation impact.

The proper response to the bearer specification discuss was to simply add a registry there, and to clearly state that this matter was discussed extensively by the WG and the design committee. Instead of representing this information to the IESG, you failed to do your job as editor and offered your personal view which was rejected by the WG and recorded in the issue tracker at the time.

You don't get a second chance to insert your personal position during the IESG review process. As editor, you only get to represent the WG consensus when addressing issues. If you go and read my responses to the long list of discuss items on the core specification you will see that I represented views I personally did not agree with (the lack of interop, undefined security, etc.) because as editor, I don't get to go to the IESG and disrespect the WG's decision.

The IESG members rely on the editor to represent the WG decisions to them when addressing issues. You failed to do that, promoted your personal view, and now we are having this discussion all over again - a discussion that last time was only resolved by creating the design committee.

EH


> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> 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
>