Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel

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

oauth-bounces@ietf.org wrote on 23/04/2012 17:09:11:

> From:
>
> Michael Thomas <mike@mtcc.com>
>
> To:
>
> Barry Leiba <barryleiba@computer.org>, "oauth@ietf.org" <oauth@ietf.org>
>
> Date:
>
> 23/04/2012 17:09
>
> Subject:
>
> Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
>
> Sent by:
>
> oauth-bounces@ietf.org
>
> [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
> > <draft-ietf-oauth-v2-threatmodel.all@tools.ietf.org> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>