Draft: draft-ietf-gnap-core-protocol

Commentary: match the flags array in the token request . While this is technically a breaking change , I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in . 
 : heavycheckmark : Deploy Preview for gnap - core - protocol - editors - draft ready ! Built : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview : 
 You know , I had that thought , and I checked the request section and it does n't have quotes . I 'm going to add the quotes to both parts . This ended up with some other language changing , not just the examples , so let me know what you think .
Paragraph (version A):
RECOMMENDED.  Flag indicating if the token is bound to the client
instance's key.  If the boolean value is "true" or the field is
omitted, and the "key" field is omitted, the token is bound to the
request-client in its request for access.  If the boolean value is
"true" or the field is omitted, and the "key" field is present,
the token is bound to the key and proofing mechanism indicated in
the "key" field.  If the boolean value is "false", the token is a
bearer token with no key bound to it and the "key" field MUST be
omitted.
Paragraph (version A):
OPTIONAL.  Flag indicating a hint of AS behavior on token
rotation.  If this flag is set to the value "true", then the
client instance can expect a previously-issued access token to
continue to work after it has been rotate-access-token or the
underlying grant request has been continue-modify, resulting in
the issuance of new access tokens.  If this flag is set to the
boolean value "false" or is omitted, the client instance can
anticipate a given access token will stop working after token
rotation or grant request modification.  Note that a token flagged
as "durable" can still expire or be revoked through any normal
means.
Paragraph (version B):
OPTIONAL.  A set of flags that represent attributes or behaviors
of the access token issued by the AS.
Paragraph (version B):
This flag indicates whether the token is bound to the client
instance's key.  If the "bearer" flag is present, the access token
is a bearer token, and the "key" field in this response MUST be
omitted.  If the "bearer" flag is omitted and the "key" field in
this response is omitted, the token is bound the request-client in
its request for access.  If the "bearer" flag is omitted, and the
"key" field is present, the token is bound to the key and proofing
mechanism indicated in the "key" field.
Paragraph (version B):
OPTIONAL.  Flag indicating a hint of AS behavior on token
rotation.  If this flag is present, then the client instance can
expect a previously-issued access token to continue to work after
it has been rotate-access-token or the underlying grant request
has been continue-modify, resulting in the issuance of new access
tokens.  If this flag is omitted, the client instance can
anticipate a given access token will stop working after token
rotation or grant request modification.  Note that a token flagged
as "durable" can still expire or be revoked through any normal
means.
Paragraph (version B):
Flag values MUST NOT be included more than once.
Paragraph (version B):
Additional flags can be defined by extensions using IANA.
Paragraph (version B):
If the AS has split the access token response, the response MUST
include the "split" flag.
Paragraph (version B):
If the AS has split the access token response, the response MUST
include the "split" flag in the "flags" array.