Hi Mike, On 18/12/2011, at 8:00 PM, Mike Jones wrote:
> 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. 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). > 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. 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. > (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 ietf-http...@w3.org 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. I've done that. Cheers, > > Thanks all, > -- Mike > > -----Original Message----- > From: Mark Nottingham [mailto:m...@mnot.net] > 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 - > > 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: > >> 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'; oauth@ietf.org >> 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 > > 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. > > >>> * 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. > > See follow-up discussion with Julian. > > >>> * 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." > > 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? > > >>> Do you really intend to disallow *all* extension parameters on the >>> challenge? >> >> Yes. There was an explicit working group consensus decision to do so. > > It would be good to note this. > > >>> 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. > > 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. > > >>> * 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? > > The easiest way would be to ask on the ietf-http...@w3.org mailing list; > there are several intermediary implementers active there. > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > > -- Mark Nottingham http://www.mnot.net/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
