Clarify redirection proposal. See #117.

Author: ioggstream

draft-ietf-oauth-v2-1.md

@@ -526,11 +526,13 @@ for certificate validation and other security considerations.
 
 This specification makes extensive use of HTTP redirections, in which
 the client or the authorization server directs the resource owner's
-user agent to another destination.  While the examples in this
-specification show the use of the HTTP 302 status code, any other
-method available via the user agent to accomplish this redirection, 
-with the exception of HTTP 307, is allowed and is considered to be an 
-implementation detail. See {{redirect_307}} for details.
+user agent to another destination.
+While this specification
+forbids the use of the 307 status code (see {{redirect_307}})
+and illustrates the use of the 302 status code,
+any other mechanism to accomplish the above redirection
+is legitimate and is considered as an implementation detail as long as
+it does not expose user credentials to untrusted parties.
 
 
 ## Interoperability
@@ -958,35 +960,37 @@ Extension grant types MAY define additional endpoints as needed.
 ## Authorization Endpoint
 
 The authorization endpoint is used to interact with the resource
-owner and obtain an authorization grant.  The authorization server
-MUST first verify the identity of the resource owner.  The way in
-which the authorization server authenticates the resource owner
+owner and obtain an authorization grant.  The AS
+MUST first authenticate the resource owner.  The way in
+which the AS authenticates the resource owner
 (e.g., username and password login, session cookies) is beyond the
 scope of this specification.
 
-The means through which the client obtains the location of the
+The means through which the client obtains the URL of the
 authorization endpoint are beyond the scope of this specification,
-but the location is typically provided in the service documentation,
+but the URL is typically provided in the service documentation,
 or in the authorization server's metadata document ({{RFC8414}}).
 
-The endpoint URI MAY include an "application/x-www-form-urlencoded"
+The authorization endpoint URL:
+
+- MUST NOT include a fragment component;
+- MAY include an "application/x-www-form-urlencoded"
 formatted (per Appendix B) query component ({{RFC3986}} Section 3.4),
-which MUST be retained when adding additional query parameters.  The
-endpoint URI MUST NOT include a fragment component.
+which MUST be retained when adding additional query parameters.
 
-The authorization server MUST support the use of the HTTP `GET`
-method {{RFC7231}} for the authorization endpoint and MAY support the
-use of the `POST` method as well.
+The authorization endpoint
+MUST support GET requests
+and MAY support POST requests.
 
-The authorization server MUST ignore unrecognized request parameters. 
+The authorization endpoint MUST ignore unrecognized request parameters.
 
 Request and response parameters
 defined by this specification MUST NOT be included more than once. 
 Parameters sent without a value MUST be treated as if they were
 omitted from the request.
 
-An authorization server that redirects a request potentially containing 
-user credentials MUST avoid forwarding these user credentials accidentally 
+An authorization endpoints that redirects a request potentially containing
+user credentials MUST NOT forward these credentials to untrusted parties
 (see {{redirect_307}} for details).
 
 ## Token Endpoint