Draft: draft-ietf-gnap-core-protocol

Commentary: To edit notification comments on pull requests , go to your . 
 Signaling Token Behavior :  '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 .  : 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 do n’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 does n’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 ca n’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 . 
 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 is n't enough for it to be in core , especially not without implementation experience . 
 I agree that there 's nothing in the protocol that does that as of today . I was thinking about why the AS can not 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 would n't say my implementation counts as it 's a POC . Please , note that RS1 and RS2 are n'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 .
Paragraph (version A):
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
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.
Paragraph (version B):
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
most recent rotation).  The token is labeled "token1-23".  The token
response structure is described in response-token-single.
Paragraph (version A):
If the client instance request-token-single, the AS MUST NOT respond
with the multiple access token structure unless the client instance
sends the "split" flag as described in request-token-single.
Paragraph (version A):
If the AS has split the access token response, the response MUST
include the "split" flag.
Paragraph (version B):
If the client instance request-token-single, the AS MUST NOT respond
with the multiple access token structure.
Paragraph (version A):
If the AS has split the access token response, the response MUST
include the "split" flag in the "flags" array.