Overall, I much prefer the organization of this document, and I think it's going to make a lot more sense to implementers. My thoughts, per section:
1.2 "Tokens may be pure capabilities." To a non-security-engineer such as myself, this bit reads very oddly on its own. I understand that "capability" has another meaning in the security world, so can we either reference that definition or give a small prose example, like "capabilities, such as ...". 1.3 Should these introductions link down to their implementation sections? Seems like a useful xref. 1.3.2, 4.2 I'm not sold on calling this "Implicit", though "user agent" and "direct" aren't much better. 1.3.2 "round trip" should be "round trips" 1.3.4 Perhaps add something along the lines of "Client credentials are also useful inside of enterprise environments where there is a high degree of trust between applications, or for direct data exchange between systems with no explicit end users." 2. "client identified" should be "client identifier" Should we strengthen the first "SHOULD NOT" to a "MUST NOT", since this is about assumptions of security made by the AS? This is possibly bikeshedding as the AS could always still say "We know that the secret-storage security of some clients might be bad but that's OK." 3.2 Can we make the token endpoint MUST support POST and MAY support GET? I understand the arguments for favoring POST, but they don't always apply to all environments. (Brought this up a while ago, seems like it's not a breaking change to allow.) 4.2 While it doesn't use the full client credentials defined in section 2, it does still use the client identifier. The identifier is usually just one half of the credentialing pair. As the opening paragraph is worded now it's a bit confusing and makes it sounds like you don't need a client_id parameter at all (an assumption which is of course contradicted by 4.2.1). 5.2 "parameters are including" should be "parameters are included" [side note: should I revise the XML encoding to have an explicit example for error responses? I would still like to make the XML encoding extension a WG item and eventual RFC.] 6. I'd like to see a paragraph on redelegation practices, but I'm not sure it belongs in the core as it's really more of a way of *using* refresh tokens and scopes in a slightly different way than it is really a *new* thing. All the mechanisms are there to support it, a recipe just hasn't been written out for it. Is there desire for an extension doc for this? 8.2 Already talked about relaxing the MUST to SHOULD here under different cover, as this actually lines up better with text in other sections stating that the Auth and Token endpoints MAY have query-string parameters which MUST be preserved. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
