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 jric...@mitre.org wrote:
The choice of the value none for the grant_type parameter in the
client-credentials case is confusing. I understand the philosophy behind
Am 16.07.2010 18:35, schrieb Brian Eaton:
On Fri, Jul 16, 2010 at 4:47 AM,wolfgang.steigerw...@telekom.de 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
+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 mscurte...@google.com wrote:
I agree that grant_type=none
On Fri, Jul 16, 2010 at 9:48 AM, Justin Richer jric...@mitre.org 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
On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt
tors...@lodderstedt.net 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
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 header
On Fri, Jul 16, 2010 at 11:21 AM, Yaron Goland yar...@microsoft.com 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
good idea.
Am 16.07.2010 21:26, schrieb Brian Eaton:
On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell
bcampb...@pingidentity.com 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
I've always found client password to be a confusing term.
On Fri, Jul 16, 2010 at 12:26 PM, Brian Eaton bea...@google.com wrote:
On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
+1 for something different but not client password as sounds like it
would
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 bea...@google.com wrote:
On
And that matters how?
EHL
On Jul 16, 2010, at 16:57, Brian Eaton bea...@google.com wrote:
On Fri, Jul 16, 2010 at 1:37 PM, David Recordon record...@gmail.com wrote:
I've always found client password to be a confusing term.
Are you going to support this flow at all...?
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 mscurte...@google.com wrote:
I agree that grant_type=none is confusing. client or direct sound better.
Marius
On Fri, Jul 16, 2010 at 9:30 AM,
If you specify it. It is supported but not required.
EHL
On Jul 16, 2010, at 16:16, Brian Eaton bea...@google.com wrote:
On Fri, Jul 16, 2010 at 11:21 AM, Yaron Goland yar...@microsoft.com wrote:
That's my point. The spec says Words of *TEXT MAY contain characters from
character sets
On Fri, Jul 16, 2010 at 2:25 PM, Eran Hammer-Lahav e...@hueniverse.com 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?
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 client
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 bea...@google.com
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. =)
On Fri, Jul 16, 2010 at 3:27 PM, Eran Hammer-Lahav e...@hueniverse.com 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,
18 matches
Mail list logo
