[GNAP] Core specification restructuring

Justin Richer <jricher@mit.edu> Fri, 26 March 2021 20:24 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E52753A0D58 for <txauth@ietfa.amsl.com>; Fri, 26 Mar 2021 13:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mnt4CG-PUwTm for <txauth@ietfa.amsl.com>; Fri, 26 Mar 2021 13:24:49 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F288B3A0D51 for <txauth@ietf.org>; Fri, 26 Mar 2021 13:24:48 -0700 (PDT)
Received: from [] (static-71-174-62-56.bstnma.fios.verizon.net []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12QKOkqX004062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <txauth@ietf.org>; Fri, 26 Mar 2021 16:24:47 -0400
From: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6B430942-C458-4EA1-B322-D6CE009C5C37"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <1C29A4EC-CF11-4C49-AB84-D91A0F9D30CD@mit.edu>
Date: Fri, 26 Mar 2021 16:24:46 -0400
To: GNAP Mailing List <txauth@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/-UMWjHWPAynZOKABEXkcvgBIA6o>
Subject: [GNAP] Core specification restructuring
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2021 20:24:51 -0000

After a long and productive conversation spanning both the mailing list and the GitHub issue tracker, it seems clear that the overall consensus is for access tokens to remain opaque to the client instance within the GNAP protocol, and the use cases asking for a non-opaque access token are either concerned more with capabilities of the RS or could be handled by an extension or profile of GNAP. What’s also become clear is the need for more focused discussion on the relationship that the RS will have an AS, and how that can be made in a more dynamic fashion when needed. Additionally, it has also become clear that carry through OAuth 2’s mindset of “the RO interacts with the AS” is too limiting. While the GNAP protocol can already accommodate other types of consent-and-authorization-gathering processes, the current draft sticks closely to OAuth 2’s presentation of a single user interacting with a server, usually through a web page at that server. 

To help fix this, the editors are going to take the following actions:

- The current section 4 (interaction at the AS) will be rewritten to accommodate the more wide set of capabilities that GNAP enables, especially in light of the syntax changes around start/finish/hints that we have there now. (see https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/224 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/224>)
- The current section 10 (resource servers) will be extracted into a companion document, along with whatever other pieces of the core are best fit for that. This document might end up being a separate publication, or the working group can always opt to merge things back in at a later date. For now, facilitating the discussion will be helped by having separate targets to focus on. (See https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/114 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/114>)

Please be on the lookout for PRs to execute these changes in the near-ish future.

Thank you to everyone who’s been participating and pushing the conversation!

Your editorial team,
 - Justin, Aaron, and Fabien