From nobody Tue Jan 4 18:24:17 2022 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AE93A233B for ; Tue, 4 Jan 2022 18:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 Wo3G2PPPU8gU for ; Tue, 4 Jan 2022 18:24:13 -0800 (PST) Received: from na01-obe.outbound.protection.outlook.com (mail-centralusazon11021019.outbound.protection.outlook.com [52.101.62.19]) (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 531E03A2339 for ; Tue, 4 Jan 2022 18:24:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PfTwCFONHWU2Efvuw1CedUB4ohEk0vlSL6GzkAoFAv6WO1XdoZ1XqGzg7s5fNqos93ADUFgS1D3bRHQ2x2X085RUtRRFj+Q8KvyNIE0p+XQ0666G8ntpEJ/qdcaoFJgKZD/RlV+KqYe6EG/6Xi7peOOuGbTK8k0hmTRp5XmU1VSTneLmKylMNeSG3D38Mf9F11cxf/ewQbzvNU4yh97qfSI4m2ZvlQSPzBCQP/+78dfaatw79ah36mz8jMDKwrBFFY4Hyw0T6yoCQEqF7X0tkI2nvYjiw8Gl2qo/leePp2GQH352pKzWyjgY4DAJglE+2tQjtqCbu2DgI3kIEL/7yQ== 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=pHTsrEbjpBjYf6abU9m9gApmdC8wSIdPcu9hkI5Yc6o=; b=jdDFgwq8hR9nYqoP/zvUerLB1brkNkNNBNZwzrVmSOaA3Nfq8mDdu/oJrJ5IVo6VzfucXyBA+V0qgIeYQd/8RSqN4jdLdx7/g+wo91cRBziOg5PPgor853C09bKN2eVCAvhDchoWs+BT0GOb2mxrXPUjeBMvycHc7A9s3++fnBJuH7h19Vn52m3DJAm5JaLRuMwGbtP8enNJIzqdkfQnpmNknWg2+HxexrFOKnyldzmshjImz7EIAlGxQDCioEQsM3UN9OOprbTPh2fHxG1BxNsqkxkBgkqUKavpjy1U1PMBBR8rW5em+lxjsg+Hkp0wXZW+zPAucli2FjgTnfaMCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pHTsrEbjpBjYf6abU9m9gApmdC8wSIdPcu9hkI5Yc6o=; b=faLPlWMXz/zpZNX0/JMw6AnucULw26iz14Ak00lN56q2heBIaoPghBswvZbxsNY/IdVFHtLJIcaLv1uLN5nhBnBnY774JJxdQuE+8H4+ji3FRo9mOjMOgAWmjZpQTqXGcRJxWG0Fj6XEFSUw6g1McL2gx++TTe9ODgh92hGR7vo= Received: from PH0PR00MB1313.namprd00.prod.outlook.com (2603:10b6:510:102::22) by CO2PR00MB0166.namprd00.prod.outlook.com (2603:10b6:102:15::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4901.0; Wed, 5 Jan 2022 02:24:06 +0000 Received: from PH0PR00MB1313.namprd00.prod.outlook.com ([fe80::b0f0:ccea:715f:64a9]) by PH0PR00MB1313.namprd00.prod.outlook.com ([fe80::b0f0:ccea:715f:64a9%4]) with mapi id 15.20.4905.000; Wed, 5 Jan 2022 02:24:05 +0000 From: Will Bartlett To: Warren Parad CC: Brian Campbell , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter Thread-Index: AQHX5sYwYWOH9aFi4UqIKbP5Xwc68awdwsOAgAGV6YCAADEbgIAASOGAgAAGgICAARd1AIAABbMAgABhoICAAPQogIAKSFGQgAduQoCAACODxg== Date: Wed, 5 Jan 2022 02:24:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-01-05T02:24:04.898Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 368709f6-0ca8-4e0e-8ea4-08d9cff27223 x-ms-traffictypediagnostic: CO2PR00MB0166:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: liaFQmJhnf7QMESgZmBWnmPMWl2yHlSQiY60y4p1tR2zMPvnhB0AWdhyJEDXwgXFVEeexnHGD1RedNo/npXlZ+ll8RYv7TUo8RYpBF8iFBZ0SCrHyEsiscoxNadwsRSTXE+n9g1xh/DJGIBrI0GwKIipXnXqSRj9vsvrgrEKhvHbyKVI2LeMGP/gFGsBivSMzY0TaAhlbGc8qWzGQgRFBkaeinv8AUMdLxbRsCWjuqVcdyWn50x2Rb68XQpHTsHbmxNoL+/Mtq9P2lq1TmOmRiduYMQalkMXtVZREkMu8Rk3ozi7JK8z+lWSaH35N6p7F/QFXXHjtjcfjAMv703ahhmrEcuymH/+LhwK5K6n/PvgbJajdPQIIgIie1xLXCHd0WPMxL7mO9x7eBoU4H0/f3ddtB+UPLxWH7S/J9/2aTka+D1DF4qu+9j6BmpmVuqLrtGJlOQ/VN9TgBADBMm4Wjm+sppp9BdyGtkKZzLFKoRLHS/uNUU8RlDelXp6X6aIFk3uvFaXsmtQNAiJWcB/qruTppKLBsEFR46pLl38kd4yFuqr43pPVk5PXaAuJR9MoCBSGDQlkf/8637gLZAqeGdD+2wupX2dHCSKGkD4Ooylo47evjMIrV1+sAwBqUGCcOfk/BlC5SzKIP3X65RBgCwnX4ITr7vOfaSFa0Ky63tnjb/V7xj2YGx0gxMFojMWm1u0y9IxsuoxeHbxp6VAm5LKpe/ODOVnWp580bKg75q/M3XYaIAb0uV7ob7Z0tdp x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR00MB1313.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(86362001)(6512007)(66574015)(19627405001)(76116006)(52536014)(6506007)(6486002)(10290500003)(316002)(38100700002)(33656002)(66946007)(2906002)(54906003)(9686003)(66476007)(66446008)(66556008)(122000001)(71200400001)(508600001)(64756008)(38070700005)(186003)(4326008)(8990500004)(82950400001)(82960400001)(83380400001)(8676002)(5660300002)(8936002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?dora/dImx9aV/ipI4sKROh2jtFvV/VHetUNodSGhYHJDbLBY+3Z6G3cMvC?= =?iso-8859-1?Q?gh6hmkdRXZJj9puaKE7fLLS+F6yAqbHaZTFl1qcPVt0J1AEPHCFeixL/a7?= =?iso-8859-1?Q?4IhXmvrgiPa4E0nv/wiPskiKcDyD6cpC/SiVgbs3MSw9OSmCUK8fIuoMF+?= =?iso-8859-1?Q?n81ECCU8J5i1vNkWbOY5Az9jP7t60yali3e4hRQuJnl9ciLfuL7DrJlNLw?= =?iso-8859-1?Q?MRiIUGULxxC602EzwMC1Epxzy7NoHv7Kkl+iWnuC3u0gznnN4DuVrkF4xq?= =?iso-8859-1?Q?6iGsI+o4E+4ZWAmskd16l7xsw7frd1pxQgsUISyYPtn78fzksenN+pKKos?= =?iso-8859-1?Q?UOrEu5Bv+QD5EYN2EGc2mLqX64SAgSsQV1IGBeYeJMihX97Tg3N1Y7e13E?= =?iso-8859-1?Q?tiZbFDSkfmbVTq1Q71UZJIUAkJf5QlahwbWxEPKGCVala/q026Ud7zCojs?= =?iso-8859-1?Q?Kd7+sBAHeIGkppYxiy9z6p8v11DGzHNZBBXwlyHxEeiUeosNDwXPVgQ9tE?= =?iso-8859-1?Q?7lUQI9YPJfAnzCEcF3fmgPmxWTmFXi4rJ0zMyiYGXNYczlRyJF5yecideg?= =?iso-8859-1?Q?x3iEMNELjVp/B7D4BvPcO/V8eozKZHYjXMh+u5faDSGpcslIsvsMgmK/+O?= =?iso-8859-1?Q?5f4217NYkvFr0i49DguX2pmPQOfOk/aBpqpPIZ1yWLHFep7YBp9V7mz4kF?= =?iso-8859-1?Q?tzMEsFugEC/TJtt270VRmN0MgOQDUQmYNveBgzqL4Dn5ZEM+I4iTM31Xsy?= =?iso-8859-1?Q?EV3ne1YbzlNbhSmsOOtP64Qxb5RPPXffJ2iTuhc62hjnfvEaZrVKq1tPyH?= =?iso-8859-1?Q?BPOmvHy3ZwYQmNjtq302dmBN7ZiTyK41TShR1jOy8no61jP3ADoGQmLBBk?= =?iso-8859-1?Q?+csNO4KvqXSVXP3VHsGc7QVhX5DreggwmJsAPtWO38oEXyg337s9YNPRd4?= =?iso-8859-1?Q?bkVPLVz/35KXoZisFasssIa7KfTugF10AGanBoe+6eifumcc3bFhs/ADH3?= =?iso-8859-1?Q?4/hQnx+5+PNE1M/3CaR5i0Et26Z8N81YMgS1dSqwZUoo9UTn/vwarVyB/u?= =?iso-8859-1?Q?vOtqP7RSt+Wcyylej5sbq2kcZ6CYJijJ8cXCVBL+kNrX4QHKJbYRgdu70R?= =?iso-8859-1?Q?PD5Le7jIwd57TMbWwzvGDcci9BMn9ZGWRRADc0J2PV1MJweavYPeiRoB/k?= =?iso-8859-1?Q?4fE0z6QB5YP6HQrPao9W6JVDqUaIuODG9QYx98dU7Bt73XVN6xUOKlHZKW?= =?iso-8859-1?Q?xbNo35f64j55xC6CburAji2lFilfmq6NYYCxoUIT030qxFxsSz9tQlhA1K?= =?iso-8859-1?Q?4Z3r1qB3pzmUdgebWnp1bTTEZz1AfwvAbBIdFYGG3EXJe+HqmoDT7vvjL6?= =?iso-8859-1?Q?doKfjpYtIvFHzEL5yxSWI0wBG+aqDpdqJA783L2Oqg6JGC0ttXAlLSO4es?= =?iso-8859-1?Q?X+/inZoSdXBFxfrw+TbW4OSmDGBBM9b3Ww57LqLxjwOisazOImSnBwQKus?= =?iso-8859-1?Q?LuD2rmXYm9cZAv81b5qwKd+VNr3AE5382Q40ulIa0rvnTRQHmHRR89vO9E?= =?iso-8859-1?Q?y5VEnC5tJNhz2mDnXJtD2/+D8ECrZ8l9wSyoKUUGq7A74emsR/BhbFf3+I?= =?iso-8859-1?Q?/NEZopptdQDulm0bnxvlqzEqMoRPO89MC4677aPkIjNfWMmp2ssMUp4xWz?= =?iso-8859-1?Q?9idlptw3/qkQ/cYgE67jBmGjFOYPuXls2drjyTsnlJM3ztM/C6P+FyUMMk?= =?iso-8859-1?Q?htOw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SJ0PR00MB1320E2358164B7F2CC7D5D9FD3769SJ0PR00MB1320namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR00MB1313.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 368709f6-0ca8-4e0e-8ea4-08d9cff27223 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2022 02:24:05.2754 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZtRmytEVolc58h5ikzN75ucbgOpJCGxvfquaGMyR8Ed8Tb/5cFAqyDJyyZQRnfXr4XmQohpJaimal9iO89FHKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0166 Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 02:24:16 -0000 --_000_SJ0PR00MB1320E2358164B7F2CC7D5D9FD3769SJ0PR00MB1320namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Warren, For (1), I will try to be more concrete using a variation of Microsoft's sy= stem on mobile for public clients - but it is a bit of a long explanation. = Microsoft OAuth applications are assigned a random ID (for example, we'll u= se 1-2-3-4). If they use iOS, they add a redirect_uri=3Dmicrosoft-ios-1-2-3= -4://sign-in - that is a URI whose scheme consists of a prefix and the OAut= h application ID. They'll also update their app registration to indicate th= at their app handles that scheme. For sign-in, instead of opening a normal = web browser with the OAuth parameters, the application opens a specific Mic= rosoft-owned native application (which we call "broker"), with the standard= OAuth parameters. The broker application uses Apple native APIs to verify = the native application identity, and then makes the requested OAuth request= , augmented with the user's SSO state, and then returns the OAuth result to= the original application on the registered scheme using IPC. For the OAuth= request, this broker application supports the standard transport (query / = form post url encoded, cookies for user SSO), but it also supports an enhan= ced (MITM-resistant) transport, modeled after OpenID Connect's "request" pa= rameter, where the OAuth parameters are instead sent as a JWS, using a user= key (which is generated at first sign-in), and the user's SSO state is sim= ilar put inside the JWS (instead of, e.g. a browser cookie). From a user pe= rspective, the way this works out is that the user signs into that special = broker application once, the first time they use the device, and it provide= s SSO to other applications. If the user is MITMed, the MITM can't interfer= e in the communication between the end-application and the broker applicati= on (as that's on-box) which includes the dpop_jwk, and the request from the= broker application to the identity server is signed over in a JWS, so it c= an't change the dpop_jwk. The MITM can tell the broker that the user's cred= entials are expired (in an attempt to force the user to re-bootstrap - note= that the bootstrap moment is inherently MITM-able), but then the user has = to be physically present at the device and willing to enter credentials, an= d it would even be possible for the broker to indicate to the server that i= t is a re-bootstrap rather than an initial bootstrap (unless the user unins= talls and re-installs the broker). From my perspective then, in summary, as= long as we are talking about off-box threats, the _earlier_ you can bind t= he user to a cryptographic binding and the more uncommon and intrusive (pro= mpts, notifications, etc.) you can make true cryptographic bootstrap moment= s, the more types of these threats you can prevent. "dpop_jwk" is general p= urpose glue to connect _whatever_ binding the SSO state already has with DP= oP. This is all proprietary, but 1) we're working fixing that 2) I do think you= can construct similar MITM-resistant profiles from things that are standar= d. Re distributed systems - not sure if it's impossible, but it's certainly ha= rd. My comment is more about complexity - distributed systems for single-us= e auth codes are much more complex (e.g. by lines of code, number of config= urations) as cryptography for the same purpose. More complexity means more = bugs, harder auditing, etc. I'm not 100% sure I follow the comment w.r.t confidential clients. The way = I had envisioned DPoP working on a confidential client was for e.g. an ASP.= NET website. On first (unauthenticated request), the website would generate= a CSRF cookie, OpenID Connect nonce, and DPoP key, store all of these in t= he session store (encrypted cookie or backend session store with session id= cookie) together, and then communicate them all to the AS on a 302 redirec= t (in the "state", "nonce", and "dpop_jkt" parameters, respectively). When = the authorization code response comes from the OAuth provider, the website = would use state to locate the correct session from the store, and redeem th= e authorization code using a DPoP header signed with the DPoP key from that= session, check the nonce in the resulting id_token, and then persist the R= T and id_token to the session store. You mention "more than one entity" - c= an you get a bit more concrete here? Similarly, I think this should work fo= r native clients as well as SPAs, except that that all this data is kept in= memory rather than in a session store. I do take your point that dpop_jkt = should be optional for clients - no pushback there. I worry a bit about the= language you suggest "the dpop_jwk MUST NOT be required by AS". At Microso= ft, app registrations have rather a lot of properties - it's possible that = we might expose a property like "bool requiresDpopJwk" and allow the app de= veloper to configure it - we do this in rather a lot of places (e.g. disabl= ing the implicit flow). DPoP being an optional extension in the first place= - I'm not sure what meaning such a statement would really have. It seems d= esirable in general for implementation to support converting bearer RTs to = bound RTs on the fly - we'd probably always allow a DPoP proof to be provid= ed on token if the incoming credential (AC or RT) is unbound. I'm usure about generalizing the parameter. I might have proposed calling t= he parameter "dpop" and making its value exactly the "DPoP" header sent to = /token - i.e. this is really just DPoP - but browsers with 2k URL length li= mits never quite seem to vanish entirely. So, DPoP coupling - expected, JWK= coupling - already present in DPoP, lack of multiple - already present in = DPoP, other needs - non-goal, lack of consistency - agree this is a shortco= ming, but couldn't solve it. FWIW, I'm not strongly opposed to generalizing= , just worried about adding complexity. I don't follow w.r.t DPoP signature on the AS without assuming that AS and = RS will adopt DPoP at the same time, which I would prefer to avoid. DPoP de= scribes a downgrade path so DPoP-unaware RS can work with DPoP-aware AS und= er "Compatibility with the Bearer Authentication Scheme". If the AS doesn't= check the DPoP signature, then a user gains no protection with a DPoP-awar= e AS and DPoP-unaware RS, instead of gaining partial protection (protection= for refresh tokens but not access tokens). I think that partial protection= is worthwhile - 90 day refresh tokens, 1 hour / 1 day access tokens, 5 min= ute DPoP proofs - 1 hour or 1 day is still a substantial gain on 90 days, e= ven if it doesn't get all the way to 5 minutes. Thanks, Will --_000_SJ0PR00MB1320E2358164B7F2CC7D5D9FD3769SJ0PR00MB1320namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Warren,
For (1), I will try to be more concrete using a variation of Microsoft's sy= stem on mobile for public clients - but it is a bit of a long explanation.&= nbsp;Microsoft OAuth applications are assigned a random ID (for example, we'll use 1-2-3-4). If= they use iOS, they add a redirect_uri=3Dmicrosoft-ios-1-2-3-4://sign-in - = that is a URI whose scheme consists of a prefix and the OAuth application I= D. They'll also update their app registration to indicate that their app handles that scheme. For sign-in, instead of op= ening a normal web browser with the OAuth parameters, the application opens= a specific Microsoft-owned native application (which we call "broker&= quot;), with the standard OAuth parameters. The broker application uses Apple native APIs to verify the native applica= tion identity, and then makes the requested OAuth request, augmented with t= he user's SSO state, and then returns the OAuth result to the original appl= ication on the registered scheme using IPC. For the OAuth request, this broker application supports the sta= ndard transport (query / form post url encoded, cookies for user SSO), but = it also supports an enhanced (MITM-resistant) transport, modeled after Open= ID Connect's "request" parameter, where the OAuth parameters are instead sent as a JWS, using a user key (wh= ich is generated at first sign-in), and the user's SSO state is similar put= inside the JWS (instead of, e.g. a browser cookie). From a user perspective, the way this works out is that the user signs into tha= t special broker application once, the first time they use the device, and = it provides SSO to other applications. If the user is MITMed, the MITM can'= t interfere in the communication between the end-application and the broker application (as that's on-box) = which includes the dpop_jwk, and the request from the broker application to= the identity server is signed over in a JWS, so it can't change the dpop_j= wk. The MITM can tell the broker that the user's credentials are expired (in an attempt to force the user t= o re-bootstrap - note that the bootstrap moment is inherently MITM-able), b= ut then the user has to be physically present at the device and willing to = enter credentials, and it would even be possible for the broker to indicate to the server that it is a re-= bootstrap rather than an initial bootstrap (unless the user uninstalls and = re-installs the broker). From my perspective then, in summary, as long as w= e are talking about off-box threats, the _earlier_ you can bind the user to a cryptographic binding and the mor= e uncommon and intrusive (prompts, notifications, etc.) you can make true c= ryptographic bootstrap moments, the more types of these threats you can pre= vent. "dpop_jwk" is general purpose glue to connect _whatever_ binding the SSO state already has with DPoP.

This is all proprietary, but 1) we're working fixing that 2) I do think you can construct similar MITM-resistant p= rofiles from things that are standard.

