Re: [OAUTH-WG] Flowchart for legs of OAuth

[Skylar Woodward <[e-mail]>]

Torsten, that's what the spec recommends already. That's my assumption for everything I've discussed thus far - that clients who can't keep secrets are never issued them and thus must omit them out of lack of having any.

We're just splitting hairs on the definition of "omit."  Also, there's confusion because not everyone has considered the alternative client auth methods apart from the 3.1 password mechanism. I feel a more productive discussion would be to discuss the details of what it means for a client to "omit" secrets for various auth mechanisms. So

- password auth
- HTTP MAC auth
- HTTP Basic?

Additionally if the Password Auth mechanism forbids omission of secrets (including sending empty string as a secret) then we should suggest an alternative, or advise that providers must use another self-defined mechanism for passing unauthenticated client IDs if they wish to require them for record tracking purposes.

skylar


On Apr 8, 2011, at 9:13 AM, Torsten Lodderstedt wrote:

> 
>>>> As to the question of interoperability, the fact that OAuth allows freedom of choice to the AS for method of authentication makes this point moot. Would you agree? (short of various providers could pooling together to standardize on an auth method outside of the spec).
> 
> One possible standard for clients without the capability to protect secrets would be to just omit secrets. Do you agree?
> And the spec itself could (should in my opinion) set this standard.
> 
> regards,
> Torsten.