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
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 i
> [Issuing multiple tokens] is not an important enough feature. Parsing an
> array response when
> 99.99% will be a single object array is annoying.
I would agree... if I believed the 99.99%, but not if it will be 80% and
falling in a year or two.
A major benefit of OAuth2 is that resource
> 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 authent
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.
__
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
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."
On 6/16/2011 4:51 PM, Brian Eaton wrote:
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt
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
would be eager to
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 wille
Am 16.06.2011 22:30, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt
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 spec says on this. If yo
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 t
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 ide
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
mailto:tors...@lodderstedt.net>> wrote:
No, it's not simpler nor clearer. Such a client secret is useless,
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 you
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
> > 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.
>
Am 16.06.2011 22:02, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt
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 to see.
From my persp
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 authentic
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
mai
> 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.
Ho
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, MAC)
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 us
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
-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
security"
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?
On Thu, Jun 16, 2011 at 10:51 AM, Eran Hammer-Lahav wrote:
> 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.
_
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 an
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
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.
__
On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav wrote:
> 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 stated, this is a
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. O
On Thu, Jun 16, 2011 at 8:48 AM, Thomas Hardjono 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 clients.
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 Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav wrote:
> 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
Tony said a new text is coming. Once that is posted, I'll ask the list for a
hum.
EHL
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, June 16, 2011 2:00 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: AW: Updated text for Native Apps
In my percept
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: [O
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; o
> -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 b
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 prob
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
-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?
On Thu, 2011-06-16 at 04:43 -0400, Tim Brody wrote:
> On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer
> 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
> >
+1 to access_token.
2011/6/16 Eran Hammer-Lahav :
> 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 [
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 was
On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer
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 key-
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
clie
+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
mailto:e...@hueniverse.com>> wrote:
I would like to add a quick discussion of acces
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
48 matches
Mail list logo
