Hi Thomas Your additional text is already covered in a countermeasure for section 4.1.4. In addition, section 4.1.4.4 states the assumption that the auth server can't protect against a user installing a malicious client
Regards Mark [email protected] wrote on 23/04/2012 17:09:11: > From: > > Michael Thomas <[email protected]> > > To: > > Barry Leiba <[email protected]>, "[email protected]" <[email protected]> > > Date: > > 23/04/2012 17:09 > > Subject: > > Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel > > Sent by: > > [email protected] > > [I accidentally sent just to Barry my take on his addition which I > think is fine > except for one thing addition...] > > Barry Leiba wrote: > > You sent it just to me. I think it's a reasonable addition, so please > > send it to the distribution (which at the moment does not include the > > OAuth list, just the > > <[email protected]> alias), and > > suggest specific text to add. I presume it would go in an new bullet > > just before the last. > > The thing I think is missing here is that the Authorization Server has a > stake in mitigating threats, and actually has a quite potent one: it can > be selective with whom it enrolls, and can revoke bad actors. > > So let me try a bullet: > > o While end users are mostly incapable of properly vetting applications they > load onto their devices, those who deploy Authorization Servers > have tools at > their disposal to mitigate malicious Clients. Namely, in order to > become a threat > at all, a Client must first become a Client. A well run > Authorization Server MAY > require a curation process when enrolling Clients, and SHOULD > have processes to > revoke bad actors after enrollment. > > Mike > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
