Draft: draft-ietf-gnap-core-protocol

Commentary: Reading the state of a request ( ) - removes section 5.4 Updating and reading access tokens ( ) Remove the links to already closed issues in the spec ( < strikeissues , , < /strike , , ) Update the list of high level changes for upcoming version 4 in appendix A 
 Deploy preview for gnap - core - protocol - editors - draft ready ! Built with commit https://deploy - preview-170 - -gnap - core - protocol - editors- 
 Guys , please do n't mix editorial and technical commits in the same PR . 
 On second read , I realize I missed a change and I agree with Yaron : this PR should not remove issue links to unrelated issues . Those should be in a separate PR . 
 OK we can split , I 'll reverse the removal of other links ( tbh did n't seem like something worth doing separately , but no problem for a separate cleanup if that seems better ) 
 Change done , only 98 and 99 are now concerned ( issues to be closed once the merge is approved ) . 
 I 'm a bit late as this has already been approved . I 'm ok with the text being removed , but I do think we need to address 
 Several contributors (  , Warren ) asked whether there should be a persistent identifier of the grant . See discussion on the mailing list as a starting point (  ) (  ) Before we dive into a potential technical solution , we should review the related use cases . Is it a problem if we do n't have an identifier ( or more precisely does it need to be exposed ) ? What kind of operations would we do with it ? 
 I guess that would mean that we 'd provide a uri specific to the grantid , for instance generated through = grantID = " FF0faxylE7eceWpZNmeW " ( in this example ) In the response : " continue " : { " accesstoken " : { xxxx } " uri " : " " } which is then the uri to be used for continuation ( or management ) ? 
 The URI for the grant API need n't be the same as the identifier for the ongoing grant itself , and I do n't see a good argument for forcing these two concepts to be tied together . Currently the access token is being used as an identifier , and I do n't see a good reason for that being tied together either . Perhaps we need something as simple as a separate identifier ? 
 Yes , it 's a possibility , the question is : what will this identifier be used for , precisely ? ( see issue too ) 
 So far that use case ( extending and referencing an existing grant ) is the only use case I 've seen for an externalized identifier . That function was put in as an effort to support some of the advanced use cases that have been brought up . It 's possible that this is a separable function that could go into an extension . 
 So use cases for grant identifiers , getting an existing grant status , etc . are : a client to update an existing grant a status of a grant from the AS - e.g. how long left before access expires ( this can be dynamic in some environments and is useful for the client to know ) Some work underway in this area ( with a customer requirement ): 
 Interesting . The grant management API in the fapi document does n't allow updates , only queries and revoke , though . 
 We can do most of those things without having an explicit external grant identifier , it all depends on how the API to do these actions is designed . 
 A grant identifier is not needed in the core protocol . However : editors suggest to write a small companion extension specification to define the use of a grant identifier and an " existing grant " reference to be used for a new request . See also 
 Detached JWS :  's note : It 's not the usual practice to put additional information into the header of a JWS , but this keeps us from having to normalize the body serialization . Alternatively , we could add all these fields to the body of the request , but then it gets awkward for non - body requests like GET / DELETE . Attached JWS :  's note : It 's not the usual practice to put additional information into the header of a JWS , but this keeps us from having to modify the body to use this signature method . Alternatively , we could add all these fields to the body of the request , but then it gets awkward for non - body requests like GET / DELETE . 
 This is a design choice . What ca n't be done or what is made difficult by what is currently in the text ? Please advise or will be closed . 
 Needs to be referenced in - there are definite trade - offs with the different signature options and they need to be considered 
 Token Management :  's note : Should we allow for " update " to an access token by the client posting new information from a " request " ? It seems this might make things weird since an access token is generally considered an unchanging thing , and the client could always request a new access token if they 're allowed to continue the grant request post - issuance as in Section 5.3 . There 's also a possibility of being able to " read " a token 's state with a GET , much like token introspection but using the token's / client 's key instead of the RS key . But would a client need to " read " a token state after issuance ? Is there a security risk to offering that functionality ? Introspection is nearly always relegated to RS calls in practice since the client is focused on using the token at the RS . The client can always read the state of the grant itself , separately . 
 See also discussion on " read " action at 
 Tokens are meant to be immutable . So update is not in the scope of what we want to do . Read access : we do n't see any compelling reason to allow read access + might be an issue for privacy . Please clarify how the mecanism would work , especially with privacy considerations . Marked as need text . Without additional text , this section will be removed in a future update . 
 Closing the issue following the merge of the PR 
 Getting the Current State of a Grant Request :  's note : I 'm a little dubious about the need for this particular function in reality , but including it for completeness sake . There are a lot of questions we need to answer , such as whether it 's safe to include access tokens and claims in the response of this kind of " read " at all , and whether it makes sense to include items like interaction nonces in the response . This discussion should be driven by the use cases calling for this " read " functionality . There have been similar functions within proprietary protocols where the client calls an endpoint at the AS to figure out where the user is in the interaction process at the AS , letting the client provide a smarter UI . It does n't seem like we could do that in depth here since it would be highly application specific , but that might be a good example of how to extend a response and give a client extra information . 
 Editors suggest this section requires additional text to explain why this action is needed and under what circumstances . Without additional text , this section will be removed in a future update . 
 Closing the issue following the merge of the PR 
 Receive a Callback After Interaction : Editor 's note : Should we enforce the callback URI to be unique per request ? That helps with some fixation attacks , but not with others , and it would be problematic for an AS that wants to lock down each client instance to a single callback instead of a family / pattern of callbacks . 
 Editors suggest closing as there are valid reasons for an AS to require an exact match of a single callback URI , such as establishing a client 's identity without any pre - registration . 
 What are the attacks that are still possible with a unique callback URL ? AS already lock down from a family or URLs . Or the callback could be a fixed URL with a parameter that makes the URL unique . 
 The question in this issue is whether to require unique URLs , or whether the current text that allows stable URLs as well as unique URLs is okay . Stable redirect URLs have a number of advantages , such as being able to be compared with exact string matching rather than needing to parse the URL and compare host / path / query / etc components . If the AS needs to be able to parse the URL , that opens up a whole world of that are avoided with simple string matching .
Mailing list commentary: A string that can be used to identify the grant in order to get its latest status , continue , update , revoke . Internally an AS will have an identifier for a grant Internally an RC will have an identifier for a grant Why ca n't we just make this explicit in the protocol . In the current world of OAuth 2 we have refresh token PAR devicecode in OAuth Device Flow grant management authreqid in CIBA " consent ids " in proprietary APIs They all somehow represent the " grant " , but the fact that most of them are tacked on to the existing protocol , causes problems . I really like the fact that GNAP has the current " continue " endpoint built into the spec - allowing " grant management " to be a first class feature of the protocol . But I do n't like the fact that an ephemeral rotating token is the identifier for the grant . A failed network request can mean that the RC no longer has access to manage a grant - in fact they may not even be able to reference it when starting a new grant as they may only have access to an expired access token that the AS may not accept . This seems unnecessarily brittle .
of the grant then it must be in the url to avoid the problem of arbitrary url construction . Of course the uri would be https://as / grants/{grantIdentifier } . And this is actually independent of whether or not the token gets rotated . # 3 The idea of a dynamic environment is important here , however the argument does n't justify having this being the same endpoint . Nothing stops us from having two endpoints , one that requests an access token separate from the ones that manage the grant resource . , CTO Secure your user data and complete your authorization architecture . Implement Authress .
Paragraph (version B):
during the interaction phase before redirect.