Re: [GNAP] Core protocol comments - Sec. 1-6

Justin Richer <jricher@mit.edu> Thu, 26 January 2023 19:30 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 BF361C14CF17 for <txauth@ietfa.amsl.com>; Thu, 26 Jan 2023 11:30:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnP_pVh46zwk for <txauth@ietfa.amsl.com>; Thu, 26 Jan 2023 11:30:19 -0800 (PST)
Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 7BE10C14CE29 for <txauth@ietf.org>; Thu, 26 Jan 2023 11:30:18 -0800 (PST)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 30QJTsHd026842; Thu, 26 Jan 2023 14:30:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1674761416; bh=zSKkaImCJ/CxxoM7r6znSBuE0G+vXkrRGcw4JBNVhJQ=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=DUBwjUtOs44GPa6G1OyTV1OS070Ceqf4j0JMTLvv67VNruD4imJfMAAOLEXgazOTG l0OMC8gQgXe/bsSZzyMfqiK28gyQgBlAJnIL4zhp9Y8hgvKq1BEZ1lEJ+E1dk4tBUE 5GZ2coB6UNou+Too3T+xi0xqQRpA/f/BmUiBCyP3eEIO/P7Wc+hHvcdhiRkc/yERV8 JlEW+DjgWhll+IZcsEMn2M9xIV3+bEsQdI8GC7JluGJ3bEQGr1QdXj00MY/QuuEMhg +xi6VKZ7yUCQPg8AlTKVdqvaPqGBzngrDhGf+vKJ1XkIMTPVJDjIRBuVCWvVuF/W0D lMxG23oNcGjog==
Received: from oc11exhyb3.exchange.mit.edu (18.9.1.99) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1497.45; Thu, 26 Jan 2023 14:28:45 -0500
Received: from oc11exhyb1.exchange.mit.edu (18.9.1.60) by oc11exhyb3.exchange.mit.edu (18.9.1.99) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 26 Jan 2023 14:29:31 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by oc11exhyb1.exchange.mit.edu (18.9.1.60) with Microsoft SMTP Server (TLS) id 15.0.1497.42 via Frontend Transport; Thu, 26 Jan 2023 14:29:31 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dtI8kX81FuPmzHFH8kS2DxBi9Br5hMfVkDQctdfcV/grGp0+byFVKg32qjkGNssuXb05bnGjbhv1++ceDfHJLDCyJ89jsRnj49OBT8OBBr+Bt0VimhzdFZQOGu5vQ0vgRULMRD/0mV6l0WAy7duPzwWAshU4iQ1OsGTLNyCxIu2WM3f2OjjfIo0v/LmsCk+0OrexL4C70zXYVLGcvr0bJNvscmlX/fWedXnSrjLIV1QuabQ7wIWRSIfV5KYesgjP5r178uN47SVnC0UtBPyjUd3b5h2bLHyz8ogqRThXr3Xio7Ra7hQaSEqt/+1g1H8WXd4Dqzw6TStBaN4D79nRMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zSKkaImCJ/CxxoM7r6znSBuE0G+vXkrRGcw4JBNVhJQ=; b=GXgvsDfdm8eG/dRuNyzjYvsL1asziZCjzvZI44RValvHwW2njlMhFgDiJCioCdJfhx47uKzWH5ijd0QL8By6hZUkhmJALJ3bT0VABs83nAui2kei5LcAUJqn/NPQoKSA56sFcwbTik2hBxKggep2sRB5wB8kgujmgl2wc48jFz2ascvYsI9ubPcFbpmxhLX5+nv2VO0HuYnboERzvN7lc/kgGRimQSOrZvf6AdBlh/tU4Kod5vGGnEtiWPgzVcIJ1p0Fe5+TreBhq7mT4l9EbWKjF8Q8MSXuxb0YGG2qNlXroE3dKEBmK0BqMEUKvMI/DmUZ8mJCkpTo1Gp+8Fqbzg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none
Received: from DM6PR01MB4444.prod.exchangelabs.com (2603:10b6:5:78::15) by BL0PR01MB4993.prod.exchangelabs.com (2603:10b6:208:69::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.33; Thu, 26 Jan 2023 19:29:29 +0000
Received: from DM6PR01MB4444.prod.exchangelabs.com ([fe80::a9b:b1f2:da45:501f]) by DM6PR01MB4444.prod.exchangelabs.com ([fe80::a9b:b1f2:da45:501f%7]) with mapi id 15.20.6043.021; Thu, 26 Jan 2023 19:29:29 +0000
From: Justin Richer <jricher@mit.edu>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
CC: GNAP Mailing List <txauth@ietf.org>
Thread-Topic: [GNAP] Core protocol comments - Sec. 1-6
Thread-Index: AQHZMEWneWyZbvk50UqlNNaDep8XIa6xGHcA
Date: Thu, 26 Jan 2023 19:29:29 +0000
Message-ID: <CF87DD79-E6BE-4585-8B7F-BD2FDE5F4F18@mit.edu>
References: <417A84D1-27D7-4B78-BA0C-FE45A45E56C1@gmail.com>
In-Reply-To: <417A84D1-27D7-4B78-BA0C-FE45A45E56C1@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=mit.edu;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR01MB4444:EE_|BL0PR01MB4993:EE_
x-ms-office365-filtering-correlation-id: a9b72758-dfb2-461b-354a-08daffd3a49d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0AepLk3gXwCcHI4xa6dFjo0ST6u2wjmFAitRcLAiuYo01N36rnaLnm/ObCusLLvxEtowUpLwPkMftmGfK9HZZYcaedmUJu/j8XoAPaKNAMZ0X0CjSGDLByzbStqUcV3KinQjRAZ4zNdxah2JXtOFS8UrqiKg2jc7kL2W/rt2nMtBAjirGuZ4/qJayIeUEu0W9FTMzGICnkrRXyVbc6SJ2N8Ce+pKpTDosjfwcvoytyV1ipROVdSOBO63XOPZoY8roaawJyXQmcg7xBArxRlxEtJdzwuNe4UrzXcrRQ1n+32VYNXIROVq7KoQfK/7c7vcsPlBWGCAYN7kgdtphcoeshyAXTEgdSB7BOpoyHInO/SPEnasiv4YEc+TDf6AOGq6wAdsrZeNpW5wNbAPPHzpShjd8V2z8T3VkBbfdaMuKp2GjcDJ0LpUO7tJ3nrp0q9B7eNo2dtEOJ2/EEFBB5g/V8/AVJa49sJPXNxQRpaUTtO3iWmjKWNvNr5DHTQyM0qU6ZvTpzmhza0lkHSlcTDxqeF47+MLlz2C0wRKrHvcu7a2BU1iZphYf8j9Kx+xlgEezYgREoOsEeC2P/DE77T0tkQQ39IYhuexH1vdGGm9cpW+7OjtWOrluElwsIEqVhW43timuYOJ9oZdK8huxQriMr1UC5C0dGaH/tDz3aF2aHAM+vPBelmc8qqMpjAGyH5t6dNXAy/jUNx7Qnr2b9JVD1RjxNzs91rp9TuC/srjjsc0m+/a+4kRa7SrUJ/pvamrE/eScS6IGWkl395voFPYhA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR01MB4444.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(346002)(376002)(136003)(396003)(39860400002)(366004)(451199018)(8936002)(83380400001)(91956017)(30864003)(53546011)(5660300002)(8676002)(64756008)(2616005)(4326008)(66946007)(38070700005)(6506007)(478600001)(786003)(86362001)(6916009)(71200400001)(66556008)(316002)(76116006)(66476007)(66446008)(75432002)(36756003)(41300700001)(6486002)(38100700002)(26005)(122000001)(966005)(186003)(33656002)(6512007)(166002)(2906002)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: L5I4JAILc7Eis2/HTKQW6LmYy4rCVxySsTABYgdncdMnpEmpZR2VQeWlCgNzyuFqTnvm2mFB/GWRbMAkC2cG3oA+P4vett3r9QrjyjMqu0ktgU3Lu8VbaIo4nNYtySNVxeBHut28HhROWBJ8rWmt8yrFuGqlDRIIZ3Vn+8htuI1JiXJCmrvF/csTrF1GCTnRgOoxhJleEMBHeDKH4/x4bxYAKlu+SnH0sRhsyRSYHw4aUJVXKxi7U96SRXvWO5MbGfQyqETcvC5e3E8w5Hhx0FAOw8NWi8X3c9gpEN/pi6E2ewBYMAnHA8Zwijt9sLSoEMmJJM9X2dYBq8UJXOFVQ9ots0IqO1suOxDxucD/oqliWsRKGF7BJPPgNUIXWGJDC/yORc3KE2GTOuzdnpneDi9iSNr8Ga00gR+MFePwho0Ua0HqtEjMo5V3Hjaua5tbdHAqWM6T4C5jNc1kUeNWha64m6mGd4eJ48Zbp3xfzdwR/odaAvj4A8N3ygTUjYEub8P/QfDbKSDjgdpxs/ZQG3fk0NL//qV2ulMFJPqm4atzmzoLdNTl0Lm717UIe+1L2hAO0oDGmv5oBMJXaAyW+0VTDfrgJZkH8kpfXKTUvSIfnTwvyQO/VbO9SSotMGyg9ipQabHodOTeXINW0n/iOMnxmd0tB8ACS/k8/6UC8Krp/XuLth7y4W2G15JmE+4oO6VvJvtvdh+E1w53Eyc6HNvMFguCXC65pKh+YTVI57K2dQ5WJM+t4IY45ysollyF+1foYBbl9QpKYoMw77/v0x9tqyWJtBySfKTofPiUj4zG8WvAwqes9G1G62sml3QxxSJpIVS9NFmHK1VzcrYaT/UcexeXTpsEqX71tfB0oj9TcJENK87/8Y4Llcmvo+5SrOgpvpBkBVUHJN0AioB2pp6PkWH1b8Pdl08S0MpTRL2Gc5h7JEfqG7GLXA37MU6eUx3oY7tMQfhOokdKipg3SqkMK167BAbW5c6jLzgZAepBtVCPsw11iWz1AbVpzZAUx0LYiMYBC8lbiH0douhuqc5NEEhOhkH+HWFL+awNLBBpQ7NnxQMjthYOdzPraebK0ZSmWKEr5IJAHipOmqDbM8YMqBke8XyHWCnbDEcAVhiy2ciwVF+EIMxOtJ6o29oB297sspFCdeO39mtNLdIBUghuIbbNMbjkKr/RnctAFiPUGz2pSwo9/8Gb5ELMJAVodlHmZfmKQK1BjgQM0kncufzuX4YrLU6gp/9sFKXTHadTrErKWY3gFSde061A38uoht4sKCwoEe9Fck2ewcWQFB9FNU+UkYqZfqg4CHJVOg8c7daWzvCUbGoMdoDq21ZGw/M094d0q2wW4pijXjF1kL+NKojZbGULiDzVyJyvrJWaGQixEj9+Jsd2RgnUDcVUXgg+zpOW3cvaXX3UIu8KrotJhEk9GvAUeaywdiwkbUOqXlFD02sFinrlue9brVTAqNFsyp22hTDsWTEtGOhstuWA+dTuwL9yMDMBhf6Vq5732l+ZHItVU4s2KqEXbOOpwEFYEZHxRhBQS06v7av9GMKciBTZBkwVAjJGcAmB26MZkpXjBey+v93O8D1ym3M/
Content-Type: multipart/alternative; boundary="_000_CF87DD79E6BE45858B7FBD2FDE5F4F18mitedu_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR01MB4444.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a9b72758-dfb2-461b-354a-08daffd3a49d
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2023 19:29:29.0982 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bs/RnllVkFDZmccAxSF7+4BFlkAYly/82AI+q8Cik59RO0FOZsLb5DEnXNCW7jmQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4993
X-OriginatorOrg: mit.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/PmQBA_nvbfPxxg0xmEvoCFF5Epk>
Subject: Re: [GNAP] Core protocol comments - Sec. 1-6
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 26 Jan 2023 19:30:20 -0000

Hi Yaron, thanks so much for the review. I think we should probably import many of these as issues in GitHub for tracking, but I wanted to take the time to respond inline below.

On Jan 24, 2023, at 5:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com<mailto:yaronf.ietf@gmail.com>> wrote:

Dear editors,

Below is a bunch of comments about the bulk of the document, some editorial and some not.

In general, despite the number of comments, I think the document is in good shape.

Thanks,
        Yaron


  *   1.5: While it is possible to deploy an AS in a stateless environment, such deployments will need a way to manage the current state of the grant request in a secure and deterministic fashion. - I'm not sure such a deployment is possible, e.g. if the state is managed by the client, it would be able to roll back to a previous state and cancel any pending revocations.

What we’re trying to say here is that the protocol itself is stateful in nature, and that if you’re deploying it in a stateless environment you’re going to have some hoops to jump through. This doesn’t say that the state of the protocol is managed by the client, just that the AS might be, say, a bunch of lambda functions that use encrypted artifacts to communicate between them.


  *   1.6.1: the generic sequence diagram seems to have a bug, especially when compared to the one in 1.6.4: after message (3), there is interaction with the RO, marked with (B). What then initiates the client's next step, the one marked (4)? Is there polling going on?

The general diagram isn’t meant to be specific about that. It could be polling or could be an interaction finish signal. We can say exactly that in the text for (4) to make it more clear.


  *   2.1.1: access token flags - the "bearer" flag is mentioned for requests and responses, but the "durable" flag only for responses. I suggest to add "allowed use" as a new column to the relevant IANA registration registry (Sec. 11.2).

Good idea, we’ll add the column.


  *   2.1.1: "since no flag is provided in this example, is bound to the client instance's key", better be more precise about the flag: since the "bearer" flag is not provided in this example, is bound to the client instance's key.

Good catch, thank you.


  *   2.2: SAML - please add a reference. Also, is "SAML 2 assertion" well defined? Are there any constraints? If we don't want to give a detailed definition, maybe leave it out.

Oh, I thought we had a SAML reference here. Yes, “SAML 2 Assertion” is well-defined, but we probably mean the authentication assertion from the WebSSO profile more specifically.


  *   2.3: the example includes both a "jwk" and a "cert" for the public key. I think this contradicts the text in Sec. 7.1: "A key [...] MUST be presented in one and only one supported format".

Whoops, must have missed cleaning that example when we changed that, thank you.


  *   13.12: when we say "natural extension point" I suggest we add a reference to the relevant IANA registry (Sec. 11.5 IMO).

Good idea to cross-link here.


  *   In general it's worth looking at where the word "extension" is mentioned throughout the document. For example, in Sec. 4, "or through some other method defined by an extension of this specification", I don't think we have defined such an extension point, so I would remove that text or add the extension point.

It would be through something outside of what’s been defined here, not necessarily an extension point within the protocol. I think we should re-word this text.


  *   2.3: the "display" URI is limited to web addresses, and can simply be a URL.

I think we had a reason for keeping this instance a more generic “URI” but I’m not finding my notes here. Even so, it seems like we can potentially back off from “web page” and instead say something like “Address of user-facing information about the client software, such as a web page.” That said, I can’t think of another example immediately.


  *   2.3: "SHOULD use a different key for each AS" - I would change it to MUST. We know of one attack, there may be more. If we leave it a “should”, deployers will not have enough information to make an informed decision here.

I think this is an unenforceable MUST (the different AS’s can’t detect this being done by good clients, which is the whole point). Additionally, there could be ecosystems where the client is known by a public key — there have been some folks talking about IoT use cases like this at the IETF meetings lately. In that case the client’s identity is more important than the mitigation of this particular mix-up attack.


  *   2.3.1: "If the client instance is identified in this manner, the registered key for the client instance MAY be a symmetric key known to the AS." I think this gets it wrong: for symmetric keys, it is the "key" value that's given by reference. The "client" value is unrelated.

The text is correct. The “client” value when passed by reference can point to an internal static registration which could in turn have a symmetric key.


  *   2.4: "Assertions SHOULD be validated by the AS." In addition to ensuring the JWS is signed correctly, are there other checks the AS must do? E.g., ensuring the assertion refers to the same identity as the sub_ids?

That really depends on the assertion and identity framework in place, which is out of scope for GNAP Core. I’d be hesitant to add anything here beyond some advice, else we get too deep into the identity protocol space.


  *   2.4.1: what is the lifetime of the user reference? Can the client assume it will remain valid forever (as long as the user itself is valid)?

That’s a good question. Ultimately it’s up to the AS, but if I were a client I’d assume that it’s good and points to the same user until it stops working.


  *   2.5: "array of strings/objects" - this is somewhat ambiguous, is it allowed to mix strings and objects in the same array?

Yes, that’s correct.


  *   2.5.1: "by a JSON object with one required field" -> "by a JSON object with the `mode` required field"

Thanks, that’s better wording. I think we have a couple places that have similar construction, so we’ll check that.


  *   2.5.2: I think the nonce MUST be valid ASCII, to avoid complexity when computing the hash. The same goes for the Finish nonce in Sec. 3.3.5.

That seems fine to me on the surface. I don’t see a reason to not restrict the nonce value if it really is going to be a random value. We’ve tried to make it so that parties don’t have to try to cram information into otherwise random fields.


  *   3.2.1: the text in 2.1 implies that for a single access token, if a table is included in the request, it should be included in the response. So I suggest: "REQUIRED for multiple access tokens or if a table was included in the request, OPTIONAL otherwise."

I think this comment is for “label”, and I think that the edit makes sense in that case, thanks.


  *   3.2.1: when the AS returns a `key` by value, there's a lot of complexity and possible security issues as the Client tries to correlate it to known keys. We should RECOMMEND to use the key reference (Sec. 7.1.1) mechanism instead.

That seems like good advice.


  *   3.2.2: this sentence got mangled: "other issued access tokens are included in the response the requested names appropriate names".

I think that should read “other issued access tokens are included in the response under their respective requested labels.”


  *   3.4: ISO8610 -> ISO 8601 (but why not RFC 3339?)

I’m fine with using the RFC reference, it’s functionally the same for our purposes.


  *   3.6: "provide a error as a string" -> "provide the `error` key as a string"

Thanks, that’s better.


  *   3.6: what is the error that corresponds to "not yet granted" - async authorization as per Sec. 1.6.4 (step #2)?

That’s not an error, the AS returns the response with no tokens and includes a continuation method.


  *   4.1.2: "the URI is usually be opened" -> "the URI is usually opened"

Got it, thanks.


  *   4.2: "follow the appropriate method at upon completion" -> "follow the appropriate method upon completion"

Got it, thanks.


  *   4.2.2: "the AS MUST protect itself" - I think this should refer to the client.

No, this is actually about the AS. The client provides this URI to the AS, and the AS is making the outbound call. Therefore the AS is the target of the SSRF.


  *   4.2.3: there's something missing here: the section discusses hash functions applied to strings, but does not mention the string's encoding to bytes. Maybe we should say, instead of "The party then hashes this string", "The party then hashes the ASCII bytes that encode to this string".

Good point, I’ll see what other specs use for similar operations.


  *   5: "Access tokens other than the continuation access tokens MUST NOT be usable for continuation requests." I would also add: "Conversely, continuation access tokens MUST NOT be usable to authorize requests into Resource Servers, even if collocated with the AS."

I thought we already had that covered in the definition of the continuation response, but that seems to have gotten lost. I think this language is sufficient and we should add it.


  *   5: "The AS MUST be able to tell from the client instance's request which specific ongoing request is being accessed, using a combination of the continuation URI, the provided continuation access token, and the client instance identified by the key signature." The first two (and preferably only one) must be sufficient to identify the request. I suggest to change to: "The AS MUST be able to tell from the client instance's request which specific ongoing request is being accessed, using a combination of the continuation URI and the provided continuation access token. The AS MUST verify the signature and MUST ensure that it is bound to the client that originated the request."

That’s a subtle change, but I think it makes sense. We’ll play with this text.


  *   5.1: "If the AS detects a client instance submitting the same interaction reference multiple times" - can we rephrase this rule so that it depends on the grant's state, in order for the AS not to have to cache references?

That’s a good point — I think the state discussion in 1.5 could actually say a bit more about interaction references and the like as well.


  *   5.2: the text says the POST does not include a message body, but the example still includes a Content-Type header.

Good catch, thanks.


  *   "If the grant request was previously in the approved state, the AS could decide to remember the larger scale of access rights associated with the grant request..." If the client first asks for A+B permissions than asks for only A, I would say "remembering" A+B and granting it again is a mistake. The client may have good reasons to ask for restricted permissions, e.g. if the client's security posture has changed and it is at higher risk now. Granting it A+B again would be a mistake. If this text is not about the access rights being granted but rather about some internal optimization at the AS, please clarify it in the text.

OK, I see where you’re going with this. The intent was that:

 - Client asked for A+B and got it
 - Client later asks for A, and the AS remembers that previous decision for A+B
 - Client gets granted A (not A+B) for this second request

We will clarify.


  *   5.3: "Modification requests MUST NOT alter previously-issued access tokens. Instead, any access tokens issued from a continuation are considered new, separate access tokens. The AS MAY revoke previously-issued access tokens after a modification has occurred." IMO the AS SHOULD revoke in this case, which would be more in line with the intuitive semantics of a PATCH. If the client wanted more access tokens for the permissions it is already holding, it could have made a whole new grant request.

I agree in principle, but token revocation and stability is a big design choice in ecosystems. That said, a “SHOULD” might be the right level of advice here. Fabien had some better-expressed thoughts on token lifetimes so I’ll let him chime in there.


  *   "In the future" -> "Some time later".

I think that’s probably better, will play with that.


  *   "The AS would likely revoke previously-issued access tokens that had the greater access rights associated with them, unless they had been issued with the durable flag." I think a more consistent interpretation of "durable" is that it is used ONLY to make access token rotation easier, by allowing overlap between the old and the new token. If a new token with reduced right is expressly requested, it would make more sense to always revoke old tokens, regardless of the "durable" flag.

This actually gets into the data model of the access token issuance and rotation brought up in the conversation on this GitHub thread: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/485

Specifically, in my head, the “rotation” doesn’t make a new token so much as change the value of a token, while continuing a grant request w/o changes (or even with changes) gets a new access token.


  *   In general the logic of Sec. 5.3 implies that the AS needs to keep track of all tokens (a potentially unlimited number of them) associated with the grant request, along with each one's associated rights, and compare each new token's rights to all previous ones. A simpler way to manage the grant request would be to just keep the last one, and always revoke it whenever the grant request is modified.

I think the implication is that the AS needs to keep track of the state of what’s been granted, not necessarily all individual access tokens that result from previous decisions. Whether the AS wants to treat the data model as additive-only (like adding additional scopes against an OAuth refresh token) or remember the last one only, I think is an underlying decision. Can we call this out better? I think going into the basic model a bit more deeply (see previous comment) might help.

Both of the proposed solutions sound like opposite ends of an implementation decision to me — always revoke previous ones or remember everything all at once.


  *   6.1: Requiring an access token to be unexpired when it is rotated would simplify the text as well as the implementation logic (e.g. around expiration vs. revocation). Why not have the client responsible to rotate the token in a timely manner? If it doesn't, it can always request a new one.

This sounds great in practice, but that puts it on the client to proactively rotate the token before it needs to. In practice, what happens in the OAuth world is that a client wakes up, uses its token, sees a failure, then goes to try the refresh token to get a new access token.

That said, since we have the ability to get new access tokens from an existing grant, in addition to rotation, we could limit rotation to only “currently valid” tokens and sidestep the whole question. That is, if your token is still good then you can rotate it, but if it’s not you need a new one which might be from a grant continuation.

Even though this is a bit of a change I think it would help so I’m inclined to go in this direction.


—

Again, thanks for all the feedback!

 — Justin

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth