Draft: draft-ietf-gnap-core-protocol

Commentary: This issue also checks all errors : in section 1 : when referring to errors , it is a generic term / no change needed same in the security considerations elsewhere we aim to have specific errors 
 To edit notification comments on pull requests , go to your . 
 This does n't build , will look at that tomorrow 
 : the build errors are due to the IANA section anchors being changed : you have a reference to the ( old ) which should now be , and you need to update the anchor for to . I only see those two but do a text search on those anchors . 
 thanks for the hint , i 'll fix that 
 Error Response : Editor 's note : I think we will need a more robust error mechanism , and we need to be more clear about what error states are allowed in what circumstances . Additionally , is the " error " parameter exclusive with others in the return ? 
 As a starting point , I would suggest adding these sentences The error code parameter MUST be required and its value SHOULD be limited to ASCII characters . The error code indicates that a request is malformed . The AS MUST return an HTTP 401 ( Unauthorized ) status code to indicate that it ca n't identify a client instance ( the error code can be ) . The AS MUST return an HTTP 401 ( Unauthorized ) status code to indicate that it ca n't authenticate a client instance ( the error code can be ) . The AS MAY uncover additional information about the cause of the error when it can authenticate a client instance ( the error code can be , , and so on ) . 
 Addressed by , still need error codes for things like token management . 
 The type of the of the error property in a response is currently ambiguous . In section 3 it is defined as an and in section 3.6 it is defined as a . 
 thanks for catching that -- looks like both " error " and " errordescription " should be to the list of parameters . I think the intent might have been for the value of " error " to be an object with " errorcode " and " error_description " fields inside of it though , so it might be better to align things in that direction instead . Do you have thoughts on which is preferable ? Interop testing of error conditions is really difficult in practice , so this is a great catch !
