Subject: [OAUTH-WG] OK to post OAuth Bearer draft 15?

From: Mike Jones <[email-masked]>
Date: Thu, 15 Dec 2011 02:13:06 +0000

Mark, Stephen, Hannes, and Barry,

Any objections to posting the updated Bearer draft incorporating the results of the APPS Area review and the TLS requirements?

                                                            -- Mike

From: Mike Jones
Sent: Monday, December 12, 2011 8:51 AM
To: Mark Nottingham; 'Stephen Farrell'; [email-masked]
Subject: RE: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

Thanks for the detailed review, Mark.

Preliminary draft 15 of the OAuth Bearer specification is attached.  It resolves the form encoding issues raised by Julian Reschke in the manner discussed at the working group meeting in Taipei, incorporates the consensus text on TLS version requirements, and contains several improvements suggested by Mark Nottingham during APPS area review.

Mark, comments on all your proposed changes follow below:

* Section 2.3 URI Query Parameter

This section effectively reserves a URI query parameter for the draft's use. This should not be done lightly, since this would be a precedent for the IETF encroaching upon a server's URIs (done previously in RFC5785, but in a much more limited fashion, as a tactic to prevent further, uncontrolled encroachment).

Given that the draft already discourages the use of this mechanism, I'd recommend dropping it altogether. If the Working Group wishes it to remain, this issues should be vetted both through the APPS area and the W3C liaison.