Re distributed systems - not sure if it's impossible, but it's certainly ha= rd. My comment is more about complexity - distributed systems for single-us= e auth codes are much more complex (e.g. by lines of code, number of config= urations) as cryptography for the same purpose. More complexity means more bugs, harder auditing, etc.

I'm not 100% sure I follow the comment w.r.t confidential clients. The way = I had envisioned DPoP working on a confidential client was for e.g. an ASP.= NET website. On first (unauthenticated request), the website would generate= a CSRF cookie, OpenID Connect nonce, and DPoP key, store all of these in the session store (encrypted cookie or= backend session store with session id cookie) together, and then communica= te them all to the AS on a 302 redirect (in the "state", "no= nce", and "dpop_jkt" parameters, respectively). When the authorization code response comes from the OAuth provider, the we= bsite would use state to locate the correct session from the store, and red= eem the authorization code using a DPoP header signed with the DPoP key fro= m that session, check the nonce in the resulting id_token, and then persist the RT and id_token to the ses= sion store. You mention "more than one entity" - can you get a bi= t more concrete here? Similarly, I think this should work for native client= s as well as SPAs, except that that all this data is kept in memory rather than in a session store. I do take your poin= t that dpop_jkt should be optional for clients - no pushback there. I worry= a bit about the language you suggest "the dpop_jwk MUST NOT be requir= ed by AS". At Microsoft, app registrations have rather a lot of properties - it's possible that we might expose a pro= perty like "bool requiresDpopJwk" and allow the app developer to = configure it - we do this in rather a lot of places (e.g. disabling the imp= licit flow). DPoP being an optional extension in the first place - I'm not sure what meaning such a statement would real= ly have. It seems desirable in general for implementation to support conver= ting bearer RTs to bound RTs on the fly - we'd probably always allow a DPoP= proof to be provided on token if the incoming credential (AC or RT) is unbound.

