Re: [GNAP] New Version Notification for draft-ietf-gnap-core-protocol-11.txt

[Justin Richer <[e-mail]>]

Hello everyone,

A new version of the GNAP core protocol has been submitted, bringing us up to -11 ahead of the upcoming meeting in London in a few weeks. This version represents some significant editorial work as well as a couple small normative changes to bring different parts of the protocol into alignment with each other or finish defining functionality that’s been hinted at but not fully defined to date. The editors have been combing through the entire issue backlog and this version is the result.

We’ll be going over this change set at the IETF meeting, but highlights include:

- Filled out IANA section
- Additional security considerations
- Interoperability profiles for mandatory-to-implement functionality subsets
- Discussion of dynamic grant endpoint discovery use cases
- Discussion of intended extension points to the core protocol, including guidance for those writing extensions
- Clarification of the relationship between TLS and the signing mechanisms in GNAP (ie, why we need both)
- Addition of an implementation status section (if you have an implementation to list here, please post to the list or raise an issue/PR to add things)
- Addition of the “sub_ids” request parameter to allow the client instance to target a user for returned subject information; this is particularly useful for cross-user cases where the end-user and RO are different people
- Keys can now be sent in only a single format in a given request
- Key proofs are now defined separately as string-type and object-type, aligned with other protocol elements like interaction start methods that use the same format
- More error codes are defined, including the places where they’re used.
- Some more normative requirements on the self-declared client fields in the dynamic introduction cases.
- All URIs in the protocol are absolute (this was assumed before but is now required)
- Access tokens have to fit “token68” characters instead of just “ASCII” (this is parallel to OAuth and other security protocols within HTTP)
- Specific mechanisms for presenting new keys during token rotation operations and presenting multiple keys during key rotation operations.
 - Addition of the “referrer” field in RS discovery responses and definitions for its use in the grant request

Thank you to everyone who’s contributed to this, and we’ll see you in London!

 — Justin and Fabien

> On Oct 24, 2022, at 3:33 PM, [e-mail] wrote:
> 
> 
> A new version of I-D, draft-ietf-gnap-core-protocol-11.txt
> has been successfully submitted by Justin Richer and posted to the
> IETF repository.
> 
> Name:		draft-ietf-gnap-core-protocol
> Revision:	11
> Title:		Grant Negotiation and Authorization Protocol
> Document date:	2022-10-24
> Group:		gnap
> Pages:		205
> URL:            https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-11.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-gnap-core-protocol-11
> 
> Abstract:
>   GNAP defines a mechanism for delegating authorization to a piece of
>   software, and conveying that delegation to the software.  This
>   delegation can include access to a set of APIs as well as information
>   passed directly to the software.
> 
> 
> 
> 
> The IETF Secretariat
> 
>