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
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/
__
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
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:
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
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
+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
-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
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.
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
-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
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
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
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
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
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
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
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
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:
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
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;
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
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:
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?
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
25 matches
Mail list logo
