On Thu, May 13, 2010 at 6:12 AM, Torsten Lodderstedt
wrote:
>
>>
>> Sure, to give one example, I would make the device flow a separate
>> spec immediately. That seems only distantly related to other things in
>> the spec, and may not be really necessary by the time the standard
>> matures.
>>
>
>
Am 13.05.2010 02:41, schrieb Robert Sayre:
On Wed, May 12, 2010 at 7:37 PM, Eran Hammer-Lahav wrote:
Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff
grouped into one document. There seems to be consensus to do that, but it
still runs counter to the conventio
On Wed, May 12, 2010 at 7:37 PM, Eran Hammer-Lahav wrote:
>
>>
>> Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff
>> grouped into one document. There seems to be consensus to do that, but it
>> still runs counter to the conventional wisdom.
>
> Can you point to specific
> -Original Message-
> From: Robert Sayre [mailto:say...@gmail.com]
> Sent: Wednesday, May 12, 2010 4:19 PM
> To: Eran Hammer-Lahav
> Cc: Prateek Mishra; oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
>
> On Wed, May 12, 2010 at 1:
On Wed, May 12, 2010 at 1:08 PM, Eran Hammer-Lahav wrote:
>
> And this is truly *not* aimed at anyone in particular: I'm getting tired of
> people lecturing the group about what makes a good standard.
Oh, I wouldn't expect it to stop. The group has a bunch of unrelated
stuff grouped into one doc
ateek.mis...@oracle.com]
> Sent: Wednesday, May 12, 2010 9:39 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
>
> Eran,
>
> I want to support the idea of a minimal specification, that supports the basic
>
Paul Madsen
Sent: Wednesday, May 12, 2010 3:57 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
But client_secret is not defined specific to a given flow - its used by the web
server, user name, and client credentials flows.
I can find no mention of the client us
cope. We define a parameter just for that called
> client_secret. If you want to use something else, you need to define an
> extension that replaces that with something else.
> >>
> >> EHL
> >>
> >>
> >>> -Original Message-
> &g
auth-boun...@ietf.org] On Behalf
Of axel.nenn...@telekom.de
Sent: Tuesday, May 11, 2010 11:22 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
I suggest a change to
"3.4. Client Credentials
When requesting access from the authorization server, the client
ec harder to read and
implement for something that is not even proposed.
EHL
> -Original Message-
> From: axel.nenn...@telekom.de [mailto:axel.nenn...@telekom.de]
> Sent: Tuesday, May 11, 2010 11:43 PM
> To: Eran Hammer-Lahav; oauth@ietf.org
> Subject: RE: [OAUTH-WG] I-D
ement for something that
is not even proposed.
EHL
> -Original Message-
> From: axel.nenn...@telekom.de [mailto:axel.nenn...@telekom.de]
> Sent: Tuesday, May 11, 2010 11:43 PM
> To: Eran Hammer-Lahav; oauth@ietf.org
> Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2
:30 AM
To: Nennker, Axel; Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
Yes, the Client authenticating using a RSA key pair seems like it
should be a different flow.
On Tue, May 11, 2010 at 11:25 PM, Eran Hammer-Lahav wrote:
> But it is
ahav [mailto:e...@hueniverse.com]
Sent: Wednesday, May 12, 2010 8:25 AM
To: Nennker, Axel; oauth@ietf.org
Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
But it is not beyond the scope. We define a parameter just for that
called client_secret. If you want to use something else, you n
e request and thereby authenticate itself.
>> The public key would need to be exchanged before out-of-band. Or it could
>> be a certificate that is e.g. issued by the authorization server or a party
>> that
>> the authorization server trusts.
>>
>> -Origin
tf.org] On Behalf
> Of axel.nenn...@telekom.de
> Sent: Tuesday, May 11, 2010 11:22 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
>
> I suggest a change to
>
> "3.4. Client Credentials
>
>When requesting access
t: Monday, May 10, 2010 7:45 AM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
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 IE
On Tue, May 11, 2010 at 2:29 PM, Paul Madsen wrote:
> Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in a
> QR code and add it to the response to the client (perhaps as you say in
> addition to the raw URI & user code). There would be no user-code, as we
> would no longer be
Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in
a QR code and add it to the response to the client (perhaps as you say
in addition to the raw URI & user code). There would be no user-code, as
we would no longer be constrained by the user's short-term memory for
strings
On Tue, May 11, 2010 at 4:12 AM, Paul Madsen wrote:
> Yes that's the idea.
>
> Where in the authorization server response would the QR code (or ref) go,
> especially if it also includes the uri & user code?
I don't know how QR codes are generated, but I was assuming that the
device can generate o
Yes that's the idea.
Where in the authorization server response would the QR code (or ref)
go, especially if it also includes the uri & user code?
I don't see mention of an extensibility model by which additional params
could be defined/added
On 5/10/2010 2:03 PM, Marius Scurtescu wrote:
O
On Mon, May 10, 2010 at 6:20 AM, Paul Madsen wrote:
> Related, is anybody thinking of a variant of the device flow where the
> user-agent sits on a device with QR-code capabilities, and so the user
> needn't type anything (uri or code)?
The end user will point their phone to the device screen and
some feedback wrt the device flow
- 'verification URI' and 'authorization URI' are used interchangeably
- in the example messages, the verification code the client sends on its
request for an access token is 'J2vC42OifV', not the same as that
previously issued by the authorization server, name
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 : The OAuth 2.0 Protocol
Author(s) : E. Hammer-Lahav, et al.
Filename: dr
23 matches
Mail list logo
