Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments
Thanks for your note, Julian. Responses follow inline...
-- Mike
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Saturday, September 24, 2011 5:07 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments
On 2011-09-24 02:13, Mike Jones wrote:
Thanks for your comments, Julian. Responses to them, which reflect the
content of draft 09, follow inline.
Thanks!
...
2.1. The Authorization Request Header Field
The Authorization request header field is used by clients to make
authenticated requests with bearer tokens. The client uses the
Bearer authentication scheme to transmit the access token in the
request.
For example:
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer vF9dft4qmT
The Authorization header field uses the framework defined by
[RFC2617] as follows:
credentials = Bearer RWS access-token
access-token = 1*( quoted-char / )
quoted-char = ALPHA / DIGIT /
! / # / $ / % / / ' / ( / ) /
* / + / - / . / / / : / / = /
/ ? / @ / [ / ] / ^ / _ / ` /
{ / | / } / ~ / \ / , / ;
This is incompatible with the RFC2617 grammar which requires auth-params.
HTTPbis P7 will introduce an alternative syntax (b64token), but that
is restricted to a single instance and thus not extensible.
I recommend to use auth-param syntax instead.
Thanks for pointing this out. I changed the credentials syntax to the
following, which directly uses the syntax in
draft-ietf-httpbis-p7-auth-16 (and so invents no new syntax):
credentials = Bearer 1*SP ( b64token / #auth-param )
The b64token is always there, right?
So you won't be able to use additional parameters, and thus the syntax is
effectively
credentials = Bearer 1*SP b64token
Is that intended and acceptable?
No, b64token isn't always there; the syntax specifies that either a b64token OR
one or more auth-params will be present. Yes, that's intended.
2.2. Form-Encoded Body Parameter
...
o The entity-body follows the encoding requirements of the
application/x-www-form-urlencoded content-type as defined by
[W3C.REC-html401-19991224].
o The HTTP request entity-header includes the Content-Type header
field set to application/x-www-form-urlencoded.
What about parameters?
Is there specific language either allowing or ruling out parameters to
the content-type value that you believe would be appropriate? Can you
provide a concrete motivating example?
The text as currently written makes it impossible to add parameters to the
type. However, the rule of thumb for unknown media type parameters is to ignore
them, not to reject them.
Maybe:
The HTTP Content-Type header field indicates a media type of
application/x-www-form-urlencoded.
What do others think of this change that is intended to allow additional
content-type parameters?
...
challenge = Bearer [ RWS 1#param ]
- please stick to the syntax defined in the authentication framework,
so use auth-param, and just define the allowed parameters separately.
I have changed the RWS to 1*SP to match httpbis-p7-auth. I retained
the param definition so as to be able to clearly syntactically limit
the acceptable set of parameters.
But the acceptable set of parameters is open-ended anyway, right?
param = realm / scope /
error / error-desc / error-uri /
auth-param
scope = scope = scope-v *( SP scope-v )
scope-v = 1*quoted-char
- This seems to override the quoted-string syntax. Don't. Generic
parsers *will* use the quoted-string syntax.
quoted-char = ALPHA / DIGIT /
! / # / $ / % / / ' / ( / ) /
* / + / - / . / / / : / / = /
/ ? / @ / [ / ] / ^ / _ / ` /
{ / | / } / ~ / \ / , / ;
This issue is tracked as issue #26. The proposed resolution to this
issue is being discussed in a separate thread.
OK.
error = error = quoted-string
error-desc = error_description = quoted-string
error-uri = error_uri = URI-reference
- missing I18N considerations
The draft now contains: the resource server MAY include the
error_description attribute to provide developers a UTF-8 encoded
human-readable explanation. (The UTF-8 language now matches the core
spec.)
UTF-8 is uncommon in HTTP header fields. It's not strictly forbidden, but most
code I've seen assumes ISO-8859-1 (see, for instance, XHR or Java servlet API).
You *can* use UTF-8, but may encounter strange problems caused by software
components in between.
This was the working group decision at the interim meeting and is used in both
the core and bearer drafts. I believe that UTF-8 is a reasonable outcome.
Unless there's a clear consensus to change both specifications, I believe that
this should stay as-is.
There was an explicit working
Re: [OAUTH-WG] Proposed resolution for issue 26
Sounds good to me. Are others good with this wording? -- Mike -Original Message- From: barryleiba.mailing.li...@gmail.com [mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba Sent: Saturday, September 24, 2011 6:33 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 My proposed resolution is that %-encoding not be required in the specification I agree with your analysis, now that I see it laid out clearly. I would feel better, though, if there were text in the document that explained that to others, who read it later. Perhaps, using your words, we could make this change to section 2.4: OLD The scope attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. The scope attribute MUST NOT appear more than once. NEW The scope attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. The scope attribute MUST NOT appear more than once. Interpretation of scope strings requires semantic agreement on the meaning of the scope strings between the parties participating the OAuth flow. Should an encoding be used for scope strings in a particular deployment context, participants have to have agreed upon that encoding, just as they agree on other OAuth configuration parameters. Does that work? Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed resolution for issue 26
While you take the viewpoint that the bearer spec is restricting scope values, in fact, the spec intentionally allows all characters that can be safely communicated in an HTTP response header parameter to be used. About whether those characters employ an encoding methodology to sometimes represent other characters or abstractions, I believe that Barry's proposed wording hits the nail on the head: Interpretation of scope strings requires semantic agreement on the meaning of the scope strings between the parties participating the OAuth flow. Should an encoding be used for scope strings in a particular deployment context, participants have to have agreed upon that encoding, just as they agree on other OAuth configuration parameters. Best wishes, -- Mike -Original Message- From: Manger, James H [mailto:james.h.man...@team.telstra.com] Sent: Saturday, September 24, 2011 7:41 AM To: Mike Jones; oauth@ietf.org Subject: RE: Proposed resolution for issue 26 From: Mike Jones Issue #26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 asks whether the semantics of scope strings should be changed to require that the % character be interpreted as introducing a percent-encoded character that follows. My proposed resolution is that %-encoding not be required in the specification; therefore no textual change would be made to the specification in response to this issue. The reasoning behind this resolution is as follows: I disagree. This does not resolve the ambiguity. I think there is some confusion between 1) the internal structure (eg encoding) of a scope string, and 2) escaping done when transporting the scope string in a protocol element. 1. Interpretation of scope strings already requires semantic agreement on the meaning of the scope strings between the parties participating the OAuth flow. Should an encoding be used for scope strings in a particularly deployment context, it is reasonable for participants to have agreed upon that encoding, just as they agree on other OAuth configuration parameters. A client app does NOT always need semantic agreement on the meaning of scope strings. Consider a client app that makes a request to a server and gets a 401 response with 'WWW-Authenticate: Bearer ... scope=X'. The client app now knows it can run an OAuth exchange to get the required permission to retry the request, and it should ask for the given scope during that OAuth exchange. The client app needs to copy XX from the response header into an OAuth exchange. It does not need to know anything more semantics about this scope value. XXX can be opaque to the client app. The client app does need to know any decode/encode steps involved in transferring this HTTP Bearer response value to an OAuth exchange value. If XXX is 1%2A2, should the client app redirect the user to https://example.org/authz?scope=1%2A2;... or https://example.org/authz?scope=1%252A2;... (or can the answer vary between different servers!!) 2. More than one encoding methodology could reasonably be employed in scope strings. For instance, base64url encoding of scope values could be used in some contexts. Quoting characters with '\' is another possibility. I see no compelling reason to mandate %-encoding over other potential encoding methods. Servers can choose any encoding they want (including none) when defining their own scope values (as logical Unicode strings). That is a separate choice to the encoding that is used in the HTTP Bearer response header when transporting a scope value. 3. Mandating %-encoding unnecessarily complicates implementations without providing a clear compensating benefit sufficient warrant the additional complexity. For example, it seems unnecessary to mandate that the scope strings email and %65mail MUST compare as being equal in all implementations. When the scope string email is transported in JSON the receiver MUST compare \u0065mail as equal. When it is transported as a URI query parameter the receiver MUST compare %65mail as equal. This is normal JSON and query parameter processing. 4. If an encoding methodology for scope strings is mandated, this should be done in the OAuth Core specification - not the OAuth Bearer Token specification. The core spec implies that a scope value can consist of any Unicode characters except space. The core spec transports scope values in JSON or url-encoded fields that have well-defined escaping mechanisms that are sufficient to handle all Unicode string, hence all possible scope values. The Bearer spec transports scope values in an HTTP response header parameter. It defines no escaping mechanism so it cannot handle all Unicode strings (ie it cannot handle all scope values that are possible in core). It is strange for the Bearer spec to restrict scope values. It should leave
[OAUTH-WG] Proposed resolution for issue 26
Issue #26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 asks whether the semantics of scope strings should be changed to require that the % character be interpreted as introducing a percent-encoded character that follows. My proposed resolution is that %-encoding not be required in the specification; therefore no textual change would be made to the specification in response to this issue. The reasoning behind this resolution is as follows: 1. Interpretation of scope strings already requires semantic agreement on the meaning of the scope strings between the parties participating the OAuth flow. Should an encoding be used for scope strings in a particularly deployment context, it is reasonable for participants to have agreed upon that encoding, just as they agree on other OAuth configuration parameters. 2. More than one encoding methodology could reasonably be employed in scope strings. For instance, base64url encoding of scope values could be used in some contexts. Quoting characters with '\' is another possibility. I see no compelling reason to mandate %-encoding over other potential encoding methods. 3. Mandating %-encoding unnecessarily complicates implementations without providing a clear compensating benefit sufficient warrant the additional complexity. For example, it seems unnecessary to mandate that the scope strings email and %65mail MUST compare as being equal in all implementations. 4. If an encoding methodology for scope strings is mandated, this should be done in the OAuth Core specification - not the OAuth Bearer Token specification. 5. I am aware of no existing practice that utilizes %-encoding of scope values. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Bearer token credentials syntax
James Manger and others pointed out that the current credentials syntax does
not comply with RFC 2617, nor does it match the updated credentials syntax
contained in HTTPbis, part 7:
Authenticationhttp://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16. The
current syntax in the bearer token
drafthttp://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-08 is:
credentials = Bearer RWS access-token
access-token= 1*( quoted-char / )
quoted-char = ALPHA / DIGIT /
! / # / $ / % / / ' / ( / ) /
* / + / - / . / / / : / / = /
/ ? / @ / [ / ] / ^ / _ / ` /
{ / | / } / ~ / \ / , / ;
The syntax in HTTPbis is:
credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
(Note that some of the BNF elements used by part 7 are defined in HTTPbis, part
1: Messaginghttp://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-16.)
To resolve this comment, I plan to change the Bearer Token draft to use this
syntax for credentials, matching HTTPbis:
credentials = Bearer 1*SP ( b64token / #auth-param )
Are people good with this approach?
Thanks,
-- Mike
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-v2-bearer-09.txt
-Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Friday, September 23, 2011 5:07 PM To: Mike Jones Cc: Mike Jones; d...@fb.com; dick.ha...@gmail.com Subject: New Version Notification for draft-ietf-oauth-v2-bearer-09.txt A new version of I-D, draft-ietf-oauth-v2-bearer-09.txt has been successfully submitted by Michael Jones and posted to the IETF repository. Filename:draft-ietf-oauth-v2-bearer Revision:09 Title: The OAuth 2.0 Authorization Protocol: Bearer Tokens Creation date: 2011-09-22 WG ID: oauth Number of pages: 18 Abstract: This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -09
Draft 09http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-09.html of the OAuth 2.0 Bearer Token Specificationhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html has been published, which incorporates Working Group Last Call feedback. It contains the following changes: · Use definitions from [I‑D.ietf‑httpbis‑p7‑auth] rather than [RFC2617]. · Update credentials definition to conform to [I‑D.ietf‑httpbis‑p7‑auth]. · Further clarified that query parameters may occur in any order. · Specify that error_description is UTF-8 encoded (matching the core specification). · Registered Bearer Authentication Scheme in Authentication Scheme Registry defined by [I‑D.ietf‑httpbis‑p7‑auth]. · Updated references to oauth-v2, httpbis-p1-messaging, and httpbis-p7-auth drafts. · Other wording improvements not introducing normative changes. The draft is available at these locations: · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-09.pdf · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-09.txt · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-09.xml · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-09.html · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-09.pdf · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-09.txt · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-09.xml · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point to new versions as they are posted) · http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, pdf, txt, and html versions available) -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments
Thanks for your comment, Peter. Done. Is there any estimated timeline for publication of the HTTPbis specs as RFCs? -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Tuesday, August 09, 2011 11:58 AM To: Julian Reschke Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments On 8/9/11 6:06 AM, Julian Reschke wrote: 1.1. Notational Conventions ... This document uses the Augmented Backus-Naur Form (ABNF) notation of [I-D.ietf-httpbis-p1-messaging], which is based upon the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the following rules are included from [RFC2617]: auth-param and realm; from [RFC3986]: URI-Reference; and from [I-D.ietf-httpbis-p1-messaging]: RWS and quoted-string. auth-param and realm should come from I-D.ietf-httpbis-p7-auth (optimally from a version = 16 which we should get out before the end of the month). And also add I-D.ietf-httpbis-p7-auth to the normative references. It appears that the authors are OK with normative references to the httpbis document series, but just so we're all aware that might delay publication of an RFC for the bearer token format spec... Peter -- Peter Saint-Andre https://stpeter.im/ ___ OAuth mailing list OAuth@ietf.orgmailto: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] draft-ietf-oauth-v2-bearer-08.txt WGLC comments
Thanks for your comments, James. Responses to them, which reflect the content of draft 09, follow inline. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Thursday, July 28, 2011 8:51 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt: 1. Mentioning that this is an HTTP authentication mechanism in the title and/or abstract would be useful to the wider IETF ( beyond) audience. Title: The BEARER HTTP authentication mechanism for use with OAuth 2 Abstract: This specification describes how to use bearer tokens in HTTP requests to access OAuth 2 protected resources. [Personally, I wouldn't bother mentioning OAuth at all here, but others seem to want this context restriction.] I revised the abstract wording, per your suggestion. I also added the word Authorization to the title so that it is exactly parallel with the core OAuth 2.0 spec. This parallelism clearly tying the two specifications together is likely more important for adopters of the specification than including HTTP Authentication in the title. 2. The ABNF for credentials does not comply with RFC 2617 HTTP Authentication. And even though RFC 2617 is broken is this aspect, the BEARER spec doesn't comply with the errata (still broken) or the more likely fixes proposed for HTTPbis [draft-ietf-httpbis-p7-auth]. I expect HTTPbis to allow a base64-like-blob consistently in Authorization and WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple WWW-Authenticate headers can have their values combined, separated by commas. They can also have quoted-string parameters. To be able to parse this, requires disallowing commas and double-quotes from the base64-like-blob (and hence from access-token) at a minimum; only allowing equals at the end also helps. The current approach in the bearer spec disallows all but 94 chars/bytes. I suggest reducing this to 69. Something in between (eg 91 chars, dropping comma, quote, and slash) might work. None of these options are materially easier than the others for a token issuer; and less symbols just means less risk of escaping problems elsewhere (eg allowing in an access token will wreck someone's XML somewhere, for no benefit). Suggestion: access-token = 1*( ALPHA / DIGIT / - / . / _ / ~ / + / / ) *= access-token includes the 66 unreserved URI characters plus a few others. It can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace [RFC4648]. Thanks for pointing this out. I changed the credentials syntax to the following, which directly uses the syntax in draft-ietf-httpbis-p7-auth-16 (and so invents no new syntax): credentials = Bearer 1*SP ( b64token / #auth-param ) 2b. If 2 is not accepted (and assuming HTTPbis will allow any content after the scheme name in a Authorization header) can we please not misuse the quoted-char label when no quoting is going on. The following is a better equivalent: access-token = 1*(%x21-7E) ; ASCII, except controls, space, or delete N/A 3. Drop '\' from the allowed chars in a scope value, to avoid clashing with the HTTP quoted-string escaping mechanism (and don't use the quoted-char label when no quoting is going on). scope-v = 1*(%x21 / %x23-5B / %x5D-7E); excludes space and and \ The place to make syntax changes to the scope value is in the OAuth 2.0 core spec - not the bearer token spec. No change made. 4. Section 3.3 Summary of Recommendations sensibly says clients MUST ensure that bearer tokens are not leaked to *unintended parties* and correctly notes that this is the primary security consideration that underlies all the others. So it is a glaring hole that OAuth2 fails to tell the client who the intended parties are when issuing a bearer token. This comment does not include a specific recommendation for a change to the spec, and so is not actionable. -- James Manger ___ OAuth mailing list OAuth@ietf.orgmailto: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] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments
Thanks for your comments, Julian. Responses to them, which reflect the content
of draft 09, follow inline.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Julian Reschke
Sent: Tuesday, August 09, 2011 5:07 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments
Hi there,
below a few comments on dependencies to HTTPbis, and the actual header field
syntax.
Best regards,
Julian
-- snip --
1.1. Notational Conventions
...
This document uses the Augmented Backus-Naur Form (ABNF) notation of
[I-D.ietf-httpbis-p1-messaging], which is based upon the Augmented
Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the
following rules are included from [RFC2617]: auth-param and realm;
from [RFC3986]: URI-Reference; and from
[I-D.ietf-httpbis-p1-messaging]: RWS and quoted-string.
auth-param and realm should come from I-D.ietf-httpbis-p7-auth (optimally from
a version = 16 which we should get out before the end of the month).
Done
2. Authenticated Requests
Clients SHOULD make authenticated requests with a bearer token using
the Authorization request header field defined by [RFC2617].
- HTTPbis P7
Done
2.1. The Authorization Request Header Field
The Authorization request header field is used by clients to make
authenticated requests with bearer tokens. The client uses the
Bearer authentication scheme to transmit the access token in the
request.
For example:
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer vF9dft4qmT
The Authorization header field uses the framework defined by
[RFC2617] as follows:
credentials = Bearer RWS access-token
access-token= 1*( quoted-char / )
quoted-char = ALPHA / DIGIT /
! / # / $ / % / / ' / ( / ) /
* / + / - / . / / / : / / = /
/ ? / @ / [ / ] / ^ / _ / ` /
{ / | / } / ~ / \ / , / ;
This is incompatible with the RFC2617 grammar which requires auth-params.
HTTPbis P7 will introduce an alternative syntax (b64token), but that is
restricted to a single instance and thus not extensible.
I recommend to use auth-param syntax instead.
Thanks for pointing this out. I changed the credentials syntax to the
following, which directly uses the syntax in draft-ietf-httpbis-p7-auth-16 (and
so invents no new syntax):
credentials = Bearer 1*SP ( b64token / #auth-param )
2.2. Form-Encoded Body Parameter
...
o The entity-body follows the encoding requirements of the
application/x-www-form-urlencoded content-type as defined by
[W3C.REC-html401-19991224].
o The HTTP request entity-header includes the Content-Type header
field set to application/x-www-form-urlencoded.
What about parameters?
Is there specific language either allowing or ruling out parameters to the
content-type value that you believe would be appropriate? Can you provide a
concrete motivating example?
o The HTTP request method is one for which a body is permitted to be
present in the request. In particular, this means that the GET
method MUST NOT be used.
GET permits a body; it's just not useful.
Changed sentence to The HTTP request method is one for which the request body
has defined semantics, per your suggestion in a private thread.
2.4. The WWW-Authenticate Response Header Field
If the protected resource request does not include authentication
credentials or contains an invalid access token, the resource server
MUST include the HTTP WWW-Authenticate response header field; it
MAY include it in response to other conditions as well. The
WWW-Authenticate header field uses the framework defined by
[RFC2617] as follows:
- HTTPbis P7
Done
challenge = Bearer [ RWS 1#param ]
- please stick to the syntax defined in the authentication framework,
so use auth-param, and just define the allowed parameters separately.
I have changed the RWS to 1*SP to match httpbis-p7-auth. I retained the
param definition so as to be able to clearly syntactically limit the
acceptable set of parameters.
param = realm / scope /
error / error-desc / error-uri /
auth-param
scope = scope = scope-v *( SP scope-v )
scope-v = 1*quoted-char
- This seems to override the quoted-string syntax. Don't. Generic
parsers *will* use the quoted-string syntax.
quoted-char = ALPHA / DIGIT /
! / # / $ / % / / ' / ( / ) /
* / + / - / . / / / : / / = /
/ ? / @ / [ / ] / ^ / _ / ` /
Re: [OAUTH-WG] Last call comments on bearer draft 08 from Yaron Goland
Thanks for your comments, Yaron. Responses to them, which reflect the content of draft 09, follow inline. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, August 10, 2011 2:39 PM To: oauth@ietf.org Subject: [OAUTH-WG] Last call comments on bearer draft 08 from Yaron Goland 1. Introduction: Adding the word directly after rather than using the resource owner's credentials. Done 1.3. Overview: Comment on first sentence: OAuth also supports having a client directly provide its own credentials to get an access token. It would seem useful to refer to this as well less the reader think that OAuth is only for delegation. That was true with OAuth 1.0 but not 2.0. Added the sentence: In some cases, a client can directly present its own credentials to an authorization server to obtain an access token without having to first obtain an access grant from a resource owner. and also qualified the phrase Before a client can access a protect resource by prefixing it with the words In the general case,. 1.3. Overview, paragraph 3: Commented on The following steps are specified within this document: Actually you also specify the token type returned in step D. I think this is worth explicitly calling out. Added the sentence: Use of this specification also requires that the access token returned in step (D) must be a Bearer token. 2. Authenticated Requests: Commented It would seem appropriate to begin with an example of step D showing that the returned access token is of type bearer. Not done, in the interest of brevity. 2.3. URI Query Parameter: Commented on second example: Does order matter? In this case the access_token is last. Is that because it has to be or because order is irrelevant? Clarified the text and example to make it clear that order doesn't matter. 2.4. The WWW-Authenticate Response Header Field: Commented on word invalid: The term invalid is a tricky one. Invalid can mean 'not supported' or 'not recognized' but that is generally taken to be a 400 Bad Request and would not require a www-authenticate response header field. Or invalid can mean 'supported but not the right credentials' in which case the error is a 401 Unauthorized and a www-authenticate response is required. I would urge you to consider simplifying this text by just stating (without preamble) that if a www-authenticate response header is returned (either from a 401 Unauthorized or other reasons) then support for the Bearer token type is specified as given below. I've changed this language to If the protected resource request does not include authentication credentials or does not contain an access token that enables access to the protected resource, the resource server MUST include I decided not to pare it down to the degree you suggested, as I believe that there is value to developers in explaining the conditions under which a WWW-Authenticate response would be used. 2.4. The WWW-Authenticate Response Header Field: Commented on param definition: As defined in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-15#section-4.4, www-authenticate is not really an error response mechanism. It's an advertisement mechanism. It says here is what I support by way of authentication. So I really don't think it's appropriate to show horn in here error information that has nothing to do with advertising authorization capabilities. If we need to return things like error, error-desc, etc. that should either be stuck in the body or put in a separate header. We should leave the www-authenticate header to be as simple as possible. As the bearer token spec has included these features since its inception, and since removing or changing these features would be a breaking change, I have not made this change. 3.1. Security Threats: Token redirect: Change An attacker uses the token generated for consumption by resource server to obtain access to another resource server to An attacker uses the token generated for consumption by a particular resource server with a different resource server that mistakenly believes the token to be for it. I've changed this to: An attacker uses a token generated for consumption by a particular resource server to gain access to a different resource server that mistakenly believes the token to be for it. 3.1 Security Threads: Token replay: Change replay to capture and change An attacker attempts to use a token that has already been used with that resource server in the past to An attacker somehow obtains a token they were not authorized to possess and uses it to access protected resources. Given that the replay attack is defined in NIST Special Publication 800-63, I am reluctant to change this attack description from token replay to token capture. 3.2 Threat Mitigation: Add at end of first paragraph: The mechanics
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments
I'm back from several weeks away from the office and presently reviewing the WGLC comments on the bearer token specification, so as to propose resolutions to the issues raised. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Tuesday, August 30, 2011 11:40 PM To: William J. Mills; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments William J. Mills said: Did item #2 below get resolved? I haven't seen any more traffic about it and it seems pretty significant. No, I haven't seen any resolution for #2 (or any of these comments). The latest HTTPbis draft (http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16) has updated ABNF for challenge and credentials that supports the base64-blobs used by BASIC and NTLM. It does not allow what BEARER tries to do. -- James Manger From: Manger, James H james.h.man...@team.telstra.com To: oauth@ietf.org oauth@ietf.org Sent: Thursday, July 28, 2011 8:51 PM Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt: 1. Mentioning that this is an HTTP authentication mechanism in the title and/or abstract would be useful to the wider IETF ( beyond) audience. Title: The BEARER HTTP authentication mechanism for use with OAuth 2 Abstract: This specification describes how to use bearer tokens in HTTP requests to access OAuth 2 protected resources. [Personally, I wouldn't bother mentioning OAuth at all here, but others seem to want this context restriction.] 2. The ABNF for credentials does not comply with RFC 2617 HTTP Authentication. And even though RFC 2617 is broken is this aspect, the BEARER spec doesn't comply with the errata (still broken) or the more likely fixes proposed for HTTPbis [draft-ietf-httpbis-p7-auth]. I expect HTTPbis to allow a base64-like-blob consistently in Authorization and WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple WWW-Authenticate headers can have their values combined, separated by commas. They can also have quoted-string parameters. To be able to parse this, requires disallowing commas and double-quotes from the base64-like-blob (and hence from access-token) at a minimum; only allowing equals at the end also helps. The current approach in the bearer spec disallows all but 94 chars/bytes. I suggest reducing this to 69. Something in between (eg 91 chars, dropping comma, quote, and slash) might work. None of these options are materially easier than the others for a token issuer; and less symbols just means less risk of escaping problems elsewhere (eg allowing in an access token will wreck someone's XML somewhere, for no benefit). Suggestion: access-token = 1*( ALPHA / DIGIT / - / . / _ / ~ / + / / ) *= access-token includes the 66 unreserved URI characters plus a few others. It can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace [RFC4648]. 2b. If 2 is not accepted (and assuming HTTPbis will allow any content after the scheme name in a Authorization header) can we please not misuse the quoted-char label when no quoting is going on. The following is a better equivalent: access-token = 1*(%x21-7E) ; ASCII, except controls, space, or delete 3. Drop '\' from the allowed chars in a scope value, to avoid clashing with the HTTP quoted-string escaping mechanism (and don't use the quoted-char label when no quoting is going on). scope-v = 1*(%x21 / %x23-5B / %x5D-7E); excludes space and and \ 4. Section 3.3 Summary of Recommendations sensibly says clients MUST ensure that bearer tokens are not leaked to *unintended parties* and correctly notes that this is the primary security consideration that underlies all the others. So it is a glaring hole that OAuth2 fails to tell the client who the intended parties are when issuing a bearer token. -- James Manger ___ OAuth mailing list OAuth@ietf.orgmailto: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] Last call comments on bearer draft 08 from Yaron Goland
1. Introduction: Adding the word directly after rather than using the resource owner's credentials. 1.3. Overview: Comment on first sentence: OAuth also supports having a client directly provide its own credentials to get an access token. It would seem useful to refer to this as well less the reader think that OAuth is only for delegation. That was true with OAuth 1.0 but not 2.0. 1.3. Overview, paragraph 3: Commented on The following steps are specified within this document: Actually you also specify the token type returned in step D. I think this is worth explicitly calling out. 2. Authenticated Requests: Commented It would seem appropriate to begin with an example of step D showing that the returned access token is of type bearer. 2.3. URI Query Parameter: Commented on second example: Does order matter? In this case the access_token is last. Is that because it has to be or because order is irrelevant? 2.4. The WWW-Authenticate Response Header Field: Commented on word invalid: The term invalid is a tricky one. Invalid can mean 'not supported' or 'not recognized' but that is generally taken to be a 400 Bad Request and would not require a www-authenticate response header field. Or invalid can mean 'supported but not the right credentials' in which case the error is a 401 Unauthorized and a www-authenticate response is required. I would urge you to consider simplifying this text by just stating (without preamble) that if a www-authenticate response header is returned (either from a 401 Unauthorized or other reasons) then support for the Bearer token type is specified as given below. 2.4. The WWW-Authenticate Response Header Field: Commented on param definition: As defined in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-15#section-4.4, www-authenticate is not really an error response mechanism. It's an advertisement mechanism. It says here is what I support by way of authentication. So I really don't think it's appropriate to show horn in here error information that has nothing to do with advertising authorization capabilities. If we need to return things like error, error-desc, etc. that should either be stuck in the body or put in a separate header. We should leave the www-authenticate header to be as simple as possible. 3.1. Security Threats: Token redirect: Change An attacker uses the token generated for consumption by resource server to obtain access to another resource server to An attacker uses the token generated for consumption by a particular resource server with a different resource server that mistakenly believes the token to be for it. 3.1 Security Threads: Token replay: Change replay to capture and change An attacker attempts to use a token that has already been used with that resource server in the past to An attacker somehow obtains a token they were not authorized to possess and uses it to access protected resources. 3.2 Threat Mitigation: Add at end of first paragraph: The mechanics of such an interaction are not defined by this specification. 3.2. Threat Mitigation: Delete and replay from paragraph 5. 3.2. Threat Mitigation: Change has to be to MUST. 3.2. Threat Mitigation: Comment on leaked in paragraph 5: Significantly? Really? In what way? Give me a token for a few hundred milliseconds and I can probably do all the damage I could do if you gave it to me for a few days. I would suggest removing the term significantly. 3.3. Summary of Recommendations: Validate SSL certificate chains: Change must to MUST. 3.3. Summary of Recommendations: Always use TLS (https): Add or equivalent transport security after TLS reference. 3.3. Summary of Recommendations: Don't store bearer tokens in cookies: Add sentence at end: Implementations that do store bearer tokens in cookies MUST take precautions against cross site request forgery. 3.3. Summary of Recommendations: Comment on Don't pass bearer tokens in page URLs: It seems like this should also be mentioned in section 3.2. Appendix A. Acknowledgements: Change Yaron Goland to Yaron Y. Goland. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Comments on Assertions draft 00 by Yaron Goland
Author List: Change MSFT to Microsoft (twice). Author List: Change Yaron Goland to Yaron Y. Goland. 2. Overview: Change privliged to privileged. 2. Overview: Change messsage to message. 3. Authentication vs. Authorization: Add a period after vs so the title becomes Authentication vs. Authorization 3. Authentication vs. Authorization: Comment on words single assertion: This sentence implies that a system could issue two tokens, one for authentication and a separate one for authorization. While this is certainly possible does anyone actually do that? If not then perhaps it's not worth calling out? 4.1. Using Assertions for Client Authentication: Comment on client_id: It seems like a bad idea to have the client_id outside of the assertion. It's either redundant or insecure. 4.1. Using Assertions for Client Authentication: Change a Authorization Code to an Authorization Code. 4.2. Using Assertions as Authorization Grants: Delete , without direct user approval, per comment This fragment sounds slimy and isn't all that relevant so I would suggest omitting it. 4.2. Using Assertions as Authorization Grants: Comment on client_id: This seems like a bug. Why is there a client_id? In any scenario I can come up with that would use an assertion all data needed to identifying the caller is provided (securely) in the assertion itself. So at best requiring client_id is just redundant and redundancy in protocols just opens up new places to have problems. So I would suggest that we require that assertions MUST identify the client and therefore the requests MUST NOT include client_id. 5. In title, change Proccessing to Processing. 5.1. Assertion Metamodel: Audience: Change the Authorization Server as the intended audience to the party intended to process the token, per the comment It's generally not considered good form to write a definition that contains the word being defined.. 5.2. General Assertion Format and Processing Rules: Change a Assertion ID to an Assertion ID and change algortihm to algorithm and change generate assertion to generate the assertion. 6.1. Client authentication: Change as in a format to in a format. 6.1. Client authentication: Comment on last 4 bullets: This is all redundant with section 5.2. I think it's not a great idea to repeat normative requirements as it just opens the door for confusion and inconsistency. So I would urge that we remove these lines and just point to section 5.2. 6.1. Client authentication: Change a client authenticating to a client authentication and change a Authorization Code to an Authorization Code. 6.2. Client acting on behalf of itself: Change analagous to analogous. 6.2. Client acting on behalf of itself: Comment on last 4 bullets: Again, I would just point to section 5.2. 6.3. Client acting on behalf of a user: Comment on last 4 bullets: Same comment as before. 6.3. Client acting on behalf of a user: Change a Authorization Code to an Authorization Code. 6.4. Client acting on behalf of an anonymous user: Change authorizaion to authorization. 7. Error Responses: Comment on Audience validation failed: Isn't returning this kind of information just helping an attacker to hone their attack by trying various values and seeing what errors they get? I'm not sure how serious this threat is though. But I get nervous any time we leak data about security validation failures. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt
This version adds a missing comma in an error response example. Thanks to Stephen Farrell for his donation of the comma. This version should be the subject of the working group last call. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Wednesday, July 27, 2011 6:17 AM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-07.txt Pages : 17 Date: 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt ___ 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] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
Updated references to oauth-v2 and httpbis. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Wednesday, July 27, 2011 6:45 AM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-08.txt Pages : 17 Date: 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt ___ 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] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
In the bearer token spec, Section 2.4 (The WWW-Authenticate Response Header
Field), scope is unambiguously defined to permit these characters:
scope = scope = scope-v *( SP scope-v )
scope-v = 1*quoted-char
quoted-char = ALPHA / DIGIT /
! / # / $ / % / / ' / ( / ) /
* / + / - / . / / / : / / = /
/ ? / @ / [ / ] / ^ / _ / ` /
{ / | / } / ~ / \ / , / ;
I misspoke in the meeting thinking that this definition was also in the core
spec. I believe that it used to be there, but apparently it has been removed.
There it just says that The scope of the access request expressed as a list of
space-delimited, case sensitive strings.
This set of characters does permit, but does not mandate, support for
percent-encoding of characters.
-- Mike
-Original Message-
From: MARCON, JEROME (JEROME) [mailto:jerome.mar...@alcatel-lucent.com]
Sent: Wednesday, July 27, 2011 7:53 AM
To: Mike Jones; oauth@ietf.org
Subject: RE: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
Mike,
Regarding the allowed characters for scope values (grammar of scope-v), is
the non-support of percent encoding intentional ? That would preclude scope
values to be (every kind of) UTF-8 strings, or URNs, or JSON (short) payload,
etc.
This character set limitation does not exist in the core spec, wherever scope
parameter can be included in a request or response, either because percent
encoding is usable, or else because scope parameter is a JSON string.
It seems besides strange that the set of characters safe to use for scope
values is not defined in the core spec, and instead is constrained by/dependent
from the type of access token used (here, bearer token).
Note that this question was raised also by the Liaison Statement received from
the Open Mobile Alliance.
Best regards,
Jerome
-Message d'origine-
De : oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] De la part de Mike
Jones Envoyé : mercredi 27 juillet 2011 15:47 À : oauth@ietf.org Objet : Re:
[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
Updated references to oauth-v2 and httpbis.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Wednesday, July 27, 2011 6:45 AM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Protocol: Bearer Tokens
Author(s) : Michael B. Jones
Dick Hardt
David Recordon
Filename: draft-ietf-oauth-v2-bearer-08.txt
Pages : 17
Date: 2011-07-27
This specification describes how to use bearer tokens when accessing
OAuth 2.0 protected resources.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt
___
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] I-D Action: draft-ietf-oauth-v2-bearer-07.txt
Thanks, Barry. For what it's worth, after submitting -07, I realized that the references to the oauth-v2 and httpbis specs needed to be updated, and did this in -08 (making no other changes). Thus, -08 should be the version that is the subject of the working group last call. Cheers, -- Mike -Original Message- From: barryleiba.mailing.li...@gmail.com [mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba Sent: Wednesday, July 27, 2011 10:44 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt This version should be the subject of the working group last call. As announced in the working group session this morning at IETF 81: This document goes into working-group last call today, ending on 12 August. Everyone: please review this version of the document, and make any comments by 12 August. The goal will be to have Mike incorporate any comments at that point, put out a final version, and send it to the IESG. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06
You're correct about the missing comma. I'll plan on updating the draft this week. To your second question, the definition of quoted-string does allow for unquoted whitespace within the quoted string. -- Mike -Original Message- From: Ian McKellar [mailto:i...@mckellar.org] Sent: Sunday, July 10, 2011 1:16 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06 Hi, I'm reading through draft 6 of the bearer token spec and had a question about one of the examples. In section 2.4 there's an error response example when an expired token is used: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=example error=invalid_token, error_description=The access token expired I think there should be a comma after realm=example Also, I wasn't sure about spaces in the error_description. I'm digging through related linked specs to try to work out what a quoted-string should actually look like. Are spaces allowed? Should characters be backslash-quoted or percent-quoted? Ian On Wed, Jun 22, 2011 at 8:53 PM, Mike Jones michael.jo...@microsoft.com wrote: I’ve published draft 06 of the OAuth Bearer Token Specification. It contains the following changes: · Changed parameter name bearer_token to access_token, per working group consensus. · Changed HTTP status code for invalid_request error code from HTTP 401 (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP working group experts. It doesn’t change the use of 403 (Forbidden) to (401) Unauthorized as had been discussed as a possibility, also due to input from the same HTTP working group experts. I believe that this addresses all the bearer token specification issues arising from the interim working group meeting and working group discussions since then. The draft is available at these locations: · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.pdf · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.txt · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.xml · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.html · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.pdf · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.txt · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.xml · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point to new versions as they are posted) · http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, pdf, txt, and html versions available) -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Ian McKellar http://ian.mckellar.org/ i...@mckellar.org: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft -19
A few editorial points about references: - the draft is referencing an old draft of the bearer token spec (-04), rather than the current version (-06), - the draft is referencing an old draft of the SAML bearer spec (-03), rather than the current version (-04), - the draft is not referencing the assertions spec draft-ietf-oauth-assertions-00, which would make sense in Section 4.5 (Extensions) Also, the example in 4.5 should be updated to match the current SAML bearer spec: grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearerassertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- Thanks, -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, July 25, 2011 1:07 AM To: OAuth WG Subject: [OAUTH-WG] Draft -19 Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and the request being discussed on the list to change the public/private client type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Extra Authorization: Basic lines in examples
In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both the line Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW and credentials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=passwordusername=johndoepassword=A3ddj3w I believe that the Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW line should be deleted from all of these examples, as you either use Basic or credentials in the post body, but not both. Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types
Thanks for making this change, Eran. I propose that we use Aiden's text, because I agree that it removes the ambiguity that he identified. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Aiden Bell Sent: Tuesday, July 19, 2011 4:39 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types I think the wording is much improved here with regards implied relationships between composite and non-composite types. However, given this new found unambiguity, I think the use of the term composite response types is misleading, as what is being described is just a characteristics of identifiers containing spaces. This newest 8.3 doesn't state if elements in the collection MUST also be registered. This leads me to (correctly?) think I can register a list of elements where the components may or may not be registered themselves. In this case, we have a registered list of response type identifiers rather than a list of response types registered. I would propose the following modification, which puts the policy-ish term of compounding elements, more in the realm of registration, as the term compounding seems to imply compound semantics, but the registration part has a mechanism-not-policy approach. The space character (%x20) is reserved for defining a collection of response type identifiers. Each collection of response type identifiers MUST be registered, even if each of its components are individually registered. The order of components in a response type identifier collection does not matter. The meaning of unregistered collections of response type identifiers made up of individually registered values is undefined. For example, the response type token code is left undefined by this specification. However, an extension can define and register the token code response type identifier collection and its composite behavior. Once registered, the same combination cannot be registered as code token, but both values can be used to make an authorization request, and refer to the same response type. Apologies if this is unsuitable, i'm just looking at it as an implementor and questioning my own assumptions, then trying to make the text clearer. The validity of my assumptions isn't presumed. Thanks, Aiden Bell On 19 July 2011 07:21, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: I have tried to accommodate both the use cases and concerns raised. The new text allows the registration of composite response types in which the order of the space-delimited values does not matter. However, every combination must be registered in order to avoid developers guessing what an unregistered combination might mean. Feedback requested. EHL --- 8.4. Defining New Authorization Endpoint Response Types New response types for use with the authorization endpoint are defined and registered in the authorization endpoint response type registry following the procedure in Section 11.3. Response type names MUST conform to the response-type ABNF. response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = _ / DIGIT / ALPHA The space character (%x20) is reserved for defining composite response types. Each composite response types MUST be registered, even if each of its components are individually registered. The order of components in a composite response type does not matter. The meaning of unregistered composite response types made up of individually registered values is undefined. For example, the response type token code is left undefined by this specification. However, an extension can define and register the token code response type. Once registered, the same combination cannot be registered as code token, but both values can be used to make an authorization request, and refer to the same response type. Also, change the definition of response_type in section 3.1.1: response_type REQUIRED. The value MUST be one of code for requesting an authorization code as described by Section 4.1.1, token for requesting an access token (implicit grant) as described by Section 4.2.1, or a registered extension value as described by Section 8.4. A value containing one or more space characters (%x25) identifies a composite response type in which the order of the space-delimited sub-values does not matter. ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- -- Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org
Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types
Good -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, July 19, 2011 9:24 AM To: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types Revised text. I changed it to focus on the implementation details. In other words, all response types must be registered. If the type name includes spaces, it changes how the value is compared (space-delimited list of values where the order does not matter). That's it. Spaces only change how values are compared. EHL --- 8.4. Defining New Authorization Endpoint Response Types New response types for use with the authorization endpoint are defined and registered in the authorization endpoint response type registry following the procedure in Section 11.3. Response type names MUST conform to the response-type ABNF. response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = _ / DIGIT / ALPHA If a response type contains one of more space characters (%x20), it is compared as a space-delimited list of values in which the order of values does not matter. Only one order of values can be registered, which covers all other arrangements of the same set of values. For example, the response type token code is left undefined by this specification. However, an extension can define and register the token code response type. Once registered, the same combination cannot be registered as code token, but both values can be used to denote the same response type. Also, change the definition of response_type in section 3.1.1: response_type REQUIRED. The value MUST be one of code for requesting an authorization code as described by Section 4.1.1, token for requesting an access token (implicit grant) as described by Section 4.2.1, or a registered extension value as described by Section 8.4. If the response type contains one or more space characters (%x20), it is interpreted as a space-delimited list of values, where the order of values does not matter (e.g. a b is the same as b a). ___ 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] Issue 18: defining new response types
I agree that this functionality is needed. However, I believe its current embodiment is overly restrictive. I would suggest changing this text: Only one response type of each combination may be registered and used for making requests. Composite response types are treated and compared in the same as manner as non-composite response types. The + notation is meant only to improve human readability and is not used for machine parsing. For example, an extension can define and register the token+code response type. However, once registered, the same combination cannot be registered as code+token, or used to make an authorization request. to this: The order of the composite response type values is not significant. For instance, the composite response types token+code and code+token are equivalent. Each composite response type value MUST occur only once. Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] defining new response types
As a data point motivating this functionality, the OpenID Connect Core spec currently includes: response_type A space delimited, case sensitive list of string values (Pending OAuth 2.0 changes). Acceptable values include code, token, and none. The value MUST include code for requesting an Authorization Code, token for requesting an Access Token, and none if no response is needed. The OpenID Connect Session Management spec also defines an id_token response_type. Combinations of these (other than none) are meaningful and used. The syntax for this can change, but this functionality is very important to OpenID Connect as it is currently written. Thanks, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Breno de Medeiros Sent: Tuesday, July 12, 2011 11:48 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav e...@hueniverse.com wrote: That's pretty farfetched. In previous versions we had 'code_and_token' which was a composite value but without any special characters. If people think that we need to force such values to avoid this claimed developer confusion, let's drop the + and be done. Maybe far fetched, but it's already available in our production environment -- we had implemented the code_and_token approach earlier (though not documented it) but abandoned that route as we thought the exponential explosion was harmful when we started contemplating adding new types and allowing various combinations of them. The only requirement I was asked to cover was to allow response type extensibility. If there is WG consensus to also support the requirement of composite values using any order, we can discuss that. Let's. In addition, defining a parsing method adds a significant amount of new complexity beyond just splitting the string: * It allows for composite values that make no sense (since anything goes, composite values are not registered, just the components). * Additional error codes are needed to indicate bad format, unsupported values (specify which one), unsupported combinations, etc. * Developers lose the benefit of a simple registry with every possible combination they may choose. So the two questions are: 1. Do you find the + proposal as defined in -18 to be useful or confusing? It is ugly. 2. Should the protocol support dynamic composite values with the added complexity (breaking change)? That's my preference. EHL -Original Message- From: Breno de Medeiros [mailto:br...@google.com] Sent: Tuesday, July 12, 2011 11:18 AM To: Eran Hammer-Lahav Cc: Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] defining new response types On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav e...@hueniverse.com wrote: Requiring parsing of the response type parameter is a big change at this point. Even if it is a decent idea, I'm against it for the sole reason that I don't want to introduce such a change - we're done. The + character makes reading values easier because it give composites of existing, individually defined values, a special meaning to *people*, but it does not change any existing code or adds any work. Servers will still perform simple string comparison. Parsing a list of values is unnecessary complexity. Developers can learn to put values in their expected order (since they are all going to cut-n-paste anyway). I disagree. I believe that servers will either not support the composite types at all, or will allow developers to enter it into any order to avoid developer pain. Also, developers will _not_ cut-and-paste. They will expect the fact that order is not meaningful by interacting with providers that don't perform exact string matching and then have interoperability issues with compliant implementations. I rather drop the special character then add parsing, but I think it is a useful *convention*. Do people want to keep it or drop it? EHL -Original Message- From: Breno de Medeiros [mailto:br...@google.com] Sent: Tuesday, July 12, 2011 10:59 AM To: Eran Hammer-Lahav Cc: Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] defining new response types Imposing order and exact string matching on response_type's while simultaneously supporting a special character '+' and introducing the concept of composite response_type is a poor compromise, IMNSHO. What is the rationale to fear allowing multiple-valued response_type as we have for other parameters in the spec? On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav e...@hueniverse.com wrote: As for the plus encoding we can choose another char or give an example. On Jul 11, 2011, at 18:07, Marius Scurtescu mscurte...@google.com wrote:
Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)]
If you're going with urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer in the SAML assertion profile, I'll use urn:ietf:wg:oauth:2.0:grant_type:jwt:1.0:bearer in the JWT assertion profile. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Saturday, July 09, 2011 6:15 AM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)] Discussion on the other item, the grant_type URI, inline below. This whole thing seems like it shouldn't be an issue at all as there's no functionality involved. But I've been hung up on it for a while and the spec needs some URI. I could *really* use the advice of the AD and/or Chairs on this. Or anyone with more experience with defining and using URIs/URNs. Thanks. On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Item 2: URI(s) The value for grant_type is currently defined as http://oauth.net/grant_type/saml/2.0/bearer but there have been some questions raised about the stability and appropriateness of the URL. I'm not a fan. I really did read RFCs 2648 3553, as was suggested at the last F2F meeting, but it's not clear to me how to register an IETF URI and/or if those RFCs are fully appropriate for this. If someone could explain it to me in terms my preschooler could understand, maybe I could jump though the proper hoops to get the URI to be something like urn:ietf:something:something. Asking on the URN list usually helps. I can try that. I'm thinking it'd be something like urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely based on seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an actual registration done for that? Or did it just start getting used? Is doing that okay? Otherwise, I can continue to use http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft should also cover client authentication, also define http://oauth.net/client_assertion_type/saml/2.0/bearer. The JWT version could then follow a similar pattern. Or perhaps we could use the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer subject confirmation method. It seems like that might be close enough to work out without violating anything serious. And it could be used for both grant_type and client_assertion_type, which is nice. Don't use an OASIS URN. That's asking for trouble. Is it really? Because it's conceptually inappropriate? Or because of some supposed (or real) rift between standards bodies? I mean, this whole draft is about profiling SAML assertions (an OASIS spec) for use with OAuth (soon an IETF spec). Would using a URN too be so terrible? You'd previously suggested (or asked why I didn't use) urn:oasis:names:tc:SAML:2.0:assertion which is the XML NS for the OASIS SAML assertion schema. Would that somehow be different? That is still an option too, I think. I hadn't used it because I wanted to differentiate the means of confirming/validating the assertion - as a bearer token - while leavening room for holder of key or other methods in the future. But using that NS wouldn't necessary preclude it. I was also looking for an identifier that would enable easy web searching and urn:oasis:names:tc:SAML:2.0:assertion wouldn't really do that. ___ 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] New Assertion Draft for review
+1 on submitting this as a WG doc by the deadline on July 4th. As background, http://www.ietf.org/meeting/cutoff-dates-2011.html: . 2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. . 2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool So because the assertions draft will be a -00 draft, it must be submitted by the 4th. A new version of the SAML doc could still be submitted until the 11th, since it's not a -00 doc. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, June 30, 2011 2:11 PM To: Barry Leiba Cc: OAuth WG Subject: Re: [OAUTH-WG] New Assertion Draft for review On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba barryle...@computer.org wrote: This document is intended to replace the SAML and Bearer Token documents, and those two will then be profiles, defining specific assertion mechanisms. Just a couple points of clarification This doc is not related to the Bearer Token document (draft-ietf-oauth-v2-bearer-04) - that is about access tokens and this series of docs is about assertions for grants (and now client authentication). This doc doesn't replace anything so much as it pulls common elements out of the SAML assertion (draft-ietf-oauth-saml2-bearer) and JWT assertion (draft-jones-oauth-jwt-bearer) documents. Those docs (and possibly others) then become profiles of this doc and get to reuse the common pieces it provides. This doc also reintroduces the abstract concept of client assertions for client authentication using http parameters (client_assertion_type and client_assertion). Presumably the SAML and JWT assertion docs will also be reworked to account for that. We would like to have them submit the restructured doc as a working-group document before the 4 July deadline, so we'd like to get any objections to this approach heard by 3 July. Barry, which docs to you need submitted by the 4th? Just draft-ietf-oauth-assertions? Or draft-ietf-oauth-saml2-bearer and draft-jones-oauth-jwt-bearer as well? I'm sorry for the very short notice, and you can blame that solely on the chairs. Chuck posted the draft about two weeks ago. See http://tools.ietf.org/html/draft-mortimore-oauth-assertions The editors can answer any questions you have about how the document restructuring is being done. We will approve draft-ietf-oauth-assertions for submission as a working-group draft, pending consideration of objections. Again, please have a quick look (it's short), and post objections by 3 July. Thanks. Barry, as chair ___ 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
[OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06
I've published draft 06http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.html of the OAuth Bearer Token Specificationhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html. It contains the following changes: * Changed parameter name bearer_token to access_token, per working group consensus. * Changed HTTP status code for invalid_request error code from HTTP 401 (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP working group experts. It doesn't change the use of 403 (Forbidden) to (401) Unauthorized as had been discussed as a possibility, also due to input from the same HTTP working group experts. I believe that this addresses all the bearer token specification issues arising from the interim working group meeting and working group discussions since then. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.pdf * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.pdf * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point to new versions as they are posted) * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, pdf, txt, and html versions available) -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Assertion Draft for review
Thanks Chuck. Adding context, this document moves the common parts of the SAML Profilehttp://trac.tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 and the JWT Profilehttp://trac.tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 to a common assertions spec. The token-type specific parts will then become profiles of this common doc. Thanks for spearheading this, Chuck! -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck Mortimore Sent: Saturday, June 18, 2011 12:42 PM To: oauth@ietf.org Subject: [OAUTH-WG] New Assertion Draft for review A number of us in the community have been working on a general model for the use of Assertions in OAuth2 for both client authentication, as well as authorization grants. We've reached general consensus on a doc that I've published as a draft: http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt Feedback and discussion welcome! Thanks -cmort ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Question on action item to make RedirectURI optional
The minutes from the special meeting included: TODO: Eran to add extensibility language for this based on requirements. -RedirectURI should be optional TODO: Eran to send mail to the list proposing language changes to either change this from REQUIRED to OPTIONAL and add clarifying language, or leave as required and add a pre-defined value for we're not actually using this. Is this proposed change just limited to section 4.5? It seems to make sense to have redirect_uri be optional in section 4.1.3 as well (access token request using grant_type authorization code). Since this request is made directly from the client to the authorization server, I don't see why this would be required. For at least some implementations of the 3-legged flow, it would make sense to not have this be a requirement. Comments? Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] bearer token authorization header
You got it right. :-)
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, May 26, 2011 9:16 AM
To: George Fletcher
Cc: Mike Jones; John Kemp; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header
Maybe I created some confusion. Earlier in the thread I was wondering why isn't
the part after the scheme name a list of name/value pairs.
If it was, then the authorization header would look like:
Bearer token=asfd2353fasdfa235q54rdasf
and the actual token would be just asfd2353fasdfa235q54rdasf, and it should be
encoded as a quoted string if it contained special characters.
But this is not what the spec currently say. The part after the scheme name is
simply the token, no encoding or names or lists. Also, the spec defines the set
of legal characters that can show up in a token (this limits what tokens can an
AS issue). With the current spec the header would look like:
Bearer asfd2353fasdfa235q54rdasf
The = character is a legal character inside a token, and it has no special
meaning.
I hope this helps, and I hope I got it right, Marius
On Thu, May 26, 2011 at 8:30 AM, George Fletcher gffle...@aol.com wrote:
So just to make sure that I'm clear... The following is ok...
The AS and RO decide that the token will be comprised of both a name
and value part. So the whole token looks like
'token=asfd2353fasdfa235q54rdasf'.
From the protocol perspective, the access token is the entire string,
even if it looks like to the developer that only the
'asfd2353fasdfa235q54rdasf'
part is the token. As a developer I find this confusing, but I think I
now understand why the 'token=asfd2353fasdfa235q54rdasf' is legal.
The key is that the client has to treat the response from the AS as
opaque (as Paul mentioned) and just put it in the Authorization header
as
'Authorization: Bearer token regardless of what the resulting
header looks like.
Thanks,
George
On 5/25/11 1:15 PM, Mike Jones wrote:
What you quoted below was the acceptable syntax. The Authorization
Server and the Resource Server still need to agree upon the semantics
of the bearer token exchanged.
-- Mike
-Original Message-
From: John Kemp [mailto:j...@jkemp.net]
Sent: Wednesday, May 25, 2011 10:11 AM
To: Mike Jones
Cc: Marius Scurtescu; George Fletcher; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header
On May 24, 2011, at 4:04 PM, Mike Jones wrote:
George, you are correct that resources and clients must agree upon the
format of the bearer token to achieve interoperability. The means for
achieving this agreement is out of the scope of this document.
I thought the means for achieving IOP was quite precisely described in
the production below (excerpted from 2.1 of
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04):
credentials= Bearer RWS access-token
access-token = 1*( quoted-char / )
quoted-char= ! / # / $ / % / / ' / (
/ ) / * / + / - / . / / / DIGIT
/ : / / = / / ? / @ / ALPHA
/ [ / ] / ^ / _ / ` / { / |
/ } / ~ / \ / , / ;
- John
-- Mike
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, May 24, 2011 11:28 AM
To: George Fletcher
Cc: Mike Jones; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header
The printable non-whitespace ASCII characters represents the access
token, which is supposed to be opaque. I don't think this affects libraries.
Marius
On Tue, May 24, 2011 at 10:24 AM, George Fletcher gffle...@aol.com wrote:
Do I understand this correctly that each resource owner can define
it's own format for the printable non-whitespace ASCII characters?
It seems like that would make it difficult for clients to use standard
libraries because the Authorization header format could be different
on a per resource/host basis.
Thanks,
George
On 5/23/11 3:10 PM, Mike Jones wrote:
[snip]
The fact that there is no escaping mechanism can potentially create
problems. The list of allowed characters is spelled out, but what if
some implementation uses other characters? Using a name value pair and
proper escaping is much safer IMO. For example:
Bearer token=dfgh76dfghdfg
or
Bearer token=dfgh76dfghdfg
The value above can be either a token or a quoted string. HTTP header
parsers know how to parse tokens and quoted strings so an implementor
has a better chance of doing it right.
Mark Lentczner started a thread on this regard a few moths ago, James
Manger replied and suggested something similar:
http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
If it is too late to switch to a name/value pair, then I think we
should at least clean up the references.
The definition allows the access token to be any string of one or more
printable non
Re: [OAUTH-WG] bearer token authorization header
You're correct that I misspoke. The Authorization Server and the Resource Server must agree on the format of the token. Yes, it's opaque to the client. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Paul Madsen Sent: Wednesday, May 25, 2011 6:50 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] bearer token authorization header Mike/George, can you clarify in what sense must a client and RS agree on the format of a bearer token? Are they not opaque to the client, and so their internal format irrelevant to it? paul On 5/24/11 4:04 PM, Mike Jones wrote: George, you are correct that resources and clients must agree upon the format of the bearer token to achieve interoperability. The means for achieving this agreement is out of the scope of this document. -- Mike -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Tuesday, May 24, 2011 11:28 AM To: George Fletcher Cc: Mike Jones; OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header The printable non-whitespace ASCII characters represents the access token, which is supposed to be opaque. I don't think this affects libraries. Marius On Tue, May 24, 2011 at 10:24 AM, George Fletchergffle...@aol.com wrote: Do I understand this correctly that each resource owner can define it's own format for the printable non-whitespace ASCII characters? It seems like that would make it difficult for clients to use standard libraries because the Authorization header format could be different on a per resource/host basis. Thanks, George On 5/23/11 3:10 PM, Mike Jones wrote: [snip] The fact that there is no escaping mechanism can potentially create problems. The list of allowed characters is spelled out, but what if some implementation uses other characters? Using a name value pair and proper escaping is much safer IMO. For example: Bearer token=dfgh76dfghdfg or Bearer token=dfgh76dfghdfg The value above can be either a token or a quoted string. HTTP header parsers know how to parse tokens and quoted strings so an implementor has a better chance of doing it right. Mark Lentczner started a thread on this regard a few moths ago, James Manger replied and suggested something similar: http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html If it is too late to switch to a name/value pair, then I think we should at least clean up the references. The definition allows the access token to be any string of one or more printable non-whitespace ASCII characters. Thus, legal access token strings include ones like the ones you are asking for, such as: param=value -- Mike -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Monday, May 09, 2011 10:32 AM To: OAuth WG; Mike Jones Cc: Mark Lentczner; Manger, James H Subject: bearer token authorization header I am working through version 04 of the Bearer Token draft: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 Not sure how to interpret the authorization header grammar described in section 2.1. The intent seems to be for something like: Bearer dfgh76dfghdfg After the scheme name, Bearer, there is a required whitespace followed by the actual token. The token is represented by a sequence of printable characters, no escaping. No spaces or other elements are allowed after the token. Is that correct? RWS is not defined, I assume it is the required whitespace from section 1.2.2 of: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 There is a reference to RFC2617, but not sure why. That seems to imply that a list of values can be specified, which is not the case. The fact that there is no escaping mechanism can potentially create problems. The list of allowed characters is spelled out, but what if some implementation uses other characters? Using a name value pair and proper escaping is much safer IMO. For example: Bearer token=dfgh76dfghdfg or Bearer token=dfgh76dfghdfg The value above can be either a token or a quoted string. HTTP header parsers know how to parse tokens and quoted strings so an implementor has a better chance of doing it right. Mark Lentczner started a thread on this regard a few moths ago, James Manger replied and suggested something similar: http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html If it is too late to switch to a name/value pair, then I think we should at least clean up the references. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https
Re: [OAUTH-WG] bearer token authorization header
What you quoted below was the acceptable syntax. The Authorization Server and
the Resource Server still need to agree upon the semantics of the bearer token
exchanged.
-- Mike
-Original Message-
From: John Kemp [mailto:j...@jkemp.net]
Sent: Wednesday, May 25, 2011 10:11 AM
To: Mike Jones
Cc: Marius Scurtescu; George Fletcher; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header
On May 24, 2011, at 4:04 PM, Mike Jones wrote:
George, you are correct that resources and clients must agree upon the format
of the bearer token to achieve interoperability. The means for achieving
this agreement is out of the scope of this document.
I thought the means for achieving IOP was quite precisely described in the
production below (excerpted from 2.1 of
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04):
credentials= Bearer RWS access-token
access-token = 1*( quoted-char / )
quoted-char= ! / # / $ / % / / ' / (
/ ) / * / + / - / . / / / DIGIT
/ : / / = / / ? / @ / ALPHA
/ [ / ] / ^ / _ / ` / { / |
/ } / ~ / \ / , / ;
- John
-- Mike
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, May 24, 2011 11:28 AM
To: George Fletcher
Cc: Mike Jones; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header
The printable non-whitespace ASCII characters represents the access token,
which is supposed to be opaque. I don't think this affects libraries.
Marius
On Tue, May 24, 2011 at 10:24 AM, George Fletcher gffle...@aol.com wrote:
Do I understand this correctly that each resource owner can define
it's own format for the printable non-whitespace ASCII characters?
It seems like that would make it difficult for clients to use
standard libraries because the Authorization header format could be
different on a per resource/host basis.
Thanks,
George
On 5/23/11 3:10 PM, Mike Jones wrote:
[snip]
The fact that there is no escaping mechanism can potentially create
problems. The list of allowed characters is spelled out, but what if
some implementation uses other characters? Using a name value pair
and proper escaping is much safer IMO. For example:
Bearer token=dfgh76dfghdfg
or
Bearer token=dfgh76dfghdfg
The value above can be either a token or a quoted string. HTTP header
parsers know how to parse tokens and quoted strings so an implementor
has a better chance of doing it right.
Mark Lentczner started a thread on this regard a few moths ago, James
Manger replied and suggested something similar:
http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
If it is too late to switch to a name/value pair, then I think we
should at least clean up the references.
The definition allows the access token to be any string of one or
more printable non-whitespace ASCII characters. Thus, legal access
token strings include ones like the ones you are asking for, such as:
param=value
-- Mike
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Monday, May 09, 2011 10:32 AM
To: OAuth WG; Mike Jones
Cc: Mark Lentczner; Manger, James H
Subject: bearer token authorization header
I am working through version 04 of the Bearer Token draft:
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04
Not sure how to interpret the authorization header grammar described
in section 2.1. The intent seems to be for something like:
Bearer dfgh76dfghdfg
After the scheme name, Bearer, there is a required whitespace
followed by the actual token. The token is represented by a sequence
of printable characters, no escaping. No spaces or other elements are
allowed after the token. Is that correct?
RWS is not defined, I assume it is the required whitespace from
section
1.2.2 of:
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13
There is a reference to RFC2617, but not sure why. That seems to
imply that a list of values can be specified, which is not the case.
The fact that there is no escaping mechanism can potentially create
problems. The list of allowed characters is spelled out, but what if
some implementation uses other characters? Using a name value pair
and proper escaping is much safer IMO. For example:
Bearer token=dfgh76dfghdfg
or
Bearer token=dfgh76dfghdfg
The value above can be either a token or a quoted string. HTTP header
parsers know how to parse tokens and quoted strings so an implementor
has a better chance of doing it right.
Mark Lentczner started a thread on this regard a few moths ago, James
Manger replied and suggested something similar:
http
Re: [OAUTH-WG] consistency of token param name in bearer token type
The working group explicitly decided that a different name should be used, to make it clear that other token types other than bearer tokens could also be used with OAuth 2. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Doug Tangren Sent: Wednesday, May 11, 2011 10:09 PM To: oauth@ietf.org Subject: [OAUTH-WG] consistency of token param name in bearer token type This may have come up before so I'm sorry if I'm repeating. Why does bearer token spec introduce a new name for oauth2 access tokens [1], bearer_token, and before that [2], oauth_token? I apologize if this may sound shallow but, why introduce a new parameter name verses sticking with what the general oauth2 spec already defines, access_token. It seems arbitrary for an auth server to hand a client an apple then have the client hand it off to the resource server and call it an orange. Was this just for the sake of differentiating the parameter name enough so that the bearer tokens may be used in other protocols without being confused with oauth2 access_tokens? [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2 -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] bearer token authorization header
Answers inline: Not sure how to interpret the authorization header grammar described in section 2.1. The intent seems to be for something like: Bearer dfgh76dfghdfg After the scheme name, Bearer, there is a required whitespace followed by the actual token. The token is represented by a sequence of printable characters, no escaping. No spaces or other elements are allowed after the token. Is that correct? Yes RWS is not defined, I assume it is the required whitespace from section 1.2.2 of: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 Correct. If this isn't a standard by the time the bearer token spec, becomes an RFC I assume this definition will be pulled into the spec. There is a reference to RFC2617, but not sure why. That seems to imply that a list of values can be specified, which is not the case. Good catch. I think this should have been 2616. The fact that there is no escaping mechanism can potentially create problems. The list of allowed characters is spelled out, but what if some implementation uses other characters? Using a name value pair and proper escaping is much safer IMO. For example: Bearer token=dfgh76dfghdfg or Bearer token=dfgh76dfghdfg The value above can be either a token or a quoted string. HTTP header parsers know how to parse tokens and quoted strings so an implementor has a better chance of doing it right. Mark Lentczner started a thread on this regard a few moths ago, James Manger replied and suggested something similar: http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html If it is too late to switch to a name/value pair, then I think we should at least clean up the references. The definition allows the access token to be any string of one or more printable non-whitespace ASCII characters. Thus, legal access token strings include ones like the ones you are asking for, such as: param=value -- Mike -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Monday, May 09, 2011 10:32 AM To: OAuth WG; Mike Jones Cc: Mark Lentczner; Manger, James H Subject: bearer token authorization header I am working through version 04 of the Bearer Token draft: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 Not sure how to interpret the authorization header grammar described in section 2.1. The intent seems to be for something like: Bearer dfgh76dfghdfg After the scheme name, Bearer, there is a required whitespace followed by the actual token. The token is represented by a sequence of printable characters, no escaping. No spaces or other elements are allowed after the token. Is that correct? RWS is not defined, I assume it is the required whitespace from section 1.2.2 of: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 There is a reference to RFC2617, but not sure why. That seems to imply that a list of values can be specified, which is not the case. The fact that there is no escaping mechanism can potentially create problems. The list of allowed characters is spelled out, but what if some implementation uses other characters? Using a name value pair and proper escaping is much safer IMO. For example: Bearer token=dfgh76dfghdfg or Bearer token=dfgh76dfghdfg The value above can be either a token or a quoted string. HTTP header parsers know how to parse tokens and quoted strings so an implementor has a better chance of doing it right. Mark Lentczner started a thread on this regard a few moths ago, James Manger replied and suggested something similar: http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html If it is too late to switch to a name/value pair, then I think we should at least clean up the references. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft 16 review notes
It would be great if you could do a similarly detailed read of the bearer token spec as well! -- Mike Sent from my Windows Phone -Original Message- From: Brian Eaton Sent: Sunday, May 22, 2011 8:39 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft 16 review notes I just read over the whole of the draft for the first time in a while. I looked it over mostly for a) places where spec and reality were going to have trouble intersecting and b) places where security advice would be useful and c) grammer and speling, because I notices things like that Mostly noticed nits. I'm really happy with the way some of the trickier issues have gotten dealt with. Sometimes those differences get papered over, but they mostly seem to have been dealt with in constructive ways. I didn't agree with all of the decisions, but I liked that the spec either made the decisions or gave clear guidance on trade-offs. So bear in mind that even though most of the comments in this e-mail are criticism, that's not because there isn't a lot of good in the spec. I won't be able to make the interim meeting tomorrow, but I wanted to send these out before hand. 1. Introduction nit: text mixes “resource-owner” and “resource owner”. I think “resource owner” is correct. consider adding bullet point: Compromise of any third-party application server results in compromise of the user’s password and all of the data protected by that password. nit: “web end-user” is an odd turn of phrase. Maybe just “end user” 1.1 Roles nit: “- access restricted resources which require authentication to access:” seems awkward. could eliminate the phrase entirely and make the meaning of the paragraph just as obvious. 1.4.1 Authorization Code maybe expand the section on important security benefits. “The use of authorization codes also improves the ability to recover in the event of compromise of an application server or authorization server.” 1.4.2 nit: “intermediary authorization grant”. I think “intermediate” is the right term here, but might be wrong. 1.5 Refresh Token “self-contain the authorization information in a verifiable manner.” That is never secure, because it makes review of issued permissions and revocation of those permissions impossible. Refresh tokens are different than access tokens; a refresh token is always going to be an identifier that you use to look up authorization information. The text should be: “The token denotes an identifier used to retrieve the authorization information.” (As another example of why you can’t have a self-verifying refresh token, consider the role of the client id and client secret in the protocol. If refresh tokens were self-verifying, you would also need bake the client secret into the refresh token, thus making client secret rotation impractical.) nit: “..., no longer valid, …” doesn’t make sense. I think the text should be “or is no longer valid.” The parenthetical phrase throws off this paragraph a bit, maybe rephrase as “The refresh token can be used to obtain a new access token when the current access token becomes invalid or expires, or to obtain addtional access tokens with identical or narrower scope. (Access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner.) Should also add, maybe in the second paragraph: “Unlike access tokens, refresh tokens are intended for use only with authorization servers. Refresh tokens are never sent to resource servers.” 3. Client Authentication I like the compromise reached here on the language around client secrets for installed app clients. It doesn’t reflect reality, but the language allows enough wiggle room to be practical. The spirit of the text is quite sensible, which is what I like best. 3.1 Client Password Authentication Referring to a password as a shared symmetric secret is misleading. “Symmetric secret” is used almost exclusively with secret key cryptography, where both sides store copies of the secret. That’s not the right way to use client passwords; they should be treated like *passwords*, not HMAC keys or encryption keys. The reference to needing consensus on when to use basic auth and when to use client_id and client_secret parameters seems quite reasonable. The current language seems to reflect a poor compromise that will make interoperable implementations less likely for no good reason. I’d rather that someone picked a winner and the spec was simple and consistent. 3.2 Other Client Authentication Methods Again, I like the compromise here. The language is vague but useful. 4.1.1. Authorization Request Please add “state” to the example. “state” is an important part of a secure client implementation, might as well encourage use by including it in examples. 4.1.2 Authorization Response “minimize the risk of leaks”: this should be “mitigate”, not “minimize”. “SHOULD expire shortly”. This should be a MUST. The security analysis of the protocol
[OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -05
In preparation for the OAuth working group meeting on Monday, I've published draft 05http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.html of the OAuth Bearer Token Specificationhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html, incorporating input received from the OAuth design team. The changes in this draft are: *Removed OAuth Errors Registry, per design team input. *Changed HTTP status code for invalid_request error code from HTTP 400 (Bad Request) to HTTP 401 (Unauthorized) to match HTTP usage [[ change pending working group consensus ]]. *Added missing quotation marks in error-uri definition. *Added note to add language and encoding information to error_description if the core specification does. *Explicitly reference the Augmented Backus-Naur Form (ABNF) defined in [RFC5234]. *Use auth-param instead of repeating its definition, which is ( token = ( token / quoted-string ) ). *Clarify security considerations about including an audience restriction in the token and include a recommendation to issue scoped bearer tokens in the summary of recommendations. The draft is available at these locations: *http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-05.pdf *http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-05.txt *http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-05.xml *http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.html *http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.pdf *http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.txt *http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.xml *http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versions as they are posted) *http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will point to new versions as they are posted) *http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point to new versions as they are posted) *http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point to new versions as they are posted) *http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, pdf, txt, and html versions available) -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Error registry proposal (round 3)
The problem with that situation is that it doesn't provide a central registry for resource server error responses across specs, unlike the other kinds of OAuth error responses. I could define that registry in the bearer token spec, but it would be less confusing to unify it with the proposed registry in the framework spec. I suspect developers would thank us for doing that. What do you say? -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, April 06, 2011 2:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Hi Mike, This is intentional. The error registry defined in v2 is not designed to record errors for the protected resource endpoint response or the WWW-Authenticate response header when used with the Bearer token scheme (or any other scheme). The only purpose of the registry is to avoid name collisions between two errors used differently with the v2 specification. Since errors used with the Bearer token scheme will never appear in the same place as the v2 endpoints, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should retain the registry there and limit it to just the protected resource response space. Ideally, you would limit it to just the WWW-Authenticate header 'error' parameter when used with the Bearer scheme. The MAC scheme does not use error codes, but instead, relies fully on HTTP status code since no additional error conditions were identified. Also, since your ABNF permits adding additional Authorization header parameters, you might want to consider defining a process for doing that, if you are going to define an error registry. Currently, to add additional parameters, one has to update the Bearer token RFC, in contrast to simply registering a new error code (which is likely to come out of a new parameter). EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Wednesday, April 06, 2011 2:25 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) Thanks for writing this up, Eran. I believe that this is a step in the right direction. Wearing my Bearer Token spec editor hat, I just tried to go through the exercise of editing my document to use the registry in draft 15 to register the errors defined in the bearer token spec and I hit a roadblock. Specifically, while the errors defined by my spec are returned by resource servers (flow F in Figure 1), the registry defined by draft 15 does not include resource server error response in the error usage location list. Can you please add this additional error usage location so that the registry can be used by the bearer token specification? At that point, I believe we'll be able to close the open issue about the need for an error registry, and I'll update my draft accordingly. Thank you, -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, April 05, 2011 3:52 PM To: OAuth WG Subject: [OAUTH-WG] Error registry proposal (round 3) The following is my new proposal, based on Mike Jones' and my earlier proposals. It is basically a combination of the two. This proposal does not allow defining new error codes unless another extension is involved (new grant type, request parameter, token type). The reason for not defining an open ended error registry is that defining new error codes for existing implementations is bad for interoperability and can lead to unexpected results (developers not taking into account receiving a new error when talking to a compliant 2.0 server). We don't have any use cases for defining such new errors for the v2 specification. New errors only come from extensions and must be defined in that context. I have applied to changes to the -14 draft and clearly marked them with [[Pending Consensus]] so that there is no issue with removing them or changing them later. --- Add to the error codes list in sections 4.1.2.1 and 4.2.2.1: a 4xx or 5xx HTTP status code (except for 400 and 401) The authorization server MAY set the error parameter value to a numerical HTTP status code from the 4xx or 5xx range, with the exception of the 400 (Bad Request) and 401 (Unauthorized) status codes. For example, if the service is temporarily unavailable, the authorization server MAY return an error response with error set to 503. Add a new section 8.4: 8.4. Defining Additional Error Codes In cases where protocol extensions (i.e. access token types, extension parameters, or extension grant types) require additional error codes to be used
Re: [OAUTH-WG] Error registry proposal (round 3)
Actually, you correctly point out (indirectly), that this is related to one of the open issues that needs to be resolved to complete the specs when you wrote For such a registry to be useful, you also need to standardize the authentication header across all schemes and define a standard parameter used to deliver such error codes. This open issue (which there wasn't time to discuss during last week's meeting) was the removal of the WWW-Authenticate Response Header. This feature was present in WRAP and earlier OAuth drafts but was removed without a clear consensus to do so. And indeed, during our private discussions on how the draft should be split, at that time, you took the position that the WWW-Authenticate response should remain in the framework spec. The result has been that there is different and incompatible WWW-Authenticate response functionality in multiple related drafts - specifically draft-hammer-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04. Interoperability and developers would both be better served by moving this functionality back into the core. I don't believe that each related OAuth specification should have to separately specify this functionality. As this was not discussed during last week's meeting, a consensus call from the chairs may be necessary to resolve this issue. -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, April 06, 2011 3:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Putting aside my view that a registry for resource server error responses across HTTP authentication schemes isn't very useful or interesting, I don't have an objection to the bearer token specification defining such general purpose registry. In a way, it is similar to the error response headers defined by Digest, only never made generally applicable. The difference in our approaches is that I don't consider the bearer token or mac token specs to be extensions of the v2 spec, but fully specified HTTP authentication schemes with OAuth 2.0 binding (i.e. the access token type registration). Because of that, I don't think the v2 spec is the right place for such a registry, which is really about HTTP authentication schemes and not OAuth. Therefore, I think it will be more confusing to put such a registry in v2. I'll give you an example. Suppose someone will define a Digest access token type. When issuing one, the server will send an access token (to be used as username) and a secret (to be used as password). To use such a token, the client will use the HTTP Digest scheme (as is). Digest defines its own set and method or specifying error code. Would you expect those to be registered in your proposed registry? I would assume not. For such a registry to be useful, you also need to standardize the authentication header across all schemes and define a standard parameter used to deliver such error codes. However, we already moved away from that design by defining separate HTTP authentication schemes for each token type. But again, I don't have an objection to such a registry defined in the bearer token spec. I have no intentions of using it for any HTTP authentication scheme I plan to author. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Wednesday, April 06, 2011 3:39 PM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Error registry proposal (round 3) The problem with that situation is that it doesn't provide a central registry for resource server error responses across specs, unlike the other kinds of OAuth error responses. I could define that registry in the bearer token spec, but it would be less confusing to unify it with the proposed registry in the framework spec. I suspect developers would thank us for doing that. What do you say? -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, April 06, 2011 2:58 PM To: Mike Jones; OAuth WG Subject: RE: Error registry proposal (round 3) Hi Mike, This is intentional. The error registry defined in v2 is not designed to record errors for the protected resource endpoint response or the WWW-Authenticate response header when used with the Bearer token scheme (or any other scheme). The only purpose of the registry is to avoid name collisions between two errors used differently with the v2 specification. Since errors used with the Bearer token scheme will never appear in the same place as the v2 endpoints, there is no need for combining these two registries. If the bearer token specification requires error extensibility, you should retain the registry there and limit it to just the protected resource response space. Ideally, you would limit it to just the WWW-Authenticate header 'error' parameter when used with the Bearer scheme. The MAC scheme does not use error codes
Re: [OAUTH-WG] draft-15 editorials
Also, change which in turns directs to which in turn directs. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Tuesday, April 05, 2011 5:51 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft-15 editorials A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-ietf-oauth-v2-15]: Abstract: Currently it is: The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. This sentence is confusing as to whom is doing the orchestrating. It is an important OAuth feature that the 3rd-party app does this. Also add an before HTTP service. The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. 2.1 Authorization Endpoints ...when sending requests to the token endpoints should be ...when sending requests to the authorization endpoint 7.1 Access Token Types I suggest adding the following sentence to the end of the 1st paragraph, just to be sure a security value is not used in the wrong protocol. A client MUST NOT use an access token if it does not understand the token type. 7.1 Access Token Types Use a different access token for the Bearer and MAC examples to avoid any implication that a given token can be used with either method at the client's discretion. Perhaps make the example Bearer token a bit longer. The current example value has at most 72 bits of entropy that doesn't match the 128-bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw 7.1 Access Token Types The timestamp value in the MAC example corresponds to a date in 1974! -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Guidance on Native Applications in the Framework Spec (was Flowchart for legs of OAuth)
One of the results at the OAuth meeting on Friday was that non-normative text describing how to use OAuth with native applications will be restored to the framework draft. We could start with the text from past drafts, but it can likely be improved upon as well. Marius, as someone who has extensively deployed an OAuth protocol with native apps, what would you like the draft to say about this? (Others with actual deployments, please respond as well if you have things to add!) Thanks, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Skylar Woodward Sent: Monday, April 04, 2011 11:54 AM To: Marius Scurtescu Cc: Kris Selden; oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth I agree with Marius' points. We plan to support the auth-code flow for native apps as well. There is no reason why native apps can't perform a successful auth-code flow, they just do so without client credentials. However, the spec doesn't make it clear that this is viable option. skylar On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote: On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden kris.sel...@gmail.com wrote: A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once. What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token? The authorization code grant, aka web server flow. The spec is misleading in this respect IMO. Marius ___ 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] Agenda Update
We ran out of time in the working group meeting to consider the JWT profile in any depth. I pointed out that it was intentionally very parallel to the SAML profile and asked people to review it toward the goal of making it a working group document. Cheers, -- Mike -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Friday, April 01, 2011 8:37 AM To: Mike Jones Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] Agenda Update Sadly, I am not in Prague. Given the similarities between the JWT and SAML grant drafts, please let me know if anything substantial comes out of the JWT discussions. Thanks! On Thu, Mar 31, 2011 at 3:05 PM, Mike Jones michael.jo...@microsoft.com wrote: To this, I'd like to add discussion of draft-jones-oauth-jwt-bearer -- the JWT equivalent of draft-ietf-oauth-saml2-bearer. In specific, I'd like us to consider taking this up as a working group item. Thanks and see you in the morning! -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, March 31, 2011 12:13 PM To: OAuth WG Subject: [OAUTH-WG] Agenda Update After a chat with Blaine we have an updated agenda proposal: First, we need to cover our working group items: -draft-ietf-oauth-v2 *Security Consideration Section (Torsten) *Error Code registry (Mike) *Client Assertion Credentials (Mike) *Anything else? -draft-ietf-oauth-v2-bearer *Open issues? -draft-ietf-oauth-saml2-bearer *Open issues? Then, we jump into the presentations of the individual submissions: *OAuth Security (Torsten) *JSON Web Token (Mike) *Use Cases (Zachary) *Simple Web Discovery (Mike) *Dynamic Client Registration (Thomas, if time permits) *Token Revocation (Torsten, if time permits) *Chain Grant Type (Hannes on behalf of Phil, if time permits) Then, we will solicit your feedback on the rechartering. The feedback from the presentations earlier will be taken into consideration. Hope that works for you! Ciao Hannes Blaine ___ 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
[OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -04
I’ve published draft 04http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-04.html of the OAuth Bearer Token Specificationhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html. All changes were in response to working group last call feedback on draft 03. The changes in this draft were: ·Added Bearer Token definition in Terminology section. ·Changed parameter name oauth_token to bearer_token. ·Added realm parameter to WWW-Authenticate response to comply with [RFC2617]. ·Removed [ RWS 1#auth-param ] from credentials definition since it did not comply with the ABNF in [I-D.ietf-httpbis-p7-auth]. ·Removed restriction that the bearer_token (formerly oauth_token) parameter be the last parameter in the entity-body and the HTTP request URI query. ·Do not require WWW-Authenticate Response in a reply to a malformed request, as an HTTP 400 Bad Request response without a WWW-Authenticate header is likely the right response in some cases of malformed requests. ·Removed OAuth Parameters registry extension. ·Numerous editorial improvements suggested by working group members. The draft is available at these locations: ·http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-04.txt ·http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-04.xml ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-04.html ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-04.txt ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-04.xml ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versions as they are posted) ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point to new versions as they are posted) ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point to new versions as they are posted) ·http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available) Responses to the suggestions not adopted will follow shortly in separate messages. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer Token draft
This suggestion has been adopted in draft 04. Thanks all, -- Mike From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Monday, March 21, 2011 11:44 AM To: George Fletcher Cc: Mike Jones; oauth-boun...@ietf.org; OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft +1 Phil phil.h...@oracle.commailto:phil.h...@oracle.com On 2011-03-21, at 8:50 AM, George Fletcher wrote: +1 On 3/11/11 2:56 AM, tors...@lodderstedt.netmailto:tors...@lodderstedt.net wrote: Why not bearer_token? This would be in line with the Authorization scheme name. regards, Torsten. Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland -Original Message- From: Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com Sender: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org Date: Fri, 11 Mar 2011 01:54:00 To: OAuth WGoauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer Token draft ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Chief Architect AIM: gffletch Identity Services Engineering Work: george.fletc...@teamaol.commailto:george.fletc...@teamaol.com AOL Inc. Home: gffle...@aol.commailto:gffle...@aol.com Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.comhttp://practicalid.blogspot.com/ Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch ___ OAuth mailing list OAuth@ietf.orgmailto: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] WGLC on draft-ietf-oauth-v2-13.txt
I have removed the extension of the OAuth Parameters registry in draft-ietf-oauth-v2-bearer-04, per your feedback Peter. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Saturday, March 26, 2011 6:56 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt 15. Section 10.2.1 says: Parameter usage location: The location(s) where parameter can be used. The possible locations are: authorization request, authorization response, token request, or token response. Are those the only allowable locations? I notice that the bearer token spec adds a locations of resource request and resource response. I'm not quite saying we need a registry of locations, but it might be good to have a well-defined way of adding to the list of allowable locations (otherwise a document like the bearer spec might need to say that it updates the base spec). The bearer token proposal to extend the locations available is in violation of the protocol and specification architecture. It is just a really bad idea. Specifically, the idea of any registry defining HTTP URI query request parameters is a violation of the provider's namespace. We can define a registry for OAuth endpoints but not for protected resources which may not even support any URI query or form-encoded body parameters. Doing so would REQUIRE updating 2616. There are no use cases or requirements for extending the locations and no extensibility is needed. So will draft-ietf-oauth-v2-bearer be fixed? Peter -- Peter Saint-Andre https://stpeter.im/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt
Responses to suggestions not adopted on draft 04 are inline below. Thanks for your input. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, March 23, 2011 1:52 PM To: Hannes Tschofenig Cc: OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt section 2.4 What is the meaning of the component ( token = ( token / quoted-string ) ) in the definiton of the rule param? Can any of the other working group members who participated in writing this particular text answer this question? I agree that this should be defined in the specification. The scope attribute MUST NOT appear more than once. Is the scope optional? Yes. Is there a particular change to the text that you believe is necessary? section 2.4.1 I don't see the benefit of those error codes as they replicate the meaning of HTTP status codes 400, 401, and 403. I disagree with this comment, as these error codes are more specific than the corresponding HTTP status codes. Furthermore, before making any change to the error codes, I would want to see a demonstration of working group consensus for a specific change before making it. section 3.1 Token redirect - does this also cover the threat of a counterfeit server phishing and abusing tokens (https://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.6.4)? No, it does not, as I see it, but because the list of threats comes from NIST800-63, I'm not prone to expand it here. I believe that this was text originally authored by you. What specific change would you suggest? I would furthermore suggest to add the following paragraph to this section: Token abuse by counterfeit server: Clients SHOULD not make authenticated requests with an access token to unfamiliar resource servers, regardless of the presence of a secure channel. If the resource server address is well-known to the client, it MUST authenticate the resource servers by using HTTPS server authentication prior sending the request. I believe that the suggested addition is largely redundant with this existing text: Presenting the token to an unauthenticated and unauthorized resource server or failing to validate the certificate chain will allow adversaries to steal the token and gain unauthorized access to protected resources. Is there are specific change you'd like to propose that would consolidate both statements of this security principle? section 3.3 Don't store bearer tokens in cookies As cookies are generally sent in the clear, implementations MUST NOT store bearer tokens within them. Every cookie can be declared to be send over encrypted channels only. Moreover, it is subject to a same origin policy. So what is the threat here? Is it about the storage in the clear? The threat is about transmission in the clear. This point has already been reworked in response to other comments. Your comments on the new text would be welcome. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt
Responses to suggestions not adopted are inline below. Thanks for your input. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, March 02, 2011 8:34 AM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt Last call comments on draft-ietf-oauth-v2-bearer-03: Section 2.1: - RWS should be replaces with SP since the header has no other attributes (and should not have any). This will make parsing easier by mandating a single space (unless HTTPbis has other guidelines). This is insufficient rationale to introduce a potentially breaking change. I would want to see a demonstration of working group consensus for this change before making it. Section 2.4: - ABNF includes '( token = ( token / quoted-string ) )', but no prose is provided about how new parameters may be defined. Retained this extensibility point must be justified with actual use cases. This is insufficient rationale to introduce a breaking change. I would want to see a demonstration of working group consensus for this change before making it. Section 2.4.1: - Why are the HTTP error code suggested and not required? Because the spec should not presume that only the example HTTP error codes might occur. Section 4.3: - This registry is unnecessary and adds no value here (namespace collision is unlikely in general, and unlikely to cause problems). No use cases where suggested to justify it, and no additional error codes were proposed in over a year of discussions. Error codes were intentionally left non-extensible to increase interoperability. If addition color is needed for existing error codes, additional response parameters may be registered. Otherwise, if new error codes are needed, a new RFC must be published updating draft-ietf-oauth-v2. - The only way to define such a registry is to bring it up as a comment for draft-ietf-oauth-v2. Otherwise, it is limited to the Bearer token header only (and since this document is not extensible, not needed even here). Your Error extensibility proposal note sent on 3/29/2011 documents the need for error extensibility. This registry meets this need, while being simpler than the 3/29 proposal and in line with standard IETF extensibility practices. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-bearer-03
Responses to suggestions not adopted are inline below. Thanks for your input. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Wednesday, March 02, 2011 7:35 PM To: OAuth Mailing List Subject: [OAUTH-WG] Comments on draft-ietf-oauth-v2-bearer-03 1. There is a whole lot of text about OAuth2 get-a-token parts that isn't necessary in the bearer token spec. A bit of context can be useful to a reader, but in this case it brings too much of the complexity of the get-a-token flows into what should be a quite simple spec. It is not as though it can replace reading OAuth2 core. I believe that the text you mention is important to set the context for the use of OAuth 2.0 bearer tokens so readers will understand the context and purpose of this specification. I would, however, consider further clarifying this text in a future draft, should you provide specific proposed edits that retain this context. 1a. Change the title from The OAuth 2.0 Protocol: Bearer Tokens to The BEARER HTTP authentication scheme, or Using Bearer Tokens in HTTP requests. Given that this specification is about using OAuth 2.0 with bearer tokens, removing OAuth 2.0 from the title would remove necessary context that frames the purpose of the specification. 2. The abstract should say this is a mechanism for HTTP requests. My suggestion: This specification describes how to include a bearer token conveying authorization information in an HTTP request. It also describes how to recognize a bearer token delivered by an OAuth 2.0 delegation flow. As above, I believe that this proposed change over-generalizes the intended purpose and scope of the specification, making it less clear to implementers and adopters. 4. Drop most of the Introduction and all of the Overview. These are all about OAuth2 core and aren't necessary for understanding how to use a bearer token in an HTTP request. Here is my suggestion: Introduction A bearer token is the simplest mechanism for a client to convey its authority when sending a request to a server. A server accepting a bearer token assumes the authority it represents applies to whom ever presented it. That is, there is no additional authentication of the client. Consequently, it is crucial that a bearer token is never exposed to any party that might misuse it. Using bearer tokens that only represents a limited amount of authority, in a specific context, for a short amount of time can reduce the risks of using bearer tokens. This document specifies the BEARER HTTP authentication scheme for conveying a bearer token in an HTTP request header. It also specifies two alternatives for situations where it is infeasible for clients to modify HTTP headers: a URI query parameter; and a parameter in the body of a POST that uses the application/x-www-form-urlencoded media type. For example: GET /resource HTTP/1.1 Host: example.com Authorization: BEARER vF9dft4qmTG_fdf-qwAS One possible source of dynamically issued bearer tokens is an OAuth 2.0 flow for user delegation or credential exchange as specified in [OAUTH2]. Section X of this document describes how a bearer token is represented in an OAuth 2.0 token response. I believe that the text you mention is important to set the context for the use of OAuth 2.0 bearer tokens so readers will understand the context and purpose of this specification. I would, however, consider further clarifying this text in a future draft, should you provide specific proposed edits that retain this context. 8. The allowed characters in access-token is crazy. Using quoted-char, but not within quotes is not a good sign?! Token issuers don't need 93 allowed chars, just allow the 66 web-safe ones and make it simpler for everyone. This is insufficient rationale to introduce a breaking change. I would want to see a demonstration of working group consensus for this change before making it. 10. Instead of concentrating on when a WWW-Authenticate: Bearer response header MUST be returned, we should focus what it means when it is present in a response. Servers can return it when they need that meaning. This would makes it clearer that it can be included with, say, a 200 OK response to indicate that more would be available if a bearer token had been included. I would want to see demonstration of a working group consensus to expend the usage of this field in this manner before making this change. 11. The WWW-Authenticate: Bearer response header would be a good place for the server to indicate whether or not it supports the URI POST-body optional methods for conveying a bearer token. Perhaps a supports=body query parameter? I would want to see a specific proposal and a demonstration of a working group consensus to expend the usage of this field in this manner before making this
Re: [OAUTH-WG] editorial comment on section 2 of bearer token draft
This text has been revised accordingly in draft 04. Thanks for the feedback. -- Mike -Original Message- From: Ron Monzillo [mailto:ron.monzi...@oracle.com] Sent: Friday, March 11, 2011 6:35 AM To: OAuth WG; Mike Jones Subject: editorial comment on section 2 of bearer token draft http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03 the doc's stated purpose is to describe how to use bearer tokens when accessing OAuth 2.0 protected resources. but then in section 2 and 2.1, it describes how clients make authenticated token requests; which can be read as an authenticated request for a (e.g., access) token, where, imv, what is being described is the use of a (bearer) token to access a protected resource. Ron ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt
Responses to suggestions not adopted on draft 04 are inline below. Thanks for your input. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Wednesday, March 23, 2011 11:11 AM To: Hannes Tschofenig Cc: OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt hat type='AD'/ 8. What is the basis for defining short-lived a lifetime less than one hour? That's plenty of time in which to launch an attack. Torsten or other working group members - can you comment on this question by Peter? Is there a specific change that any of you would like to propose to this text? 12. Regarding Section 4.3, I'll post separately about an OAuth Errors Registry, but if it's defined it would belong in the base spec, not here. I've left this registry definition in the spec for the time being, since it has not yet been incorporated into the framework specification. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Error extensibility proposal
I object to this proposal on two grounds:
First, changing some of the error return codes to HTTP numbers is an
unnecessary and unsolicited breaking change at a time that we should be
stabilizing the spec.
Second, the OAuth Errors registry is simpler and follows IETF standard
practices. I know of no other specification where a parameters registry is
overloaded in this manner. Please incorporate the OAuth Errors registry into
the framework specification in lieu of this proposal.
Thank you,
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, March 29, 2011 4:02 PM
To: OAuth WG
Subject: [OAUTH-WG] Error extensibility proposal
*** Requirements
The following proposal is based on two requirements:
1. Provide a way to return an OAuth error response for error situations other
then 400 and 401. For example, if the server is temporarily unavailable, it
will return an HTTP 503 status. However, it is often desirable to still return
a response body using the same format as any other error. This makes client
development easier, having to always check for a single error code.
2. Allow extensions modifying the behavior of the authorization and token
endpoints via additional request/response parameters to define additional error
codes to go along with the new functionality. For example, the UX extension
defines the 'display' parameter. It could define a matching
'unsupported_display' error response.
No other use cases were identified for error extensibility. Note that this
proposal is strictly limited to error resulting from the authorization and
token endpoints. No other endpoints are included (in particular, protected
resources are not covered by this proposal).
*** Design goals
The proposal was specifically designed to be minimalistic, tailored to the
specific use cases defined, and as effortless as possible. This avoids defining
error codes identical to existing HTTP status codes, as well as bind new errors
to specific extension parameters. Since the error is useless without
understanding the extension, this method guarantees that those developing and
implementing extensions will present it as a complete unit.
*** Proposal
- Non 400/401 responses
If the HTTP response status code is 4xx (other than 400/401) or 5xx, the
'error' parameter SHOULD be set to the HTTP status code. For example:
HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Cache-Control: no-store
{
error:503
}
This will also enable passing HTTP status codes such as 503 via the redirection
response which is currently not possible. It will allow the authorization
server to indicate a 503 situation without defining another error code that has
the exact same meaning.
- Extension errors
Instead of defining an additional error registry, I propose we add a single
field to the 'OAuth parameters registry' template:
Additional error codes:
Additional error codes related to the parameter usage. Error codes
SHOULD begin with the parameter name
when possible (e.g. 'example_invalid' error code for use with the
'example' parameter).
Error collisions are unlikely because when a new extension is authored, the
registry is reviewed for potential conflicts. Since the errors are
extension-specific, collisions only matter if two extensions are to be used
together. In that case, the review process will identify any potential
problems. And since the errors are meaningless without understanding the
extension, a registry with a random list of errors is not very helpful.
*** Feedback
Please send any feedback, comments, support, and objections by 3/1 (so it can
be included or not in -14).
EHL
___
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] Agenda Update
To this, I'd like to add discussion of draft-jones-oauth-jwt-bearer -- the JWT equivalent of draft-ietf-oauth-saml2-bearer. In specific, I'd like us to consider taking this up as a working group item. Thanks and see you in the morning! -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, March 31, 2011 12:13 PM To: OAuth WG Subject: [OAUTH-WG] Agenda Update After a chat with Blaine we have an updated agenda proposal: First, we need to cover our working group items: -draft-ietf-oauth-v2 *Security Consideration Section (Torsten) *Error Code registry (Mike) *Client Assertion Credentials (Mike) *Anything else? -draft-ietf-oauth-v2-bearer *Open issues? -draft-ietf-oauth-saml2-bearer *Open issues? Then, we jump into the presentations of the individual submissions: *OAuth Security (Torsten) *JSON Web Token (Mike) *Use Cases (Zachary) *Simple Web Discovery (Mike) *Dynamic Client Registration (Thomas, if time permits) *Token Revocation (Torsten, if time permits) *Chain Grant Type (Hannes on behalf of Phil, if time permits) Then, we will solicit your feedback on the rechartering. The feedback from the presentations earlier will be taken into consideration. Hope that works for you! Ciao Hannes Blaine ___ 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] JSON Web Token (JWT) Draft -04
Draft -04 of the JSON Web Token (JWT)http://self-issued.info/docs/draft-jones-json-web-token.html specification is available. It corrects a typo found by John Bradley in -03. The draft is available at these locations: *http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.txt *http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.xml *http://self-issued.info/docs/draft-jones-json-web-token-04.html *http://self-issued.info/docs/draft-jones-json-web-token-04.txt *http://self-issued.info/docs/draft-jones-json-web-token-04.xml *http://self-issued.info/docs/draft-jones-json-web-token.html (will point to new versions as they are posted) *http://self-issued.info/docs/draft-jones-json-web-token.txt (will point to new versions as they are posted) *http://self-issued.info/docs/draft-jones-json-web-token.xml (will point to new versions as they are posted) *http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Subversion repository, with html, txt, and html versions available) -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs
These are now published as IETF drafts. The IETF .txt version links are: http://www.ietf.org/id/draft-jones-json-web-token-03.txt http://www.ietf.org/id/draft-jones-json-web-signature-01.txt -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, March 25, 2011 10:26 PM To: oauth@ietf.org; w...@ietf.org; openid-specs...@lists.openid.net Cc: openid-sp...@lists.openid.net Subject: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs As promised, I have split the contents of the JWT spec draft-jones-json-web-token-01http://self-issued.info/docs/draft-jones-json-web-token-01.html into two simpler specs: draft-jones-json-web-token-02http://self-issued.info/docs/draft-jones-json-web-token-02.html draft-jones-json-web-signature-00http://self-issued.info/docs/draft-jones-json-web-signature-00.html These should have introduced no semantic changes from the previous spec. I then applied the feedback that I received since JWT -01 and created revised versions of the split specs: draft-jones-json-web-token-03http://self-issued.info/docs/draft-jones-json-web-token-03.html draft-jones-json-web-signature-01http://self-issued.info/docs/draft-jones-json-web-signature-01.html The only breaking change introduced was that x5t (X.509 Certificate Thumbprint) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practice for certificate thumbprint calculations. See the Document History sections for details on each change made. .txt and .xml versions are also available. I plan to publish these as IETF drafts once the submission window re-opens on Monday. Feedback welcome! -- Mike P.S. Yes, work on the companion encryption spec is now under way... ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth JWT Bearer Token Profile
This is now published as an IETF draft. The IETF .txt version link is: http://www.ietf.org/id/draft-jones-oauth-jwt-bearer-00.txt -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, March 16, 2011 10:57 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth JWT Bearer Token Profile I've just published an OAuth JWT Bearer Token Profilehttp://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html. It defines a means of using a JSON Web Token (JWT) bearer token to request an OAuth 2.0 access token. This profile is intentionally strongly based upon the SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0http://www.ietf.org/id/draft-ietf-oauth-saml2-bearer-03.txt by Brian Campbell and Chuck Mortimore; it borrows some text from the SAML profile with their permission. Thanks Brian and Chuck, for supporting the writing of this profile and for your reviews of preliminary drafts. The profile draft is available at these locations: http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.html http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.txt http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.xml http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html (will point to new versions as they are posted) http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.txt (will point to new versions as they are posted) http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.xml (will point to new versions as they are posted) http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available) I will also submit this as a formal Internet draft after the IETF tool re-opens for submissions (on March 28th). -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Openid-specs-ab] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs
Correct - good catch. I'll update the draft. The intent was for there to be no pad character in that case. -- Mike From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Monday, March 28, 2011 3:00 PM To: Mike Jones Cc: oauth@ietf.org; w...@ietf.org; openid-specs...@lists.openid.net; openid-sp...@lists.openid.net Subject: Re: [Openid-specs-ab] [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs Mike in JWT 6.7 if the alg is none. Otherwise, if the alg value is none, the JWT Claim Segment is the empty string. I may be missing something. If the Alg is none then the Claim segment is still the claim segment. It is the Crypto segment that would just be padding to maintain the format. In 8 10 the decoding has it correct. So in the event the signature alg is none do we make the cripto segment a pad character? So normally it would be xxx..x Dropping the cripto segment looks like xxx.. Or with a pad char to be ignored xxx.x.0 Or something like that. John B. On 2011-03-28, at 5:28 AM, Mike Jones wrote: These are now published as IETF drafts. The IETF .txt version links are: http://www.ietf.org/id/draft-jones-json-web-token-03.txt http://www.ietf.org/id/draft-jones-json-web-signature-01.txt -- Mike From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, March 25, 2011 10:26 PM To: oauth@ietf.orgmailto:oauth@ietf.org; w...@ietf.orgmailto:w...@ietf.org; openid-specs...@lists.openid.netmailto:openid-specs...@lists.openid.net Cc: openid-sp...@lists.openid.netmailto:openid-sp...@lists.openid.net Subject: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs As promised, I have split the contents of the JWT spec draft-jones-json-web-token-01http://self-issued.info/docs/draft-jones-json-web-token-01.html into two simpler specs: draft-jones-json-web-token-02http://self-issued.info/docs/draft-jones-json-web-token-02.html draft-jones-json-web-signature-00http://self-issued.info/docs/draft-jones-json-web-signature-00.html These should have introduced no semantic changes from the previous spec. I then applied the feedback that I received since JWT -01 and created revised versions of the split specs: draft-jones-json-web-token-03http://self-issued.info/docs/draft-jones-json-web-token-03.html draft-jones-json-web-signature-01http://self-issued.info/docs/draft-jones-json-web-signature-01.html The only breaking change introduced was that x5t (X.509 Certificate Thumbprint) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practice for certificate thumbprint calculations. See the Document History sections for details on each change made. .txt and .xml versions are also available. I plan to publish these as IETF drafts once the submission window re-opens on Monday. Feedback welcome! -- Mike P.S. Yes, work on the companion encryption spec is now under way... ___ Openid-specs-ab mailing list openid-specs...@lists.openid.netmailto:openid-specs...@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs-ab ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13
Actually, despite having submitted this comment, I'm having second thoughts about it as well based upon some possible use cases I'm aware of. If, for instance, a scope element contains base64url encoded content in a URL, case-folding it will destroy it. Therefore, on reconsideration, I'd like to withdraw the comment and have the sentence about scope elements being case-insensitive removed from the draft. Thanks, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Friday, March 25, 2011 9:17 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13 It didn't align with the my assumption when I was implementing, which is why I asked:) With respect to URIs, I believe that the scheme and host are always case-intensive but the case-sensitivity of the other parts are scheme dependent and that, in general, comparison is hard and error prone. It just feels like a slippery slope to start adding normalization/comparison rules to scope. But with that said, it's not a big deal and I won't quibble about it. On Fri, Mar 25, 2011 at 9:02 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: It's a safe language to align it with common assumptions. Also, in the case of URI values, they are usually case insensitive. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Friday, March 25, 2011 8:00 AM To: Eran Hammer-Lahav Cc: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13 4.1.1: Scope string matching rules are ambiguous In the scope definition, add The space-delimited strings are case insensitive. Good call. I'd like to better understand why? Other than a means to delimit and allow for multiple values, the spec is otherwise leaving the interpretation of scope values up to the implementation/deployment. ___ 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] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs
As promised, I have split the contents of the JWT spec draft-jones-json-web-token-01http://self-issued.info/docs/draft-jones-json-web-token-01.html into two simpler specs: draft-jones-json-web-token-02http://self-issued.info/docs/draft-jones-json-web-token-02.html draft-jones-json-web-signature-00http://self-issued.info/docs/draft-jones-json-web-signature-00.html These should have introduced no semantic changes from the previous spec. I then applied the feedback that I received since JWT -01 and created revised versions of the split specs: draft-jones-json-web-token-03http://self-issued.info/docs/draft-jones-json-web-token-03.html draft-jones-json-web-signature-01http://self-issued.info/docs/draft-jones-json-web-signature-01.html The only breaking change introduced was that x5t (X.509 Certificate Thumbprint) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practice for certificate thumbprint calculations. See the Document History sections for details on each change made. .txt and .xml versions are also available. I plan to publish these as IETF drafts once the submission window re-opens on Monday. Feedback welcome! -- Mike P.S. Yes, work on the companion encryption spec is now under way... ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Apparent consensus on OAuth Errors Registry
People voted as follows in the poll I conducted on the OAuth Errors Registry: For A: Mike Jones Igor Faynberg Justin Richter Anthony Nadalin For D or C: Eran Hammer-Lahav William Mills Given that twice as many people indicated a preference for A as for any other option, that seems to indicate a consensus for A. Therefore Eran, when you update your draft, can you please proceed on that basis? Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth JWT Bearer Token Profile
I've just published an OAuth JWT Bearer Token Profilehttp://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html. It defines a means of using a JSON Web Token (JWT) bearer token to request an OAuth 2.0 access token. This profile is intentionally strongly based upon the SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0http://www.ietf.org/id/draft-ietf-oauth-saml2-bearer-03.txt by Brian Campbell and Chuck Mortimore; it borrows some text from the SAML profile with their permission. Thanks Brian and Chuck, for supporting the writing of this profile and for your reviews of preliminary drafts. The profile draft is available at these locations: http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.html http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.txt http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.xml http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html (will point to new versions as they are posted) http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.txt (will point to new versions as they are posted) http://self-issued.info/docs/draft-jones-oauth-jwt-bearer.xml (will point to new versions as they are posted) http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available) I will also submit this as a formal Internet draft after the IETF tool re-opens for submissions (on March 28th). -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Feedback on draft-ietf-oauth-v2-13
My last call feedback on draft 13 follows. NORMATIVE FEEDBACK 2.1.1: If no valid redirection URI is available, the authorization server SHOULD - I don't understand why this is a SHOULD and not a MUST 3: Restore Client Assertion Credentials Restore the Client Assertion Credentials feature that was present in draft 11, section 3.2. 4.1.1: Scope string matching rules are ambiguous In the scope definition, add The space-delimited strings are case insensitive. 4.1, 4.2, 4.3.2, 4.4.2, 5.1, 6: Scope parameter should be paired with complimentary resource parameter It is desirable to be able to have a single service protecting multiple resources. To achieve that, there needs to be a parameter specifying what the desired resource being accessed is. This is different than scope. At least as we're using it, scope would be a space-separated list of kinds of access requested. For instance you might be requesting read access to someone's calendar free/busy times and the right to post new calendar requests. Those would be scope statements and would use URIs specifying those rights. Therefore, we request that an additional optional resource parameter be added to the specification in the same places that scope appears. Resource would be the URI (probably a URL) of the resource being protected by the service. 4.2.2: Add optional expires_at parameter SAML, WS-Trust, JWT, and several other specifications use absolute, rather than relative expiration times. Please add an optional expires_at parameter, enabling absolute times to be used. The value should be an integer specifying the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the desired date/time. See RFC 3339 for details regarding date/times in general and UTC in particular. 4.4.2 etc.: The name client_credentials is confusing The name client_credentials does not refer to the same concept as the uses of the term Client Credentials in 1.4.4 and other locations in the document. It would be far better to rename this parameter none or implicit, to indicate that no explicit credentials are being passed in the protocol. It might also clarify this concept if you added an example. 7: Restore WWW-Authenticate Response Header Field Restore the WWW-Authenticate Response Header Field that was present in draft 11, section 6.2. 10: Add OAuth Errors Registry Add the OAuth Errors Registry from the bearer token specification, draft 03, section 4.3, to the IANA Considerations. 10.2: Add parameter locations to OAuth Parameters Registry Add the resource request and resource response parameter locations, as defined in the bearer token specification, draft 03, section 4.2, to the OAuth Parameters Registry. EDITORIAL FEEDBACK 1.2 item (D) : and if valid issues a access token - and if valid, issues an access token and optional refresh token 1.3: an access token is a string - an access token is a string encoded 1.4.5: OAuth and other trust frameworks - OAuth - The term trust framework seems to have taken on a different meaning than this one these days. 1.5: used to obtain a new access token when the current access token expires - used to obtain a new access token when the current access token is no longer valid. expires is just one case. 1.5 item (F) : access token is invalid (expired) - access token is invalid (e.g., expired) 2.1.1: resource owner's user-agent this may not be possible if the resource owner is a device or if the resource owner does not have a user agent 2.1.1: which MUST be retained - which MUST be preserved 2.2: The location of the token endpoint can be found in the service documentation - There is no service documentation; suggest that this just say The location of the token endpoint discovery is out of scope of this document 3: keeping their secrets confidential - keeping their credentials confidential 4: which the client uses to requesting the access - which the client uses to request the access 4.1: with the resource owner's user-agent this may not be possible if the resource owner is a device or if the resource owner does not have a user agent 4.1.1: parameters are present and valid - there are no processing requirements section to determine what valid means; suggest that a processing section be added to understand what valid means otherwise remove the references to valid 4.1.3: Usage of verify and validate, should consistent. Validate the client credentials and ensure they match the authorization code this is misleading and should read Validate the client credentials and ensure that the authorization code given is authorized 4.1.4: the authorization server return - the authorization server returns 4.1.2.1, 4.2.2, 4.2.2.1: List REQUIRED parameters before OPTIONAL parameters. 4.2: It's unclear what the actual meaning of user-agent's same-origin policy really is as there are many and I don't think there is common agreement on this; I suggest that the actual
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt
This specification is ready to publish. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, March 02, 2011 12:32 AM To: OAuth WG Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt This is a Last Call for comments on http://www.ietf.org/id/draft-ietf-oauth-v2-bearer-03.txt Please have your comments in no later than March 25 (extended deadline because of the ongoing OAuth base specification WGLC). Do remember to send a note in if you have read the document and have no other comments other than its ready to go - we need those as much as we need I found a problem. Thanks! Hannes Blaine ___ 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] Vote: Location of OAuth Errors Registry, deadline Friday, March 18
Per the previous discussions, the use case is enabling OAuth specifications to be able to extend the set of interoperable error codes. Use of an IANA registry for this purpose is standard IETF practice. (To see *lots* of other examples of this in practice, go to http://www.iana.org/protocols/ and search for error.) One non-hypothetical motivating example is extending the set of errors in 4.2.2.1 to add an insufficient_scope error to indicate that the request is valid but requires higher privileges than currently held by the caller. This is different than invalid_scope. Another possible error code that is meaningful and actionable in some contexts is please_retry, indicating that this same request may succeed later if retried. Services may return this when out of resources or during initialization. Given that we all intend OAuth to be a building block for a family of related protocols and for new services, it would be presumptive of us to assert that we've identified of all the actionable error conditions up front. This is exactly parallel to the argument for the OAuth Parameters registry, which does exist. The IETF has a straightforward mechanism and for extending parameter spaces in an orderly way. I believe that we'll best serve those building new protocols and services on top of OAuth by using it! Cheers, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, March 14, 2011 6:30 PM To: David Recordon Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18 It's a clear example of defining facilities without *ANY* use cases or requirements. We have clear use cases and actual registration requests for the current registries defined in v2. What's most annoying about this entire push for an error registry is that the author and supporters have all failed to show a single example of an actual value to be registered. I don't think I'm asking for much. Registries must be held to the same level of adoption as any other part of the protocol. If a feature is not being use by the time the document is finalized, it MUST NOT be included and left out. Otherwise, this is pure astronaut architecture and design by committee. As for the reference to the editorial comment in draft 11 - there were other such notes in part drafts which were simply removed without addressing throughout the process. This registry is new, and is baseless. An important part of our process is weeding out what is not necessary, and an error registry clearly fails to meet this standard. This entire thread should be stopped until someone can offer clear use cases and requirements. Otherwise, this is a joke. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David Recordon Sent: Monday, March 14, 2011 6:04 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18 Has anyone extended error codes? Is there a list of error codes currently being used in the wild that need standardizing? --David On Mon, Mar 14, 2011 at 11:28 PM, Mike Jones michael.jo...@microsoft.com wrote: This is not new. This is meeting the need expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as [[ Add mechanism for extending error codes ]]. It's there to provide a coordination mechanism among OAuth-related specifications so that different specs use the same errors for the same thing. -- Mike -Original Message- From: David Recordon [mailto:record...@gmail.com] Sent: Monday, March 14, 2011 4:15 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18 I still haven't seen an explanation of what this registry accomplishes or why it's become needed in the past few weeks. --David On Fri, Mar 11, 2011 at 11:04 PM, Mike Jones michael.jo...@microsoft.com wrote: As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth Errors Registry to increase interoperability among implementations using the related OAuth specifications. As you also know, there has been some discussion about whether: A) The OAuth Errors Registry belongs in in the Framework specification rather than the bearer token specification, B) The OAuth Errors Registry should continue to be defined in the Bearer Token specification and apply to all OAuth specifications, C) The OAuth Errors Registry should reside in the Bearer Token specification but be scoped back to only apply to that specification, or D) The OAuth Errors Registry should be deleted because the set of errors should
Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18
This is not new. This is meeting the need expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as [[ Add mechanism for extending error codes ]]. It's there to provide a coordination mechanism among OAuth-related specifications so that different specs use the same errors for the same thing. -- Mike -Original Message- From: David Recordon [mailto:record...@gmail.com] Sent: Monday, March 14, 2011 4:15 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18 I still haven't seen an explanation of what this registry accomplishes or why it's become needed in the past few weeks. --David On Fri, Mar 11, 2011 at 11:04 PM, Mike Jones michael.jo...@microsoft.com wrote: As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth Errors Registry to increase interoperability among implementations using the related OAuth specifications. As you also know, there has been some discussion about whether: A) The OAuth Errors Registry belongs in in the Framework specification rather than the bearer token specification, B) The OAuth Errors Registry should continue to be defined in the Bearer Token specification and apply to all OAuth specifications, C) The OAuth Errors Registry should reside in the Bearer Token specification but be scoped back to only apply to that specification, or D) The OAuth Errors Registry should be deleted because the set of errors should not be extensible. Please vote for A, B, C, or D by Friday, March 18th. I personally believe that A makes the most sense, but given that other points of view have also been voiced, this consensus call is needed to resolve the issue. Cheers, -- 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] Vote: Location of OAuth Errors Registry, deadline Friday, March 18
As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth Errors Registryhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html#errors-registry to increase interoperability among implementations using the related OAuth specifications. As you also know, there has been some discussion about whether: A) The OAuth Errors Registry belongs in in the Framework specification rather than the bearer token specification, B) The OAuth Errors Registry should continue to be defined in the Bearer Token specification and apply to all OAuth specifications, C) The OAuth Errors Registry should reside in the Bearer Token specification but be scoped back to only apply to that specification, or D) The OAuth Errors Registry should be deleted because the set of errors should not be extensible. Please vote for A, B, C, or D by Friday, March 18th. I personally believe that A makes the most sense, but given that other points of view have also been voiced, this consensus call is needed to resolve the issue. Cheers, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18
That would be yet a different option. With (C), the initial set of errors
registered by the bearer token spec {invalid_request, invalid_token,
insufficient_scope} could be extended by registering new errors. With your
alternative wording, this set would not be extensible.
-- Mike
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Friday, March 11, 2011 3:35 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline
Friday, March 18
Should option C read: No OAuth Errors Registry, but each specification may
specify its own set of errors. Or is this another option and C is different?
Phil
phil.h...@oracle.commailto:phil.h...@oracle.com
On 2011-03-11, at 3:04 PM, Mike Jones wrote:
As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth Errors
Registryhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html#errors-registry
to increase interoperability among implementations using the related OAuth
specifications. As you also know, there has been some discussion about whether:
A) The OAuth Errors Registry belongs in in the Framework specification rather
than the bearer token specification,
B) The OAuth Errors Registry should continue to be defined in the Bearer Token
specification and apply to all OAuth specifications,
C) The OAuth Errors Registry should reside in the Bearer Token specification
but be scoped back to only apply to that specification, or
D) The OAuth Errors Registry should be deleted because the set of errors
should not be extensible.
Please vote for A, B, C, or D by Friday, March 18th.
I personally believe that A makes the most sense, but given that other points
of view have also been voiced, this consensus call is needed to resolve the
issue.
Cheers,
-- Mike
___
OAuth mailing list
OAuth@ietf.orgmailto: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] Vote: Location of OAuth Errors Registry, deadline Friday, March 18
The value of having a common OAuth Errors Registry, as provided by both (A) and
(B), is that when “one is defining a non-bearer spec”, the errors will be
consistent with those used in the bearer spec (and other OAuth specs), which
can only help interoperability.
Your statement “It doesn't seem right to put registry in bearer spec” is the
argument for (A) rather than (B).
-- Mike
From: Phillip Hunt [mailto:phil.h...@oracle.com]
Sent: Friday, March 11, 2011 4:32 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline
Friday, March 18
Extensibility for the new option would be defined within each spec.
It doesn't seem right to put registry in bearer spec. What if one is defining a
non-bearer spec?
Phil
Sent from my phone.
On 2011-03-11, at 15:41, Mike Jones
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote:
That would be yet a different option. With (C), the initial set of errors
registered by the bearer token spec {invalid_request, invalid_token,
insufficient_scope} could be extended by registering new errors. With your
alternative wording, this set would not be extensible.
-- Mike
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Friday, March 11, 2011 3:35 PM
To: Mike Jones
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline
Friday, March 18
Should option C read: No OAuth Errors Registry, but each specification may
specify its own set of errors. Or is this another option and C is different?
Phil
phil.h...@oracle.commailto:phil.h...@oracle.com
On 2011-03-11, at 3:04 PM, Mike Jones wrote:
As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth Errors
Registryhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html#errors-registry
to increase interoperability among implementations using the related OAuth
specifications. As you also know, there has been some discussion about whether:
A) The OAuth Errors Registry belongs in in the Framework specification rather
than the bearer token specification,
B) The OAuth Errors Registry should continue to be defined in the Bearer Token
specification and apply to all OAuth specifications,
C) The OAuth Errors Registry should reside in the Bearer Token specification
but be scoped back to only apply to that specification, or
D) The OAuth Errors Registry should be deleted because the set of errors
should not be extensible.
Please vote for A, B, C, or D by Friday, March 18th.
I personally believe that A makes the most sense, but given that other points
of view have also been voiced, this consensus call is needed to resolve the
issue.
Cheers,
-- Mike
___
OAuth mailing list
OAuth@ietf.orgmailto: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] OAuth Bearer Token draft
Several people have asked for this parameter name to be changed to oauth2_token. If a change is made, it would seem to me that that would be the logical name to use. Is anyone strongly opposed to making this change? -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher Sent: Thursday, March 10, 2011 4:28 PM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I'm not crazy about the compromise either, but it's not possible for a site using JSONP and it's cross-domain tricks to set the Authorization header out of the browser or POST the data out of the browser in a cross-domain way (due to the same origin browser policy). Quoting Eran from a previous message JSON-P is one valid example (though JSON-P usage is in decline with new methods for cross-domain calls) I do agree we need to give the url parameter a different name than oauth_token. Thanks, George On 3/10/11 5:31 PM, Phil Hunt wrote: In theory yes, sometimes a token has limited scope. But since a token will often have unlimited scope, it carries the same potential for risk. I would say one-time use tokens (e.g. grant codes) are really the only things that should be passed by URL. Note that if the client was able to obtain a token from a token server, then it must have been previously been able to send data as headers or forms to obtain a token. So why can't it pass the authorization token using the HTTP Authorization header? I'm missing what the problem is here that leads to needing this security compromise. Phil phil.h...@oracle.commailto:phil.h...@oracle.com On 2011-03-10, at 1:43 PM, Torsten Lodderstedt wrote: I would assume refresh token exposure to be less dangerous than the leakage of uid/password since a refresh tokens is restricted to a scope. regards, Torsten. Am 10.03.2011 20:22, schrieb Phil Hunt: I think I was confused because of the use of the term credential rather than token. If you are calling the token service end-point then it is a big issue. E.g. exposing a refresh token would be as bad as a uid/pwd since it is long-lived. For a resource server, I agree, the risk is lower. Phil phil.hunt@oracle.comermailto:phil.hunt@oracle.comer On 2011-03-10, at 11:17 AM, Richer, Justin P. wrote: Nobody said UID and password -- we're talking about tokens here. The cost of a leaked temporary token (even a straight bearer token) is much, much lower. -- Justin From: Phil Hunt [phil.h...@oracle.commailto:phil.h...@oracle.com] Sent: Thursday, March 10, 2011 2:01 PM To: Richer, Justin P. Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft Well, for one if you promote this, it becomes general technique. Now you have uid/passwords in browser history etc potentially accessible to javascript and could be leaked/hacked in any number of ways. Also, I would say that credentials are a higher risk item then say a specific API call. Why? because credentials are used universally and so the exposure is much higher. That said, it is still possible that application data can just as costly to expose. Another reason to use secure forms over URLs. Phil phil.h...@oracle.commailto:phil.h...@oracle.com On 2011-03-10, at 10:37 AM, Richer, Justin P. wrote: 1) Yes. And don't discount ease-of-use for developers. If I'm already sending my parameters over the query, this becomes another parameter and is really easy to manage. 2) Yes, for parallelism to #1, when using a POST. 3) The idea of a parameter registry for this part is absurd, and the parameter should be kept simple. I do think that it needs to be named something other than oauth_token. I'm happy with discouraging the use of 1 and 2 with discussion in the security considerations, but I think that if we don't specify this behavior and discuss it, then people are going to do it anyway and we run more risk of things going wrong. Simply ignoring the issue in the spec (by remaining silent about it) will not make it go away. Since all formats are optional, couldn't an AS/PR setup that wants to just lock things down and require auth headers for their particular setup? If in two years nobody deploys it anymore, then let's deprecate it from the spec and never speak of this again. -- Justin From: Eran Hammer-Lahav [e...@hueniverse.commailto:e...@hueniverse.com] Sent: Thursday, March 10, 2011 1:29 PM To: Phil Hunt; Richer, Justin P. Cc: OAuth WG Subject: RE: [OAUTH-WG] OAuth Bearer Token draft There are a few issues to consider. 1. Should the spec support sending bearer token in a query parameter? - The argument that there are many use cases for this is unproven. JSON-P is one valid example (though JSON-P usage is in decline with new methods for
[OAUTH-WG] OAuth bearer token draft ready for working group last call
As editor, having received no comments on the normative content of draft-ietf-oauth-v2-bearer-03, and having made no breaking changes since draft -01, other than one change voted upon by the working group, I believe that draft-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerations section framework specification to register its errors. This should happen in draft -14 at the same time that the security considerations are added. At that point, hopefully we can go to working group last call on the framework specification as well. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth bearer token draft ready for working group last call
I did not ignore your feedback. I replied to it, pointing out why I believe your position is incorrect. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Monday, February 28, 2011 1:14 PM To: Mike Jones; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call I am opposed to all the new registration changes and requirements which have any impact on draft-ietf-oauth-v2. This request seems a bit odd given my feedback (which you have, again, ignored). EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, February 28, 2011 12:51 PM To: Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last call As editor, having received no comments on the normative content of draft-ietf-oauth-v2-bearer-03, and having made no breaking changes since draft -01, other than one change voted upon by the working group, I believe that draft-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerations section framework specification to register its errors. This should happen in draft -14 at the same time that the security considerations are added. At that point, hopefully we can go to working group last call on the framework specification as well. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -03
I've published draft 03http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html of the OAuth Bearer Token Specificationhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html. It contains one breaking change relative to draft 02http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html that was voted on by the working group: changing the OAuth2 OAuth access token type name to Bearer. The full set of changes in this draft is: * Restored the WWW-Authenticate response header functionality deleted from the framework specification in draft 12 based upon the specification text from draft 11. * Augmented the OAuth Parameters registry by adding two additional parameter usage locations: resource request and resource response. * Registered the oauth_token OAuth parameter with usage location resource request. * Registered the error OAuth parameter. * Created the OAuth Error registry and registered errors. * Changed the OAuth2 OAuth access token type name to Bearer. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-03.txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-03.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point to new versions as they are posted) * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available) Your feedback is solicited. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry
I wanted to explicitly call out that draft -03 of the Bearer Token Specification establishes the OAuth Errors registry to increase interoperability among the related OAuth specifications. Eran, when you produce draft -14 of the framework specification, please register the errors in the specification to comply with this new requirement. Errors in other OAuth specifications should likewise be registered in updated drafts. I also wanted to call out that draft -03 augments the OAuth Parameters registry by adding two additional parameter usage locations: resource request and resource response. Like parameters for the parameter usage locations authorization request, authorization response, token request, and token response, parameters for these usage locations must also be registered. Eran, if you would prefer, on an editorial basis, to move these OAuth registry requirements into the framework spec, I would be fine with that. If you do so in your draft -14, I will remove them from my draft -04. Best wishes, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry
I see a problem with collision of error codes. I believe that the working group will likely concur. I agree that it is odd for the bearer token specification to impose requirements upon the framework specification. Hence my editorial request for you to incorporate these registry additions into the framework specification. Nonetheless, if you do not, the requirement remains, as the two specs are intended to work together as a seamless whole. It is far from absurd to require parameter registrations for the resource request and resource response messages in OAuth specifications. Phil and Brian's notes just today point out the value of just such registration. Again, I'll politely repeat my request to update the framework specification, and other specifications that you are an editor of, to comply with these requirements. -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Friday, February 25, 2011 2:33 PM To: Mike Jones; oauth@ietf.org Subject: RE: OAuth Errors Registry and OAuth Parameters Registry I don't see a point in an error registry (and I find it odd for the Bearer token specification to impose any requirements of the protocol specification). Registries are created to prevent namespace collision. I don't see real problem with collision of error codes, especially not for a while. The OAuth protocol errors are not extensible. To extend them, a specification must be published that updates the OAuth 2.0 RFC. Not making it extensible actually helps interoperability. You can't define a resource request and resource response locations. That's absurd. The resource endpoint is service specific and by definition will have an unlimited number of parameters. How exactly do you expect this registry to work? Every provider registering every parameter they are going to use as part of their own API? It's enough that the 'oauth_token' parameter invades the provider's space as it is. No changes are needed to the OAuth 2.0 protocol specification and I'd suggest you drop all these new additions from the bearer token draft. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, February 25, 2011 2:18 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry I wanted to explicitly call out that draft -03 of the Bearer Token Specification establishes the OAuth Errors registry to increase interoperability among the related OAuth specifications. Eran, when you produce draft -14 of the framework specification, please register the errors in the specification to comply with this new requirement. Errors in other OAuth specifications should likewise be registered in updated drafts. I also wanted to call out that draft -03 augments the OAuth Parameters registry by adding two additional parameter usage locations: resource request and resource response. Like parameters for the parameter usage locations authorization request, authorization response, token request, and token response, parameters for these usage locations must also be registered. Eran, if you would prefer, on an editorial basis, to move these OAuth registry requirements into the framework spec, I would be fine with that. If you do so in your draft -14, I will remove them from my draft -04. Best wishes, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Freedom of assembly for response_type
I also support the proposed refinement of the specification. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly. The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type). - Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=code response_type=token response_type=code+token response_type=cookie response_type=code+cookie response_type=token+cookie response_type=foo+bar Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow extensions to define what do with 'code+token' or with any other values or combinations of values. -- Breno de Medeiros -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)
I'm likewise OK with #1. As I'd written previously, I wasn't religious about the name OAuth2; I was for it for to be consistent with past drafts and so as not to introduce a breaking change. Given that there appears to be consensus to make a change, I'll plan on publishing a draft later this week that contains it unless discussion in the next few days convinces us that we should follow a different course. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marius Scurtescu Sent: Tuesday, February 08, 2011 9:24 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Mike, Brian, Dirk, and Marius - can you live with #1? Works for me. Marius ___ 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] Bearer token scheme name - new vote deadline Sat, 2/12
Given that people are clearly voting to change the bearer token scheme name, but that there is also significant discussion asking for OAuth2 to be part of the name, I'd like to settle the matter by vote on the list. Please vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)
It will be either OAuth2Bearer or Bearer, depending upon the outcome of the vote just sent to the list. -- Mike -Original Message- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Tuesday, February 08, 2011 2:48 PM To: Mike Jones; Marius Scurtescu Cc: OAuth WG Subject: RE: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thanks Mike. How are you going to show the scheme name? bearer, Bearer, BEARER, ...? It is case-insensitive but want to be consistent. EHL -Original Message- From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Tuesday, February 08, 2011 9:46 AM To: Marius Scurtescu; Eran Hammer-Lahav Cc: OAuth WG Subject: RE: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) I'm likewise OK with #1. As I'd written previously, I wasn't religious about the name OAuth2; I was for it for to be consistent with past drafts and so as not to introduce a breaking change. Given that there appears to be consensus to make a change, I'll plan on publishing a draft later this week that contains it unless discussion in the next few days convinces us that we should follow a different course. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marius Scurtescu Sent: Tuesday, February 08, 2011 9:24 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Mike, Brian, Dirk, and Marius - can you live with #1? Works for me. Marius ___ 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] Bearer token scheme name - new vote deadline Sat, 2/12
Yes, but it also had other options that were none of the above relative to this naming issue. I'd like to obtain an unambiguous outcome on this point by having people vote between two choices. I personally agree with those that made the case that it is presumptive to claim the generic name Bearer. Hence, I will personal vote for #1. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Tuesday, February 08, 2011 3:13 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 The previous poll already had these two options, with the non-OAuth-specific name getting 14 votes to 1 vote for an OAuth prefix. 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) ... 3. Name prefix (e.g. oauth2_bearer) I vote for 2 Bearer. -- James Manger From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, 9 February 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Given that people are clearly voting to change the bearer token scheme name, but that there is also significant discussion asking for OAuth2 to be part of the name, I'd like to settle the matter by vote on the list. Please vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme'
Here's one objection, per my note sent on January 18th: 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like a huge step away from interoperability. As one data point, Microsoft implements this in our WIF OAuth2 protected resource code. All up, clients need a way to authenticate to the protected resource. Also, existing WRAP implementations need this functionality to migrate to OAuth2. For all these reasons, we support retaining this functionality in OAuth2. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, February 03, 2011 7:31 AM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' Hey Tony, thanks for the feedback. I might have missed the objection. Could you be more specific about who did not want this functionality to be removed? Ciao Hannes On 2/3/2011 5:19 PM, Anthony Nadalin wrote: There have been several of us that have objected and several of that have implemented this feature, it's late in the cycle to remove, so I raise the objection. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, February 03, 2011 12:11 AM To: oauth@ietf.org Subject: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' Hi all, Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme functionality from the specification in his mail from last month: http://www.ietf.org/mail-archive/web/oauth/current/msg05026.html The discussion got off topic pretty quickly with the discussion about OAuth usage for SASL. I couldn't see a strong objection but rather clarifying discussions. Please correct me if I misread your feedback on this issue. So, my current impression is that there is no objection and we confirm the design decision to remove the 'OAuth2' HTTP Authentication Scheme from draft-ietf-oauth-v2. Deadline for feedback: Feb, 10th 2011 Ciao Hannes ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto: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] Bearer token type and scheme name (deadline: 2/10)
This seems like an overly complex characterization - especially because you're including hypothetical choices such as schemes and sub-schemes that don't provide substantial benefits over the straightforward schemes we have now and would complicate implementations and people's understanding of the spec, and that don't have substantial support within the working group. Given that we're trying to bring the specs to working group last call, I would personally vote no to introducing any further any breaking changes. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options and have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' in it), as well as a matching HTTP authentication scheme if a new one is being defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining new methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged OAuth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatment. - built-in discovery using 401 challenge header for which schemes are supported (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribute used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, which will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusive (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (with or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting comparison of the various token types available. - Creates a very odd usage where the authorization server issues an access token of type 'OAuth2' which is non-descriptive and very confusing (since there are other token types). - Uses the name OAuth2 which stands for authorization in an authentication flow, continuing the confusion about what OAuth is (an authorization protocol). --- Please reply with your preference by 2/10. As always, please provide feedback on the options and analysis. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)
I realize that spec stability doesn't matter to you, but that doesn't mean that it's not important to others, including those actually using the specs. Call that a process argument if you want, but that doesn't make it any less pertinent - the technical argument is that breaking changes break implementations. I already did vote below -- for option 4. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, February 03, 2011 9:14 AM To: Mike Jones; OAuth WG Subject: RE: Bearer token type and scheme name (deadline: 2/10) All these suggestions were posted to the list by members (Marius, William, James, Justin). Nothing here is new. If you disagree with my analysis of any of the points, please raise your *technical* concerns. Trying to use process arguments is simply not going to fly. Pick an option, provide a new option (with full analysis), or don't vote. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Thursday, February 03, 2011 8:20 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Bearer token type and scheme name (deadline: 2/10) This seems like an overly complex characterization - especially because you're including hypothetical choices such as schemes and sub-schemes that don't provide substantial benefits over the straightforward schemes we have now and would complicate implementations and people's understanding of the spec, and that don't have substantial support within the working group. Given that we're trying to bring the specs to working group last call, I would personally vote no to introducing any further any breaking changes. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options and have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' in it), as well as a matching HTTP authentication scheme if a new one is being defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining new methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged OAuth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatment. - built-in discovery using 401 challenge header for which schemes are supported (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribute used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, which will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusive (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (with or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting comparison of the various token types available. - Creates a very odd usage where the authorization server issues an access token of type 'OAuth2' which is non-descriptive and very confusing (since there are other token types). - Uses the name OAuth2 which stands for authorization in an authentication flow, continuing the confusion about what OAuth is (an authorization protocol). --- Please reply with your preference by 2/10. As always, please provide feedback on the options and analysis. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02
The argument in favor of OAuth2 is a consistency argument. Just as this parameter was called WRAP in the WRAP spec and called OAuth in the OAuth specs through draft 10 until it was moved to the OAuth2 bearer token spec, it should logically be called OAuth2 to remain consistent with the precursor specifications. Also, since the use of bearer tokens is the primary OAuth2 use case (it was the motivating use case for WRAP, which was the reason for a second version of OAuth in the first place), it makes sense for this primary use case bear the primary specification name. I'm not religious about this (I already asked for working group on this topic a while ago and received very little), but absent a clear working group consensus to change the name, as editor, I believe that it's my job to not introduce breaking changes at this point in the specification development cycle. Cheers, -- Mike From: William Mills [mailto:wmi...@yahoo-inc.com] Sent: Friday, January 28, 2011 2:54 PM To: Mike Jones; oauth@ietf.org Subject: RE: OAuth 2.0 Bearer Token Specification draft -02 I'd like to add my objection to using OAuth2 as the scheme name for the access token. It's confusing in my opinion. I would much prefer (in my own order of preference): oauth_bearer, oauth2_bearer, or bearer. I think including OAuth in the name makes sense because it is defined in that context, but we've already talked about other possible token types. Is there any argument in favor of simply using OAuth2 that offsets the possible confusion and muddiness? -bill From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, January 28, 2011 1:36 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 I've published draft 02 of the bearer token specification. This incorporates consensus feedback received to date. It contains no normative changes relative to draft 01. Your feedback is solicited. Specific changes were: * Changed terminology from token reuse to token capture and replay. * Removed sentence Encrypting the token contents is another alternative from the security considerations since it was redundant and potentially confusing. * Corrected some references to resource server to be authorization server in the security considerations. * Generalized security considerations language about obtaining consent of the resource owner. * Broadened scope of security considerations description for recommendation Don't pass bearer tokens in page URLs. * Removed unused reference to OAuth 1.0. * Updated reference to framework specification and updated David Recordon's e-mail address. * Removed security considerations text on authenticating clients. * Registered the OAuth2 OAuth access token type and oauth_token parameter. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available) This version is explicitly not ready for working group last call, as changes may need to be made due to the open issues in the framework spec about the removal of the Client Assertion Credentials and OAuth2 HTTP Authentication Scheme. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Update required for bearer token spec
Your request below is ambiguous. Please provide the precise new text you're requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update the draft to comply with -12 registration guidelines and requirements asap. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Update required for bearer token spec
Once approved, the existing names will be registered, hence no changes are needed to the bearer token draft to comply with these requirements. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, January 27, 2011 2:36 PM To: Mike Jones Cc: OAuth WG Subject: RE: Update required for bearer token spec -12 section 8.1 and 10.1. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Thursday, January 27, 2011 2:10 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Your request below is ambiguous. Please provide the precise new text you're requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update the draft to comply with -12 registration guidelines and requirements asap. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Bear token scheme name
To the extent that the OAuth2 protocols are intended to provide an end-to-end solution, the more consistency the better, hence the OAuth2 name. Since the same feature used the OAuth name in draft 10 (which you authored), I find it hard to take seriously your objections to the OAuth2 name in the bearer token spec, when the description of the feature is exactly the same (and which you actually wrote). -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, January 25, 2011 9:59 PM To: Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name Simply because authentication is not what OAuth is about. OAuth is an authorization protocol for issuing access tokens. Access tokens can have different properties and therefore need different schemes. I was the first to suggest a scheme with sub-schemes but that idea was strongly rejected (over a year ago). Since then I came to the same conclusion that the proper way is to define separate authentication schemes. It is also how most HTTP authentication framework operate. One benefit to this approach is that HTTP authentication already covers the discovery of which schemes are supported by the resource server, as well as token schemes can be used independently from OAuth, something the 2-legged OAuth 1.0 has shown has great value. Also, it keeps the protocol modular which enable providers to tailor it to their security needs. OAuth 2.0 is authentication agnostic and must remain so. It is an authorization protocol and as such has no business defining authentication mechanisms. For this reason, I object to using the OAuth2 scheme name with the bearer token scheme. It's a trademark issue. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marius Scurtescu Sent: Tuesday, January 25, 2011 6:26 PM To: Mike Jones Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones michael.jo...@microsoft.com wrote: I'd like a sense from the working group whether others want this change, and if so, what the name should be changed to. Probably this was debated, but I will ask again. Why can't we use OAuth2 as the scheme in all cases and require a token_type name/value pair? Is it wise to dump lots of new schemes in a name space we do not control? Marius ___ 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] JSON Web Token Java implementation
Very cool! -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of axel.nenn...@telekom.de Sent: Thursday, January 20, 2011 9:39 AM To: oauth@ietf.org Subject: [OAUTH-WG] JSON Web Token Java implementation My java code for implementing the new JSON Web Token draft-01 http://self-issued.info/docs/draft-jones-json-web-token-01.html is ready and commited to the openinfocard source code repository. JUNIT tests are here: https://code.google.com/p/openinfocard/source/browse/trunk/testsrc/org/x mldap/json/WebTokenTest.java The JUNIT test verify all examples from the draft-01. The implementation is here: https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmlda p/json/WebToken.java The code supports all algorithms and all size variants. HS256, HS384, HS512 : HMAC with sha256, sha384, sha512 RS256, RS384, RS512 : RSA with sha256, sha384, sha512 ES256, ES384, ES512 : ECDSA 256, 384, 521 (sic) with sha256, sha384, sha512 Cheers Axel ___ 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] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations
Having thought about it, I'm willing to remove the text below. Are there any other sections of the bearer token security considerations that you believe belong in the framework spec rather than the bearer token spec, or that don't belong at all? Thanks again, -- Mike From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, January 17, 2011 6:10 AM To: Mike Jones Cc: oauth Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations That text still seems more restrictive than what is in the framework specification. And it's probably unnecessary - to the point James made previously, any mention of the AS (beyond specifying the token_type) in a using a token specification should probably be avoided unless there is a very specific reason for including it. In general, the AS is involved when getting a token and the RS is involved when using a token. On Fri, Jan 14, 2011 at 6:40 PM, Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: Thanks for your input, Brian. I accepted these suggestions for draft -02. The referenced text now reads: Furthermore, the authorization server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the authorization server. The authorization server MUST also obtain the consent of the resource owner prior to providing a token to the client. I'll leave it up to Eran how much of this security considerations text to incorporate into the framework specification. -- Mike -Original Message- From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, December 09, 2010 1:38 PM To: oauth Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however, a couple things jumped out at me in areas that hadn't received much attention yet so I wanted to raise the questions on a separate thread. Near the end of section 3.2. Threat Mitigation, it says: Furthermore, the resource server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the resource server. Was the intent here to say authorization server rather than resource server? The resource server doesn't hand out tokens. Also, aren't there legitimate cases where the client isn't authenticated (anonymous or other cases where the client can't keep secrets)? Then it says: The authorization server MUST also receive a confirmation (the consent of the resource owner) prior to providing a token to the client. Does this allow for implicit consent? On my first read of it, I interpret this as potentially being more restrictive than what is in draft-ietf-oauth-v2-11 ___ OAuth mailing list OAuth@ietf.orgmailto: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] Bear token scheme name
I'd like a sense from the working group whether others want this change, and if so, what the name should be changed to. Thanks, -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Tuesday, January 18, 2011 11:06 PM To: Mike Jones Cc: OAuth WG Subject: Bear token scheme name Please change the draft to use a different scheme name than 'OAuth2' for the bearer token authentication scheme. Given the unstable state of the header (still is), it is perfectly fine to make this change. The list includes a detailed discussion about this. I am strongly opposed to giving the bearer token scheme a name giving it the appearance of the preferred or canonical token authentication method. I don't care what you change it to as long as it is not 'OAuth2' or 'OAuth'. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme
You wrote: Those who still want to advocate for it need to show not only consensus for keeping it This seems backwards to me. In particular, given the industry consensus that draft 10 was nearly done, the onus to establish consensus should fall on advocates of any proposals to remove features - not the other way around - particularly so when the features are implemented and in use. It's also pertinent that the implementation call went out for draft 11. Therefore, we should not be removing draft 11 features without decisive consensus for doing so. -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Tuesday, January 18, 2011 10:13 AM To: Mike Jones Cc: oauth@ietf.org Subject: RE: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme I agree that at this stage, we should do our best to avoid making breaking changes. But first, we need to establish what is going to break and how. The argument that removing the client assertion credentials affects interoperability or breaks implementations is without merit. As currently specified, the text is useless for any level of interoperability or implementation. This means you must have your own specification providing the actual meaningful information. At most, removing this section will require you to register the two parameter names it defines. Since neither is being used for a new purpose, removing this section creates no conflict. Hopefully, your parameter registration will provide more meaningful information about them than currently offered. If you are going to object to my conclusions, you first need to show where my arguments are wrong. I have seen nothing to contradict a single point I have made about both issues. This goes for both the client assertion credentials and OAuth2 scheme. Just in case, I'll repeat my points. Client assertion credentials: 1. The mechanism is under specified, especially in its handling of the client_id identifier (when used to obtain end-user authorization). 2. It does not contain any implementation details to accomplish any level of interoperability or functionality. 3. The section is a confused mix of security considerations sprinkled with normative language. 4. Those who still want to advocate for it need to show not only consensus for keeping it, but also active community support for deploying it. Deployment, of course, will also require showing progress on public specifications profiling the mechanism into a useful interoperable feature. Which open source library supports or plan to support it? 'OAuth2' WWW-Authenticate header: 1. Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope. 2. The WWW-Authenticate header has absolutely no value, interoperability-wise or otherwise. Discovery was rules to be beyond the scope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspecified client flow is confusing at best. 3. OAuth is agnostic to token authentication, and we already have three discrete token type proposals - all with active deployment plans in the coming months. 4. HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery can be added to HTTP authentication schemes as attributes, but makes no sense as a scheme of its own. The issues we are having with 'realm' is one of the examples showing that we are abusing the header. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Tuesday, January 18, 2011 9:36 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Having spoken to a number of people implementing the spec here, I've encountered strong objections to removing Client Assertion Credentials and the OAuth2 HTTP Authentication Scheme. It's also not clear to me why we would make substantial breaking changes to the specification when it is essentially ready for approval. I've summarized the reasons I believe we should keep these two features below. Client Assertion Credentials: Many of the scenarios we care about require this capability. They were key motivators for the Assertion Profile in WRAP (see § 5.2), have been part of OAuth 2 for quite a while, and we have running code that requires this support. For example, the Azure Access Control Service is a cloud Authorization server that supports several protocols, including parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We are happy to update our implementation
Re: [OAUTH-WG] Preparation for draft-ietf-oauth-v2-bearer-02
FYI, people can have a look at the current draft in the SubVersion repository if they're interested: http://svn.openid.net/repos/specifications/oauth/2.0/. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, January 14, 2011 5:40 PM To: oauth@ietf.org Subject: [OAUTH-WG] Preparation for draft-ietf-oauth-v2-bearer-02 I'd like to publish draft -02 of the bearer token specification next week. As a heads-up, I have made no normative changes to date. Most changes are in the security considerations section, which reflects the nature of the majority of feedback received. I'm about to send replies to a number of messages providing feedback. If I did not respond to your feedback or you disagree with my response, feel free to bring it to my attention. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on OAuth 2.0 Bearer Token specification draft -01
Thanks for your comments, Torsten. I've removed the sentence Encrypting the token contents is another alternative ... from draft -02 since it was redundant and potentially confusing. I deleted the word rare, since I agree with your conclusion. The reuse phrase now reads: To deal with token capture and replay, ... -- Mike -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Monday, January 10, 2011 12:04 PM To: Mike Jones; OAuth WG Cc: Hannes Tschofenig Subject: Comments on OAuth 2.0 Bearer Token specification draft -01 Hi Mike, I've got some more comments on § 3.2 of your I-D. paragraph 4: Encrypting the token contents is another alternative ... How does token content encryption prevent the disclosure and abuse of a token? paragraph 5: For those rare cases where the client is prevented from observing the contents of the token, token encryption has to be applied in addition to the usage of TLS protection How did you come to the conclusion these are _rare_ cases? The token is used to pass data between authorization server and resource server via the client as a intermediary. A self-contained token may contain a lot of user-specific or service provider internal information neither end-user nor authorization server would like to disclose to the client. Therefore, here at Deutsche Telekom we encrypt token contents per default. paragraph 6: To deal with token reuse, ... The reuse appears a bit misleading, isn't this paragraph talking about capture/tap and replay attacks? regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations
Thanks for your input, Brian. I accepted these suggestions for draft -02. The referenced text now reads: Furthermore, the authorization server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the authorization server. The authorization server MUST also obtain the consent of the resource owner prior to providing a token to the client. I'll leave it up to Eran how much of this security considerations text to incorporate into the framework specification. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, December 09, 2010 1:38 PM To: oauth Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however, a couple things jumped out at me in areas that hadn't received much attention yet so I wanted to raise the questions on a separate thread. Near the end of section 3.2. Threat Mitigation, it says: Furthermore, the resource server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the resource server. Was the intent here to say authorization server rather than resource server? The resource server doesn't hand out tokens. Also, aren't there legitimate cases where the client isn't authenticated (anonymous or other cases where the client can't keep secrets)? Then it says: The authorization server MUST also receive a confirmation (the consent of the resource owner) prior to providing a token to the client. Does this allow for implicit consent? On my first read of it, I interpret this as potentially being more restrictive than what is in draft-ietf-oauth-v2-11 ___ 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] OAuth 2.0 Bearer Token specification draft -01
Thanks James, I wanted to provide feedback on your comments. You wrote token_type should be an HTTP authentication scheme name. I disagree with this. The token_type is intended be used to identify the type of the token, meaning that it is likely to take on values like: SWT JWT urn:oasis:names:tc:SAML:1.0:assertion urn:oasis:names:tc:SAML:2.0:assertion http://service.example.com/oauth/custom_token_format You wrote the bearer spec (draft-ietf-oauth-v2-bearer) must not use the 'OAuth2' scheme name. It needs its own scheme name, eg 'BEARER'. I also disagree with this. For the same reason that it was appropriate for draft 11 to use the scheme name OAuth, it is appropriate for the bearer token spec to use the scheme name OAuth2 for the corresponding text. In the interest of completing the specification, I'm not prone to introduce a breaking change by modifying the scheme name at this time. Working group feedback is welcome. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Thursday, December 02, 2010 3:42 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 token_type should be an HTTP authentication scheme name (eg BASIC or BEARER or MAC...). The core spec (draft-ietf-oauth-v2) should explicitly state this rule. From the token_type, the client app knows which auth scheme to use. [renaming the parameter from token_type to scheme would help.] Defining token_type to be an HTTP authentication scheme name effectively defines how OAuth2 can deliver credentials for auth schemes that are independent of OAuth2, eg schemes specified before OAuth2 existed. It eliminates the need for additional specs just to provide a link from OAuth2 to every authentication mechanism. Some auth mechanisms for which OAuth2 could deliver credentials are not actually HTTP authentication schemes. Eg OAuth2 delivering an id/secret to use in TLS-PSK (pre-shared key). For that you will need a small additional spec to define a token_type value -- ie define a pseudo-HTTP-auth-scheme-name. P.S. Related to this, the bearer spec (draft-ietf-oauth-v2-bearer) must not use the OAuth2 scheme name. It needs its own scheme name, eg BEARER. -- James Manger ___ 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] Specification organization (Endpoints vs. Flows) - Vote by 1/17
+1 for option 2 - flow based organization From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, January 11, 2011 11:19 PM To: OAuth WG Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 (Vote at the end, please read) Background Between draft -00 and -05 the document used a flow-based organization. This was changed to an endpoint-based organization in draft -06. I have received requests to go back to the flow-based organization, and with -12, have been planning to do that. It is important to note that -12 is not meant to include any change in normative language and that -11 code would remain unchanged under -12. This is purely editorial. Part of that effort included reviewing the various flows in -05. The flow categories and definitions have always been a source of confusion. Some target specific client architecture (user-agent, web server, device), some are abstractions for future extensibility (assertion), and some are useful features that can apply to a wide range of clients (client credentials, username and password). We also have the odd anti-profile of the native application flow, which in practice is a half-baked guide to navigating the entire range of flows. In practice we have a few ways to get an access token which can be categorized in multiple ways: 1. How authorization is obtained? a. Redirection-based - user-agent, web-server b. Direct credentials - client credentials, username and password, assertion 2. Is the client authenticated? a. Yes - web-server, client credentials, username and password, assertion (based on type) b. No - user-agent, assertion (based on type) In the past we had another (broken) organization of User delegation, User credentials, and Autonomous. Analysis After studying the document and breaking it apart (in my editor) I came to a few conclusions (which you are invited to disprove): 1. Flow names must be consistent and based on the key differentiator of each flow. I believe the ability of the client to authenticate is the most significant aspect of each flow. I agree that ease of deployment and performance are important, but this is a security protocol and the security considerations should be the primary attribute used to select flows. 2. The endpoint-based organization turned a few discrete flows into a single protocol. This protocol should be profiled based on some key client characteristics (such as redirection and ability of the client to authenticate). The main objective of the profiles would be to provide a security-focused description. 3. The hybrid flow, combining the user-agent and web-server into a code-and-token solution is a distinct profile with its own unique security properties. While its implementation details are important for efficiency, the main differentiator is the client dual nature of being able to maintain secret credentials in some parts, but not in others. It produces two access tokens using a single authorization and client identifier. 4. The document must not repeat the mistake of 1.0, focusing on a single client type at the expense of others. OAuth 1.0 focused on the web-server flow and treated everything else as second class citizens. -05 treated native applications similarly, giving much more attentions to the web-server and user-agent clients, even when their underlying flows could have been written primarily for some native applications. The issue is mostly in naming the profiles after one typical client type instead of their key property. Options I came up with two options for finalizing the specification's structure (please feel to suggest additional ideas): 1. Keep the document's endpoint-based organization (-11) and add a Client Profiles section describing specific client implementations based on the protocol. These profiles will not include wire information (parameters, values, etc.), but will include security-minded normative language (MUST register, SHOULD match redirection URI, etc.). 2. Switch back to flow-based organization and include 5 flows in 2 groups (note the new names), plus extensions: a. Redirection-based i. Authenticated client (web server) ii. Unauthenticated client (user-agent) iii. Mix authentication client (code-and-token) b. Direct Credentials i. Username and password ii. Client credentials c. Extensions Option 1 -Easier for server developers because it will include all the wire-protocol details for each endpoint in one place (single list of parameters, error codes, etc.). -Shorter,
[OAUTH-WG] Feedback on normative issues in OAuth2 draft 11 from implementers of draft 10
Our implementers of draft 10 have raised the following issues with draft 11. Please address them before publishing a draft 12. I'll send editorial feedback in a separate message. 6.2 etc.: Specification MUST permit parameter extensibility There will be uses of OAuth2 where additional parameters need to be passed in the messages. While some messages implicitly permit extensibility through language like 4.1's the client constructs the request URI by adding the following parameters to the end-user authorization endpoint URI query component others do not. In particular, the BNF for the WWW-Authenticate Response in 6.2 appears to permit only a fixed set of parameters (scope, error, error-desc, error-uri, token). This must be addressed. Please add language to 6.2 that explicitly allows for other arguments to be added to the response and mandates that they be ignored if not recognized. Also, define an IANA registration process for registering new parameter values for all messages. In particular, even if the following request to add an optional resource parameter is not adopted, it must be possible to add one to all relevant messages so that a resource parameter can be added as a legal extension. 4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1: Scope parameter should be paired with complimentary resource parameter It is desirable to be able to have a single service protecting multiple resources. To achieve that, there needs to be a parameter specifying what the desired resource being accessed is. This is different than scope. At least as we're using it, scope would be a space-separated list of kinds of access requested. For instance you might be requesting read access to someone's calendar free/busy times and the right to post new calendar requests. Those would be scope statements and would use URIs specifying those rights. Therefore, we request that an additional optional resource parameter be added to the specification in the same places that scope appears. Resource would be the URI (probably a URL) of the resource being protected by the service. 5.1.3 etc.: The name client_credentials is confusing The name client_credentials does not refer to the same concept as the uses of the term Client Credentials in 1.4.3, 3, 5.1.3, and other locations in the document. It would be far better to rename this parameter none or implicit, to indicate that no explicit credentials are being passed in the protocol. It might also clarify this concept if you added an example. 6.2: Token_type needed for WWW-Authenticate Response An optional token_type parameter should be added to the WWW-Authenticate Response. This, paired with adding this parameter to the authenticated token requests in the bearer token spec, will complete the ability to communicate token type information for all legs of the protocol. TBDs And of course, we're very interested in seeing the write-ups for adding token types in 6.1 and new credential types in 7.1 Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JSON Web Token (JWT) draft -01
Not that I'm aware of at present, but I expect that to change shortly. -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Monday, January 10, 2011 1:04 AM To: Mike Jones Cc: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] JSON Web Token (JWT) draft -01 I was wondering whether there is some running code available as well? On Jan 5, 2011, at 4:31 AM, Mike Jones wrote: Draft -01 of the JSON Web Token (JWT) specification is now available. This version incorporates the consensus decisions reached at the Internet Identity Workshop. The remaining open issues and to-do items are documented in Section 12. As a reminder, the suggested pronunciation of JWT is the same as the English word jot. The draft is available at these locations: - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml - http://self-issued.info/docs/draft-jones-json-web-token-01.html - http://self-issued.info/docs/draft-jones-json-web-token-01.txt - http://self-issued.info/docs/draft-jones-json-web-token-01.xml - http://self-issued.info/docs/draft-jones-json-web-token.html (will point to new versions as they are posted) - http://self-issued.info/docs/draft-jones-json-web-token.txt (will point to new versions as they are posted) - http://self-issued.info/docs/draft-jones-json-web-token.xml (will point to new versions as they are posted) - http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Subversion repository, with html, txt, and html versions available) The decisions reached at IIW are documented here: - JSON Token Spec Results at IIW: http://self-issued.info/?p=361 - JSON Token Encryption Spec Results at IIW: http://self-issued.info/?p=378 - JSON Token Naming Spec Results at IIW: http://self-issued.info/?p=386 - JSON Public Key Spec Results at IIW: http://self-issued.info/?p=390 This announcement is also posted here: - http://self-issued.info/?p=446 Thanks to all who provided the input that led to this draft! Feedback is highly welcome. -- 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
Re: [OAUTH-WG] BOF about JSON Cryptographic Syntax and Processing
Please put me in touch with the others who are working on JSON signing and encryption so we can coordinate our efforts. Thanks! -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, January 10, 2011 1:19 AM To: oauth@ietf.org Subject: [OAUTH-WG] BOF about JSON Cryptographic Syntax and Processing Hi all, Mike had posted a mail about version -01 of the JSON Web Token document: http://www.ietf.org/mail-archive/web/oauth/current/msg04912.html The usage of JSON and security applied to it became crucial to the work in OAuth. As we start our re-chartering it would be logical to add it to our charter as well. While this is my first choice there may be resistance in doing so since we expand our charter quite a bit. As a backup, I would therefore like to propose to (a) try to include it in the OAuth re-chartering and (b) at the same time request a BOF at the next IETF meeting. Here is the charter writeup for the BOF: http://ietherpad.com/ce7Vc6AAay Interestingly enough there are others in the IETF who also want to standardize JSON signing and encryption (but for other use cases). I am in contact with them and will try to combine our effort to reach the goal faster. Your comments on the charter writeup are appreciated. Ciao Hannes ___ 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] Error codes registry
I believe the draft should continue to say that the error code space MAY be extended. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, January 10, 2011 11:54 AM To: OAuth WG Subject: [OAUTH-WG] Error codes registry I am questioning the value of an explicit extension mechanism (and registry) for error codes. It seems like an overkill since name collisions are not likely or as problematic (given new error codes imply some other extension involved as well). I am going to drop notes about error code extensibility. If you have an objection, please propose an extension mechanism. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] TLS is needed for redirecting back to the client
You can read about the Artifact Binding at https://bitbucket.org/openid/ab/wiki/Home. The latest draft is at https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_0.html. Nat Sakimura is actively updating the specification as we speak, incorporating some of the ideas from OpenID Connect. The merger of the specs that Nat is working on is sometimes referred to as OpenID Artifact Binding/Connect or OpenID ABC for short. FYI, specification will be using JSON Web Tokens (JWTs). -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Francisco Corella Sent: Tuesday, January 04, 2011 5:04 PM To: Marius Scurtescu; Justin Richer Cc: oauth@ietf.org; Karen P. Lewison Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client --- On Tue, 1/4/11, Justin Richer jric...@mitre.orgmailto:jric...@mitre.org wrote: We need a protocol that does both authentication and authorization. We can take OAuth and adapt it for authentication, or take OpenID and adapt it for authorization, or combine OpenID and OAuth (great solution for people who love complexity) or... take the best ideas from OpenID and OAuth and incorporate them into a new protocol that's designed from the start for both authentication and authorization. That's one of my motivations for proposing PKAuth. Are you aware of OpenIDConnect? http://openidconnect.com/ And also the latest drafts of OpenID Artifact Binding: http://wiki.openid.net/w/page/12995134/Artifact-Binding I'm not familiar with that, and I haven't been able to find a draft at the site. Francisco ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] JSON Web Token (JWT) draft -01
Draft -01 of the JSON Web Token (JWT) specificationhttp://self-issued.info/docs/draft-jones-json-web-token.html is now available. This version incorporates the consensus decisions reached at the Internet Identity Workshop. The remaining open issues and to-do items are documented in Section 12http://self-issued.info/docs/draft-jones-json-web-token-01.html#TBD. As a reminder, the suggested pronunciation of JWT is the same as the English word jot. The draft is available at these locations: - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml - http://self-issued.info/docs/draft-jones-json-web-token-01.html - http://self-issued.info/docs/draft-jones-json-web-token-01.txt - http://self-issued.info/docs/draft-jones-json-web-token-01.xml - http://self-issued.info/docs/draft-jones-json-web-token.html (will point to new versions as they are posted) - http://self-issued.info/docs/draft-jones-json-web-token.txt (will point to new versions as they are posted) - http://self-issued.info/docs/draft-jones-json-web-token.xml (will point to new versions as they are posted) - http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Subversion repository, with html, txt, and html versions available) The decisions reached at IIW are documented here: - JSON Token Spec Results at IIW: http://self-issued.info/?p=361 - JSON Token Encryption Spec Results at IIW: http://self-issued.info/?p=378 - JSON Token Naming Spec Results at IIW: http://self-issued.info/?p=386 - JSON Public Key Spec Results at IIW: http://self-issued.info/?p=390 This announcement is also posted here: - http://self-issued.info/?p=446 Thanks to all who provided the input that led to this draft! Feedback is highly welcome. -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
