Draft: draft-ietf-gnap-core-protocol

Commentary: Based on the 
 Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview : 
 Looks good , although there seems to be some whitespace issues and will need a new line in document history 
 The changes to the whitespace are made automatically by any editor that respects the editorconfig file . I can undo them , but for anyone who wants to make changes in the future with an editor that respects editorconfig , those changes will then be made again automatically . Presumably these whitespace issues should be fixed by a separate commit in the main branch if the editorconfig file is to continue to be used . 
 Please remove the changes to only whitespace so as not to bury the text contributions . Please see individual comments below for suggested new wording for the contributed text . Thank you !
Paragraph (version A):
The means of directing the RO to this URL are outside the scope of
this specification, but common options include redirecting the RO
from a web page and launching the system browser with the target URL.
Paragraph (version B):
The means of directing the RO to this URL are outside the scope of
this specification, but common options include redirecting the RO
from a web page and launching the system browser with the target URL.
See security-redirect-status-codes for considerations on which HTTP
status code to use when redirecting a request that potentially
contains credentials.
Paragraph (version B):
As already described in I-D.ietf-oauth-security-topics, a server
should never use the HTTP 307 status code to redirect a request that
potentially contains user credentials.  If an HTTP redirect is used
for such a request, the HTTP status code 303 "See Other" should be
used instead.
Paragraph (version B):
The status code 307, as defined in the HTTP standard RFC7231,
requires the user agent to preserve the method and body of a request,
thus submitting the body of the POST request to the redirect target.
In the HTTP standard RFC7231, only the status code 303 unambiguously
enforces rewriting the HTTP POST request to an HTTP GET request,
which eliminates the POST body from the redirected request.  For all
other status codes, including status code 302, user agents are
allowed not to rewrite a POST request into a GET request and thus to
resubmit the body.
Paragraph (version B):
The use of status code 307 results in a vulnerability when using the
response-interact-finish.  With this method, the AS potentially
prompts the RO to enter their credentials in a form that is then
submitted back to the AS (using an HTTP POST request).  The AS checks
the credentials and, if successful, may directly redirect the RO to
the client instance's redirect URI.  Due to the use of status code
307, the RO's user agent now transmits the RO's credentials to the
client instance.  A malicious client instance can then use the
obtained credentials to impersonate the RO at the AS.
Paragraph (version B):
Redirection away from the initial URL in an interaction session could
also leak information found in that initial URL through the HTTP
"Referer" header field, which would be sent by the user agent to the
redirect target.  To avoid such leakage, a server can first redirect
to an internal interstitial page without any identifying or sensitive
information on the URL before processing the request.  When the user
agent is ultimately redirected from this page, no part of the
original interaction URL will be found in the Referrer header.