[OAUTH-WG] Re: Deferred Key Binding / TMB
Justin Richer <jricher@mit.edu> Tue, 10 June 2025 19:27 UTC
Return-Path: <jricher@mit.edu>
X-Original-To: oauth@mail2.ietf.org
Delivered-To: oauth@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E64AF3353FEB for <oauth@mail2.ietf.org>; Tue, 10 Jun 2025 12:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbpYA77vI5sT for <oauth@mail2.ietf.org>; Tue, 10 Jun 2025 12:27:12 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2043.outbound.protection.outlook.com [40.107.236.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3F72D3353FE6 for <oauth@ietf.org>; Tue, 10 Jun 2025 12:27:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=j2ewrngeZEs5JY8ARvsR2i+2qHF+lwJeWO0jkOJp/KVIHrP1P5T3wY0UxxzApMT3mvQh9tVhAzLa4hzfkCROEO06tpII/7wEYEI84tZ+kRDgpNcuRDGz06NNcB0DDN5nR9JCZbJm0P0Bf6Z5Lvy5L/eTzf5EmCJdH8VLIas92vQwC/cs6T/j9cMQfPqCle3NRRq8G95wkLnUw2dCVqCqGvSX5QU129ZbZ8wxllPXyCPdtQqP+Oq3nJ433JHPN7S95BJkOk7TrGx96CegCxZD9WQk4P0zSsqMrh0Iqnwhj8mqEPgLY4g5gtbB0MgHLgpsuauxRemV/cz/pXAVR17cMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=HvFG/ojuT3Kbq5CeDYIJgsaASSelLuAzBQx0e6cWzqY=; b=ldvFApuxw8XiiQVktzRmfk0hSwFHhay0ssPVK18XuAAxo5vwJm8e1JELzpE+Z8hLastwDhkJKCoMWEYrrxoBSRvWOhq9jm4XFTofzrPDS3RqkFp35SbpXQieE03DKFttDpezcysHUpQwumph0WSFZEXCiDgXhvQf1x1B9CkyLbUQd9OIaQiwKj3lucbh8OdIv5ljfR0BNWy2Ma0Vry//jBPzZSWnLSPIvuzpiZ+PCxYXlUA8a5O+PP+xiBe+qT90Qwd1Who9Yz7dnRFTmA4Ok/JGWqiM180+IvKD3wKxVU05Zd1vVX4GqANvYrHwYs39WGWK5JaseepbyL9XDc7dwQ==
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
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HvFG/ojuT3Kbq5CeDYIJgsaASSelLuAzBQx0e6cWzqY=; b=sWIN5i8Ap/ddmhOjgHdEzCu1JTFG50EnMS5bGARARY2fyZHc6MzByXKBtl1xdiktyekLpbdSHNRvGHAJ8EjMpg+CCLUX0SynsN3EEdyODjbQtZizlVu6Xvuq3yFJpH8Q4bpH/EIG5Pm5C+sYTJtYDz+BnVnezR4Y9XQputNHoqA=
Received: from LV8PR01MB8677.prod.exchangelabs.com (2603:10b6:408:1e8::20) by BY3PR01MB6626.prod.exchangelabs.com (2603:10b6:a03:360::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.29; Tue, 10 Jun 2025 19:27:10 +0000
Received: from LV8PR01MB8677.prod.exchangelabs.com ([fe80::e7d6:999:270f:a820]) by LV8PR01MB8677.prod.exchangelabs.com ([fe80::e7d6:999:270f:a820%3]) with mapi id 15.20.8813.024; Tue, 10 Jun 2025 19:27:09 +0000
From: Justin Richer <jricher@mit.edu>
To: John Kemp <stable.pseudonym@gmail.com>
Thread-Topic: [OAUTH-WG] Deferred Key Binding / TMB
Thread-Index: AQHb1jk3/8LCdLbD2Uezp0Bo8vdKH7P3ujAAgAUUooA=
Date: Tue, 10 Jun 2025 19:27:09 +0000
Message-ID: <46381B94-84FB-49D3-9C71-2FE4F5A97256@mit.edu>
References: <E40270D7-F032-49B1-9B10-87167331EA3C@mit.edu> <fdcb60f9-3bc6-4aff-8c2e-3cf74d17f90d@gmail.com>
In-Reply-To: <fdcb60f9-3bc6-4aff-8c2e-3cf74d17f90d@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: LV8PR01MB8677:EE_|BY3PR01MB6626:EE_
x-ms-office365-filtering-correlation-id: 3740f528-88a3-4573-f866-08dda854cb3a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|4022899009|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info: c8vkfSXx14aLrvYws94C0C2Qkv/I0mDbmhv4h+gGrY/CQGTKabf5HBQZO585d167bwiGX47lLUYqMc7tF5qHG5gEYEvrhiygNg5K14eOr1qQqe5YBjG83plR4PN0JvssXW3NBV6WWTNBGDz9p7/b36jOmUSBJudqkXw61UjpUsZcMZ55/VaqHBDRAC3n8ylWYILTXvrZfn+53FO/ROrlKJCHJv8MLJ/JA3pqiYJRJ+NrcnLcF3KTzbd1OmRvI+VHDoWJ1pXvcZIhbv4Cmw8W+eWYPZ08a9B8LjeASMMpzfzXxlH3PfjFjV7/BtlssUh1s9cDUE+OU4jd9DfImIS5Yxy55bRXVCWQ5JTGI7oYjyPvEEAc4y2wAPGFzXVu8InPOcZpz9phzobUoVscGqGIAxeOlkOH6rWxSyzPyVyZP23+In5UFreK0UD52FvnWXQL+IAu+YJT36pA1WwOyxXN0k5GKuSQ5s1voPG45EWWdsNM6yAYp3NIVhxxjNEwrqibAk3GdV2FG9S0kaHU7vlaf7RpWtiYfIJPZlev0zeqQBJt9+RSkaemC+EPYz4bDF5f4SZK4AxP6pcqvRJIg1S/hcAYnOkrxRb9TawuoIKCOBpAsWFGmS+D9qc83ru3DkOez7++mw9jgUQ4iDPXuuj15khCCRSLYKpSaEvVw3xeZDpEuG9hxGOSB7aE4eF56Qr76VUJDYFXcj5BX/fjoAWVwZWEnvHOy2AJB7WJ69BHwLQl+qNieLR2cX2/g/WOp5OY888jNublIrQoe9inFQk7MCchVj/7BhEvdkSNlyQPz8eHSpIbTCqdVj+OVmt1a2bezfQLSQG2E0vjiDFG/CxVLXwMINQ5FYsNv+jcrPyS9wcBlCHVgPPuVh3k8lHIQKR2lt4UudHNqmbqYZeqd1QgBEJB3Lkz5AxMJ2+e32Li+b6BUNFUELm/XykAK+5QzwICQvcQPgCCO3MvvpdBgZZPJz5s/KeV+skzFGWw3SgsQIchytacVSDVPnKfIfoSR60+K11uYlAJhkEkeXfkg+IaDcAesD3byfXM9S6RJtu2fWztwVupvpsMKGeikvYyrCHzOiOzIM2uaY02eDaJw2Vt0LUMz2u5VkrBJWNJRMVIlZrM82AnH6l0AzMdh09DiGBKaabB/BsXe8I+wcp7UpKZn39zjN5ilYri1TkiN3idcdWiOf/ol2rwEd2mu8pKg6ThJrZ1cjYWVRb5+AuZUAfyaqqkYG59cA3qbOex0DDsqBC/qOb3nIQyxasiPYY/uZ5I5ONDMYzWoheKw0PtArG0qsO5RSRlISeqLAKFlLbdrfU3gBJ3oj6vhMLHrWF7LtoMZlXc2YvvvUVhfDQrLyysNI3O9ikae3AnBakY79fdsrAU+7vJenfVG/NRGQlAIEyQivzQLA9u4fmxFBeQtUpoQbjVNNv9Xkvo66gBfMPRIvM=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV8PR01MB8677.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230040)(4022899009)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ANuvmmUF1Wh+a70nqK1yIAbPPVcWgkgV/owp5/cC3R+82jX6AMzwHXPlCxM2TVOOVNPiJS3jOQfbXfN5j6tnEQMo6R4eXQZoA8JFDsEi/x0a8iSlMwsz050C1c0612ZDf2WgG4hUSXgV5mMXSz4uXxK/LERz5FiFSpvvhSCJhlgKzY4tEK48ErrIhAC2olBj+vDmTGxxXyVmMbuoYTmet9QIOlDXsKflea3YGhE0fV54Bug7h8Gqs4FiMkStFske+8ymxmor4FdLJ+ZND7fyVv+7wcGCtyQGQlhg3Hbbz311V/84QOUeAVeZzp2CEmji59CFZqCSxHX+z2PjaVZ2b3toMxqMVbKAT1S00WPpFWCBN/pfbsbPJe0VXsK3WoppFB/iN85iD1oUsN3c78pgGN1A1lE77AmgVC1Ea9Wiha4fNFSjb99im0+CY/IYzYqVCbNIbiPVrcfVniqbNm2GHy+Gt2hH7k2biC1dS6cQVYS6lPaT+CbGwHRPHLIKRddVhIqrRe0HtJSfuc5EpQKCIN4RQvDTZRCsXv6EihTlH7DvLxVrWut6vj4I0phs0U4iIJGnEyWQ7Bzy9oKcyWoED4uPMdeS/N4iTN4rJ3QQExPIiCQPKqz305CyCTahYvQEkmOqIfhohx6/TfABN0klBQkZFRGqlA8MCh25z2Hj1BANsQErpk3NdtwiI5LGF8QpLmOPXGJGtnqJJ6CcJA3rMvaIlbV5eeWt9Cd34WMLj7XsICp/pxdB5BuYiEJvG7V6hac7rXMypQ46CNywpj0yr5yQj6ui6K+JFrNtkTxvXNNT8VJsOyWmx8uHFfE+d/H11H56KfXIRFUZRcwu1LsQIIrB4OI4H5duP9npz5bQl0F7S5ouq//OIUiLdq1wheJqePiviNgojY7jsZnCdeJSyePql//YRkaQ5hYB0CwAS8wkqZrYa0inRFlZnbGhTZem8Jl0Z+0G2XgdJMWZ06A+KvXm5QvVxozd4RAsUegGxmfC5ukIJ7hUNSUnyPL4DYDVNTXTAaF8Zytt8kvNhK+9/muH5RSyvEaEs5ooTkIH3u8nteRP4yBnStvcJeZxQH8eVvpdU7T1E7G1kHggtShi7lggQ/chJXwWYABF6AJIx7GPzwgju6cN6xJwO55i8A5vhu2FQwzxqELmDpVtfoCOYAMxiFF5HFq7N6vUA5JlxSRtOqbzg6DnG9nuVkUXws2F098B5b1OaqZVaoKOW00fJ21znfsokz3RVsSktivqW+0XI3fj+rc+JV0Uxkvyy7kciizi+SFCshyLmm/uEy7xzmGPfy4/WFuqHU/W5A5/CQ/fJtX9UqIBJBqc6ISdZX4e1mJxpTUhTNyvW4XkrSO/Ouz7qR5+WQgB1vb0I6v2YTqDn7o1U7h+6krSSYI13gIrd5zDKI4ypq9IgBFXrYnrpu3ZyyaVievjZCgCH10jh7G6veQ9TR3lDK+2l6T8Mo0zWiai76of0bvImVphSF9tjE2exXRra2bbw8lmxxixKK0FAHvbuePHdNOndKdpGQXhoww2fbVKF54MG9nW/GJZQHmV+rG99ONjkEnSBd6+fqtPQIav1snZ+GY6uLX/LiSR
Content-Type: text/plain; charset="utf-8"
Content-ID: <76C4CE7569DDD24781E09201130F739D@prod.exchangelabs.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LV8PR01MB8677.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3740f528-88a3-4573-f866-08dda854cb3a
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2025 19:27:09.6699 (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: 3MExS8/3L/faC0i4XqRyIux9kI+Uz+Lh1CDcTghfR2de6VEWVBcF8C0YTjiYOfFG
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR01MB6626
Message-ID-Hash: JDLBTW2LSBJDFYT26ZI2WGXL47JF5UK5
X-Message-ID-Hash: JDLBTW2LSBJDFYT26ZI2WGXL47JF5UK5
X-MailFrom: jricher@mit.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: Deferred Key Binding / TMB
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qmvX94c716dg7JmJxa76ZrmRcp0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>
“Deferred” is maybe not the most accurate term, I wrote the draft itself VERY quickly — but it was meant to convey that you don’t bind the token to the key being presented but defer that to another party. I’d be happy to list out possible mechanisms for establishing trust beyond configured policy (which is the only thing I’ve seen in the wild) — that’s one of the things I’m hoping to gather in the conversation about this! It’s not a bearer token because the resulting token IS bound to a key, just not a key held by the requesting software. Think of it this way: if you logically split the OAuth “Client” into two parts, you can have one part that can ask for a new token and one that can present that new token but with a key binding of some kind (DPoP, MTLS, HTTPSig, the mechanism doesn’t matter here I believe). The part that gets the token can’t use it at an RS, but it can hand it over to someone who CAN use it, and use it with a specific key. The part that can use the token (with the key) doesn’t have a means of getting a new token from the AS (either through architectural decisions or through performance concerns or just not mapping to the OAuth view of a monolithic client), but it can talk to the other part that’s able to get the token on its behalf. So the token does need a key to be used at the RS, and it’s the second part of the client that holds the key. — Justin > On Jun 7, 2025, at 9:51 AM, John Kemp <stable.pseudonym@gmail.com> wrote: > > Some initial feedback upon a quick read (with no background context for this issue): > > [...] > >> that up again and see if that interim can get scheduled soon. I’d >> also like to encourage people to read through the draft and open the >> discussion here on the list more. > > * What is the point of using the word "deferred" in this case? Is the "key binding" made at some future time? Why? What value does that bring? Until when is it deferred? > > * Might we enumerate the mechanisms by which you might "trust me, bruh" if not by PoP? > > * How is this _not_ just effectively a bearer token then? > > - johnk > > El 06/05/25 a las 12:45, Justin Richer escribió: >> Hi Chairs and WG, >> Back in Bangkok, we presented the draft https://datatracker.ietf.org/ >> doc/draft-richer-oauth-tmb-claim/ that introduces, in a concrete >> way, the notion of getting a token bound to a key that you don’t >> possess. As we discussed, this is a topic that keeps coming up in >> the OAuth space and is usually dutifully pushed aside for the sake >> of simplicity (and some would argue sanity). >> The chairs mentioned pulling together an interim meeting for the >> OAuth WG for us to discuss this topic ahead of Madrid, to see if >> there was anything more we as a community want to do with it. As >> we’re now more than halfway between the meetings, we wanted to bring >> that up again and see if that interim can get scheduled soon. I’d >> also like to encourage people to read through the draft and open the >> discussion here on the list more. >> — Justin _______________________________________________ OAuth >> mailing list -- oauth@ietf.org To unsubscribe send an email to oauth- >> leave@ietf.org > > -- > Independent Security Architect > t: +1.413.645.4169 > e: stable.pseudonym@gmail.com > > https://www.linkedin.com/in/johnk-am9obmsk/ > https://github.com/frumioj >
- [OAUTH-WG] Deferred Key Binding / TMB Justin Richer
- [OAUTH-WG] Re: Deferred Key Binding / TMB Watson Ladd
- [OAUTH-WG] Re: Deferred Key Binding / TMB Ethan Heilman
- [OAUTH-WG] Re: Deferred Key Binding / TMB Justin Richer
- [OAUTH-WG] Re: Deferred Key Binding / TMB Watson Ladd
- [OAUTH-WG] Re: Deferred Key Binding / TMB John Kemp
- [OAUTH-WG] Re: Deferred Key Binding / TMB Justin Richer
- [OAUTH-WG] Re: Deferred Key Binding / TMB Filip Skokan
- [OAUTH-WG] Re: Deferred Key Binding / TMB Justin Richer
- [OAUTH-WG] Re: Deferred Key Binding / TMB Pieter Kasselman
- [OAUTH-WG] Re: Deferred Key Binding / TMB John Kemp