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
The reason why I suggested the name bearer_token was to achieve a consistent
naming convention across different ways to uses those tokens (URI query, HTTP
authn scheme). Now the discussion centers around achieving a consistent naming
between token acquisition and usage. I'm basically fine with
+1
Von: Brian Eaton [mailto:bea...@google.com]
Gesendet: Mittwoch, 15. Juni 2011 20:33
An: Eran Hammer-Lahav
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] Refresh tokens
On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com wrote:
I would like to add a quick
The ability to describe a client to the user does not depend on the
authentication but on the identification of the client and the meta data
available to the authz server. The only difference between identified and
authenticated clients is the trust level the authz server has regarding the
On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer jric...@mitre.org
wrote:
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
In my perception, the main concern raised at the F2F was the absent of the
implicit grant in the text. That's what Chuck added including a discussion of
the pros and cons.
Most of the discussion in the thread you referred to was about refresh tokens
support in the implicit grant type, which
+1 to access_token.
2011/6/16 Eran Hammer-Lahav e...@hueniverse.com:
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:
On Thu, 2011-06-16 at 04:43 -0400, Tim Brody wrote:
On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer jric...@mitre.org
wrote:
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
-Doug Tangren
http://lessis.me
Just one question:
Is the assumption of the group that bearer tokens are the only type of
tokens to be used in conjunction with URI query parameters? Otherwise, a
mechanism is needed to distinguish bearer and other tokens, e.g. another
parameter (token_type?).
If we're changing the bearer token's name, are we going to change the
parameter name inside of MAC as well? At the moment, it's id, which
I've always found an odd naming choice.
I would argue for consistency across the three main documents.
-- Justin
On Thu, 2011-06-16 at 08:40 -0400, KIHARA,
Apologies for the late response.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Wednesday, June 15, 2011 1:27 PM
To: OAuth WG
Subject: [OAUTH-WG] Client authentication requirement
Client authentication has been one of the main problem
-Original Message-
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, June 16, 2011 1:26 AM
To: Eran Hammer-Lahav; Mike Jones; David Recordon; George Fletcher
Cc: paul Tarjan; oauth@ietf.org
Subject: AW: [OAUTH-WG] consistency of token param name in bearer
Nope. OAuth is a secondary goal of the MAC scheme and calling it access_token
there would make no sense for anything but OAuth.
EHL
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, June 16, 2011 7:01 AM
To: KIHARA, Boku
Cc: Eran Hammer-Lahav;
Easier said than done. If you don't have strong trust, giving the user hints
will cause more harm than good.
EHL
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: AW:
On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
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
Eran:
I think the issue of refreshing tokens should be a configurable parameter
(security policy) that the authorization server (ie. admin managing it) sets.
Perhaps the parameter value should be advertised in the service documentation
of the authorization end-point. So the client can choose
On Thu, Jun 16, 2011 at 8:48 AM, Thomas Hardjono hardj...@mit.edu wrote:
Requiring client authentication doesn't defend against
attacks directly; it makes recovery after a successful
attack easier.
I presume you mean direct attacks on the authorization server.
Also attacks on the
Agree with Torsten's assessment here.
From: Eran Hammer-Lahav [e...@hueniverse.com]
Sent: Thursday, June 16, 2011 8:34 AM
To: Lodderstedt, Torsten; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps
Tony said a new text is coming.
On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
1. Why not require the registration of a redirection URI for implicit grant
requests, removing the redirect_uri parameter completely from the request
(the client can still use the state parameter)?
As others have
I agree with the statement. Authorization server provides information about a
client to a user based on the client's identifier, which client has presented
to the server. If authorization server cannot validate the client's identity
claim, it must make the user aware.
I think we want the same thing and I can adjust my proposal to align with your
comments below. I'll post in a separate thread.
EHL
From: Brian Eaton [mailto:bea...@google.com]
Sent: Thursday, June 16, 2011 9:19 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Redirection URI and
This is nice on paper but doesn't work.
The user will see the client name or logo and will not read any of the fine
print. We know this as a fact. If you can't validate the client identifier, you
should not show the user any information about the client that you cannot vouch
for. Disclaimers
On Thu, Jun 16, 2011 at 10:51 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
This is nice on paper but doesn’t work.
I have to agree. It doesn't matter what the spec says on this point. No
one is going to take advice from the spec about what the text on their
approval page ought to say.
What seems to be missing in the discussion and the security considerations
of the spec is a decent list of general and grant-type-specific security
implications/pros/cons for the system if meaningful client authentication
at the token endpoint is available or not available.
What about this?
-1 making client authentication required at the access token endpoint
Client authentication is useful in some situations to raise the security
level. But requiring it will either keep out native apps or force there
developers to use useless/insecure secrets (I would call this pseudo
On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
-1 making client authentication required at the access token endpoint
Client authentication is useful in some situations to raise the security
level. But requiring it will either keep out native apps or
Agree with Torsten -- I would hate for us to repeat the
anonymous/anonymous thing that Google implemented for OAuth1.
-- Justin
On Thu, 2011-06-16 at 15:42 -0400, Torsten Lodderstedt wrote:
-1 making client authentication required at the access token endpoint
Client authentication is useful
token_type is defined in the core spec only and indicates the token type
to the client and not the resource server.
So either the core spec defines a way to distinguish token types towards
resource servers (probably by utilizing the token_type parameter) or the
respective schemes (BEARER,
If you can't validate the client identifier, you should not show the user any
information about the client that you cannot vouch for.
According to the flow described in section 1.2, authorization by the resource
owner (user) is done before the authorization server authenticates the client.
How
Certainly not. Are we discussing to make client authentication required
just for syntactical purposes?
To me, notasecret logically means to abandon on client authentication.
regards,
Torsten.
Am 16.06.2011 21:46, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
**
Certainly not. Are we discussing to make client authentication required
just for syntactical purposes?
That is what I'd like to see.
From my perspective, no harm is done by making client authentication
Am 16.06.2011 22:02, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
Certainly not. Are we discussing to make client authentication
required just for syntactical purposes?
That is what I'd like
Certainly not. Are we discussing to make client
authentication required just for syntactical purposes?
That is what I'd like to see.
From my perspective, no harm is done by making client authentication
a syntactical requirement of the protocol.
-
On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
**
No, it's not simpler nor clearer. Such a client secret is useless, so the
security implications have to be explained anyway.
The issue really isn't the security implications being unclear; the issue is
The user should be informed and in control, but there is a limit to how much
information you can give with confidence. My point is that it is really hard to
provide the user with trustworthy information without client registration and
secure client credentials or pre-registered callback.
If
no I'm saying people will use real secrets and rely on them - just as
with OAuth 1.0
Am 16.06.2011 22:20, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
No, it's not simpler nor clearer. Such a
If this is an implicit grant, using the redirection URI registered before. If
this is the authorization code, the server knows that the client will have to
present a secret later to get access, so it can make that information available
with confidence. If someone else is asking using a stole
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
**
no I'm saying people will use real secrets and rely on them - just as with
OAuth 1.0
=)
People are going to ignore what the spec says on this. If you read through
the mailing list threads on this topic,
Am 16.06.2011 22:30, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
no I'm saying people will use real secrets and rely on them - just
as with OAuth 1.0
=)
People are going to ignore what the
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
**
If those people have reasonable means in place to protect secrets on
deployment channels and in the local installation - fine. I would be eager
to learn more about those means because I would be willed to
On 6/16/2011 4:51 PM, Brian Eaton wrote:
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
If those people have reasonable means in place to protect secrets
on deployment channels and in the local installation - fine. I
I agree with the factual information, but I disagree with the conclusion.
Indeed, there were postings from people who will bake secrets into
installed applications. But there have also been postings from people
(like Torsten and me) who said they will use real secrets and rely on
them.
I
On Thu, Jun 16, 2011 at 2:14 PM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
**
On 6/16/2011 4:51 PM, Brian Eaton wrote:
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
If those people have reasonable means in place to protect secrets on
Probably defining a token type of multiple_tokens would be my preference, and
if you get that back then you have to parse an array of {type, token}*. What
that array looks like could be JSON in the payload, or something else. That
leaves the single token use case alone.
If we're changing the bearer token's name, are we going to change the
parameter name inside of MAC as well? At the moment, it's id, which
I've always found an odd naming choice.
I would argue for consistency across the three main documents.
OAuth2 should be consistent with the
I'm standing behind my 99.99% projection for the next 5 years.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Thursday, June 16, 2011 9:04 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] issuing multiple tokens
[Issuing multiple tokens] is not an
Hi Thomas,
Am 02.06.2011 21:17, schrieb Thomas Hardjono:
Hi Torsten, folks,
I reviewed the text of Section 4.1 of draft-lodderstedt-oauth-security, and
also the text of Section 9 of oath-draft16.
I think there seems to be a disconnect (may be its just me).
(a) Oauth2.0 today is designed for
47 matches
Mail list logo
