On Wed, May 11, 2011 at 7:23 PM, Lodderstedt, Torsten <
t.lodderst...@telekom.de> wrote:
> Hi Breno,
>
> thanks for the feedback. Please find my comments inline.
>
> > >
> > > Now higher level comments:
> > >
> > > On Native Apps protection of refresh token:
> > >
> > > On section Definitions, the
The name needs to be unique enough not to conflict with likely parameters
already used by providers. I don’t have an opinion which name is better, just
that it was oauth_token before and when we changed the scheme name to Bearer,
changed it too.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-b
This may have come up before so I'm sorry if I'm repeating. Why does bearer
token spec introduce a new name for oauth2 access tokens [1],
"bearer_token", and before that [2], "oauth_token"?
I apologize if this may sound shallow but, why introduce a new parameter
name verses sticking with what the
Hi Breno,
thanks for the feedback. Please find my comments inline.
> >
> > Now higher level comments:
> >
> > On Native Apps protection of refresh token:
> >
> > On section Definitions, there is a sentence in the Native Apps "It is
> > assumed that such applications can protect dynamically issued
My .02 -
On 10/05/2011, at 2:49 AM, Eran Hammer-Lahav wrote:
> The OAuth working group has defined an authorization protocol [1] for
> delegating access to protected resources. Once access has been authorized,
> the client is issued a set of token credentials which are uses to make
> authenti
On Wed, May 11, 2011 at 3:26 PM, Lodderstedt, Torsten <
t.lodderst...@telekom.de> wrote:
> >
> > Through registration and redirect URI validation. A native app does
> > not have to impersonate, they can just register a user-agent client.
> > Everything boils down to the user trusting the app. As B
>
> Through registration and redirect URI validation. A native app does
> not have to impersonate, they can just register a user-agent client.
> Everything boils down to the user trusting the app. As Breno mentions,
> nothing the spec can do to help with that.
It could recommend the authorization
On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten
wrote:
> How shall the authorization server ensure that the calling client is a
> user-agent based app (i.e. a native app could impersonate an user-agent based
> app)?
Through registration and redirect URI validation. A native app does
not
On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten <
t.lodderst...@telekom.de> wrote:
> How shall the authorization server ensure that the calling client is a
> user-agent based app (i.e. a native app could impersonate an user-agent
> based app)?
>
> In my opinion, enforcing explicit user cons
How shall the authorization server ensure that the calling client is a
user-agent based app (i.e. a native app could impersonate an user-agent based
app)?
In my opinion, enforcing explicit user consent is the only way to prevent this
kind of attack.
regards,
Torsten.
> -Ursprüngliche Nach
Breno did a review of the security draft.
Thanks a lot!
Begin forwarded message:
> From: Breno de Medeiros
> Date: May 7, 2011 4:25:53 AM GMT+03:00
> To: Hannes Tschofenig
> Subject: Re: OAuth Security Consideration Text
>
> Hi Hannes,
>
> I have gone through the test and I have a few edits a
On Wed, May 11, 2011 at 11:32 AM, Breno wrote:
>
>
> On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten <
> t.lodderst...@telekom.de> wrote:
>
>> Hi Marius,
>>
>> wrt "auto-approval": how is the authorization server supposed to validated
>> the client's identity in a reliable way? Otherwise an
On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten <
t.lodderst...@telekom.de> wrote:
> Hi Marius,
>
> wrt "auto-approval": how is the authorization server supposed to validated
> the client's identity in a reliable way? Otherwise another application
> (using the id of the legitimate client) co
On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten
wrote:
> Hi Marius,
>
> wrt "auto-approval": how is the authorization server supposed to validated
> the client's identity in a reliable way? Otherwise another application (using
> the id of the legitimate client) could abuse the authorizatio
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : HTTP Authentication: MAC Access Authentication
Author(s) : E. Hammer-Lahav, et al.
Thanks guys. Added my name to the list.
-Doug Tangren
http://lessis.me
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Doug says...
> 2. Is this open to implementors of the spec in addition to it's authors?
> (I'm currently implementing draft 15 as developer @ meetup.com)
Eran says...
> This is an official interim working group meeting which goes by all the
> normal IETF rules of such meetings and is open for all.
On 09.05.2011 18:49, Eran Hammer-Lahav wrote:
...
The OAuth WG is seeking guidance on the following questions:
1. Should the WG define a general purpose method for returning errors with a
401 WWW-Authenticate headers, including a cross-scheme error code registry?
...
Not sure. Are there error
18 matches
Mail list logo