Paragraph (version B):
To request multiple access tokens to be returned in a single
response, the client instance sends an array of objects as the value
of the "access_token" parameter.  Each object MUST conform to the
request format for a single access token request, as specified in
request-token-single.  Additionally, each object in the array MUST
include the "label" field, and all values of these fields MUST be
unique within the request.  If the client instance does not include a
"label" value for any entry in the array, or the values of the
"label" field are not unique within the array, the AS MUST return an
"invalid_request" error.
Paragraph (version A):
If the AS does not recognize the instance identifier, the request
MUST be rejected with an error.
Paragraph (version B):
If the AS does not recognize the instance identifier, the request
MUST be rejected with an "invalid_client" error.
Paragraph (version A):
If the identified end user does not match the RO present at the AS
during an interaction step, the AS SHOULD reject the request with an
error.
Paragraph (version B):
If the identified end user does not match the RO present at the AS
during an interaction step, the AS SHOULD reject the request with an
"unknown_user" error.
Paragraph (version A):
If the AS does not recognize the user reference, it MUST return an
error.
Paragraph (version B):
If the AS does not recognize the user reference, it MUST return an
"unknown_user" error.
Paragraph (version B):
If the client instance does not provide a suitable interaction
mechanism, the AS cannot contact the RO asynchronously, and the AS
determines that interaction is required, then the AS SHOULD return an
"invalid_interaction" error since the client instance will be unable
to complete the request without authorization.
Paragraph (version B):
If the AS determines that the request cannot be issued for any
reason, it responds to the client instance with an "error" response.
Paragraph (version B):
When the RO enters this code at the user code URI, the AS MUST
uniquely identify the pending request that the code was associated
with.  If the AS does not recognize the entered code, the interaction
component MUST display an error to the user.  If the AS detects too
many unrecognized code enter attempts, the interaction component
SHOULD display an error to the user indicating too many attempts and
MAY take additional actions such as slowing down the input
interactions.  The user should be warned as such an error state is
approached, if possible.
Paragraph (version A):
When the RO enters this code at the given URI, the AS MUST uniquely
identify the pending request that the code was associated with.  If
the AS does not recognize the entered code, the interaction component
MUST display an error to the user.  If the AS detects too many
unrecognized code enter attempts, the interaction component SHOULD
display an error to the user and MAY take additional actions such as
slowing down the input interactions.  The user should be warned as
such an error state is approached, if possible.
Paragraph (version B):
When the RO enters this code at the given URI, the AS MUST uniquely
identify the pending request that the code was associated with.  If
the AS does not recognize the entered code, the interaction component
MUST display an error to the user.  If the AS detects too many
unrecognized code enter attempts, the interaction component SHOULD
display an error to the user indicating too many attempts and MAY
take additional actions such as slowing down the input interactions.
The user should be warned as such an error state is approached, if
possible.
Paragraph (version B):
When receiving the request, the client instance MUST parse the query
parameters to calculate and validate the hash value as described in
interaction-hash, or else return an "unknown_interaction" error.  If
the hash validates, the client instance sends a continuation request
to the AS as described in continue-after-interaction using the
interaction reference value received here.
Paragraph (version B):
When receiving the request, the client instance MUST parse the JSON
object and validate the hash value as described in interaction-hash,
or else return an "unknown_interaction" error.  If the hash
validates, the client instance sends a continuation request to the AS
as described in continue-after-interaction using the interaction
reference value received here.
Paragraph (version A):
The AS MUST be able to tell from the client instance's request which
specific ongoing request is being accessed, using a combination of
the continuation URI, the provided continuation access token, and the
client instance identified by the key signature.  If the AS cannot
determine a single active grant request to map the continuation
request to, the AS MUST return an error.
Paragraph (version B):
The AS MUST be able to tell from the client instance's request which
specific ongoing request is being accessed, using a combination of
the continuation URI, the provided continuation access token, and the
client instance identified by the key signature.  If the AS cannot
determine a single active grant request to map the continuation
request to, the AS MUST return an "invalid_continuation" error.
Paragraph (version A):
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 MUST NOT poll immediately and SHOULD wait at
least 5 seconds.  If the client instance does not respect the given
wait period, the AS MUST return the error "too_fast" defined in
response-error.
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 MUST NOT poll immediately and SHOULD wait at
least 5 seconds.  If the client instance does not respect the given
wait period, the AS MUST return the "too_fast" error defined in
response-error.
Paragraph (version B):
Since the interaction reference is a one-time-use value as described
in interaction-callback, if the client instance needs to make
additional continuation calls after this request, the client instance
MUST NOT include the interaction reference.  If the AS detects a
client instance submitting the same interaction reference multiple
times, the AS MUST return a "too_many_attempts" error and SHOULD
invalidate the ongoing request.
Paragraph (version A):
An attempt to change the "proof" method or parameters, including an
attempt to rotate the key of a bearer token (which has no key), MUST
result in an error returned from the AS.
Paragraph (version B):
An attempt to change the "proof" method or parameters, including an
attempt to rotate the key of a bearer token (which has no key), MUST
result in a "invalid_rotation" error code returned from the AS.
Paragraph (version A):
The client software MUST reject as an error a situation where the
"flags" field contains the "bearer" flag and the "key" field is
present with any value.
Paragraph (version B):
The client software MUST reject as an "invalid_flag" error a
situation where the "flags" field contains the "bearer" flag and the
"key" field is present with any value.
Paragraph (version A):
This document defines a set of errors that the AS can return to the
client instance, for which IANA is asked to create and maintain a new
registry titled "Error Responses".  Initial values for this registry
are given in IANA-error-response-contents.  Future assignments and
modifications to existing assignment are to be made through the
Expert Review registration policy RFC8126 and shall follow the
template presented in IANA-error-response-template.
Paragraph (version B):
This document defines a set of errors that the AS can return to the
client instance, for which IANA is asked to create and maintain a new
registry titled "Error Codes".  Initial values for this registry are
given in IANA-error-code-contents.  Future assignments and
modifications to existing assignment are to be made through the
Expert Review registration policy RFC8126 and shall follow the
template presented in IANA-error-code-template.