Hi David,
I have a couple of questions/comments:
§2 - The flows use shared secrets for client authentication only. What
about adding support for public-key-based signatures for that purpose as
an alternative? That's one of the use cases on
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
§2.4 - Looks like a POST-Request in combination with a password-based
user authentication. What about using a standard BASIC Authorization
Header instead of oauth_username and oauth_password? In that way,
existing code for BASIC-Authentication can easily be ported to OAUTH.
§3
- Why is the parameter oauth_client_secret required for refreshing
access tokens? Use cases 2.2 and 2.3 do not require the client to use
(possess) a secret. Does this imply such client are not entitled to
refresh tokens? I would suggest to simply remove this parameter.
- Why is the refresh method the only way to obtain token secrets? This
forces every client needing a token secret to perform two calls (and get
a useless access token in the first call). I would suggest to add the
parameter oauth_want_secret to all flows in §2.
- "If an access token secret is included in the response, the protected
resource MUST NOT allow the use of the corresponding access token
without its secret .... " Why is that neccessary?
- response value oauth_signature_methods: Why is it the obligation of an
autorization server to know the signature methods a protected resource
supports? IMHO this is a question of the protocol between client and
protected resource and the client should pass in to the request the
desired signature method. In that way the authorization server is able
to create adequate secret.
§4.1 Why do you want to enforce such a strong coupling between bearer
tokens and TLS per spec? I would recommend to split protocol definition
and security considerations as in RFC2617. There, BASIC authentication
is defined without any references to transport security mechanisms and
the relevant considerations/recommandations are discussed in the
security consideration section. IMHO this would simplify the
specification because bearer token requests and requests w/ access
tokens + signature would just be variant of the same protocol definition.
§4.2.2 The WWW-Authenticate header does not give the client any hint
what signature methods to use. How shall the client that information obtain?
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
