OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-08

I am ballotting No Objection based ona quick read and assuming that the
Applications and Security ADs have done their jobs.

I think having all of this analysis written down is fine, but I'm not convinced this document will end up being useful. It's quite a bit of information in a form that I'm not sure any implementer will be able to get through and act on. But I certainly don't think we should dispose of all of this information. I just wish there was more meat on these bones. In particular:


Introduction:

   Note: This document cannot assess the probability nor the risk
   associated with a particular threat because those aspects strongly
   depend on the particular application and deployment OAuth is used to
   protect.

While this may be generally true, I do think it's possible to assess some sort of relative risk between this massive list of threats. I find the lack of such an assessment, along with the sheer volume of this document, makes the document significantly less useful than it might be.

A few small comments on some earlier bits of the document that I hope will be useful for edits throughout the document, but if they don't get done, the world will not end:

3.7 says:

   Deployment-independent client_id with pre-registered redirect_uri and
   with client_secret  This is an option for native applications only,
      since web application would require different redirect URIs.  This
      category is not advisable because the client secret cannot be
      protected appropriately (see Section 4.1.1).
      
You bet it's not advisable. :-) And I think that itself is a fine thing to say. But then 4.1.1 goes on to say:

   Attack: Obtain Secret From Source Code or Binary:

   This applies for all client types.

It does? I thought it only applied to client types that are pre-configured with client secrets? Then in the Countermeasures, it says:

   Countermeasures:

   o  Don't issue secrets to public clients or clients with
      inappropriate security policy - Section 5.2.3.1

OK, but that's effectively "don't use this deployment model", right?

   o  Public clients require user consent - Section 5.2.3.2

That's worded badly. Do you mean, "Require user consent" as the counter measure?

   o  Use deployment-specific client secrets - Section 5.2.3.4

Isn't this identical to the first bullet?

   o  Client secret revocation - Section 5.2.3.6

That's not worded as a countermeasure. Do you mean, "Routinely revoke client secrets"? How can you do secret revocation without disabling entire implementations?

In general, throughout the document, there are lots of things labeled "countermeasures" that are worded in noun form instead of verb form.  For example, in 4.1.2 you have listed as a countermeasure:

  o  Limited scope tokens - Section 5.1.5.1

It would be much clearer if these were all reworded as the action one should take, not the topic area regarding the counter measure.

(If I have additional time, I'll add to this list of comments.)

I've cleared.  Thanks for addressing my discusses.

On the basis of a quick scan of the text I can see no Routing issues with this document and am thus taking a position of no objection.