Eran,
Agree, having an array all the time would be a pain.
Still, I maintain a +1 to explore this a wee bit further much as I hate to do
so at this late stage.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-06-15, at 10:46 PM, Eran Hammer-Lahav wrote:
> It is not a
It is not an important enough feature. Parsing an array response when 99.99%
will be a single object array is annoying. Also, what would you return in case
of error? A single object? What is the client supposed to do if it gets an
empty array? Array with more than one token?
*This* would be the
+1
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-06-15, at 10:01 PM, Manger, James H wrote:
> Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said +1 to
> that; John Bradley identified that OpenID Connect needs to request multiple
> tokens; Eran
My comment was not about not issuing an access token, but about the need for a
refresh token *and* client authentication.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Wednesday, June 15, 2011 10:02 PM
> To:
Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said +1 to
that; John Bradley identified that OpenID Connect needs to request multiple
tokens; Eran Hammer-Lahav even mentioned a no-token flow as something that
could make sense; ...
Issuing 0, 1 or more tokens looks like an imp
I would be interested in working out a solution where client identifier is just
the redirection URI registered (or not), which would completely decouple client
authentication from the rest of the flow. But that's a much bigger change.
EHL
From: Manger, James H [mailto:james.h.man...@team.telstr
It seems like an authorization server receiving a request with an unregistered
redirect_uri of https://example.org/ can tell the user:
"Permission will be passed to your browser then onto *example.org*"
An authorization server receiving a request with a registered redirect_uri of
https://
Brian Eaton wrote on 16-06-2011 10:36:18 AM:
> From: Brian Eaton
> To: Shane B Weeden/Australia/IBM@IBMAU
> Cc: OAuth WG
> Date: 16-06-11 10:49 AM
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden
wrote:
> Brain - can you elaborat
Your comment was that having client authentication makes it easier to recovery
from an attack. I don't understand how the comments below about changing client
secrets every 30 days are relevant. Are you suggesting to wait until the next
routine secret cycle to revoke compromised credentials? Or
On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav wrote:
> How does it make recovery easier? Why is revoking refresh token any harder
> than changing client secret?
>
Changing a client secret can be done without disrupting users. You can even
schedule it, do it every 30 days as part of your gen
> -Original Message-
> From: Shane B Weeden [mailto:swee...@au1.ibm.com]
> Sent: Wednesday, June 15, 2011 3:19 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
>
> > From: Eran Hammer-Lahav
> > To: OAuth WG
> > Date: 16-06-11 05:43 A
How does it make recovery easier? Why is revoking refresh token any harder than
changing client secret?
As for the assertion grant type, where is the specified that the refresh token
is bound to the private keys used to produce the assertion used to obtain the
refresh token in the first place?
On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden wrote:
> Brain - can you elaborate on that a little? Are you suggesting that clients
> that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy
> "requiring client authentication"?
>
Or use random secrets. Whatever floats your boat a
On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav wrote:
> So basically, it is authentication on top of bearer credentials to achieve
> another level of security. Are we just assuming that stealing the refresh
> token will be harder than stealing the client credentials? Seems a bit
> optimistic.
Ok. That makes sense and in line with my other thread about implicit grant and
registration.
So if a callback is not registered, we are basically at the mercy of the user
not being an idiot.
Seems like a good reason to require redirection URI registration for implicit
grant clients.
EHL
From
On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav wrote:
> > I suspect another choice of words would be useful there. Implicit grants
> rely
> > on the browser's authentication of the receiving web site. When https is
> > used, that authentication is fairly strong.
>
> "authentication of the re
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Wednesday, June 15, 2011 1:53 PM
> > But I have no idea why we need client authentication for using a refresh
> token?
>
> This is covered here: http://www.ietf.org/mail-
> archive/web/oauth/current/msg06362.htm
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Wednesday, June 15, 2011 1:53 PM
> To: Eran Hammer-Lahav
> Cc: Brian Campbell; OAuth WG
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> > We have one grant type without client authentication (impl
'Payload body' as defined by
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-3.3
Message body is the wire bits which may include a range of content encoding,
compression, fragmentation, etc. The point is that the client can't really know
what the message body is going to l
> From: Eran Hammer-Lahav
> To: OAuth WG
> Date: 16-06-11 05:43 AM
> Subject: [OAUTH-WG] Redirection URI and Implicit grant
> Sent by: oauth-boun...@ietf.org
>
> This is coming from recent experience building a full web service
> and multiple clients using OAuth 2.0. I am going to make these
> ch
Eran: > > I would like to go back to requiring client authentication for
the access token endpoint
Brian: > Sure. Why not?
>
> 1) It makes the spec simpler.
> 2) It has no impact on the security of clients that can't keep secrets.
> 3) It has no impact on the security of clients that can keep sec
We had a discussion today about the MAC token spec. There was confusion was to
whether payload body included the headers or just the HTTP request message
body. I think the confusion comes about because of subtle term differences in
other RFCs, see the message from Ron below...
From Ron:
> I to
+ 1
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-06-15, at 1:39 PM, Brian Eaton wrote:
> Yeah, I agree with that change.
>
> On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills
> wrote:
> I like your draft in general, but
>
> 10.1.3. Access Tokens
>
>
> We have one grant type without client authentication (implicit)
I suspect another choice of words would be useful there. Implicit grants
rely on the browser's authentication of the receiving web site. When https
is used, that authentication is fairly strong.
> I would like to go back to requi
Yeah, I agree with that change.
On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills wrote:
> I like your draft in general, but
>
>
> 10.1.3. Access Tokens
>
> Access tokens are shorter-lived versions of refresh tokens.
>
> Doesn't work for me. Access tokens are credentials used to access
Makes sense to me.
From: John Bradley
To: Eran Hammer-Lahav
Cc: paul Tarjan ; "oauth@ietf.org"
Sent: Wednesday, June 15, 2011 11:04 AM
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
I agree access_token is better.
John B.
On 201
I like your draft in general, but
10.1.3. Access Tokens
Access tokens are shorter-lived versions of refresh tokens.
Doesn't work for me. Access tokens are credentials used to access protected
resources. Refresh
tokens are credentials used to obtain access tokens.
-bill
__
Well, that's where this is coming from...
Client registration needs to be defined, and it should be specific about the
requirements for clients capable of authentication vs. not, as well as the
redirection URI registration requirements for using the implicit grant type
(see other message).
We
And we need to say that explicitly.
Even if we allow servers to use the two tokens differently, we should clearly
state their design considerations and apply any needed restrictions to make
that clear. We are leaving way too much to the whims of the individual
developer.
Are the access tokens
This is coming from recent experience building a full web service and multiple
clients using OAuth 2.0. I am going to make these changes to my own
implementation and would like to raise the questions here and discuss possible
changes.
A few questions:
1. Why not require the registration of a r
I agree to the extent that the user can be trusted to know how they got to the
authorization endpoint.
If the client cannot be authenticated, the authorization server is limited in
the information it can offer the user to make the decision. It is extremely
hard to come up with language that wil
There is a scalability reason, in that the access_token could be verifiable on
the resource server without DB lookup or a call out to a central server, then
the refresh token serves as the means for revoking in the "an access token good
for an hour, with a refresh token good for a year or good-t
Yes, this is useful and on my list of changes to apply.
But I would like to start with a more basic, normative definition of what a
refresh token is for. Right now, we have a very vague definition for it, and it
is not clear how developers should use it alongside access tokens.
EHL
From: Brian
Also seems this is related to the topic of native/mobile clients. As I
understand it, native apps using the authorization code grant/flow have been
the primary motivator for keeping client authentication optional. Anonymous
client have come up too.
On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer
On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav wrote:
> I would like to add a quick discussion of access token and refresh token
> recommended deployment setup, providing clear guidelines when a refresh
> token SHOULD and SHOULD NOT be issued, and when issues, how it is difference
> from the
I agree access_token is better.
John B.
On 2011-06-15, at 1:38 PM, Eran Hammer-Lahav wrote:
> It should be pretty easy :-)
>
> Anyone objects to changing the parameter name from 'bearer_token' to
> 'access_token'? Let Mike know by 6/20 or he will make the change.
>
> EHL
>
>
>> -Original
It should be pretty easy :-)
Anyone objects to changing the parameter name from 'bearer_token' to
'access_token'? Let Mike know by 6/20 or he will make the change.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Mike Jones
> Sent:
That's an odd way of looking at it. I'm looking at over 30 responses to the
text with clear disagreement on how native applications should be deployed
using different grant types. To say that there is consensus to the text, but
not to the other comments objecting to it is ignoring the lack of co
The main source of confusion about refresh token is caused by the protocol lack
of clear definition of access token lifetime, even in relative terms, and the
objectives of refresh tokens. For example, the authorization server can issue:
- an access token good for an hour, with a refresh token go
Client authentication has been one of the main problem areas in OAuth 1.0 and
2.0 does nothing to resolve it (arguably, it makes it more confusing).
Because of the desire to allow any client type in any deployment environment,
we ended up with a barely defined client authentication model. We off
Not seeing what you write about below, I think that the basic text that was
discussed at the F2F has consensus around the guidance (with some changes that
were discussed and Chuck provided), I think that some of the other thoughts
people have thrown out don't. I disagree with dropping the text a
This working group has failed, for well over a year, to reach any sort of
consensus regarding which grant types are suitable for a given client type.
There was no draft between 00 and 16 in which we had agreement on the
definition of client types, or the exclusivity of any flow to any given type
Since Torsten and I had the action item to propose text we will update the text
based upon the list and give you back an update
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
S
Is there an updated text based on the long thread?
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck
Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps
Minor updates for section 9 based upon feedba
> > I couldn't find a conclusion to the May 2010 discussions about using x-www-
> > form-urlencoded vs. json nor a rationale in the spec for using JSON. Why do
> > I
> > need to add a JSON lexer/parser to my library just to get key-value pairs
> > that
> > can be represented by form-urlencoded?
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Tim Brody
> Sent: Wednesday, June 15, 2011 5:42 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] HTTP/1.0 and JSON
>
> Hi All,
>
> I'm the author of this Perl library for signing OAuth 1.0 re
Hi All,
I'm the author of this Perl library for signing OAuth 1.0 requests:
http://search.cpan.org/~timbrody/LWP-Authen-OAuth-1.01/
I've been asked about OAuth 2.0 so have scanned through the spec and
joined this list :-)
The MAC-signing draft section 1.2 refers to "Host:" but I have an HTTP
li
On 15/06/11 02:30, David Recordon wrote:
Bearer token doesn't exist within the core spec around getting an
access token. The term that is used is "access token".
Right, I get that Bearer is defined in another draft document (which the
core spec references and probably should not btw, that's
These problems all seem sovled with the new definition of age to not
be necessarily related to time.
Adam
On Wed, Jun 15, 2011 at 12:07 AM, Manger, James H
wrote:
> The MAC scheme’s cookie mode [draft-ietf-oauth-v2-http-mac-00, section 6]
> says the cookie’s creation-time is used to determine t
The MAC scheme's cookie mode [draft-ietf-oauth-v2-http-mac-00, section 6] says
the cookie's creation-time is used to determine the age that goes in the nonce
in a request. The creation-time is the time the client receives the Set-Cookie
response - unless the client already has a cookie with the
50 matches
Mail list logo
