I think I see the confusion now between this and Torsten's questions. The
assumption is that if the client has no secret, no assertion would be made. No
client authentication is performed. The app is essentially anonymous. That's
how folks interpret this?
So while I agree in theory, I propose that many providers still want to know
the proposed identity of client, primarily for statistics or record-tracking
purposes. There is barely an incentive for a malicious client to forge that of
a secret-less client other than to skew the statistics of that client. What's
more, the Kiva system, as many others, allow developers to revoke or disable
all tokens associated with their client. This would not be possible w/o some
proposal of client ID during authorization. Native clients are clients without
secrets, but the don't fall into the category of fully "anonymous" apps as I
understand this term to be used in the spec.
So, perhaps this explains why we would allow password-less or secret-less
identity to be passed during authorization. Rather than invent a new way to
suggest identity in these cases, we simply use the same mechanism (MAC) with no
secret. It's a valid argument that we should use another mechanism such as a
provider-specific field or Bearer.
For what it's worth, we use the terminology VERIFIABLE and FORGEABLE in our
documentation to refer to clients with secrets and those without, respectively.
Forgeable clients are neither privileged nor punished (as it were) for their
spoof-able nature - native clients are an important part of the ecosystem.
skylar
On Apr 4, 2011, at 5:08 PM, Marius Scurtescu wrote:
> On Mon, Apr 4, 2011 at 4:14 PM, Skylar Woodward <sky...@kiva.org> wrote:
>> In our implementation (not yet public) we accept the empty string ("") as
>> the value for clients not issued secrets. While this was done to simplify
>> the interface and implementation, it would make it compliant in my view. In
>> this case, the authorization server is validating the credentials, which are
>> the client ID and the empty string, which is equivalent security-wise to any
>> other length of "secret" issued to a native client.
>
> I am splitting hairs now, but according to the spec an empty parameter
> value should be treated the same as if the parameter was not sent at
> all. So, empty secret violates the requirement for the parameter to be
> present.
>
> Marius
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
