Original text:
If access is approved, the resulting access token is valid for the described resource and is bound to the client instance's key (or its <del> most recent rotation).  The token is labeled "token1-23" and could be split into multiple access tokens by the AS, if the AS chooses.  The token response structure is described in response-token-single. </del>  2.1.2. token with access to two described resources. If the client instance request-token-single, the AS MUST NOT respond <del> with the multiple access token structure unless the client instance sends the "split" flag as described in request-token-single. If the AS has split the access token response, the response MUST include the "split" flag. </del>  [[ See issue #69 [6] ]] access token is granted.  In such cases, the AS responds with a multiple access token structure containing one access token. <del> If the AS has split the access token response, the response MUST include the "split" flag in the "flags" array. </del> Each access token MAY be bound to different keys with different proofing mechanisms.

Reviewer comments:
To edit notification comments on pull requests, go to your .
Signaling Token Behavior: Editor's note: This functionality is controversial at best as it requires significantly more complexity on the client in order to solve one class of AS/RS deployment choices.
Yaron (referring to ): I suggest to extend the editor's note to clarify what is the use case, so that the group can decide whether split tokens are indeed necessary. Justin: I think we should have a more detailed conversation about this potential feature than an editor’s note could reasonably get into. There are a number of large items (splitting access tokens, directing access tokens to specific portions of API or RS’s, among others) that I think will be big conversations for the WG, and all the context of these don’t necessarily need to be documented inside the notes in the document itself. But for discussion and context, this feature was proposed to deal with cases where the AS might decide to issue several access tokens in any case where the client requested one, because the AS wants to have restricted audiences for individual access tokens but the client doesn’t know about the audiences ahead of time. I agree that it’s a compelling use case, and it puts security of the protected domains in the hands of the AS where it belongs, but it would require a client to be smart enough to know what to do with these tokens downstream, and if OAuth has taught us anything it’s that we can’t rely on client software to be smart about most anything. :)
See also
I always considered the "split_token" functionality as a nice addition to the protocol. It gets available for the client when it explicitly requests it + the AS can issue multiple ATs. Among other described scenarios above, I had in mind this particular one; let's say there are two almost identical RSs, the difference is only in the way how much you need to pay to use them, for example, our client wants to store video recordings, RS2 works a bit faster and guarantees more protection against data loss. At the same time, RS1 and RS2 belong to different organizations that have nothing in common + the client knows nothing about RS1 and RS2 in advance.
NAME For this scenario, you'd also need a way to explicitly direct the client instance to either RS1 or RS2 along with the token. There's nothing in the protocol that does that today (see ). Both of these could be handled as an extension. The current view of the editors is that this is a "nice to have", which isn't enough for it to be in core, especially not without implementation experience.
NAME I agree that there's nothing in the protocol that does that as of today. I was thinking about why the AS cannot pass a piece of the information along with an AT or ATs (for the split token feature) it issues. This is what would happen in my implementation of the AS and the client library (SDK). This piece of information is nothing more than a JSON object and it's assumed that the AS and the client both know how to deal with it (there is already a bright example of the information we pass in a similar fashion, it's "expires_in" parameter). I also assume that might have something like that. I wouldn't say my implementation counts as it's a POC. Please, note that RS1 and RS2 aren't mutually exclusive for the client in my example. The client may use them both at the same time. The client wants to store the video recordings and these RSs might do something meaningful with them even say in real-time. It's up to you to decide what and what not to have at the very core of the protocol. The split-token feature and seem to be controversial topics that might bring lots of complexity.

Revised text:
If access is approved, the resulting access token is valid for the described resource and is bound to the client instance's key (or its  <ins> most recent rotation).  The token is labeled "token1-23".  The token response structure is described in response-token-single. </ins> 2.1.2. token with access to two described resources. If the client instance request-token-single, the AS MUST NOT respond  <ins> with the multiple access token structure. </ins> [[ See issue #69 [6] ]] access token is granted.  In such cases, the AS responds with a multiple access token structure containing one access token.  Each access token MAY be bound to different keys with different proofing mechanisms.