> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Richer, Justin P. > Sent: Thursday, January 27, 2011 12:05 PM
> 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 ...". I dropped this. This means nothing to most people. I have no objection for this to be added in the security considerations section. > 1.3 > > Should these introductions link down to their implementation sections? > Seems like a useful xref. > > 1.3.2, 4.2 Nah. I want people to read the introduction as a whole, then just use the rest as reference. Jumping between sections is just confusing. > I'm not sold on calling this "Implicit", though "user agent" and "direct" > aren't > much better. It's descriptive. > 2. > > 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." I actually changed it to lowercase since it is not really normative. > 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.) It applies to the web as a whole. What you do internally is your business... Requiring POST removes the need to write security consideration about the issues with GET. > 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? >From my experience, writing a draft works better than asking for interest. I >am sure you'll find an audience. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
