Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
I'd like to propose the following changes and additions, derived largely from Bill and James suggestions, to draft-ietf-oauth-v2-bearer-17. These changes have no normative impact and only aim to add additional clarity and explanation the workings and implications of the current spec. I'm definitely open to changes or improvements in the wording here (not my strong suit by any means) but I think it's important that these general ideas be conveyed in the draft. == Insert the following text at the beginning of §2: To make a protected resource request, the client must be in possession of a valid bearer token. Typically a bearer token is returned to the client as part of an access token response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. When the token_type parameter of the access token response is Bearer, the string value of the access_token parameter becomes the bearer access token used to make protected resource requests. == Change the value of the token in the Authorization header example to this: Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b == Insert the following text before the last paragraph of §2.1: Note that the name b64token does not imply base64 encoding but rather is the name for an ABNF syntax definition from HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]. Because of its use, the access_token string value from an access token response MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Thanks, Brian On Tue, Mar 6, 2012 at 11:45 AM, William Mills wmi...@yahoo-inc.com wrote: Yeah, something as simple as, Note that the name 'b64token' does not imply base64 encoding, see the definition in [[INSERT REFERENCE HERE]]. would do it. -bill From: Brian Campbell bcampb...@pingidentity.com To: Mike Jones michael.jo...@microsoft.com Cc: oauth oauth@ietf.org Sent: Tuesday, March 6, 2012 8:23 AM Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones michael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the access_token member of an access token response is the bearer token. The access_token string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the Bearer OAuth access token type is defined. Also, does the use of b64token implicitly limit the allowed characters that an AS can use to construct a bearer access token? Yes. * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1 **
[OAUTH-WG] Status of OAUTH re-charter discussion
What is the status of the OAUTH WG re-charter efforts? The last thread was back in October. Will the re-charter be on the IETF-Paris agenda? (or will it be pushed out to the July 2012 IETF). Thanks. /thomas/ __ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Status of OAUTH re-charter discussion
I was planning to kick of a discussion next week with a strawman proposal for a new charter text. Ciao Hannes On Mar 7, 2012, at 8:36 PM, Thomas Hardjono wrote: What is the status of the OAUTH WG re-charter efforts? The last thread was back in October. Will the re-charter be on the IETF-Paris agenda? (or will it be pushed out to the July 2012 IETF). Thanks. /thomas/ __ ___ 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] question about the b64token syntax in draft-ietf-oauth-v2-bearer
works for me. P.S. Please start using the http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest for new requests like product and feature reviews. From: Brian Campbell bcampb...@pingidentity.com To: William Mills wmi...@yahoo-inc.com Cc: Mike Jones michael.jo...@microsoft.com; oauth oauth@ietf.org Sent: Wednesday, March 7, 2012 9:16 AM Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer I'd like to propose the following changes and additions, derived largely from Bill and James suggestions, to draft-ietf-oauth-v2-bearer-17. These changes have no normative impact and only aim to add additional clarity and explanation the workings and implications of the current spec. I'm definitely open to changes or improvements in the wording here (not my strong suit by any means) but I think it's important that these general ideas be conveyed in the draft. == Insert the following text at the beginning of §2: To make a protected resource request, the client must be in possession of a valid bearer token. Typically a bearer token is returned to the client as part of an access token response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. When the token_type parameter of the access token response is Bearer, the string value of the access_token parameter becomes the bearer access token used to make protected resource requests. == Change the value of the token in the Authorization header example to this: Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b == Insert the following text before the last paragraph of §2.1: Note that the name b64token does not imply base64 encoding but rather is the name for an ABNF syntax definition from HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]. Because of its use, the access_token string value from an access token response MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Thanks, Brian On Tue, Mar 6, 2012 at 11:45 AM, William Mills wmi...@yahoo-inc.com wrote: Yeah, something as simple as, Note that the name 'b64token' does not imply base64 encoding, see the definition in [[INSERT REFERENCE HERE]]. would do it. -bill From: Brian Campbell bcampb...@pingidentity.com To: Mike Jones michael.jo...@microsoft.com Cc: oauth oauth@ietf.org Sent: Tuesday, March 6, 2012 8:23 AM Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones michael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the access_token member of an access token
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Makes sense to me, except that I think the token_type value is typically lowercase bearer, though it's defined to be case insensitive in Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of this field for the Bearer token type ever got defined anywhere. Section 7.1 references the bearer spec as defining the value of the token_type parameter, and passes its example as if by reference. Would be worthwhile giving an example of a token endpoint response, such as what's found in OAuth-v2-23 section 5.1. -- Justin On 03/07/2012 12:16 PM, Brian Campbell wrote: I'd like to propose the following changes and additions, derived largely from Bill and James suggestions, to draft-ietf-oauth-v2-bearer-17. These changes have no normative impact and only aim to add additional clarity and explanation the workings and implications of the current spec. I'm definitely open to changes or improvements in the wording here (not my strong suit by any means) but I think it's important that these general ideas be conveyed in the draft. == Insert the following text at the beginning of §2: To make a protected resource request, the client must be in possession of a valid bearer token. Typically a bearer token is returned to the client as part of an access token response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. When the token_type parameter of the access token response is Bearer, the string value of the access_token parameter becomes the bearer access token used to make protected resource requests. == Change the value of the token in the Authorization header example to this: Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b == Insert the following text before the last paragraph of §2.1: Note that the name b64token does not imply base64 encoding but rather is the name for an ABNF syntax definition from HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]. Because of its use, the access_token string value from an access token response MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Thanks, Brian On Tue, Mar 6, 2012 at 11:45 AM, William Millswmi...@yahoo-inc.com wrote: Yeah, something as simple as, Note that the name 'b64token' does not imply base64 encoding, see the definition in [[INSERT REFERENCE HERE]]. would do it. -bill From: Brian Campbellbcampb...@pingidentity.com To: Mike Jonesmichael.jo...@microsoft.com Cc: oauthoauth@ietf.org Sent: Tuesday, March 6, 2012 8:23 AM Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Thanks Mike, I think changing the example would be helpful. However I think that including some text along the lines of what James suggested would also be very valuable. I agree that the connection between OAuth and Bearer could and should be made more explicit. And that the implications of the b64token syntax, particularly on what AS can use to construct ATs, could/should be made more clear. I can propose some specific text (building on James') if others in the WG agree? On Mon, Mar 5, 2012 at 5:32 PM, Mike Jonesmichael.jo...@microsoft.com wrote: I'm fine with changing the example to make it clearer that b64token allows a wider range of characters than just those legal for base64 and base64url encodings of data values. I'll add it to my to-do list for any additional edits for the Bearer spec. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Monday, March 05, 2012 3:33 PM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer Brian, On casual reading of The OAuth 2.0 Authorization Protocol: Bearer Tokens* I've encountered several people (including myself) who have made the assumption that the name b64token implies that some kind of base64 encoding/decoding on the access token is taking place between the client and RS. Digging a bit deeper in to HTTP/1.1, part 7: Authentication**, however, I see that b64token is just an ABNF syntax definition allowing for characters typically used in base64, base64url, etc.. So the b64token doesn't define any encoding or decoding but rather just defines what characters can be used in the part of the Authorization header that will contain the access token. Do I read this correctly? Yes. If so, I feel like some additional clarifying text in the Bearer Tokens draft might help avoid what is (based on my small sample) a common point of misunderstanding. Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing: Authorization: Bearer vF9dft4qmT to Authorization: Bearer vF9.dft4.qmT The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Yeah, it is case insensitive. I just went with the upper case B
because that's how it was written in §5.1.1 of
draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
Either one would be fine.
I agree that an example response from the token endpoint would be
worthwhile. Something like the following might help tie together with
the Authorization header example (proposed earlier). It could maybe be
worked in near the top of §2?
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
access_token:vF_9.5dCf-t4.qbcmT_k1b,
token_type:example,
expires_in:3600,
refresh_token:stGzv3xOdkF0X35Qp2TlKWIA,
}
It'd probably make sense to change the examples in the body §2.2***
and query §2.3 to use the same access token value too.
* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3
On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer jric...@mitre.org wrote:
Makes sense to me, except that I think the token_type value is typically
lowercase bearer, though it's defined to be case insensitive in
Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of
this field for the Bearer token type ever got defined anywhere. Section 7.1
references the bearer spec as defining the value of the token_type
parameter, and passes its example as if by reference. Would be worthwhile
giving an example of a token endpoint response, such as what's found in
OAuth-v2-23 section 5.1.
-- Justin
On 03/07/2012 12:16 PM, Brian Campbell wrote:
I'd like to propose the following changes and additions, derived
largely from Bill and James suggestions, to
draft-ietf-oauth-v2-bearer-17. These changes have no normative impact
and only aim to add additional clarity and explanation the workings
and implications of the current spec. I'm definitely open to changes
or improvements in the wording here (not my strong suit by any means)
but I think it's important that these general ideas be conveyed in the
draft.
== Insert the following text at the beginning of §2:
To make a protected resource request, the client must be in possession
of a valid bearer token. Typically a bearer token is returned to the
client as part of an access token response as defined in OAuth 2.0
[I-D.ietf-oauth-v2]. When the token_type parameter of the access
token response is Bearer, the string value of the access_token
parameter becomes the bearer access token used to make protected
resource requests.
== Change the value of the token in the Authorization header example to
this:
Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b
== Insert the following text before the last paragraph of §2.1:
Note that the name b64token does not imply base64 encoding but rather
is the name for an ABNF syntax definition from HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. Because of its use, the access_token
string value from an access token response MUST match the b64token
ABNF so it can be used with the Bearer HTTP scheme.
Thanks,
Brian
On Tue, Mar 6, 2012 at 11:45 AM, William Millswmi...@yahoo-inc.com
wrote:
Yeah, something as simple as, Note that the name 'b64token' does not
imply
base64 encoding, see the definition in [[INSERT REFERENCE HERE]]. would
do
it.
-bill
From: Brian Campbellbcampb...@pingidentity.com
To: Mike Jonesmichael.jo...@microsoft.com
Cc: oauthoauth@ietf.org
Sent: Tuesday, March 6, 2012 8:23 AM
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer
Thanks Mike, I think changing the example would be helpful.
However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.
I can propose some specific text (building on James') if others in the WG
agree?
On Mon, Mar 5, 2012 at 5:32 PM, Mike Jonesmichael.jo...@microsoft.com
wrote:
I'm fine with changing the example to make it clearer that b64token
allows
a wider range of characters than just those legal for base64 and
base64url
encodings of data values.
I'll add it to my to-do list for any additional edits for the Bearer
spec.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of
Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question
Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
+1
On 3/7/12 4:08 PM, Brian Campbell wrote:
Yeah, it is case insensitive. I just went with the upper case B
because that's how it was written in §5.1.1 of
draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually
defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.
Either one would be fine.
I agree that an example response from the token endpoint would be
worthwhile. Something like the following might help tie together with
the Authorization header example (proposed earlier). It could maybe be
worked in near the top of §2?
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
access_token:vF_9.5dCf-t4.qbcmT_k1b,
token_type:example,
expires_in:3600,
refresh_token:stGzv3xOdkF0X35Qp2TlKWIA,
}
It'd probably make sense to change the examples in the body §2.2***
and query §2.3 to use the same access token value too.
* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1
** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1
*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3
On Wed, Mar 7, 2012 at 12:00 PM, Justin Richerjric...@mitre.org wrote:
Makes sense to me, except that I think the token_type value is typically
lowercase bearer, though it's defined to be case insensitive in
Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of
this field for the Bearer token type ever got defined anywhere. Section 7.1
references the bearer spec as defining the value of the token_type
parameter, and passes its example as if by reference. Would be worthwhile
giving an example of a token endpoint response, such as what's found in
OAuth-v2-23 section 5.1.
-- Justin
On 03/07/2012 12:16 PM, Brian Campbell wrote:
I'd like to propose the following changes and additions, derived
largely from Bill and James suggestions, to
draft-ietf-oauth-v2-bearer-17. These changes have no normative impact
and only aim to add additional clarity and explanation the workings
and implications of the current spec. I'm definitely open to changes
or improvements in the wording here (not my strong suit by any means)
but I think it's important that these general ideas be conveyed in the
draft.
==Insert the following text at the beginning of §2:
To make a protected resource request, the client must be in possession
of a valid bearer token. Typically a bearer token is returned to the
client as part of an access token response as defined in OAuth 2.0
[I-D.ietf-oauth-v2]. When the token_type parameter of the access
token response is Bearer, the string value of the access_token
parameter becomes the bearer access token used to make protected
resource requests.
==Change the value of the token in the Authorization header example to
this:
Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b
==Insert the following text before the last paragraph of §2.1:
Note that the name b64token does not imply base64 encoding but rather
is the name for an ABNF syntax definition from HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. Because of its use, the access_token
string value from an access token response MUST match the b64token
ABNF so it can be used with the Bearer HTTP scheme.
Thanks,
Brian
On Tue, Mar 6, 2012 at 11:45 AM, William Millswmi...@yahoo-inc.com
wrote:
Yeah, something as simple as, Note that the name 'b64token' does not
imply
base64 encoding, see the definition in [[INSERT REFERENCE HERE]]. would
do
it.
-bill
From: Brian Campbellbcampb...@pingidentity.com
To: Mike Jonesmichael.jo...@microsoft.com
Cc: oauthoauth@ietf.org
Sent: Tuesday, March 6, 2012 8:23 AM
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer
Thanks Mike, I think changing the example would be helpful.
However I think that including some text along the lines of what James
suggested would also be very valuable. I agree that the connection
between OAuth and Bearer could and should be made more explicit. And
that the implications of the b64token syntax, particularly on what AS
can use to construct ATs, could/should be made more clear.
I can propose some specific text (building on James') if others in the WG
agree?
On Mon, Mar 5, 2012 at 5:32 PM, Mike Jonesmichael.jo...@microsoft.com
wrote:
I'm fine with changing the example to make it clearer that b64token
allows
a wider range of characters than just those legal for base64 and
base64url
encodings of data values.
I'll add it to my to-do list for any additional edits for the Bearer
spec.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of
Manger, James H
Sent: Monday, March 05, 2012 3:33 PM
To: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] question about the
Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23
-Original Message- From: Henry S. Thompson [mailto:h...@inf.ed.ac.uk] Sent: Tuesday, February 14, 2012 9:07 AM 11 It seems at best old-fashioned that the designer of a new access token type, parameter, endpoint response type or extension error has no better tool available than Google to help him/her discover whether the name they have in mind is in use already. The same is true under the proposed approach for any developer trying to determine what they can use or must support. Is there some reason that mandated URI templates, after the fashion of http://www.iana.org/assignments/media-types/text/ are not mandated for the registries, e.g. http://www.iana.org/assignments/access-token-types/bearer ? If there is a good reason, please use it to at least explicitly acknowledge and justify the basis for failing to provide a way for users and developers to use the quot;follow your nosequot; strategy [1]. If there is no good reason, please include the appropriate language to require something along the lines suggested above. If you need a model, see [2]. I'm confused - is this a request to use a full URI for all extension values? I thought the purpose of a registry was to deconflict the short names, and that URIs could be used for anything else. No, I appreciate that you want to use registered short names in the protocol, that's just fine. My problem is that you have left users, developers etc. with no way to discover what shortnames have been registered short of a non- trivial and error-prone informal search effort. What I'm asking for is support for probe URI prefixes for each family of shortnames. So, just as today I use text/n3 as the media type for my Notation3 documents, I can check that this is a registered media type by attempting to retrieve http://www.iana.org/assignments/media-types/text/n3 and I can see all the registered text types by retrieving from http://www.iana.org/assignments/media-types/text likewise I ought to be able to check e.g. the bearer token type by attempting retrieval from (something along the lines of) http://www.iana.org/assignments/access-token-types/bearer and I should be able to see all the registered token types by retrieving from http://www.iana.org/assignments/access-token-types Hope this clarifies what I meant. Not sure I understand what you are asking for, but what would the IANA instruction include to support this? EH ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23
Henry says... No, I appreciate that you want to use registered short names in the protocol, that's just fine. My problem is that you have left users, developers etc. with no way to discover what shortnames have been registered short of a non- trivial and error-prone informal search effort. What I'm asking for is support for probe URI prefixes for each family of shortnames. So, just as today I use text/n3 as the media type for my Notation3 documents, I can check that this is a registered media type by attempting to retrieve http://www.iana.org/assignments/media-types/text/n3 and I can see all the registered text types by retrieving from http://www.iana.org/assignments/media-types/text likewise I ought to be able to check e.g. the bearer token type by attempting retrieval from (something along the lines of) http://www.iana.org/assignments/access-token-types/bearer and I should be able to see all the registered token types by retrieving from http://www.iana.org/assignments/access-token-types Hope this clarifies what I meant. Eran says... Not sure I understand what you are asking for, but what would the IANA instruction include to support this? Yeh, I'm not understanding this either. The spec establishes an access-token-type registry, and anyone will be able to look in that registry the same way they look in any other IANA registry, such as media-types. It looks like Henry is asking for this to use some sort of type/subtype mechanism, as media-types does, wherein when a new token type is registered, that registration or subsequent ones can create subtypes of that token type. But it's not clear that such a type/subtype scheme would always apply here, as it does with media types. Some token types will have no subtypes. What makes more sense is for the token types that need to create their own sub-registries to do so. And then those entries will be found from IANA as well -- no error-prone informal search effort should be needed. Or am I missing the same thing Eran is? Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4)
Added: unsupported parameter value (other than grant type) EH -Original Message- From: Roger Crew [mailto:c...@cs.stanford.edu] Sent: Tuesday, February 07, 2012 12:53 PM To: Eran Hammer Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4) (2) [in 4.2.2.1] If the response_type is provided but unknown, is that an 'invalid_request' (since this is clearly an unsupported parameter value) or is it an 'unsupported_response_type'? Seems to me it should be the latter. If so, then... ... should the description for 'invalid_request' even be referring to unsupported values at all? ... Section 5.2 has the same problem w.r.t. 'unsupported_grant_type' Changed the definition of invalid_request to: The request is missing a required parameter, includes an invalid parameter value, or is otherwise malformed. Just noticed in draft 23 that you changed 4.2.2.1 but didn't change 5.2, which still refers to unsupported parameter values and thus similarly conflicts with the definition of 'unsupported_grant_type'. -- Roger Crew c...@cs.stanford.edu ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
-Original Message- From: Songhaibin [mailto:haibin.s...@huawei.com] Sent: Friday, February 17, 2012 12:53 AM To: Justin Richer Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin Stiemerling; oauth@ietf.org; tsv-...@ietf.org Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 Hi Justin, Thank you for the clarification. See in line. -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Wednesday, February 15, 2012 9:44 PM To: Songhaibin Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin Stiemerling; oauth@ietf.org; tsv-...@ietf.org Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 On 02/15/2012 04:33 AM, Songhaibin wrote: I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. First, I should apologize for the delay in this review, I should have finished it two days ago. I have some common security knowledge but not an expert. Summary This draft is basically ready for publication, but has nits that should be fixed before publication. General issues need discussion: 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner password credentials, and client credentials. These two have the same flow and many in common, and they are significantly different than the authorization code grant type and implicit grant type described in previous sections. And in section 1.3.4, it also says Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner), Is it better to combine these two grant types as one client credentials grant type where the client can be the resource owner? No, they are quite distinct -- It all comes down to what you're authenticating. The Resource Owner Password Credentials flow *also* includes client credentials which are distinct from the resource owner's own credentials. The client's credentials are going to be the same for a given client across many different users, while the Resource Owner's credentials are going to be different across different users, but the same across different clients (for the same resource owner). In most flows, the client's credentials identify just the client, and the resource owner is identified through some other means (a direct password, a redirected login to the authz endpoint). In the Client Credentials flow, the client's credentials are the only ones that you have. Okay, in the Resource Owner Password Credentials flow, it adds client credentials, but any client who was issued credentials from the authorization server can pass. How much security does the client credential in this flow add? It can allow the server to enforce policies, but more importantly, client authentication is part of every access token request make to this endpoint as part of the overall architecture. 2. Two concepts confused me in section 2.4, I don't know if I am the only person who is confusing here. One is user-agent-based application and another is native application, why are they executed on the device used by the resource owner? I think they can run on any device used by resource consumer instead of resource owner. Resource owner is only used to grant access to resources. OAuth's main 3-legged pattern allows what's called Alice-to-Alice sharing, in that the Client is consuming on behalf of the resource owner. In cases where you have an in-user-agent app or a native app, the end user (resource owner) is going to be the one running it, and the one authorizing it. Yes, I understand that. But the document seems like resource owner is the only one who can run the UA app or native app? Or I missed something? It is the only one. Only the resource owner can grant access. EH Thanks, -Haibin Thanks for your feedback, and I hope this can help clear up the intent of the working group here. If you can suggest language that will solidify these points further, it can help make sure this doesn't further confuse people. -- Justin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] How an AS can validate the state parameter?
Can't validate, but can sanitize. EH From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Andrew Arnott Sent: Sunday, February 19, 2012 7:36 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] How an AS can validate the state parameter? From section 10.14: (draft 23) The Authorization server and client MUST validate and sanitize any value received, and in particular, the value of the state and redirect_uri parameters. Elsewhere in the spec the AS is instructed to exactly preserve the state and to consider it an opaque value. How then, can an AS validate and sanitize the state parameter? -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] error response for invalid refresh token
Invalid_grand is correct. EH From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Buhake Sindi Sent: Tuesday, February 21, 2012 7:16 AM To: Peter Brindisi Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] error response for invalid refresh token Hi invalid_grant The provided authorization grant (e.g. authorization code, resource owner credentials) is invalid, expired, revoked, does not match the redirection URI used I would think that the refresh_token is an authorization code that needs refreshing, so this would be valid. On 21 February 2012 15:33, Peter Brindisi peter.brind...@gmail.commailto:peter.brind...@gmail.com wrote: Hi all, I am currently implementing version 23 of the oauth2 spec, and I came across a bit of ambiguity. What is the appropriate error code for an invalid refresh token? I am unsure whether it should be 'invalid_grant' or 'invalid_request'. Neither seems 100% clear. Thanks in advance! Best, Peter ___ 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] Server cret verification in 10.9
New text: In order to prevent man-in-the-middle attacks, the authorization server MUST implement and require TLS with server authentication as defined by xref target='RFC2818' / for any request sent to the authorization and token endpoints. The client MUST validate the authorization server's TLS certificate as defined by xref target='RFC6125' /, and in accordance with its requirements for server identity authentication. EH -Original Message- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Tuesday, January 24, 2012 2:24 PM To: Peter Saint-Andre Cc: Eran Hammer; OAuth WG Subject: Re: [OAUTH-WG] Server cret verification in 10.9 We added the reference to RFC6125 in openID Connect. The Client MUST perform a TLS/SSL server certificate check, per xref target=RFC6125RFC 6125/xref. We wanted to be more general to allow for non http bindings in the future. If you don't do it in core, every spec that references core will probably have to add it. John B. On 2012-01-24, at 12:32 AM, Peter Saint-Andre wrote: On 1/20/12 4:46 PM, Eran Hammer wrote: Stephen asked: (13) 10.9 says that the client MUST verify the server's cert which is fine. However, does that need a reference to e.g. rfc 6125? Also, do you want to be explicit here about the TLS server cert and thereby possibly rule out using DANE with the non PKI options that that WG (may) produce? Can someone help with this? I don't know enough to address. The OAuth core spec currently says: The client MUST validate the authorization server's TLS certificate in accordance with its requirements for server identity authentication. RFC 2818 has guidance about endpoint identity, in Section 3.1: http://tools.ietf.org/html/rfc2818#section-3.1 RFC 6125 attempts to generalize the guidance from RFC 2818 and many similar specs for use by new application protocols. Given that OAuth as defined by the core spec runs over HTTP, I think referencing RFC 2818 would make sense. So something like: The client MUST validate the authorization server's TLS certificate in accordance with the rules for server identity authentication provided in Section 3.1 of [RFC2818]. Peter -- Peter Saint-Andre https://stpeter.im/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
Thanks Haibin. -Original Message- From: Songhaibin [mailto:haibin.s...@huawei.com] Sent: Wednesday, February 15, 2012 1:33 AM Nits: 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the authorization server who sends the request to the authorization endpoint? Or is it the resource owner? The client. Added clarification in section 3. 2. Section 3.1.1, paragraph 3, ...where the order of values does not matter.. I think a little clarification on the reason for this would be better for people like me. I don't think we need to explain it, but it's to meet typical developers' expectations. 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the authorization server who sends request to the token endpoint? Same as #1. 4. Section 10.12, paragraph 4, should the terminology end-user be changed to resource owner? There are same issues in other places of this document. Changed some. Clarified end-user in the intro. 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent to.../ When the authorization code request is sent to... Not sure what you mean. EH ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
5. Section 10.6, paragraph 2, second sentence, When the attacker is sent to.../ When the authorization code request is sent to... Not sure what you mean. I mean you may have to change the attacker is sent to... to the authorization code is sent to BR, -Haibin -Original Message- From: Eran Hammer [mailto:e...@hueniverse.com] Sent: Thursday, March 08, 2012 8:16 AM To: Songhaibin; tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org Cc: tsv-...@ietf.org; oauth@ietf.org; Martin Stiemerling Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23 Thanks Haibin. -Original Message- From: Songhaibin [mailto:haibin.s...@huawei.com] Sent: Wednesday, February 15, 2012 1:33 AM Nits: 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the authorization server who sends the request to the authorization endpoint? Or is it the resource owner? The client. Added clarification in section 3. 2. Section 3.1.1, paragraph 3, ...where the order of values does not matter.. I think a little clarification on the reason for this would be better for people like me. I don't think we need to explain it, but it's to meet typical developers' expectations. 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the authorization server who sends request to the token endpoint? Same as #1. 4. Section 10.12, paragraph 4, should the terminology end-user be changed to resource owner? There are same issues in other places of this document. Changed some. Clarified end-user in the intro. 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent to.../ When the authorization code request is sent to... Not sure what you mean. EH ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Multiple access tokens
The spec doesn't seem to have any recommendations on this point, but should an OAuth v2 API always return the same access token if the same client makes multiple requests? Is there any benefit to not generating a new access token for each request? Similarly, if you do generate new access tokens (as I am doing now), should you also generate new refresh tokens? An unrelated question about revoking access tokens when the same authorization code is used more than once: should refresh tokens also be revoked? And, if so, should any tokens issued with that refresh token then also be revoked? It seems simpler (if slightly less correct) to just revoke all access tokens for that specific client/resource pair in that case, rather than tracking the ancestry of all tokens. Thanks, Ross smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
New text: The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). Removed reference to RFC 1750. EH -Original Message- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Monday, February 06, 2012 5:07 PM To: Eran Hammer Cc: Julian Reschke; i...@ietf.org; The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard RE new text in Draft 23 http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.10 Generated tokens and other credentials not intended for handling by end-users MUST be constructed from a cryptographically strong random or pseudo-random number sequence ([RFC1750]) generated by the authorization server. Given that many implementations may elect to use signed tokens, such as SAML or JWT (JOSE) this should not be a MUST. Giving people sensible defaults such as the probability of an attacker guessing a valid access token for the protected resource should be less than 2^(-128). The probability of generating hash colisions randomly is a odd metric, 2^(- 128) for a SHA256 as I recall. Many factors play into what is secure, token lifetime etc. I don't mind some reasonable defaults but adding a requirement for unstructured tokens is a bit much. Regards John B. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
OK. I understand. Then I have no questions. Thank you for the answer. -Haibin -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer Sent: Thursday, March 08, 2012 8:02 AM To: Songhaibin; Justin Richer Cc: draft-ietf-oauth...@tools.ietf.org; tsv-...@tools.ietf.org; tsv-...@ietf.org; oauth@ietf.org; Martin Stiemerling Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 -Original Message- From: Songhaibin [mailto:haibin.s...@huawei.com] Sent: Friday, February 17, 2012 12:53 AM To: Justin Richer Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin Stiemerling; oauth@ietf.org; tsv-...@ietf.org Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 Hi Justin, Thank you for the clarification. See in line. -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Wednesday, February 15, 2012 9:44 PM To: Songhaibin Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin Stiemerling; oauth@ietf.org; tsv-...@ietf.org Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23 On 02/15/2012 04:33 AM, Songhaibin wrote: I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. First, I should apologize for the delay in this review, I should have finished it two days ago. I have some common security knowledge but not an expert. Summary This draft is basically ready for publication, but has nits that should be fixed before publication. General issues need discussion: 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner password credentials, and client credentials. These two have the same flow and many in common, and they are significantly different than the authorization code grant type and implicit grant type described in previous sections. And in section 1.3.4, it also says Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner), Is it better to combine these two grant types as one client credentials grant type where the client can be the resource owner? No, they are quite distinct -- It all comes down to what you're authenticating. The Resource Owner Password Credentials flow *also* includes client credentials which are distinct from the resource owner's own credentials. The client's credentials are going to be the same for a given client across many different users, while the Resource Owner's credentials are going to be different across different users, but the same across different clients (for the same resource owner). In most flows, the client's credentials identify just the client, and the resource owner is identified through some other means (a direct password, a redirected login to the authz endpoint). In the Client Credentials flow, the client's credentials are the only ones that you have. Okay, in the Resource Owner Password Credentials flow, it adds client credentials, but any client who was issued credentials from the authorization server can pass. How much security does the client credential in this flow add? It can allow the server to enforce policies, but more importantly, client authentication is part of every access token request make to this endpoint as part of the overall architecture. 2. Two concepts confused me in section 2.4, I don't know if I am the only person who is confusing here. One is user-agent-based application and another is native application, why are they executed on the device used by the resource owner? I think they can run on any device used by resource consumer instead of resource owner. Resource owner is only used to grant access to resources. OAuth's main 3-legged pattern allows what's called Alice-to-Alice sharing, in that the Client is consuming on behalf of the resource owner. In cases where you have an in-user-agent app or a native app, the end user (resource owner) is going to be the one running it, and the one authorizing it. Yes, I understand that. But the document seems like resource owner is the only one who can run the UA app or native app? Or I missed something? It is the only one. Only the resource owner can grant access. EH Thanks, -Haibin Thanks for your feedback, and I hope this can
Re: [OAUTH-WG] Quick question about error response for response_type=unknown
Section 3.1.1 states: If an authorization request is missing the response_type parameter, the authorization server MUST return an error response as described in Section 4.1.2.1. The intention was to make this the catch-all scenario. While I do appreciate the issue here of the client using a response type that may require special encoding of the error information in the response, it is pretty easy to also support the authorization code response type error transport when using a response type other than code and token. I have made the following change to clarify this: If an authorization request is missing the response_type parameter, [[or if the response type is not understood, ]] the authorization server MUST return an error response as described in Section 4.1.2.1. Not understood means the server does not know anything about it. It should know about code and token, even if one or both are not supported and provide the required error response. This really is only about unknown extensions. Then according to section 4.1.2.1, the error code should be 'unsupported_response_type'. I have tried to make the change as small as possible, but if my explanation isn't clear from the new text, please let me know and we'll get it clarified. EH From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of matake@gmail Sent: Tuesday, February 21, 2012 4:23 AM To: Buhake Sindi Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Quick question about error response for response_type=unknown When server cannot understand the response_type, it can't know where the error response should be included. ex.) A JS client used response_type=code%20id_token and expected all returned parameters would be included in fragment. However server couldn't understand the response_type and returned error messages in query. Then client won't be able to handle the error. Actually, clients expects returned parameters in query only when it uses response_type=code, at least in current proposed response_types. (I'm thinking current proposed response_types as code, token, code token, token id_token, code id_token and code token id_token) On 2012/02/21, at 20:42, Buhake Sindi wrote: Oops. Sorry, I believe I should have said, case 2. And why is case 2 impossible? The only time case 1 is valid in the redirect_uri is invalid. Buhake Sindi On 21 February 2012 13:40, Buhake Sindi buh...@googlemail.commailto:buh...@googlemail.com wrote: Hi guys, OAuth 2, Draft 23, Paragraph 4.1.2.1 clearly states: If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error, and MUST NOT automatically redirect the user-agent to the invalid redirection URI. So, Case 1 is the only accepted case here. Buhake Sindi On 21 February 2012 13:34, matake@gmail mat...@gmail.commailto:mat...@gmail.com wrote: So the answer is Show the error to the user without redirecting back to the client, right? I'm now developing OAuth2 and OpenID Connect ruby library, and both of them return errors case 1. redirect with error in query if response_type is code but it's not supported case 2. redirect with error in fragment if response_type is token code, token id_token, token code id_token or code id_token but it's not supported case 3. otherwise show error to the user without redirect since server cannot understand the response_type at all But other server might not understand some of response_types listed in case 2 at all and choose case 3 in such case. (ie. OAuth servers which don't understand OpenID Connect won't understand id_token) So I'm afraid that it reduces interoperability, a bit. On 2012/02/21, at 13:22, William Mills wrote: I does allow some parts of your server config to be discovered. More of a problem in error responses is usually echoing back the user data, or allowing user enumeration for example. Care is required, but you don't have a ton of options here. From: Igor Faynberg igor.faynb...@alcatel-lucent.commailto:igor.faynb...@alcatel-lucent.com To: oauth@ietf.orgmailto:oauth@ietf.org Sent: Monday, February 20, 2012 9:37 AM Subject: Re: [OAUTH-WG] Quick question about error response for response_type=unknown Could there be a potential security hole in providing an error response? (Not that I see it, but many problems in the past had been caused by helpful responese.) Igor On 2/20/2012 11:57 AM, William Mills wrote: Respond with an error in protocol. Thta won't include a redirect, and the client has to know what to do. From: nov matake n...@matake.jpmailto:n...@matake.jp To: oauth WG oauth@ietf.orgmailto:oauth@ietf.org Sent: Monday, February 20, 2012 6:11 AM Subject: [OAUTH-WG] Quick question about error response for response_type=unknown Hi OAuthers, My apologies if you already
Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
Should simple read the attacker's user-agent is sent to. EH -Original Message- From: Songhaibin [mailto:haibin.s...@huawei.com] Sent: Wednesday, March 07, 2012 6:11 PM To: Eran Hammer; tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org Cc: tsv-...@ietf.org; oauth@ietf.org; Martin Stiemerling Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent to.../ When the authorization code request is sent to... Not sure what you mean. I mean you may have to change the attacker is sent to... to the authorization code is sent to BR, -Haibin -Original Message- From: Eran Hammer [mailto:e...@hueniverse.com] Sent: Thursday, March 08, 2012 8:16 AM To: Songhaibin; tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org Cc: tsv-...@ietf.org; oauth@ietf.org; Martin Stiemerling Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23 Thanks Haibin. -Original Message- From: Songhaibin [mailto:haibin.s...@huawei.com] Sent: Wednesday, February 15, 2012 1:33 AM Nits: 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the authorization server who sends the request to the authorization endpoint? Or is it the resource owner? The client. Added clarification in section 3. 2. Section 3.1.1, paragraph 3, ...where the order of values does not matter.. I think a little clarification on the reason for this would be better for people like me. I don't think we need to explain it, but it's to meet typical developers' expectations. 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the authorization server who sends request to the token endpoint? Same as #1. 4. Section 10.12, paragraph 4, should the terminology end-user be changed to resource owner? There are same issues in other places of this document. Changed some. Clarified end-user in the intro. 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent to.../ When the authorization code request is sent to... Not sure what you mean. EH ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.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 Authorization Protocol Author(s) : Eran Hammer David Recordon Dick Hardt Filename: draft-ietf-oauth-v2-24.txt Pages : 66 Date: 2012-03-07 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.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-24.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt
This draft is ready to go to IESG Review. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Wednesday, March 07, 2012 9:42 PM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.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 Authorization Protocol Author(s) : Eran Hammer David Recordon Dick Hardt Filename: draft-ietf-oauth-v2-24.txt Pages : 66 Date: 2012-03-07 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.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-24.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] Multiple access tokens
Hi, Ross Boucher rbouc...@gmail.com schrieb: The spec doesn't seem to have any recommendations on this point, but should an OAuth v2 API always return the same access token if the same client makes multiple requests? Is there any benefit to not generating a new access token for each request? I don't see any. Similarly, if you do generate new access tokens (as I am doing now), should you also generate new refresh tokens? Depends on the grant type. I would expect an authz server to generate new refresh tokens for code, whether the authz server creates a new one for grant type refresh_token might depend on server impl. and client-specific policy (refresh token rotation). An unrelated question about revoking access tokens when the same authorization code is used more than once: should refresh tokens also be revoked? Does it make sense to not revoke refresh token? Otherwise, it could be used to obtain fresh access tokens. And, if so, should any tokens issued with that refresh token then also be revoked? It seems :-) sounds reasonable but not nessessarily feasable simpler (if slightly less correct) to just revoke all access tokens for that specific client/resource pair in that case, rather than tracking the ancestry of all tokens. Generally, I would consider revoking access tokens more difficult then revoking refresh tokens. It depends on your token design. One can use handles for refresh tokens and self-contained access tokens and revoke refresh tokens only. In that case, I would limit the access token lifetime in order to force a periodic refresh. Regarding client/resource: Depends on whether you are able to really identify a particular client instance. Otherwise, you would revoke tokens for different (potentially a lot of) client installations using the same client_id. regards, Torsten. Thanks, Ross___ 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] Multiple access tokens
You might want to put issuance time and other info in an access token. The spec is silent on your first question. On revocation: One of the reasons for short lived access tokens is to only revoke the refresh token, which has to be presented at a central server type rather than trying to extend revocation to all protected resources. So if you're in that model you would not bother revoking the access token. The use case I can see for invalidating access tokens and still honoring refresh tokens is the case where you might have had the access token symmetric secret compromised but not the refresh token secret. That's not really user revocation though. I don't se an actual user revocation of access that would not potentially kill both tokens and always kill the refresh token. - Original Message - From: Ross Boucher rbouc...@gmail.com To: OAuth WG oauth@ietf.org Cc: Sent: Wednesday, March 7, 2012 6:14 PM Subject: [OAUTH-WG] Multiple access tokens The spec doesn't seem to have any recommendations on this point, but should an OAuth v2 API always return the same access token if the same client makes multiple requests? Is there any benefit to not generating a new access token for each request? Similarly, if you do generate new access tokens (as I am doing now), should you also generate new refresh tokens? An unrelated question about revoking access tokens when the same authorization code is used more than once: should refresh tokens also be revoked? And, if so, should any tokens issued with that refresh token then also be revoked? It seems simpler (if slightly less correct) to just revoke all access tokens for that specific client/resource pair in that case, rather than tracking the ancestry of all tokens. Thanks, Ross ___ 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
