Draft: draft-ietf-gnap-core-protocol

Commentary: I do n't know much about the GNAP revocation plan , but it seems like having text specifying ' MUST < taskif possible ' is the same as SHOULD , per RFC 2119 . Maybe I 'm missing something :) I read the contributing doc , but if PRs as contributions are n't acceptable , please let me know . 
 PR text contributions are just fine , they fall under the IETF contribution guidelines . Thank you ! See and for discussion on token revocation . 
 Thanks , those both deal with token rotation ; not sure if that is different than token revocation / cancelling . It seems like the " MUST invalidate the current access token ... if possible " is used in a few different places . I see it in 5.5 , 6.1 , 6.2 . I guess I do n't understand what " MUST ... if possible " means from an implementation standpoint , other than " SHOULD " . ( If this has been discussed on the mailing list -- a quick search there did n't turn anything up . 
 The issues in question are specifically about what to do with old tokens under rotation circumstances , which falls under the same conversation as what to do with explicitly revoked tokens that 's addressed here . I linked those issues because the same discussion of " if possible " has been brought up in those places as well ( as you point out here ) . Before a PR like this is accepted with a normative change , we need to bring the proposal to the working group for consensus building . If you want to kick off the conversation on the list more quickly , please feel free to start a thread and link to this PR ! Why the " MUST if possible " phrasing ? Mostly because sometimes it 's impossible to revoke a token once it 's in flight . Some OAuth 2 systems today use self - contained access tokens , which by nature ca n't be revoked in any meaningful way . However , the requirement is that if the AS is able to revoke the tokens , then it does n't have a choice in doing so . If it 's impossible for the AS to fulfill the requirement , that 's ok , but the AS does n't get to just choose to not revoke the tokens , it just ca n't . To me this seems more than a SHOULD , but I could be wrong . 
 As currently written , this does read like a SHOULD . If we care a lot about token revocation , we can make it a MUST and totally disallow self - contained tokens . If we do n't , we need to clarify the situation , maybe by defining revocable vs. non - revocable tokens . And then say that in this instance , if the tokens are revocable , they MUST be revoked . 
 That was the intent of the text as it is right now . I kinda like the idea of " revocability " being a variable attribute on access tokens , as it allows us to talk about them in different ways . There 's currently a stub section in the document ( appendix B ) for talking about the data models , and this would be part of that discussion . 
 The idea of specifying whether tokens are revocable or not might be useful . We might want to illustrate when we 'd use one vs the other . One could imagine using non revocable tokens when the information is not critical , short lived and when maintaining state is not worth the trouble . Note that there 's the potential issue of allowing rotating these tokens , while not revoking them , hereby creating new tokens without falling into the classic flow . So probably we should limit that behavior . Revocable tokens would require that current tokens be revoked ( MUST ) when they 're rotated . 
 Rotating the Access Token :  's note : We could also use different verbs to signal whether or not the old token should be kept around or not , instead of using a token flag to do this . 
 Keep " MUST if possible " here . If you want two access tokens , use the grant API not the token rotation API . The rotation mechanism should be for getting a new value for an existing token and replacing it , not for minting entirely new separate tokens ( which is what the grant continuation / update API is for ) . We need to keep " if possible " for the case of using stateless tokens ( fully self - contained JWTs ) , and add a discussion on when it might not be possible . 
 Modifying an Existing Request :  's note : This might be subject to the " multi_token " flag , but since we 're creating a NEW access token and not rotating an existing one , this seems to be a different use case . There is a solid argument to be made for always revoking old access tokens here , but we need more discussion on the boundaries for such a requirement . If they stick around , it does make a " read " request weird because now we 've got multiple access tokens sticking around associated with a grant request and no good place to put them . 
 I do n't think we should put a strict requirement on revoking old access tokens , since it may be difficult or impossible in some implementations . At most this could be a " SHOULD " or " RECOMMENDED " .
Paragraph (version A):
If the request is successfully cancelled, the AS responds with an
HTTP 202.  The AS MUST revoke all associated access tokens, if
possible.
Paragraph (version B):
If the request is successfully cancelled, the AS responds with an
HTTP 202.  The AS SHOULD revoke all associated access tokens.