Re: [OAUTH-WG] MAC Token Comments

I'll take a swag and your comment on #5.  Based on the current abstract of the OAuth 2.0 spec
The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

Which I find somewhat obtuse, how about:

The OAuth 2.0 authorization protocol provides an authentication framework 
supporting multiple HTTP authorization schemes.  This allows a user to
grant (limited) HTTP service access to an application on behalf of 
the user or to a third party application to use on it's own behalf.

The Bearer token spec, for example, could include that text and state it is an authorization scheme usable within the OAuth 2 framework.

-bill

________________________________
From: Justin Richer <jricher@mitre.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Cc: "Anganes, Amanda L" <aanganes@mitre.org>
Sent: Friday, August 12, 2011 11:43 AM
Subject: [OAUTH-WG] MAC Token Comments

2: MAC Key: "The server MUST NOT reissue a previously issued MAC key and
MAC key identifier combination." 

3: I would still like to see a binding for post body and url parameters.
This could be as simple as defining a set of parameter names for
everything used in the auth header, but I'm still given the impression
that this has been deemed outside the scope of the MAC token. Our use
case is to pass around signed URLs between servers with all query
parameters protected by the signature, which we use 2-legged OAuth 1.0
for today. We can try to get language for this together if there's
enough draw for it, but I haven't been hearing that from other folks yet
so we might just try to draft an extension to the extension, instead.

5: This section's wording should be brought more in line with the
descriptions of the OAuth protocol in both core and bearer, which in
turn should actually be a bit closer together themselves. Seems like we
need a succinct elevator pitch for "what is OAuth2" to drop into all of
these locations (and other extension specs) -- anybody want to take a
crack at distilling one from these three sources?

7.9: Grammar tweak: "Those designing additional methods should evaluate 
    the compatibility of the normalized request string with their 
    own security requirements."

-- Justin Richer

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth