On Fri, Jul 16, 2010 at 3:27 PM, Eran Hammer-Lahav wrote:
> The client authentication can be used to retrieve a grant previously arranged.
Really?
Who is going to implement that?
I'm pretty sure that if the only inputs to the protocol are a client
name and a client password, the output is going
I withdraw my question. David might not be interested in implementing
the client password flow, but he is certainly interested in
implementing other flows that involve the client password term. So
he's entitled to an opinion on what color the client password bike
shed should be painted. =)
(Davi
The client authentication can be used to retrieve a grant previously arranged.
While the grant is linked to the client, it is not always about the client's
resources. Calling it 'client' implies it is about the client's resources.
EHL
On Jul 16, 2010, at 18:19, Brian Eaton wrote:
> On Fri,
I agree that these parameters are useful, but not sure if they belong
in the User Experience extension.
I think we should create a separate extension for unregistered clients:
- how to signal that this client is unregistered, maybe use a special
value like "anonymous" as the client id
- what clien
On Fri, Jul 16, 2010 at 2:25 PM, Eran Hammer-Lahav wrote:
> External, out-of-band, implicit.
>
> It cannot be client because that is not always the case.
Can you point to a use case where someone is going to use the client
password flow to authenticate something besides a client?
Because I'm pre
If you specify it. It is supported but not required.
EHL
On Jul 16, 2010, at 16:16, "Brian Eaton" wrote:
> On Fri, Jul 16, 2010 at 11:21 AM, Yaron Goland wrote:
>> That's my point. The spec says " Words of *TEXT MAY contain characters from
>> character sets other than ISO- 8859-1 [22] only
External, out-of-band, implicit.
It cannot be client because that is not always the case.
EHL
On Jul 16, 2010, at 12:40, Marius Scurtescu wrote:
> I agree that grant_type=none is confusing. "client" or "direct" sound better.
>
> Marius
>
>
>
> On Fri, Jul 16, 2010 at 9:30 AM, Justin Ric
And that matters how?
EHL
On Jul 16, 2010, at 16:57, "Brian Eaton" wrote:
> On Fri, Jul 16, 2010 at 1:37 PM, David Recordon wrote:
>> I've always found "client password" to be a confusing term.
>
> Are you going to support this flow at all...?
> _
I guess I don't see why there's a need to distinguish between, in the
grant type identifier, how the client authenticates? (this is all
presupposes, of course, some kind of assertion based client
authentication technique)
On Fri, Jul 16, 2010 at 1:26 PM, Brian Eaton wrote:
> On Fri, Jul 16, 201
On Fri, Jul 16, 2010 at 1:37 PM, David Recordon wrote:
> I've always found "client password" to be a confusing term.
Are you going to support this flow at all...?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I've always found "client password" to be a confusing term.
On Fri, Jul 16, 2010 at 12:26 PM, Brian Eaton wrote:
> On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell
> wrote:
> > +1 for something different but not "client password" as sounds like it
> > would preclude other methods of client aut
good idea.
Am 16.07.2010 21:26, schrieb Brian Eaton:
On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell
wrote:
+1 for something different but not "client password" as sounds like it
would preclude other methods of client authentication
I think it would work like this:
grant_type=cli
On Fri, Jul 16, 2010 at 11:21 AM, Yaron Goland wrote:
> That's my point. The spec says " Words of *TEXT MAY contain characters from
> character sets other than ISO- 8859-1 [22] only when encoded according to the
> rules of RFC 2047 [14]." But since RFC 2047 is a dead letter as a practical
> mat
On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell
wrote:
> +1 for something different but not "client password" as sounds like it
> would preclude other methods of client authentication
I think it would work like this:
grant_type=client_password:
maps to the "client password flow" from
http:
+1 for something different but not "client password" as sounds like it
would preclude other methods of client authentication
On Fri, Jul 16, 2010 at 10:41 AM, Brian Eaton wrote:
> +1.
>
> How about calling it "client password", or something along those
> lines...? That's what Dick called it for
Am 16.07.2010 19:00, schrieb Brian Eaton:
On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt
wrote:
then we should put those use cases and requirements on the table and try to
find a solution fulfilling these different needs. That's what (from my point
of view) standard definition is all
That's my point. The spec says " Words of *TEXT MAY contain characters from
character sets other than ISO- 8859-1 [22] only when encoded according to the
rules of RFC 2047 [14]." But since RFC 2047 is a dead letter as a practical
matter the only safe way to move non-ASCII content in a HTTP heade
On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt
wrote:
> then we should put those use cases and requirements on the table and try to
> find a solution fulfilling these different needs. That's what (from my point
> of view) standard definition is all about.
>
> What do you think?
Sounds fine
Oh hey, so you did. And I even agreed to it back then! Yeah, let's
update it. Between this and the other proposed upgrade flow, we should
cover most ways people would want to trade one flavor of token for
another.
-- Justin
On Fri, 2010-07-16 at 12:56 -0400, Marius Scurtescu wrote:
> On Fri, Ju
On Fri, Jul 16, 2010 at 9:48 AM, Justin Richer wrote:
> The current proposal for a 1.0->2.0 upgrade flow is to use the assertion
> profile and pass the OAuth token in there. Instead, one could create an
> endpoint that speaks the 1.0 protocol fully, signatures and client
> secrets and everything,
The current proposal for a 1.0->2.0 upgrade flow is to use the assertion
profile and pass the OAuth token in there. Instead, one could create an
endpoint that speaks the 1.0 protocol fully, signatures and client
secrets and everything, but issues 2.0 tokens, JSON and all. It's a
hybridized endpoint
+1.
How about calling it "client password", or something along those
lines...? That's what Dick called it for WRAP.
http://tools.ietf.org/html/draft-hardt-oauth-01#page-13
Cheers,
Brian
On Fri, Jul 16, 2010 at 9:39 AM, Marius Scurtescu wrote:
> I agree that grant_type=none is confusing. "clie
Am 16.07.2010 18:35, schrieb Brian Eaton:
On Fri, Jul 16, 2010 at 4:47 AM, wrote:
+1 to Thorstens statement. There are use cases beyond local deployments.
Definitely.
For example, I'm interested in deployments where neither clients nor
resource servers need secret keys. This makes
I agree that grant_type=none is confusing. "client" or "direct" sound better.
Marius
On Fri, Jul 16, 2010 at 9:30 AM, Justin Richer wrote:
> The choice of the value "none" for the grant_type parameter in the
> client-credentials case is confusing. I understand the philosophy behind
> this choi
On Fri, Jul 16, 2010 at 9:13 AM, William Mills wrote:
> For token migration from Oauth 1 to 2 are we ever really going to need
> to do that silently for a user in a client? It's reasonable when the
> user gets a new client install that supports a new protocol for them to
> have to re-authenticate
On Fri, Jul 16, 2010 at 4:47 AM, wrote:
> +1 to Thorstens statement. There are use cases beyond local deployments.
Definitely.
For example, I'm interested in deployments where neither clients nor
resource servers need secret keys. This makes adding new clients and
resource servers trivial.
Th
The choice of the value "none" for the grant_type parameter in the
client-credentials case is confusing. I understand the philosophy behind
this choice, but I think that calling it "none" here gives the wrong
impression. It almost sounds like it's a deny-request on first glance,
or even a revoke re
For token migration from Oauth 1 to 2 are we ever really going to need
to do that silently for a user in a client? It's reasonable when the
user gets a new client install that supports a new protocol for them to
have to re-authenticate. Where I see this happening is in a big server
migration wher
+1 to Thorstens statement. There are use cases beyond local deployments.
Best regards
Wolfgang
-Ursprüngliche Nachricht-
Von: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] Im Auftrag von
Torsten Lodderstedt
Gesendet: Freitag, 16. Juli 2010 00:49
An: Marius Scurtescu
Cc: OAuth
Outside of what happens based on the newly refreshed conversation
about this, currently this point should be moved to 5.1 rather than
5.1.1 as its not specific to the Authorization header.
Rob
On 7/14/10 6:15 PM, Eran Hammer-Lahav wrote:
Already in -10.
EHL
On Jul 14, 2010, at 14:46, Rob
On 7/14/10 6:33 PM, Marius Scurtescu wrote:
On Wed, Jul 14, 2010 at 11:46 AM, Rob Richards wrote:
Finally getting a chance to catchup and respond to this thread.
Marius Scurtescu wrote:
See comments bellow...
On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia wrote:
Hallo Marius,
thanks f
On Jul 15, 2010, at 1:10 PM, Torsten Lodderstedt wrote:
> Why don't you use the client secret to authenticate the application? The spec
> allows you to use a BASIC authorization header for that purpose.
We hadn't thought of that, but suits perfectly to our use case!
Thanks!
>
> Regards,
> Torst
32 matches
Mail list logo
