Draft: draft-ietf-gnap-core-protocol

Commentary: To edit notification comments on pull requests , go to your . _ 
 An AS may not always allow its client instances to rotate the keys , correct ? Therefore , client instances might " learn " whether it 's possible in advance , during ongoing negotiation with the AS specification may define a dedicated error that will basically tell the client instances , this operation is n't allowed Originally posted by in
Paragraph (version A):
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 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 (response-error).
Paragraph (version A):
"invalid_client" error or choose to return lesser levels of
privileges.  See additional discussion of client instance
impersonation in security-impersonation.
Paragraph (version B):
"invalid_client" error (response-error) or choose to return lesser
levels of privileges.  See additional discussion of client instance
impersonation in security-impersonation.
Paragraph (version A):
If the AS does not recognize the instance identifier, the request
MUST be rejected with an "invalid_client" error.
Paragraph (version B):
If the AS does not recognize the instance identifier, the request
MUST be rejected with an "invalid_client" error (response-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
"unknown_user" 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 (response-error).
Paragraph (version A):
If the AS does not recognize the user reference, it MUST return an
"unknown_user" error.
Paragraph (version B):
If the AS does not recognize the user reference, it MUST return an
"unknown_user" error (response-error).
Paragraph (version A):
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 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 (response-error) since the client
instance will be unable to complete the request without
authorization.
Paragraph (version A):
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 query
parameters to calculate and validate the hash value as described in
interaction-hash, or else return an "unknown_interaction" error
(response-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):
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 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 (response-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 "invalid_continuation" 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
(response-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 "too_fast" error 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 (response-
error).
Paragraph (version A):
If the AS determines that the client instance can make a further
continuation request, the AS MUST include a new response-continue.
The new "continue" response MUST include a continuation access token
as well, and this token SHOULD be a new access token, invalidating
the previous access token.  If the AS does not return a new
"continue" response, the client instance MUST NOT make an additional
continuation request.  If a client instance does so, the AS MUST
return an "invalid_continuation" error.
Paragraph (version B):
If the AS determines that the client instance can make a further
continuation request, the AS MUST include a new response-continue.
The new "continue" response MUST include a continuation access token
as well, and this token SHOULD be a new access token, invalidating
the previous access token.  If the AS does not return a new
"continue" response, the client instance MUST NOT make an additional
continuation request.  If a client instance does so, the AS MUST
return an "invalid_continuation" error (response-error).
Paragraph (version A):
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 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 (response-
error) and SHOULD invalidate the ongoing request.
Paragraph (version B):
If the AS is unable or unwilling to rotate the value of the access
token, the AS responds with an "invalid_rotation" error (response-
error).  Upon receiving such an error, the client instance SHOULD
consider the access token to not have changed its state.
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 a "invalid_rotation" error code returned from the AS.
Paragraph (version B):
Failure to present the appropriate proof of either the new key or the
previous key for the access token, as defined by the proof method,
MUST result in an "invalid_rotation" error code from the AS
(response-error).
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 an "invalid_rotation" error code returned from the AS
(response-error).
Paragraph (version B):
If the AS does not allow rotation of the access token's key for any
reason, including but not limited to lack of permission for this
client instance or lack of capability by the AS, the AS MUST return a
"key_rotation_not_supported" error code (response-error).
Paragraph (version A):
The information returned from this method is for optimization
purposes only.  The AS MAY deny any request, or any portion of a
request, even if it lists a capability as supported.  For example, a
given client instance can be registered with the "mtls" key proofing
mechanism, but the AS also returns other proofing methods from the
discovery document, then the AS will still deny a request from that
client instance using a different proofing mechanism.
Paragraph (version B):
The information returned from this method is for optimization
purposes only.  The AS MAY deny any request, or any portion of a
request, even if it lists a capability as supported.  For example, a
given client instance can be registered with the "mtls" key proofing
mechanism, but the AS also returns other proofing methods from the
discovery document, then the AS will still deny a request from that
client instance using a different proofing mechanism.  Similarly, an
AS with "key_rotation_supported" set to "true" can still deny any
request for rotating any access token's key for a variety of reasons.