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
