Agree with Torsten -- I would hate for us to repeat the "anonymous/anonymous" thing that Google implemented for OAuth1.
-- Justin On Thu, 2011-06-16 at 15:42 -0400, Torsten Lodderstedt wrote: > -1 making client authentication required at the access token endpoint > > Client authentication is useful in some situations to raise the security > level. But requiring it will either keep out native apps or force there > developers to use useless/insecure secrets (I would call this "pseudo > security"). > > +1 making the client authentication required for certain client types. > > for a definition of client types and there respective security > properties see http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10 > > In my opinion, the security considerations section already gives a clear > guideline when client authentication should be used and when the authz > server should rely on other mechanims. > > regards, > Torsten. > > Am 16.06.2011 17:08, schrieb Thomas Hardjono: > > Apologies for the late response. > > > > > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > >> Of Eran Hammer-Lahav > >> Sent: Wednesday, June 15, 2011 1:27 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] Client authentication requirement > >> > >> Client authentication has been one of the main problem areas in OAuth > >> 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more > >> confusing). > >> > >> Because of the desire to allow any client type in any deployment > >> environment, we ended up with a barely defined client authentication > >> model. We offer password-based client authentication using HTTP Basic > >> (and an alternative parameter), but leave it optional. > > I would to suggest that perhaps we need a better definition of the "client" > > by way of identifying one or two (or three) types of clients and listing > > their respective security properties/capabilities. For example, if a client > > can/cannot keep cryptographic keys (secrets), then say so. Similarly, if a > > client can do TLS but cannot do proper X509 processing, then list this, > > etc. etc. > > > > In this way developers can at least map (in the minds) which client type > > matches their deployment scenario, based on the best-match capabilities > > list. > > > > > >> I would like to go back to requiring client authentication for the > >> access token endpoint, using HTTP Basic or other schemes. To leave the > >> door open for clients incapable of authenticating to use the endpoint, > >> we will add a security consideration section discussing the > >> ramifications of using the access token endpoint without client > >> authentication. > >> > >> This suggestions is linked to the topic of refresh tokens which I'll > >> post separately. > >> > >> EHL > > +1 agree that client authentication (to access token endpoint) should be > > made a requirement. > > > > /thomas/ > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
