Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01
Keep in mind that a major purpose of this document is to encourage best practices by well-meaning developers. We want to make it clear for people who want to do the right thing what the right thing to do is. No document in the world will make ill-meaning developers do the right thing. -- Justin On 01/23/2012 07:17 PM, Michael Thomas wrote: On 01/23/2012 01:47 PM, S Moonesamy wrote: Minor Issues: 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would be obvious to someone who is an OAuth2 implementor. Actually I'd say that it is *not* obvious because I joined the working group mailing list as an oauth deployer who had precisely questions along these lines expecting that I was *wrong* in worrying about this attack. I'd also say in this section and others like it dealing with native apps that saying: Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software Is wrong headed. It's not the authorization server's task to protect the end user, but the authorization server *surely* has an interest in protecting *itself* from rogue clients. An attack by a malicious client is an attack against the end user *and* the authorization server. 4.4.1.9 I think where it says iFrame it might mean WebView, i.e. a Web Browser control embedded in the native app. If that's not what it means, I don't understand what it's saying. If this is true, then the second bullet point is probably wrong. I agree, and don't think the first bullet makes any sense either: Native applications SHOULD use external browsers instead of embedding browsers in an iFrame when requesting end-user authorization Who exactly is the attacker here? If it's the native app itself, then this isn't a countermeasure at all because the rogue client will ignore this SHOULD. If it's not the native app, then what is the an external browser doing that an embedded browser cannot? I don't understand the third bullet in this one either, but if only works in older browsers it's probably not worth mentioning. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] REVISED Last Call: draft-ietf-oauth-v2-23.txt (The OAuth 2.0 Authorization Protocol) to Proposed Standard
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol' draft-ietf-oauth-v2-23.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. There are a few downrefs to note: * There is a normative reference to RFC 1750, which will be updated to point to RFC 4086 before publication. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 5246 (TLS 1.2). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. * There is a normative reference to Informational RFC 2818 (HTTP over TLS). This is an allowed downref. * There is a normative reference to Informational RFC 4627 (application/json Media Type). This is an allowed downref. * There is a normative reference to Informational RFC 4949 (Internet Security Glossary). This is an allowed downref. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ No IPR declarations have been submitted directly on this I-D. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 5246 (TLS 1.2). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ No IPR declarations have been submitted directly on this I-D. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
Folks, The OAuth bearer and base last calls had to be re-done since I forgot to include some downref information. Other than adding a day to IETF LC, there should be no other difference. Sorry about that. S On 01/24/2012 03:00 PM, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 5246 (TLS 1.2). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01
On 01/24/2012 05:57 AM, Justin Richer wrote: Keep in mind that a major purpose of this document is to encourage best practices by well-meaning developers. We want to make it clear for people who want to do the right thing what the right thing to do is. No document in the world will make ill-meaning developers do the right thing. That what BCP's are for. A threat document is supposed to outline threats and what good guys can do to mitigate them. Telling bad guys to be good is completely useless. Mike -- Justin On 01/23/2012 07:17 PM, Michael Thomas wrote: On 01/23/2012 01:47 PM, S Moonesamy wrote: Minor Issues: 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would be obvious to someone who is an OAuth2 implementor. Actually I'd say that it is *not* obvious because I joined the working group mailing list as an oauth deployer who had precisely questions along these lines expecting that I was *wrong* in worrying about this attack. I'd also say in this section and others like it dealing with native apps that saying: Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software Is wrong headed. It's not the authorization server's task to protect the end user, but the authorization server *surely* has an interest in protecting *itself* from rogue clients. An attack by a malicious client is an attack against the end user *and* the authorization server. 4.4.1.9 I think where it says iFrame it might mean WebView, i.e. a Web Browser control embedded in the native app. If that's not what it means, I don't understand what it's saying. If this is true, then the second bullet point is probably wrong. I agree, and don't think the first bullet makes any sense either: Native applications SHOULD use external browsers instead of embedding browsers in an iFrame when requesting end-user authorization Who exactly is the attacker here? If it's the native app itself, then this isn't a countermeasure at all because the rogue client will ignore this SHOULD. If it's not the native app, then what is the an external browser doing that an embedded browser cannot? I don't understand the third bullet in this one either, but if only works in older browsers it's probably not worth mentioning. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01
Hi, thanks for the thoroughly review. The threat document is intended to become an Informational RFC. So we will follow your advice and remove all normative language. regards, Torsten. Am 23.01.2012 22:47, schrieb S Moonesamy: The following is the AppsDir review performed by Tim Bray. It would be appreciated if a reply is sent to Tim Bray with a copy to the apps-discuss mailing list. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 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-threatmodel-01 Title: OAuth 2.0 Threat Model and Security Considerations Reviewer: Tim Bray Review Date: Jan 23, 2012 Summary: This needs some more editorial work, but is basically sound. It's not clear, though, whether it wants to be an Informational RFC or not; the use of RFC2119 language needs special attention. I think a few of the minor issues are worthy of a little bit more work in another draft. Major Issues: The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I normally wouldn't expect a threat model to include normative text. The basic idea would be to say Here is an enumeration of the threats, and here are the tools available to OAUTH2 implementors to meet them. I was impressed by the enumeration, which seemed very complete and well thought through. But the usage of 2119, which makes statements normative, seems inconsistent. I can think of 2 ways to address this: 1. Remove all the 2119 words, so this document isn't normative, and publish it as an Informational RFC 2. Go through and clean up the 2119 language so it's used consistently; then this becomes a normative document. This is going to affect the references to this document from other I-Ds in the OAuth suite, which are currently in last call. Here are all the section-numbered notes enumerating my issues around 2119, as I encountered them: Section 2.3, I'm a little confused about the use of RFC2119 MAY in a threat analysis. When you say The following data elements MAY be stored or accessible..., Is this saying that The OAuth2 RFC says that the following data elements MAY be... or is it saying something else. I don't think there's anything seriously wrong here, but a bit more explanation might be in order. I note a comparative absence of 2119-ese in section 5 describing countermeasures, where one would expect to find it. Also in 4.3.1, first bullet point, there's Authorization servers MUST... Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 Related: SHALL?! in 4.6.3 Adding to the concern, there is use of lower-case must; note 2nd 3rd bullet points in 4.4.3, which use MUST and must respectively. Minor Issues: 4.1.2 first attack: It says An attack may obtain the refresh tokens issued to a web server client. This needs to be clearer... a Web server client can be a browser or a native app. Do you mean, the refresh tokens issued by the web server to multiple clients? 4.1.2 last attack. In the case where a device is cloned, wouldn't Utilize device lock to prevent unauthorized device access still be a countermeasure? In many devices, such cloning would carry along the user's device-lock settings. 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would be obvious to someone who is an OAuth2 implementor. 4.4.1.9 I think where it says iFrame it might mean WebView, i.e. a Web Browser control embedded in the native app. If that's not what it means, I don't understand what it's saying. If this is true, then the second bullet point is probably wrong. 4.6.6 1st bullet. I'm not convinced that the Cache-Control header will *ensure* that a client protects information properly. Should say something like minimize the risk that authenticated content is not protected 5.* The enumeration, for some but not all of the countermeasures in this section, of the threats against which this is a countermeasure, reduces readability and, unless it's generated automatically from the underlying source, is redundant information, which is unlikely to be consistent between sections 4 and 5, and adds difficulty to maintenance of this document without adding much value. I'd just wipe all these bullet lists out. If it's generated automatically it's less damaging, but still reduces readability. In the current draft, this is there for some countermeasures but absent for others. Another good reason to just take it out. 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is not adequate, but there are ways to do it without
Re: [OAUTH-WG] Server cret verification in 10.9
We added the reference to RFC6125 in openID Connect. The Client MUST perform a TLS/SSL server certificate check, per xref target=RFC6125RFC 6125/xref. We wanted to be more general to allow for non http bindings in the future. If you don't do it in core, every spec that references core will probably have to add it. John B. On 2012-01-24, at 12:32 AM, Peter Saint-Andre wrote: On 1/20/12 4:46 PM, Eran Hammer wrote: Stephen asked: (13) 10.9 says that the client MUST verify the server's cert which is fine. However, does that need a reference to e.g. rfc 6125? Also, do you want to be explicit here about the TLS server cert and thereby possibly rule out using DANE with the non PKI options that that WG (may) produce? Can someone help with this? I don’t know enough to address. The OAuth core spec currently says: The client MUST validate the authorization server's TLS certificate in accordance with its requirements for server identity authentication. RFC 2818 has guidance about endpoint identity, in Section 3.1: http://tools.ietf.org/html/rfc2818#section-3.1 RFC 6125 attempts to generalize the guidance from RFC 2818 and many similar specs for use by new application protocols. Given that OAuth as defined by the core spec runs over HTTP, I think referencing RFC 2818 would make sense. So something like: The client MUST validate the authorization server's TLS certificate in accordance with the rules for server identity authentication provided in Section 3.1 of [RFC2818]. Peter -- Peter Saint-Andre https://stpeter.im/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-23 16:58, Julian Reschke wrote: On 2012-01-23 16:46, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard ... Please see my comments in https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html which I think have not been addressed. ... In an off-list conversation I heard that what I said before may not be as clear as it could be. So... 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme. 2) In the IANA considerations, it references the registration procedure defined in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3 (now -18, but that doesn't matter here). 3) That document recommends in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1: 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. 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been mentioned that it might not have ignored it if it had UPPERCASE requirements, but in HTTPbis we try to restrict BCP14 keywords to the actual protocol, not on recommendations on other specs. 5) The registration requirement for a new scheme is IETF review, which RFC 5226 defines in http://tools.ietf.org/html/rfc5226#section-4.1 as: IETF Review - (Formerly called IETF Consensus in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. In this case the WG exists (it's HTTPbis), and the OAuth got two reviews from HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair, and myself, one of the authors. And yes, I believe the way OAuth defines the syntax *will* impact interoperability. Also, I haven't seen any explanation why OAuth can not follow the recommendation from HTTPbis. Hope this clarifies things, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth specs in IETF last call
On 2012-01-23 18:39, Peter Saint-Andre wrote: On 1/23/12 10:11 AM, Mike Jones wrote: FYI, the OAuth Core and Bearer specifications have reached IETF last call status - the last step before becoming RFCs. See the following notes from the Internet Engineering Steering Group (IESG). Well, last step might be a bit optimistic. :) For those who aren't familiar with the process, the next steps are: 1. IETF Last Call, which lasts two weeks. This is essentially your last opportunity to provide feedback! 2. During IETF Last Call, the documents will be reviewed by several cross-area teams within the IETF, including folks like the GEN-ART review team and the AppsDir. We'll expect at least some feedback from those teams. And at this stage anyone in the Internet community can provide feedback, too. 3. After IETF Last Call, this WG's document editors will work to address any feedback we've received. 4. The documents will then be scheduled for disussion during an IESG telechat. Before the telechat, all the members of the Internet Engineering Steering Group will review the specs and also provide feedback. If there are DISCUSSES and COMMENTS lodged then the document editors will need to address those (often in concert with the WG chairs). If some of those issues are substantive, the editors and chairs might bring those issues back to the WG for more discussion. 5. Assuming the documents are approved by the IESG, they will then be handed off to the RFC Editor team for final copy editing, proofreading, reference checking, etc. ... 6. ...and then will have to wait until all normatively referenced drafts are ready, too. Best regards, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
Per the discussion at
http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, the working
group's rationale for supporting quoted-string but not token syntax for these
parameters, and for requiring that backslash ('\') quoting not be used when
producing them is as follows:
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.
Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible
with standard parameter parsers, and so no interoperability problems are
created by restricting the parameter syntax to a subset of the syntax allowed
by HTTPbis. No non-standard code is needed to use parameters in the manner
described in the Bearer spec.
The current text is the result of thorough and informed discussion among the
working group, and reflects the best consensus available as I understand it in
my role as editor, attempting to accurately represent the working group's
decisions and rationale.
Best wishes,
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Julian Reschke
Sent: Tuesday, January 24, 2012 3:24 PM
To: i...@ietf.org
Cc: The IESG; oauth@ietf.org
Subject: Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The
OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-23 16:58, Julian Reschke wrote:
On 2012-01-23 16:46, The IESG wrote:
The IESG has received a request from the Web Authorization Protocol
WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol: Bearer Tokens'
draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard ...
Please see my comments in
https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html
which I think have not been addressed.
...
In an off-list conversation I heard that what I said before may not be as clear
as it could be.
So...
1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme.
2) In the IANA considerations, it references the registration procedure defined
in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3
(now -18, but that doesn't matter here).
3) That document recommends in
http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1:
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.
4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been
mentioned that it might not have ignored it if it had UPPERCASE requirements,
but in HTTPbis we try to restrict BCP14 keywords to the actual protocol, not on
recommendations on other specs.
5) The registration requirement for a new scheme is IETF review, which RFC
5226 defines in http://tools.ietf.org/html/rfc5226#section-4.1 as:
IETF Review - (Formerly called IETF Consensus in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.
In this case the WG exists (it's HTTPbis), and the OAuth got two reviews from
HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair, and
myself, one of the authors.
And yes, I believe the way OAuth defines the syntax *will* impact
interoperability.
Also, I haven't seen any explanation why OAuth can not follow the
recommendation from HTTPbis.
Hope this clarifies things,
Julian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-25 01:03, Mike Jones wrote:
Per the discussion at
http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, the working
group's rationale for supporting quoted-string but not token syntax for these
parameters, and for requiring that backslash ('\') quoting not be used when
producing them is as follows:
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.
Mike, you continue to ignore that WWW-Authenticate needs to be processed
by generic parsers, as a single instance can contain challenges for
different schemes.
If you disagree with the text below:
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.
(which is from the text defining the registry you are using), then
please come over to the HTTPbis WG and ask for a change. It's
work-in-progress.
Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible
with standard parameter parsers, and so no interoperability problems are
created by restricting the parameter syntax to a subset of the syntax allowed
by HTTPbis. No non-standard code is needed to use parameters in the manner
described in the Bearer spec.
That is not true. Using standard components will cause recipients to
accept invalid field instances, which *is* an interoperability problem.
This has happened before: RFC 2617 states that the realm parameter needs
to be quoted, but we see that all browsers accept the token form as well
(http://greenbytes.de/tech/tc/httpauth/#simplebasictok). That's not a
surprise because it's the natural thing to do with a generic parser.
Please don't add to the mess. In particular when there really is no
reason to do so. All I heard from you is: we prefer it that way. I'm
sorry, but that's not sufficient.
...
Best regards, Julian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The
Thanks for asking, Martin. That's effectively what the spec does already. It
restricts the input values of these parameters to be quoted strings containing
no backslashes.
As long as that syntax restriction remains in place, it wouldn't actually
matter whether the BNF for scope, error, error_description, and
error_uri continues to be defined as quoted-string, is defined as token /
quoted-string, per HTTPbis, or defined by referencing the HTTPbis auth-param
definition and containing no parameter-specific BNF declarations. The meaning
of the spec would remain the same.
It's written the way it is, at present, because it would seem to be clearer to
implementers what the restrictions are by using the quoted-string BNF
production, rather than by imposing the restriction only in prose. But if
deleting the BNF definitions and leaving the syntax restrictions in the prose
would resolve this issue for people, I'm pretty sure the working group would be
fine with that, as it would be a non-normative change.
Best wishes,
-- Mike
-Original Message-
From: Martin Rex [mailto:m...@sap.com]
Sent: Tuesday, January 24, 2012 4:29 PM
To: Mike Jones
Cc: i...@ietf.org; i...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The
Mike Jones wrote:
Per the discussion at
http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html,
the working group's rationale for supporting quoted-string but not
token syntax for these parameters, and for requiring that backslash
('\') quoting not be used when producing them [...]
I'm slightly confused...
Instead of inappropriately re-specifying the WWW-Authenticate:, how about
referencing the original specification an rules, and then add your desired
requirements for *creation* of the contents on top of that, so that
oauth-bearer can permit recipients to reject stuff that doesn't fit the
additional send-requirements when processing the request.
I would assume that pretty much all authentication schemes will effectively
require subsetting of what can be conveyed to what they can parse, and further
subset this to what they can successfully verify, and reject everything else --
without having to rewrite the WWW-Authenticate syntax.
-Martin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Missing characters in draft-ietf-oauth-v2-23
Revision 23 of draft-ietf-oauth seems to be the victim of some form of sloppy character conversion; perhaps a conversion to ASCII without character transliteration. Some apostrophes have been removed and some names were changed in the acknowledgments. Here are the errors I could find while comparing revs 22 and 23: Section 1 the end-user's password became the end-user s password Section 12 Bill de hOra became Bill de h ra Andre DeMarre became Andr DeMarre Christian Stuebner became Christian St bner Appendix A one of OAuth's most became one of OAuth s most Regards, Andre DeMarre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
