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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 May 2012 01:06:49 +0300

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 May 2012 22:15:35 +0000

2) Consistent syntax across both OAuth specs.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, May 09, 2012 3:07 PM
To: [email-masked] WG
Subject: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

Hi all, 

So, I see two options: 

Ciao
Hannes

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Wed, 9 May 2012 15:18:16 -0700 (PDT)

+1

>________________________________
> From: Mike Jones <[email-masked]>
>To: Hannes Tschofenig <[email-masked]>; "[email-masked] WG" <[email-masked]> 
>Sent: Wednesday, May 9, 2012 3:15 PM
>Subject: Re: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec
>

---

From: John Bradley <[email-masked]>
Date: Wed, 9 May 2012 18:27:43 -0400

Consistent syntax across bearer, core and MAC.

That wasn't one of the options:)

John B.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 9 May 2012 22:34:30 +0000

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

> 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.
> 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.
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 May 2012 22:41:21 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Wednesday, May 09, 2012 3:35 PM
To: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

As for this survey - 

EH

> 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.
> 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:
> 
> 2) Harmonize the encoding between the two specifications by 
> incorporating the restrictions from the bearer specification into the base specification.
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 May 2012 22:42:24 +0000

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; [email-masked] WG
Subject: RE: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

				-- Mike

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

As for this survey - 

EH

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 10 May 2012 00:59:35 +0200

+1 for the consistency.

Nat Sakimura

On 2012/05/10, at 0:18, William Mills <[email-masked]> wrote:

+1

  ------------------------------
*From:* Mike Jones <[email-masked]>
*To:* Hannes Tschofenig <[email-masked]>; "[email-masked] WG" <
[email-masked]>
*Sent:* Wednesday, May 9, 2012 3:15 PM
*Subject:* Re: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer
Spec

                -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Wednesday, May 09, 2012 3:07 PM
To: [email-masked] WG
Subject: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

Hi all,

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.

So, I see two options:

Ciao
Hannes

---

From: Eran Hammer <[email-masked]>
Date: Wed, 9 May 2012 23:04:44 +0000

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

> From: Mike Jones [mailto:[email-masked]]
> To: Eran Hammer; Hannes Tschofenig; [email-masked] WG
> 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.
> 
> 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:
> 
> 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:
> 
> * 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.
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 May 2012 23:32:34 +0000