I'm usure about generalizing the parameter. I might have proposed calling t= he parameter "dpop" and making its value exactly the "DPoP&q= uot; header sent to /token - i.e. this is really just DPoP - but browsers with 2k URL length limits never quite seem = to vanish entirely. So, DPoP coupling - expected, JWK coupling - already pr= esent in DPoP, lack of multiple - already present in DPoP, other needs - no= n-goal, lack of consistency - agree this is a shortcoming, but couldn't solve it. FWIW, I'm not strongly oppos= ed to generalizing, just worried about adding complexity. 

I don't follow w.r.t DPoP signature on the AS without assuming that AS and = RS will adopt DPoP at the same time, which I would prefer to avoid. DPoP de= scribes a downgrade path so DPoP-unaware RS can work with DPoP-aware AS und= er "Compatibility with the Bearer Authentication Scheme". If the AS doesn't check the DPoP signature, t= hen a user gains no protection with a DPoP-aware AS and DPoP-unaware RS, in= stead of gaining partial protection (protection for refresh tokens but not = access tokens). I think that partial protection is worthwhile - 90 day refresh tokens, 1 hour / 1 day access to= kens, 5 minute DPoP proofs - 1 hour or 1 day is still a substantial gain on= 90 days, even if it doesn't get all the way to 5 minutes.

Thanks,
Will
--_000_SJ0PR00MB1320E2358164B7F2CC7D5D9FD3769SJ0PR00MB1320namp_--