Change:
Adds registry and discussion for access token formats and where they could be used in the protocol, particularly as part of discovery from the AS. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 99546a7caad92bf2495cb9416f5e4604f9fcc7c0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Section 3.1 mentions: A sub-section describing the structure of this list of token formats is currently missing.
In section 2. Access Token Formats, the text states: Token formats can be the topic of agreements between the AS and RS , if the AS has prior relationships with every RS. However, it should be mentioned that the access token format can also be negotiated. Add:
The negotiation is between the AS and RS, not the client. This spec is about negotiation between the AS and RS.

Discussion:
have some means of understanding what the access token is for in order to determine how to respond to the request.  The core GNAP protocol makes no assumptions or demands on the format or contents of <del> the access token, but such token formats can be the topic of agreements between the AS and RS. </del> <ins> the access token, and in fact the token format and contents are opaque to the client instance.  However, such token formats can be the topic of agreements between the AS and RS. </ins> Self-contained structured token formats allow for the conveyance of information between the AS and RS without requiring the RS to call <del> the AS at runtime as described in introspection. </del> <ins> the AS at runtime as described in introspection.  Structured tokens can also be used in combination with introspection, allowing the token itself to carry one class of information and the introspection response to carry another. </ins> Some token formats, such as Macaroons and Biscuits, allow for the RS to derive sub-tokens without having to call the AS as described in token-chaining. <ins> The supported token formats can be communicated dynamically at runtime between the AS and RS in several places. The AS can declare its supported token formats as part of RS- facing discovery The RS can require a specific token format be used to access a registered resource set The AS can return the token's format in an introspection response In all places where the token format is listed explicitly, it MUST be one of the registered values in the GNAP Token Formats Registry iana- token-format. </ins> 3. To facilitate runtime and dynamic connections, the AS can offer an

be https, a host component, and optionally, port, path and query components and no fragment components. <del> A list of token formats supported by this AS. </del> <ins> A list of token formats supported by this AS.  The values in this list MUST be registered in the GNAP Token Format Registry. </ins> The URL of the endpoint offering resource registration.  The location MUST be a URL RFC3986 with a scheme component that MUST

[[ TBD: There are a lot of items in the document that are expandable through the use of value registries. ]] <ins> 5.1. This specification establishes the GNAP Token Format Registry to define token formats. 5.1.1. 5.1.2. The table below contains the initial contents of the GNAP Token Format Registry. </ins> 6. [[ TBD: There are a lot of security considerations to add. ]]