Per the earlier correction to my typo, the DISCUSS was on the bearer spec.  It asked me to reference syntax restrictions for scope and error values the core spec, that it turns out were not uniformly present there.  The chairs decided to ask the working group whether to add them there (allowing me to satisfy the bearer DISCUSS) or whether not to (in which case, we'll have to come up with a different resolution).

I believe it was reasonable of the person filing the DISCUSS to expect the syntax for these elements to be the same between the two specs, and so reasonable of the chairs to ask the question.

To my knowledge, there was no working group consensus that the syntax of these elements should be different across the OAuth specs (despite your apparent representation to the contrary below).  In fact, at least in the case of the scope parameter, there was clear WG consensus tracked as http://trac.tools.ietf.org/wg/oauth/trac/ticket/27 to make them be the same. 

Yes, I have expressed my personal opinions as a member of the working group in appropriate contexts (as have you).  But I have never represented my personal opinions as working group consensus unless that was actually the case, your statements below notwithstanding.

				-- Mike

P.S.  As you know, the other outstanding consensus call about registering OAuth Errors was a result of a DISCUSS on the bearer spec that explicitly asked us to register the bearer errors in the existing OAuth Errors Registry - not a result of me suggesting that that should occur or me failing to accurately represent the working group discussions on that issue to date.  Again, it's a fair question raised by an IESG member, and one that Stephen Farrell asked the chairs to make a working group consensus call on, so that DISCUSS can be addressed as well.

-----Original Message-----
From: Eran Hammer [mailto:[email-masked]] 
Sent: Wednesday, May 09, 2012 4:05 PM
To: Mike Jones; Hannes Tschofenig; [email-masked] WG
Subject: RE: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec

EH

> 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 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:
> 
> * 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.
> 
> > 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.
> > Consequently, 
> > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19
> > 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.
> >
> > incorporating the restrictions from the bearer specification into 
> > the base
> specification.
> >

---

From: Eran Hammer <[email-masked]>
Date: Wed, 9 May 2012 23:43:15 +0000

I am only talking about the error code registry (location and value restrictions).

Go back to your responses to the IESG questions about adding the errors to the core spec's registry and you'll clearly see how you failed to represent the WG consensus. Instead, you should have pointed to the WG consensus regarding the scope of the error registry in the core spec, and only suggesting adding a registry in the bearer for that purpose alone.

EH

> Sent: Wednesday, May 09, 2012 4:33 PM
> Per the earlier correction to my typo, the DISCUSS was on the bearer spec.  It
> asked me to reference syntax restrictions for scope and error values the core
> spec, that it turns out were not uniformly present there.  The chairs decided
> to ask the working group whether to add them there (allowing me to satisfy
> the bearer DISCUSS) or whether not to (in which case, we'll have to come up
> with a different resolution).
> 
> I believe it was reasonable of the person filing the DISCUSS to expect the
> syntax for these elements to be the same between the two specs, and so
> reasonable of the chairs to ask the question.
> 
> To my knowledge, there was no working group consensus that the syntax of
> these elements should be different across the OAuth specs (despite your
> apparent representation to the contrary below).  In fact, at least in the case
> of the scope parameter, there was clear WG consensus tracked as
> http://trac.tools.ietf.org/wg/oauth/trac/ticket/27 to make them be the
> same.
> 
> Yes, I have expressed my personal opinions as a member of the working
> group in appropriate contexts (as have you).  But I have never represented
> my personal opinions as working group consensus unless that was actually
> the case, your statements below notwithstanding.
> 
> 				-- Mike
> 
> P.S.  As you know, the other outstanding consensus call about registering
> OAuth Errors was a result of a DISCUSS on the bearer spec that explicitly
> asked us to register the bearer errors in the existing OAuth Errors Registry -
> not a result of me suggesting that that should occur or me failing to
> accurately represent the working group discussions on that issue to date.
> Again, it's a fair question raised by an IESG member, and one that Stephen
> Farrell asked the chairs to make a working group consensus call on, so that
> DISCUSS can be addressed as well.
> 
> 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
> 
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 09 May 2012 21:37:17 -0400

+1

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          Home: [email-masked]
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

---

From: SM <[email-masked]>
Date: Thu, 10 May 2012 23:59:49 -0700

Hi Eran,
At 16:04 09-05-2012, Eran Hammer wrote:
>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.

Isn't it up the Document Shepherd to coordinate the resolution of 
DISCUSS or COMMENT items?

Regards,
-sm

---

From: Eran Hammer <[email-masked]>
Date: Fri, 11 May 2012 07:18:56 +0000

Don't know. In the 5 RFCs I've worked on, I - as editor - was the only personal who interacted with the IESG. Either way, it is usually the editor who is addressing questions about the text and proposing changes.

EH

> From: SM [mailto:[email-masked]]
> Sent: Friday, May 11, 2012 12:00 AM
> To: Eran Hammer
> Cc: [email-masked]
> >- a discussion that last time was only resolved by creating the design
> >committee.
> 
> Isn't it up the Document Shepherd to coordinate the resolution of DISCUSS
> or COMMENT items?
> 
> Regards,
> -sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 11 May 2012 13:51:42 +0000

> Sent: Friday, May 11, 2012 12:19 AM
> To: SM
> Cc: [email-masked]
> Don't know. In the 5 RFCs I've worked on, I - as editor - was the only
> personal who interacted with the IESG. Either way, it is usually the
> editor who is addressing questions about the text and proposing
> changes.

It sounds like you've had some pretty hands-off shepherds in your experience (as have I), or you dealt with the issues yourself which obviated the need for that person to act.  But formally, SM is correct about the Document Shepherd's function.  See RFC4858.

-MSK

---

From: Eran Hammer <[email-masked]>
Date: Fri, 11 May 2012 13:57:37 +0000

Ok. Would the document shepherd for the bearer specification please raise your hand?

EH

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Murray S. Kucherawy
> Sent: Friday, May 11, 2012 6:52 AM
> To: [email-masked]
> It sounds like you've had some pretty hands-off shepherds in your
> experience (as have I), or you dealt with the issues yourself which obviated
> the need for that person to act.  But formally, SM is correct about the
> Document Shepherd's function.  See RFC4858.
> 
> -MSK
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 May 2012 21:11:57 +0300

I am the shepherd for the bearer specification. 

On May 11, 2012, at 4:57 PM, Eran Hammer wrote:

>>> Of Eran Hammer