Subject: [OAUTH-WG] Questions about sections 3.2/3.3

From: Yaron Goland <[email-masked]>
Date: Thu, 20 May 2010 19:19:53 +0000

I was reading through the spec and had some questions about 3.2 and 3.3 that I list below.
                Thanks,
                                Yaron
Section 3.2/3.3 - Handling requests without supported transport layer security

Although optional in section 3.2 and mandatory in section 3.3 both sections have a similar challenge - what happens if someone makes a request without the transport layer security required by the endpoint? What HTTP error is to be returned? 401? 403?

A further complication is that both sections explicitly allow for transport layer security solutions other than TLS/SSL. Doesn't this mean that we need to extend section 6.1's definition of the www-authenticate response header to also specify what transport layer security mechanisms are supported?

Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what version of TLS/SSL?

The specification currently states:

   ...the

   authorization server MUST require the use of a transport-layer

   mechanism such as TLS/SSL (or a secure channel with equivalent

   protections) when sending requests to the token endpoints.

To me this text implies that an OAuth server could be conformant and not implement TLS/SSL but instead implement some other transport-layer security mechanism (say a VPN protocol). From an interoperability perspective that seems problematic since it means clients can't know what transport-layer solution the token endpoint will support. Wouldn't it be reasonable to put in a requirement that all OAuth endpoints MUST support RFC 5246 and RFC 5746?

In other words the language could read: "...the authorization server MUST require the use of a transport-layer mechanism when sending requests to the token endpoints. Specifically, authorization servers MUST support version 1.2 of TLS as defined in RFC 5246 and extended in RFC 5746 and MAY support other equivalent secure channel mechanisms".

Section 3.3.1 - What error is returned if clients provide credentials in both the header and the body?

Section 3.3.1 explicitly prohibits submitting client credentials using multiple schemes but it doesn't define what error to return if this requirement is violated. Given the requirement in section 3.3.2.2 to include the "error" field wouldn't it be useful to define URIs that map to specific errors defined in the specification? For example, "If the client does include multiple client credential schemes then, per section 3.3.2.2, a 400 Bad Request response MUST be sent with an error code of urn:ietf:rfc:X:multiple-client-credentials".

Section 3.3.1 - How exactly are client credentials passed via HTTP Basic authentication?

Although section 3.3.1 states that HTTP basic authentication is to be supported, it doesn't specify how. I realize the mapping is pretty obvious but standards are one area where it pays off to be pedantic. Would it be useful to add language such as?:

"The authorization server MUST accept the client credentials using both the request parameters and the HTTP Basic authentication scheme as defined in [RFC2617]. When using HTTP Basic the client id MUST be mapped to the HTTP Basic userid and the client secret MUST be mapped to the HTTP Basic password. The realm value can either be discovered by sending an unauthenticated request and examining the returned realm value in the www-Authenticate header or by reading the authorization service's documentation."

---

From: Yaron Goland <[email-masked]>
Date: Wed, 26 May 2010 23:12:20 +0000

Since there was no response to this mail may I assume it went to /dev/null?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Goland
Sent: Thursday, May 20, 2010 12:20 PM
To: [email-masked]
Subject: [OAUTH-WG] Questions about sections 3.2/3.3

   ...the