(The same criticism could be leveled at Section 2.2 Form-Encoded Body Parameter, but that at least isn't surfaced in an identifier)

There are some contexts, especially limited browsers and/or development environments, where query parameters are usable but the other methods are not.  Thus, the query parameter method must be retained.  Also, Justin Richter’s comments describing the value to him of the query parameter method are pertinent:  “A URL with all parameters including authorization is a powerful artifact which can be passed around between systems as a unit”.

As to using a standard parameter name, this is essential for interoperability.  It is not “reserved” in any contexts other than when the Bearer spec is employed, which is a voluntary act by both parties.  Thus, this poses no undue burdens or namespace restrictions on implementations in practice.

Finally, you’ll find that OAuth 1.0 [RFC 5849<http://tools.ietf.org/html/rfc5849>] similarly defined, not one, but two standard query parameter values:  oauth_token and oauth_verifier.  As this didn’t cause any problems in practice then, I’m sure that defining an access_token parameter within the Bearer spec for interoperability purposes won’t cause a problem either.

* Section 3 The WWW-Authenticate Response Header Field

The draft references the quoted-string ABNF from HTTP, but changes its processing in a later paragraph:

"""In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character."""

This is at best surprising (as many readers will reasonably surmise that using the quoted-string ABNF implies that the same code can be used).

Please either use quoted-string as defined (i.e., with escaping).

This parameter definition was a result of significant working group discussion and reflects a solid consensus position.  Using the quoted string BNF makes it clear, per Julian Reschke’s suggestions, that generic parameter parsing code can be safely used.  Whereas prohibiting the use of backslash quoting by senders also makes it clear that custom implementations can directly utilize the parameter values as transmitted without performing any quote processing.

In short, the spec doesn’t change the processing of quoted strings.  It simply restricts the set of legal input characters within the quoted strings.

* Section 1: Introduction

The introduction explains oauth, but it doesn't fully explain the relationship of this specification to OAuth 2.0. E.g., can it be used independently from the rest of OAuth? Likewise, the overview (section

1.3) seems more specific to the OAuth specification than this document.

As I read it, this mechanism could be used for ANY bearer token, not just one generated through OAuth flows.

If it is indeed more general, I'd recommend minimising the discussion of OAuth, perhaps even removing it from the document title.

Per your suggestion, I’ve made it clear in the introduction that bearer tokens from any source can be used to access associated protected resources.  The new language in the introduction is:

“This specification defines the use of bearer tokens over HTTP/1.1 [I‑D.ietf‑httpbis‑p1‑messaging] using TLS [RFC5246] to access protected resources. … While designed for use with access tokens resulting from OAuth 2.0 Authorization [I‑D.ietf‑oauth‑v2] flows to access OAuth protected resources, this specification actually defines a general HTTP authorization method that can be used with bearer tokens from any source to access any resources protected by those bearer tokens.”

* Section 3 The WWW-Authenticate Response Header Field

The difference between a realm and a scope is not explained. Are the functionally equivalent, just a single value vs. a list?

Realm is as defined by HTTPbis.  It says that “The realm value is a string, generally assigned by the origin server, which can have additional semantics specific to the authentication scheme.”  The Bearer specification intentionally adds no extra semantics to the realm definition.  Whereas the scope parameter is defined as an order-independent space-separated list of scope values.  The contextual meaning of both the realm and scope parameters is deployment-dependent.

Do you really intend to disallow *all* extension parameters on the challenge?

Yes.  There was an explicit working group consensus decision to do so.

Also, the scope, error, error_description and error_uri parameters all specify only a quoted-string serialisation. HTTPbis strongly suggests that new schemes allow both forms, because implementation experience has shown that implementations will likely support both, no matter how defined; this improves interoperability (see p7 2.3.1).

Once again, the current text reflects a consensus decision of the working group.  It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implementations without any compensating benefit; better to support one syntax for each semantic operation and require all implementations to use it.

Finally, the error_description parameter can carry only ASCII characters. While I understand a tradeoff has been made here (and, in my judgement, an appropriate one), it's appropriate to highlight this in review.

Noted

* General

The draft currently doesn't mention whether Bearer is suitable for use as a proxy authentication scheme. I suspect it *may*; it would be worth discussing this with some proxy implementers to gauge their interest (e.g., Squid).

Who would you recommend review the draft from this perspective?

Finally, Mark, I applied all the editorial suggestions you made.  Thanks for those.

Mark, Stephen, and chairs, please let me know whether to now post this draft as an actual submission.

                                                            Thanks all,

                                                            -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Wednesday, November 23, 2011 11:51 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

FYI

-----Original Message-----

From: [email-masked]<mailto:[email-masked]>

[mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of ext Mark Nottingham

Sent: Thursday, November 24, 2011 8:22 AM

To: IETF Apps Discuss; [email-masked]<mailto:[email-masked]>

Cc: The IESG

Subject: [apps-discuss] APPS Area review of

draft-ietf-oauth-v2-bearer-14

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see <http://www.apps.ietf.org/content/applications-area-review-team>).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-oauth-v2-bearer-14

Title: OAuth 2.0 Bearer Tokens

Reviewer: Mark Nottingham

Review Date: 24/11/2011

Summary: This draft is almost ready for publication as a Proposed Standard, but has a few issues that should be fixed.

Major Issues

------------

* Section 2.3 URI Query Parameter

This section effectively reserves a URI query parameter for the draft's use. This should not be done lightly, since this would be a precedent for the IETF encroaching upon a server's URIs (done previously in RFC5785, but in a much more limited fashion, as a tactic to prevent further, uncontrolled encroachment).

Given that the draft already discourages the use of this mechanism, I'd recommend dropping it altogether. If the Working Group wishes it to remain, this issues should be vetted both through the APPS area and the W3C liaison.

(The same criticism could be leveled at Section 2.2 Form-Encoded Body Parameter, but that at least isn't surfaced in an identifier)

* Section 3 The WWW-Authenticate Response Header Field

The draft references the quoted-string ABNF from HTTP, but changes its processing in a later paragraph:

"""In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character."""

This is at best surprising (as many readers will reasonably surmise that using the quoted-string ABNF implies that the same code can be used).

Please either use quoted-string as defined (i.e., with escaping).

Minor Issues

------------

* Section 1: Introduction

The introduction explains oauth, but it doesn't fully explain the relationship of this specification to OAuth 2.0. E.g., can it be used independently from the rest of OAuth? Likewise, the overview (section

1.3) seems more specific to the OAuth specification than this document.

As I read it, this mechanism could be used for ANY bearer token, not just one generated through OAuth flows.

If it is indeed more general, I'd recommend minimising the discussion of OAuth, perhaps even removing it from the document title.

* Section 3 The WWW-Authenticate Response Header Field

The difference between a realm and a scope is not explained. Are the functionally equivalent, just a single value vs. a list?

Do you really intend to disallow *all* extension parameters on the challenge?

Also, the scope, error, error_description and error_uri parameters all specify only a quoted-string serialisation. HTTPbis strongly suggests that new schemes allow both forms, because implementation experience has shown that implementations will likely support both, no matter how defined; this improves interoperability (see p7 2.3.1).

Finally, the error_description parameter can carry only ASCII characters. While I understand a tradeoff has been made here (and, in my judgement, an appropriate one), it's appropriate to highlight this in review.

* General

The draft currently doesn't mention whether Bearer is suitable for use as a proxy authentication scheme. I suspect it *may*; it would be worth discussing this with some proxy implementers to gauge their interest (e.g., Squid).

Nits

----

* Section 2.1 Authorization Request Header Field

"simplicity reasons" --> "simplicity"

"If additional parameters are desired in the future, a different scheme could be defined." --> "If additional parameters are needed in the future, a different scheme would need to be defined."

* Section 3 The WWW-Authenticate Response Header Field

The requirement that a resource server MUST include the HTTP WWW-Authenticate response header field is odd; really this is at the discretion of the server. Is it really necessary to use a conformance requirement here?

URI-reference --> URI-Reference

* Section 3.1 Error Codes

405 belongs in the list of typically appropriate status codes as well.

Kind regards,

--

Mark Nottingham   http://www.mnot.net/

_______________________________________________

apps-discuss mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/apps-discuss

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Dec 2011 13:36:37 +1100

Hi Mike -

It's not my function to object (or not) to the publication of the draft; I merely provided the APPS review, which will be considered by the responsible AD (like all other Last Call comments), and potentially the IESG.

If you're asking whether my concerns have been addressed, see some specifics below.

Regards,

On 15/12/2011, at 1:13 PM, Mike Jones wrote:

> There are some contexts, especially limited browsers and/or development environments

What does "developmental environments" mean here?

> , where query parameters are usable but the other methods are not.  Thus, the query parameter method must be retained.  Also, Justin Richter’s comments describing the value to him of the query parameter method are pertinent:  “A URL with all parameters including authorization is a powerful artifact which can be passed around between systems as a unit”.
>  
> As to using a standard parameter name, this is essential for interoperability.

I find it hard to believe that you could not find or design a mechanism to discover a URI.

> It is not “reserved” in any contexts other than when the Bearer spec is employed, which is a voluntary act by both parties.  Thus, this poses no undue burdens or namespace restrictions on implementations in practice.
>  
> Finally, you’ll find that OAuth 1.0 [RFC 5849] similarly defined, not one, but two standard query parameter values:  oauth_token and oauth_verifier.  As this didn’t cause any problems in practice then, I’m sure that defining an access_token parameter within the Bearer spec for interoperability purposes won’t cause a problem either.

The fact that a non-standards-track document did something that's potentially harmful doesn't make it OK. Saying that problems won't occur based upon such short-term implementation experience with this type of issue is ludicrous; the nature of the issue is long-term encroachment and setting precedent.

> In short, the spec doesn’t change the processing of quoted strings.  It simply restricts the set of legal input characters within the quoted strings.

See follow-up discussion with Julian.

> Realm is as defined by HTTPbis.  It says that “The realm value is a string, generally assigned by the origin server, which can have additional semantics specific to the authentication scheme.”

Yes...

> The Bearer specification intentionally adds no extra semantics to the realm definition.  Whereas the scope parameter is defined as an order-independent space-separated list of scope values.  The contextual meaning of both the realm and scope parameters is deployment-dependent.

That's not a great story for interop. How are people actually supposed to use them? Can you at least give an example?

> Yes.  There was an explicit working group consensus decision to do so.

It would be good to note this.

> Once again, the current text reflects a consensus decision of the working group.  It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implementa…

And I'm sure you're aware that the goal of this text in HTTPbis is to encourage reuse of code, rather than having multiple implementations of slightly different things. This is doubly true when you're not actually defining the syntax, but instead reusing syntax from elsewhere (HTTP), which already has parsers and generators implemented. 

> Who would you recommend review the draft from this perspective?

The easiest way would be to ask on the [email-masked] mailing list; there are several intermediary implementers active there.

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Fri, 16 Dec 2011 15:46:26 -0800

At 18:13 14-12-2011, Mike Jones wrote:
>Any objections to posting the updated Bearer draft incorporating the 
>results of the APPS Area review and the TLS requirements?

Mark Nottingham followed up on his review [1].  If this working group 
considers that the concerns raised have been addressed, I gather that 
it ok for me to raise them as issues during the Last Call for 
draft-ietf-oauth-v2-bearer.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/oauth/current/msg08052.html
2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html

---

From: Mike Jones <[email-masked]>
Date: Mon, 19 Dec 2011 01:00:57 +0000

Thanks for your comments, Mark.  Here are my thoughts on the issues that you see as being outstanding.  I'd also welcome additional input from the working group on these topics:

ON THE URI QUERY PARAMETER METHOD:

It seems like your objection to this is based on it using a standard query parameter name.  It therefore seems like there are four possible resolutions to this issue:

1.  Delete the query parameter method, as you suggested in your initial comments.  Given that I know this method is in widespread use in certain contexts, I doubt that there would be working group consensus for this resolution.

2.  Use a method for discovering the query parameter name.  It's my understanding that discovery work is presently out of scope for the OAuth working group as currently chartered.  The chairs and area directors could obviously change this, but it's my sense that developing a discovery spec for this purpose would delay the approval of this spec by a significant period of time.  I also question whether working group consensus could be developed for this resolution.

3.  Change the normative requirement for using the name access_token to a recommendation.  Specifically, we could change the text "When sending the access token in the HTTP request URI, the client adds the access token to the request URI query component ... using the 'access_token' parameter" to "When sending the access token in the HTTP request URI, the client adds the access token to the request URI query component ... using a query parameter.  It is RECOMMENDED that the query parameter name 'access_token' be used".  (If we change this to RECOMMENDED, I suspect we'd also do the same for the name of the form-encoded body parameter.)  This would seem to resolve your core objection, while still providing clear guidance to aid interoperability.  What would people think of this?

4.  Leave the specification as-is.

I'd like to hear working group opinions on which of these potential resolutions members support.

ON THE WWW-AUTHENTICATE RESPONSE HEADER FIELD:  

See the follow-up discussion with Julian.

ON THE REALM AND SCOPE DEFINITIONS:

You wrote "That's not a great story for interop. How are people actually supposed to use them? Can you at least give an example?"  I agree with you that that's not a great story for interop but it's also the current reality of OAuth usage.  Indeed, I know that different deployments use them in different ways for different things.  There's a bunch of information that currently needs to be exchanged in a manner not covered by the specifications to use OAuth between parties.  Among other things, this includes the endpoint addresses, the ways that realm and scope are used, and (when not opaque) the format of the access token.

(Profiles of OAuth such as OpenID Connect address this by providing specific guidance, but that guidance, I believe, is too specific to add to the OAuth specs themselves.)

Given that both scope and realm are used in practice in different ways by different deployments, I don't see a clear resolution to this issue other than to leave the spec as-is.  I'd welcome specific alternative wording proposals, however.

ON SPECIFYING ONLY A QUOTED-STRING SERIALIZATION:

I understand and agree with your desire to promote code reuse.  You cite HTTPbis P7 2.3.1 to support adding a requirement for supporting token serialization in addition to quoted-string serialization for all parameters.  I believe that the relevant text there is:
      When the auth-param syntax is used, all parameters ought
      to support both token and quoted-string syntax, and syntactical
      constraints ought to be defined on the field value after parsing
      (i.e., quoted-string processing).  This is necessary so that
      recipients can use a generic parser that applies to all
      authentication schemes.

      Note: the fact that the value syntax for the "realm" parameter is
      restricted to quoted-string was a bad design choice not to be
      repeated for new parameters.

First, it's my understanding that this text was added between -16 and -17 explicitly to try to force a change the definitions used in the Bearer spec.  While this seems heavy-handed, be that as it may.   Assuming the specification remains as-is, I think there are two code reusability cases to consider:

Recipient Case:  Recipients are able to use code capable of parsing both token and quoted-string syntax to parse fields that may only contain quoted string syntax.  Thus, the rationale for this requirement given in P7 is actually incorrect; recipients *can* use a generic parser that applies to all authentication schemes.  (Perhaps P7 should be corrected?)  There is no code-reuse problem for recipients.

Producer Case:  I will grant that it is possible for generic parameter producer code to exist that does not give the caller control over how the parameter is serialized.  If such code is used, it would be possible for a parameter value such as "xyz" to be erroneously serialized as xyz, thus creating an interoperability problem.  Note however, that serialization of the HTTP-defined realm parameter MUST occur using quoted-string serialization.  Thus, in practice, it would seem that generic frameworks still need to enable callers to control the serialization formats of specific parameters.  Hence, I doubt that this problem-in-theory is actually a problem-in-practice.  I'd be interested in data points from the working group about whether HTTP frameworks they use would have his problem in practice or not.

It seems that there are two possible resolutions to this issue:

1.  Change the spec to allow both quoted-string and token serialization for these parameters.

2.  Leave the specification as-is.

I'd like to hear working group opinions on which of these potential resolutions members support.

ON SUITABILITY AS A PROXY AUTHENTICATION SCHEME:

Could someone who is a member of [email-masked] volunteer to ask that list whether they would like to make any review comments on http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15 as to its suitability for use as a proxy authentication scheme (and to cc: me when you ask the question)?  I'm not a member of this list.

				Thanks all,
				-- Mike

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Wednesday, December 14, 2011 6:37 PM
To: Mike Jones
Cc: Stephen Farrell; Hannes Tschofenig; Peter Saint-Andre; Barry Leiba; OAuth WG
Subject: Re: OK to post OAuth Bearer draft 15?

Hi Mike -

Regards,

> , where query parameters are usable but the other methods are not.  Thus, the query parameter method must be retained.  Also, Justin Richter's comments describing the value to him of the query parameter method are pertinent:  "A URL with all parameters including authorization is a powerful artifact which can be passed around between systems as a unit".
>  

> It is not "reserved" in any contexts other than when the Bearer spec is employed, which is a voluntary act by both parties.  Thus, this poses no undue burdens or namespace restrictions on implementations in practice.
>  
> Finally, you'll find that OAuth 1.0 [RFC 5849] similarly defined, not one, but two standard query parameter values:  oauth_token and oauth_verifier.  As this didn't cause any problems in practice then, I'm sure that defining an access_token parameter within the Bearer spec for interoperability purposes won't cause a problem either.

> This parameter definition was a result of significant working group discussion and reflects a solid consensus position.  Using the quoted string BNF makes it clear, per Julian Reschke's suggestions, that generic parameter parsing code can be safely used.  Whereas prohibiting the use of backslash quoting by senders also makes it clear that custom implementations can directly utilize the parameter values as transmitted without performing any quote processing.
>  
> In short, the spec doesn't change the processing of quoted strings.  It simply restricts the set of legal input characters within the quoted strings.

> Realm is as defined by HTTPbis.  It says that "The realm value is a string, generally assigned by the origin server, which can have additional semantics specific to the authentication scheme."

Yes...

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Dec 2011 11:37:37 +0100

On 2011-12-19 02:00, Mike Jones wrote:
> ...
> ...

The text change was caused by both the early interactions with OAuth 
(mainly thanks to James), and the fact that we see that was defined for 
Realm isn't implemented in practice 
(<http://greenbytes.de/tech/tc/httpauth/#simplebasictok>).

(Note: we had a working feedback loop between WG's here; that's a feature)

If you disagree with what HTTPbis P7 now says than you really really 
ought to come over to the HTTPbis WG's mailing list (*) and argue your 
point.

(*) Similarly to how I'm arguing my point over here.

> Recipient Case:  Recipients are able to use code capable of parsing both token and quoted-string syntax to parse fields that may only contain quoted string syntax.  Thus, the rationale for this req…

Yes, there is. As the test case above shows, all UA recipients accept 
both forms; none of them rejects the token syntax. This is a problem as 
people frequently do not code against specs but just do "what works".

I'm pretty sure that changing a UA's behavior here would cause breakage 
in practice.

> ...

3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined 
in HTTPbis. Just state the names of the parameters, their syntax *after* 
parsing and their semantics.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 24 Dec 2011 08:47:09 -0500

Hi Mike,

> I'd like to hear working group opinions on which of these potential resolutions members support.

One other possibility would be to split the query term out in a separate draft and publish as Informational, to emphasise that it's not the preferred mechanism (with suitable language in-document).

> You wrote "That's not a great story for interop. How are people actually supposed to use them? Can you at least give an example?"  I agree with you that that's not a great story for interop but it'…

So, why are these things exchanged in a field called "scope"? It seems to me that if they're really that broad, then either they should be transferred using a broad name (e.g., "cookie", "opaque"), or (preferably, IMO) they should be transferred in extensions.

> Could someone who is a member of [email-masked] volunteer to ask that list whether they would like to make any review comments on http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15 as to its…

I've done that.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Mike Jones <[email-masked]>
Date: Thu, 29 Dec 2011 21:18:11 +0000

You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbis. Just state the names of the parameters, their syntax *after* parsing and their semantics."

About some of Mark Nottingham's comments, Barry wrote "Let me point out that "this represents working-group consensus" is not always a valid response.  If the working group has actually considered the *issue*, that might be OK.  But if there's consensus for the chosen solution and someone brings up a *new* issue with it, that issue needs to be addressed anew."

Relative to these two statements, I believe that I should remark at this point that your proposed semantics of only considering the syntax after potential quoting was explicitly considered earlier by the working group and rejected.  The consensus, instead, was for the present "no quoting will occur for legal inputs" semantics.

I believe that in the New Year the chairs and area directors will need to decide how to proceed on this issue.  (The working group consensus, as I see it, is already both well-informed and clear on this point, but I understand that that's not the only consideration.)  It would be good to see the spec finished shortly.

				Best Wishes,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, December 19, 2011 2:38 AM
To: Mike Jones
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?

> First, it's my understanding that this text was added between -16 and -17 explicitly to try to force a change the definitions used in the Bearer spec.  While this seems heavy-handed, be that as it…

The text change was caused by both the early interactions with OAuth (mainly thanks to James), and the fact that we see that was defined for Realm isn't implemented in practice (<http://greenbytes.de/tech/tc/httpauth/#simplebasictok>).

If you disagree with what HTTPbis P7 now says than you really really ought to come over to the HTTPbis WG's mailing list (*) and argue your point.

> Recipient Case:  Recipients are able to use code capable of parsing both token and quoted-string syntax to parse fields that may only contain quoted string syntax.  Thus, the rationale for this req…

Yes, there is. As the test case above shows, all UA recipients accept both forms; none of them rejects the token syntax. This is a problem as people frequently do not code against specs but just do "what works".

I'm pretty sure that changing a UA's behavior here would cause breakage in practice.

> 2.  Leave the specification as-is.

3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbis. Just state the names of the parameters, their syntax *after* parsing and their semantics.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Dec 2011 11:25:56 +0100

> Relative to these two statements, I believe that I should remark at this point that your proposed semantics of only considering the syntax after potential quoting was explicitly considered earlier…

It would be helpful if you could back this statement with pointers to 
mails. As far as I can tell it's just you disagreeing with me.

Back to the facts:

a) the bearer spec defines an HTTP authentication scheme, and 
normatively refers to HTTPbis Part7 for that

b) HTTPbis recommends new scheme definitions not to have their own ABNF, 
as the header field syntax is defined by HTTPbis, not the individual scheme

c) the bearer spec defines it's own ABNF nevertheless

So the two specs are in conflict, and we should resolve the conflict one 
way or the other.

If you disagree with the recommendation in HTTPbis, then you really 
really should come over to HTTPbis WG and argue your point of view.

If you agree with it, but think that the bearer spec can't follow the 
recommendation, then it would be good to explain the reasoning 
(optimally in the spec).

If you agree with it, and think the bearer spec *could* follow it, 
then... change it, by all means.

Anyway, if this issue isn't resolved before IETF LC then it will be 
raised again at that time.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Fri, 30 Dec 2011 23:19:56 +0000

I did already back the statement that this is the working group consensus with the e-mails attached in this note sent to you on December 12, 2011:
  - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html

But since that apparently wasn't convincing to you that this working group decision represents more than "just me disagreeing with you", here are references to individual messages referenced in the above e-mail:
  - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
  - John Bradley:  http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
  - William Mills:  http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
  - Mike Jones:  http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
  - Phil Hunt:  http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
  - Justin Richer:  http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html

As for your assertion that the specs are in conflict, yes, the Bearer spec includes a different decision than a RECOMMENDED clause in the HTTPbis spec (which was added after the Bearer text was already in place).  However, it is not violating any MUST clauses in the HTTPbis spec.  Given that no MUSTS are violated, I don't see it mandatory for this tension to be resolved in favor of one spec or the other in order for both to be approved as RFCs.  I look forward to seeing that happen soon in both cases (and for the OAuth core spec as well).

				Best wishes,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?

> Relative to these two statements, I believe that I should remark at this point that your proposed semantics of only considering the syntax after potential quoting was explicitly considered earlier…

It would be helpful if you could back this statement with pointers to mails. As far as I can tell it's just you disagreeing with me.

Back to the facts:

a) the bearer spec defines an HTTP authentication scheme, and normatively refers to HTTPbis Part7 for that

b) HTTPbis recommends new scheme definitions not to have their own ABNF, as the header field syntax is defined by HTTPbis, not the individual scheme

