Thanks for the feedback.
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Wednesday, July 20, 2011 1:59 PM
> 2.1 Client types
>
> I'm struggeling with the new terminology of "private" and "public"
> clients. In my perception, the text just distinguishes clients which can be
> authenticated and such which cannot. This is fine but I consider the wording
> misleading. I would suggest to change it to something like trusted/untrusted
> or authenticated/unauthenticated or Verifiable/Forgeable.
One alternative is confidential/open or confidential/public.
> Moreover, I think merging the text on client types in section 10 into section
> 2.1 would make sense for the following reasons:
> - there is large overlap between them
> - It would introduce the term "native application" before it is used for the
> first time in Section 9
Done.
> 2.2. Registration Requirements
>
> Why is the redirect URI a MUST? It should be a MUST for clients using the
> implicit grant and probably for "private" clients but why generally?
> I would suggest to change this to RECOMMENDED.
It is a qualified MUST because you follow the reference. But I'll fix it to
make it read better.
> 2.4 Client Authentication
>
> "In addition, the client and authorization server establish a client
> authentication method suitable for the client type and security
> requirements of the authorization server."
>
> Does this hold true for public clients?
New text:
If the client type is private, the client and authorization server
establish a client
authentication method suitable for the security requirements of the
authorization server.
The authorization server MAY accept any form of client authentication
meeting its
security requirements.
Private clients are typically issued (or establish) a set of client
credentials used for
authenticating with the authorization server (e.g. password,
public/private key pair).
The authorization server SHOULD NOT make assumptions about the client
type or accept the
type information provided without establishing trust with the client
or its developer.
The authorization server MAY establish a client authentication method
with public
clients. However, the authorization server MUST NOT rely on public
client authentication
for the purpose of identifying the client.
> 2.4.1 Client Password
>
> "Clients in possession of a client password MAY " Why not SHOULD?
I rather never recommend Basic for anything... If the server supports DIGEST or
better forms of password authentication, I don't want this text to imply Basic
takes precedence.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
