Draft: draft-ietf-gnap-core-protocol

Commentary: This removes the " capabilities " and " existinggrant " portions of the request , as well as related aspects from discovery and responses . This also removes the separate " instanceid " field for the " client " part of the request , instead relying only on collapsing to a single value instead of an otherwise empty object . These could still be back in with extensions at some point in the future . 
 : heavycheckmark : Deploy Preview for gnap - core - protocol - editors - draft ready ! : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview : 
 Yes , " existinggrant " was the only driving reason behind having a persistent grant identifier . It 's not needed for any of the other maintenance activities since you 're given a URL and access token directly . My personal thought is that the identifier and existinggrant can be written together as an extension -- if you get the identifier you can use the existing grant , but you ca n't without it . That way it does n't burden the rest of the system . 
 I would have preferred a separate PR for " existing grant " vs. " capabilities " . Specifically , I suggest to reconsider " capabilities " . First , there will be extensions in the future ( especially the more features we trim from the base protocol ) , and it 's good to have an extension mechanism from the get go . Second , in security protocols it 's useful to mark certain extensions as critical , and this can only be enforced if we have a " capabilities " field in the base protocol . 
 For , I believe we would have a better idea of what the extension mechanism would be used for if we had any extensions that used it . I still like the feature , personally , but it does n't make sense to have an extension point in place with nothing to hang from it -- it begs the question of whether it 's the right extension point to begin with . The rest of the protocol already has huge amounts of extensibility built in , in ways that do n't need this feature . I think the group should revisit the topic but without this piece getting in the way of how we think about it when we do . We can plan to discuss all of the removed features at the next meeting . 
 So , should we have an issue to keep track of extensibility ? And specifically with the requirement to enable future critical extensions ? 
 and both cover different aspects of this , in my mind . 
 regrouping and to provide guidance 
 I would appreciate more detail here : A finite list of specific extension points that we want to enable ( additional claims in the request ? in the response ? ) . IMO supporting too many extension points leads to code complexity , hence security issues . It also makes it harder to formally verify the protocol . Features that we trimmed and that we 'd like to enable to reinstate if someone cares about them ( maybe signature methods ? ) . Additional requirements ( having named extensions ? allowing a protocol party to declare that one or more extensions are critical ? ) . We should aim for a strict protocol definition ( e.g. messages can be validated using   ) where implementations refuse to accept unexpected " stuff " , and only allow very specific places where additional " stuff " is acceptable . This may not be best practice for JSON - using protocols , but it is for security protocols . 
 I would be in favor of further reducing some of the options in the core spec , and putting them in extensions ( + that provides concrete examples of what we mean by extensions ) This may concern :  assertions ( + makes sense to isolate due to distinct security issues with XML ) detached / attached JWS : because there 's an adherence on JOSE , that we do n't find anywhere else 
 I agree with in principle , but let 's not go too far . I think that  is functionality that 'll be widely used from day one ( correct me if I am wrong ) . If so , it needs to stay in the core spec . 
 After discussion between editors , that 's currently what will be proposed ( draft8 includes the related security considerations ) , and I agree with that  the question of JOSE , which will be discussed at IETF112 . Personally I believe a separate draft would make sense ( detached and attached JWS could be used by the oauth community as well ) and it would also be easier to rally people that dislike  to the GNAP WG . In short we 'd be agnostic to those subjective assessments . Additional comment after IETF112 : note that security is already baked into the protocol via HTTP message signatures or mTLS . We now need to decide if  methods are also needed in the core protocol , which of course could be useful to people already relying a lot on  ( as an alternative to HTTP message signatures ) . However , this does n't go into the direction of option minimization ( for the same features ) . 
 Editors will list all intended extension points within Core , probably pulling together all the existing stubs for extensions in different sections into a larger discussion . This would require at least a shell of the IANA section for creating necessary registries . In cases where it 's not clear how an extension would happen , the extension point should be removed explicitly . The goal being to have only clearly defined extension points in Core . 
 Related to ( OpenID connect ) but able to support also other schemes ( e.g.  ) , and related query syntax Most probably by extensions 
 To revisit when we have something concrete 
 This discussion gets us close into the identity protocol space , and the method for defining this should be a part of the extensions discussion in 
 This could help Seems fairly straightforward to extend assertions formats and responses , although I 'm wondering whether we should also include a type for assertions to allow for such extensions ( they 're quite different from id_token / samlv2 ) 
 Identifying the RC Instance :  's note : It seems clear that an instance identifier is mutually exclusive with most of the fields in the request ( eg , we do n't want an attacker being able to swap out a client 's registered key just by accessing the identifier ) . However , some proposed concepts might fit alongside an instance identifier that change at runtime , such as device posture or another dynamic attestation . Should these be sent in the " client " block alongside the instance identifier , should there be a separate top - level block for runtime attestations , or some other mechanism ? 
 Yaron : The AS MUST ignore any unknown extension .  : I ’m OK with this stance , but it needs to be consistent throughout the protocol , not just at this level . Yaron : we can actually have one policy for an AS that does n't understand something defined in the RFC ( e.g. a token binding method ) vs. extensions . Unknown extensions clearly must be ignored , otherwise you can not deploy extensions incrementally . For RFC elements , this is more nuanced . 
 With the guidance on extension points from and error codes from and similar , this should now be covered by the current text . 
 Personally in favor of that change , although i think it would make sense to make 2 separate PRs for that . Regarding existing_grant , do we expect some impact on ?
Paragraph (version A):
Identifies named extension capabilities that the client instance
can use, signaling to the AS which extensions it can use.
Paragraph (version A):
Identifies a previously-existing grant that the client instance is
extending with this request.
Paragraph (version A):
If the client instance has an instance identifier that the AS can use
to determine appropriate key information, the client instance can
send this value in the "instance_id" field.  The instance identifier
MAY be assigned to a client instance at runtime through the response-
dynamic-handles or MAY be obtained in another fashion, such as a
static registration process at the AS.
Paragraph (version A):
An identifier string that the AS can use to identify the
particular instance of this client software.  The content and
structure of this identifier is opaque to the client instance.
Paragraph (version A):
If there are no additional fields to send, the client instance MAY
send the instance identifier as a direct reference value in lieu of
the object.
Paragraph (version A):
If the "instance_id" field is sent, it MUST NOT be accompanied by
other fields unless such fields are explicitly marked safe for
inclusion alongside the instance identifier.
Paragraph (version B):
If the client instance has an instance identifier that the AS can use
to determine appropriate key information, the client instance can
send this instance identifier as a direct reference value in lieu of
the "client" object.  The instance identifier MAY be assigned to a
client instance at runtime through the response-dynamic-handles or
MAY be obtained in another fashion, such as a static registration
process at the AS.
Paragraph (version A):
If the client software supports extension capabilities, the client
instance MAY present them to the AS in the "capabilities" field.
This field is an array of strings representing specific extensions
and capabilities, as defined by IANA.
Paragraph (version A):
If the client instance has a reference handle from a previously
granted request, it MAY send that reference in the "existing_grant"
field.  This field is a single string consisting of the "value" of
the "access_token" returned in a previous request's response-
continue.
Paragraph (version A):
The AS MUST dereference the grant associated with the reference and
process this request in the context of the referenced one.  The AS
MUST NOT alter the existing grant associated with the reference.
Paragraph (version A):
OPTIONAL.  A list of the AS's capabilities.  The values of this
result MAY be used by the client instance in the request-
capabilities of the request.