[GNAP] Access Token for Continuation API

Justin Richer <jricher@mit.edu> Fri, 20 November 2020 19:48 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CB13A100F for <txauth@ietfa.amsl.com>; Fri, 20 Nov 2020 11:48:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFzPtUvD_4Ot for <txauth@ietfa.amsl.com>; Fri, 20 Nov 2020 11:48:53 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3BB893A100E for <txauth@ietf.org>; Fri, 20 Nov 2020 11:48:52 -0800 (PST)
Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AKJmokD008793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <txauth@ietf.org>; Fri, 20 Nov 2020 14:48:51 -0500
From: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4C74015C-33CE-4DE2-9DC3-AEBCE1323194"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Message-Id: <6692BEB7-7EBF-4289-9ED3-15DE83EE50DE@mit.edu>
Date: Fri, 20 Nov 2020 14:48:50 -0500
To: GNAP Mailing List <txauth@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/9DRl5SKUYtPLo-SS7mr0cd2i154>
Subject: [GNAP] Access Token for Continuation API
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, 20 Nov 2020 19:48:55 -0000

At Tuesday’s call, there was some general support for addressing issue #67 (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67>) by requiring the “continue” block of the response to include an “access_token” field, and consequently requiring the RC to present that access token when calling the continuation request endpoint/API. In the current draft, the access token is optional but the client is required to use the token if one is given by the AS, so the optionality was really only on the AS side.

The editors have made a pull request that makes the the access token mandatory:

https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 <https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129>

This change hopefully also clarifies the nature of the access token being bound to the RC’s key and presentation mechanism, which means that the RC won’t need any additional functionality in order to call the continuation endpoint since it uses the same signing/proofing mechanisms that it did with its initial request. 

Since the process for this WG is new, I want to point out that “general support” in a meeting does not mean there is necessarily consensus for this change. The pull request represents a concrete proposal of changes that the editors believe would address this issue. Please review the pull request and provide any suggestions for better text for this issue. If you believe there is a better approach to this issue (#67), please provide alternative text changes.

Thanks,
— Justin