Draft: draft-ietf-gnap-core-protocol

Commentary: fix running references , - move considerations text for assertions to correct section list formatting , changelog , link fixes , and general cleanup 
 Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview : 
 Top of Sec . 5 : I think in the plain text version this would be " to return a response { Section 3 } " but in the HTML rendering , this comes out incorrect . There are several more cases of this pattern . In Sec . 4 : 
 This pattern occurs for references that match the description , it seems . Each time we have a text like ' [ request ] ( # request ) ' or ' [ response ] ( # response ) ' ( without the space ) I suggest we always use a composite namespace , such as accessrequest or grantresponse to avoid the problem , but in we want this to be consistent , then many references will have to change as well ( sub sections ) would that be fine for you ?
Paragraph (version A):
end-user / AS: when the client supports it (see response-
interact), the end-user gets to interact with front-channel URLs
provided by the AS.
Paragraph (version B):
end-user / AS: when the client supports it (see response-
interact), the end-user gets to interact with front-channel URLs
provided by the AS.  See security-front-channel for some
considerations in trusting these interactions.
Paragraph (version A):
See security-assertions for considerations that the AS has to make
when accepting and processing assertions from the client instance.
Paragraph (version B):
See security-assertions for considerations that the client instance
has to make when accepting and processing assertions from the AS.
Paragraph (version A):
The AS will verify this presented information in the context of the
client instance's request and can only trust the information as much
as it trusts the presentation and context of the information.  If the
AS determines that the information presented in the initial request
is sufficient for granting the requested access, the AS MAY return
the positive results immediately in its response with access tokens
and subject information.
Paragraph (version B):
The AS will verify this presented information in the context of the
client instance's request and can only trust the information as much
as it trusts the presentation and context of the information.  If the
AS determines that the information presented in the initial request
is sufficient for granting the requested access, the AS MAY return
the positive results response with access tokens and subject
information.
Paragraph (version B):
If a "wait" parameter was included in the response-continue, the
client instance MUST NOT call the continuation URI prior to waiting
the number of seconds indicated.  If no "wait" period is indicated,
the client instance SHOULD wait at least 5 seconds.  If the client
instance does not respect the given wait period, the AS MUST return
an error.
Paragraph (version A):
example, if the request is a grant request [41], the AS needs to
compare the TLS client certificate presented at the TLS layer to the
key identified in the request body itself (either by value or through
a referenced identifier).
Paragraph (version B):
example, if the request is a grant request [40], the AS needs to
compare the TLS client certificate presented at the TLS layer to the
key identified in the request body itself (either by value or through
a referenced identifier).
Paragraph (version A):
The privacy considerations in this section are modeled after the list
of privacy threats in [RFC6973], "Privacy Considerations for Internet
Protocols", and either explain how these threats are mitigated or
advise how the threats relate to GNAP.
Paragraph (version B):
The privacy considerations in this section are modeled after the list
of privacy threats in RFC6973, "Privacy Considerations for Internet
Protocols", and either explain how these threats are mitigated or
advise how the threats relate to GNAP.