So the two specs are in conflict, and we should resolve the conflict one way or the other.

If you disagree with the recommendation in HTTPbis, then you really really should come over to HTTPbis WG and argue your point of view.

If you agree with it, but think that the bearer spec can't follow the recommendation, then it would be good to explain the reasoning (optimally in the spec).

If you agree with it, and think the bearer spec *could* follow it, then... change it, by all means.

Anyway, if this issue isn't resolved before IETF LC then it will be raised again at that time.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 31 Dec 2011 12:58:41 +0100

>    - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html

I replied in 
<http://www.ietf.org/mail-archive/web/oauth/current/msg08043.html>:

"I'm not disagreeing with the decision not to allow "\" in the value. 
What I'm disagreeing with is writing the ABNF in a way that will make it 
likely for implementers to special-case OAuth parameters when they 
should not."

So you're citing a consensus for a related but different question. I 
recommend to read the mailing thread to the end.

> As for your assertion that the specs are in conflict, yes, the Bearer spec includes a different decision than a RECOMMENDED clause in the HTTPbis spec (which was added after the Bearer text was alr…

As a matter of fact, the HTTPbis P7 text on considerations for new 
schemes doesn't use any BCP14 keywords at all. That's on purpose, 
because we think they should be used with care, and in particular that 
they should only be used to discuss the protocol, not the style of other 
specifications.

So it's really not relevant; what's essential is the intent of the spec 
text, and I believe that is VERY clear:

    o  The parsing of challenges and credentials is defined by this
       specification, and cannot be modified by new authentication
       schemes.  When the auth-param syntax is used, all parameters ought
       to support both token and quoted-string syntax, and syntactical
       constraints ought to be defined on the field value after parsing
       (i.e., quoted-string processing).  This is necessary so that
       recipients can use a generic parser that applies to all
       authentication schemes.

(Note the "cannot").

So again, if you disagree with this statement, please argue your case in 
the HTTPbis WG.

If you *do* agree, but somehow feel that the bearer spec can't do this, 
the bearer spec should document the reason (just like when an 
implementation fails to implement a SHOULD).

As to the question of timing (when certain paragraphs were added): yes, 
HTTPbis P7 changed based on feedback and review of the OAuth bearer spec 
(triggered by James Manger). That's a feature.

If it hadn't, for instance, the bearer spec wouldn't conform to the base 
grammar *at all*. See 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/195>.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Sat, 31 Dec 2011 19:40:14 +0000

Maybe I misunderstood your position.  If you agree that '\' may not occur in the INPUT string, then that issue can be closed.  That was the working group consensus position, per the cited e-mails.  I thought that you were arguing that syntax restrictions on the parameters should only be placed upon the OUTPUT string - which forces all implementations to support unnecessary encodings like "\a\b\c" for "abc".  Please let me know whether you're fine with the working group prohibiting the use of '\' in the input string as the spec presently currently does.

				Happy New Year!
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Saturday, December 31, 2011 3:59 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?

I replied in

"I'm not disagreeing with the decision not to allow "\" in the value. 
What I'm disagreeing with is writing the ABNF in a way that will make it likely for implementers to special-case OAuth parameters when they should not."

So you're citing a consensus for a related but different question. I recommend to read the mailing thread to the end.

> As for your assertion that the specs are in conflict, yes, the Bearer spec includes a different decision than a RECOMMENDED clause in the HTTPbis spec (which was added after the Bearer text was alr…

As a matter of fact, the HTTPbis P7 text on considerations for new schemes doesn't use any BCP14 keywords at all. That's on purpose, because we think they should be used with care, and in particular that they should only be used to discuss the protocol, not the style of other specifications.

So it's really not relevant; what's essential is the intent of the spec text, and I believe that is VERY clear:

(Note the "cannot").

So again, if you disagree with this statement, please argue your case in the HTTPbis WG.

If you *do* agree, but somehow feel that the bearer spec can't do this, the bearer spec should document the reason (just like when an implementation fails to implement a SHOULD).

As to the question of timing (when certain paragraphs were added): yes, HTTPbis P7 changed based on feedback and review of the OAuth bearer spec (triggered by James Manger). That's a feature.

If it hadn't, for instance, the bearer spec wouldn't conform to the base grammar *at all*. See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/195>.

Best regards, Julian