-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Peter Saint-Andre
Sent: Wednesday, June 01, 2011 11:43 AM
Throughout the document, the various parameters (e.g., client_secret and
client_id) are essentially undefined. There is no text
the
client's identity. It must clearly indicate this fact to the end-user.
regards,
Torsten.
Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
I agree
: [OAUTH-WG] review of draft-ietf-oauth-v2-16
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
.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Lodderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe
.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Lodderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe
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.
Lodderstedt';
'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16
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
, Torsten; Brian Eaton
Cc: OAuth WG
Subject: AW: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16
I thought keeping the user informed and in control are core principles of
oAuth? Do you suggest not informing the user is better than stating something
like: the client should be XXX, accept the request
: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16
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
: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
I fully agree with Brian and would like to add some thoughts:
Not authenticating
I fully agree with Brian and would like to add some thoughts:
Not authenticating the client does not directly create a security
problem at all. If we would follow this line, every e-Mail client out
there would be considered insecure because the client itself is never
authenticated. Not even
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Thursday, June 02, 2011 5:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
I fully agree with Brian and would like to add some thoughts
Actually, for the devices that use smart cards (mobile devices, in
particular), this assumption is quite appropriate.
Igor
Thomas Hardjono wrote:
...
However, there is indeed the assumption in Kerberos/RFC4120 (and in the original
Needham-Schroeder protocol) that the client can keep
On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono hardj...@mit.edu wrote:
Well, not to belabor this point :) but in Kerberos it is the proof of
possession of the client secret key which _is_ the authentication mechanism.
There is also PKINIT (RFC4556) which can be used to pre-authenticate the
__
From: Brian Eaton [mailto:bea...@google.com]
Sent: Thursday, June 02, 2011 3:45 PM
To: Thomas Hardjono
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono
/
__
-Original Message-
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Thursday, June 02, 2011 3:31 PM
To: Thomas Hardjono
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Actually, for the devices that use smart cards
: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Thursday, June 02, 2011 3:31 PM
To: Thomas Hardjono
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Actually, for the devices that use smart cards (mobile devices, in
particular
Hardjono
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Actually, for the devices that use smart cards (mobile devices, in
particular), this assumption is quite appropriate.
Igor
Thomas Hardjono wrote
On Thu, Jun 2, 2011 at 4:24 PM, Thomas Hardjono hardj...@mit.edu wrote:
Oh ok, now I get what authenticating the client means here. My bad.
Perhaps the term authenticating is not accurate. Maybe integrity
verification of client code is a better phrase.
It *may* include integrity verification
On 6/1/11 1:06 PM, Brian Eaton wrote:
Hey Peter -
I haven't read all of your comments yet, but I wanted to clarify one
point about client impersonation and installed apps. The cuirrent text
is unrealistic, but your request would push it the wrong way. CC'ing
Torsten as well.
On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre stpe...@stpeter.imwrote:
I think I might have misunderstood that text -- I took it to be talking
about the client's authentication with the authorization server, not the
client's authentication with the resource server.
No, you understand
On 6/2/11 4:11 PM, Brian Eaton wrote:
On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre stpe...@stpeter.im
mailto:stpe...@stpeter.im wrote:
I think I might have misunderstood that text -- I took it to be talking
about the client's authentication with the authorization server, not the
On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre stpe...@stpeter.imwrote:
I think the SHOULD we had originally is probably fine -- with the
understanding that SHOULD means you really ought to do this unless
you have a good reason not to. I think one such really good reason
might be a
On 6/2/11 6:48 PM, Brian Eaton wrote:
On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre stpe...@stpeter.im
mailto:stpe...@stpeter.im wrote:
I think the SHOULD we had originally is probably fine -- with the
understanding that SHOULD means you really ought to do this unless
you
Hey Peter -
I haven't read all of your comments yet, but I wanted to clarify one point
about client impersonation and installed apps. The cuirrent text is
unrealistic, but your request would push it the wrong way. CC'ing Torsten
as well.
-
OLD:
The authorization server
25 matches
Mail list logo
