[OAUTH-WG] comments on draft-hammer-oauth-03

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<hat type='individual'/>

On the flight to Japan for IETF 76, I finally got a chance to finish
reviewing draft-hammer-oauth-03, the informational documentation of
what's known as "OAUth Core 1.0 Revision A" in the community. Many of my
comments are purely editorial, so I will send those directly to the
document editor. Here are a few slightly more substantive issues...

1. I think it would be very helpful to provide a bit more context in the
Introduction. Say, two or three sentences about the provenance of this
technology, the community that developed it, and a link to oauth.net
(along with something like the final paragraph of the current
Introduction). Something like this:

  The OAuth protocol was originally created by a loose group of
  technologists from a variety of websites and other Internet
  services, who wanted to solve the common problem of enabling
  delegated access to protected resources.  The resulting OAuth
  protocol was stabilized at version 1.0 in October 2007 and
  published at the oauth.net website.  This specification provides
  informational documentation of OAuth Core 1.0 Revision A as
  finalized in June 2009, incorporating several errata reported
  since that time as well as numerous editorial clarifications.
  It is not an item of the IETF's OAuth Working Group, which at
  the time of writing is working on an OAuth version that can be
  appropriate for publication on the standards track.

2. In the Terminology section, I think it might be helpful to provide
pointers to the old terminology, as in:

  "(In the community edition, a client was called a consumer.)"

We might also want to point to RFC 4949 regarding terminology and check
that our usage of key terms like "authorization" is consistent with that
document.

3. Before jumping right into authenticated requests in section 3, I
think it would be helpful to provide a bit more context about the
overall protocol flow (similar to Section 6 of the community edition).

4. In Section 3.1, we might want to say explicitly which parameters are
required and which are not. For example, "Protocol parameters MUST NOT
appear more than once per request. The following parameters are REQUIRED
unless otherwise noted." Then say that, for example, oauth_version is
RECOMMENDED instead of REQUIRED (or whatever).

5. In Section 3.2, it's not completely clear that the timestamp value
must be numerical instead of, say, in ISO 8601 format. It's also not
clear how the server would specify that the timestamp is something other
than "the number of seconds since January 1, 1970 00:00:00 GMT".

6. In Section 3.2, let's explicitly say that methods that enable the
client to sync its clock with the server's clock are out of scope for OAuth.

7. In Section 3.3, let's refer to the Security Considerations from the
paragraph about not mandating a particular signature method (since
that's where we talk about the properties of various methods).

8. In Section 3.3.1.1, we might want to be more explicit about which
parameters are included in the "specific set of request parameters" (see
recent discussion on the community list).

9. In Section 3.3.1.1 second bullet point, we say "The HTTP request
entity-body, but only if..." -- does this mean that all of the three
listed conditions need to be met, or any one of the conditions?

10. In Section 3.3.1.1, the sentence

    The "oauth_signature" parameter MUST be excluded if present.

might be taken to imply that all other oauth_* parameters MUST be
included (if found in the request). Let's be explicit about that.

11. In Section 3.3.4, we say that PLAINTEXT method SHOULD be used with
SSL/TLS. Does that deserve to be a MUST? At least it might be worth a
mention in the Security Considerations.

12. In Section 3.6, we say that "Text values are first encoded as UTF-8"
but it's not fully clear to me which values this applies to or exactly
where in the protocol the encoding rules are applied.

13. In Section 4, I think that a brief flow diagram would be helpful to
illustrate the authorization process (e.g., this would provide context
for why the client obtains a set of temporary credentials, which might
not otherwise be obivous to first-time readers of Section 4.1).

14. In Section 4.2 (or in a security consideration pointed to from
Section 4.2), it might be helpful to describe why oauth_callback is
important and the nature of the session fixation attach that it helps to
prevent.

15. In Section 6.8, I think there is a non-sequitur. Just because a
client is a freely available desktop application does not mean that an
attacker will be able to recover the client credentials. Perhaps one
step in the chain of reasoning is not spelled out here?

16. Section 6.15 says:

    Clients should prevent CSRF attacks on OAuth callback URIs
    by verifying that the resource owner at the client site intended to
    complete the OAuth negotiation with the server.

No guidance is provided on how the client might be able to do so. Saying
that "methods for doing so are out of scope for this specification" is
probably acceptable.

17. In Appendix A.1 the phrase "HTTPS POST" is used, but I think that's
more accurately an HTTP POST to an SSL-protected host.

Overall the spec looks very good, and IMHO is a big improvement over the
community edition!

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4lD0ACgkQNL8k5A2w/vzkJwCfeOy6ZH1u8La20llLhgksyb4T
mOYAoPrGjaVIL9w801IuguP3161i2X0/
=tN+p
-----END PGP SIGNATURE-----