Re: [OAUTH-WG] Draft -12 feedback deadline

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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