Re: [OAUTH-WG] Issue 15, new client registration

[Eran Hammer-Lahav <[e-mail]>]

Thanks for the feedback.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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