> > Certainly not. Are we discussing to make client > > authentication required just for syntactical purposes? > > > > That is what I'd like to see. > > > > > > From my perspective, no harm is done by making client authentication > > a syntactical requirement of the protocol. > > > > > > - clients that can't keep secrets aren't harmed; they have the exact > > same security they do today. > > - everyone else benefits because the spec becomes simpler and more > > consistent. > > No, it's not simpler nor clearer. Such a client secret is useless, so > the security implications have to be explained anyway. Moreover, > whatever the spec will state people would start to _rely_ on client > secrets even for native apps, which is a really bad idea.
Not only does it give the wrong impression for developers using this, it forces client developers to use a pattern that doesn't make sense. I really don't like the approach of "if you're not going to really use this, then use this well-known dummy value instead." I'd rather have the useless bits simply not sent instead of filled in with nonsense values. This is getting back to the one-size-fits-all OAuth 1.0 approach that we were trying to get *away* from here. At least, I thought we were. -- Justin _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
