[OAUTH-WG] Re: Call for adoption - PIKA
Michael Jones <michael_b_jones@hotmail.com> Wed, 18 September 2024 19:43 UTC
Return-Path: <michael_b_jones@hotmail.com>
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 EFD01C16942E for <oauth@ietfa.amsl.com>; Wed, 18 Sep 2024 12:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.232
X-Spam-Level:
X-Spam-Status: No, score=-6.232 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, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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=hotmail.com
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 E906YirTNsXG for <oauth@ietfa.amsl.com>; Wed, 18 Sep 2024 12:43:25 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02olkn2011.outbound.protection.outlook.com [40.92.44.11]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA88C169422 for <oauth@ietf.org>; Wed, 18 Sep 2024 12:43:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fYb+r5BdgOq4nUsltuv/xDM7uNWPDFJ+ZQXv8Szemh4WahDvqKAMuLqENMcn+T1LyHASVHpa0h5LXiroD0W8MLnnfe/rGKbQsuK66i7QVV1yF0x3yhydpJFIOgcWRIsOinZkdxEsRVRiGgT72TzI39cESgbM6udI3bmoH50MtlycGTr0tkW24r5pYoQrMa7yP7fLEuyJwdN0jaYpYO+lRa7eZplF4KmrgJsMJBEftrutSkbx9V094vC5UwPyE/SDe6C4sZnBIjo8+3svKusIyJc2mCpPu2yc49lU7086if1QOrpWA+Wx3bF5pEPQxOjPCV2fbqAYkULmQM/ogP6V/Q==
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=gVF/TEijkb85NRYR1dJDSWGsKOHiCWvq2UfWedZ9cnc=; b=tyfQuBhxHbF5VbF2QZ6gVEty/YlZIPJ3aL8FFK0p2Aj6zZ1f6N1XnoflUbkmWHI3Gb2Mk8FawMVK8JLUWJBOxlsjIaFgnQX/WP0SMvKOQCy8K6koCZs+3QQLNmxsZNNCcLLPofxHX46NdJfeud2lI8Hl1QHBW6j3SKVWZowvbZouZLUsKCkW2iGA6Mg1358lAynPHDl14k+12+l4s8YBYlCiLlbwF6ASJfbRT2NDRuQRhLp3rMQStnlBniwcpr5Stskjiz6DDECzs+6rM4xbSVWxlRUWmpv7wfFWhmPYcMwEjbzUkV8RGDmmwLCUInfoY5Bu8yNAbAxiz2gMVpgn9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gVF/TEijkb85NRYR1dJDSWGsKOHiCWvq2UfWedZ9cnc=; b=VrGVOvfAzuKkGeZDEF8Rc4OVYUk3b06tm7g1qcE7XBaU3PZND+Mv6jBHR6mrlosaPZN0C7w4evoYQI3rMiJPnOwH3aFB9YIQNPaYWjHgoXOFbP3475m+e29XZqRCGeIqAjAQWjmDxr7aOUa491o6lzNcZQzrAIxKbqf313iwCLdj67bVuXZNM36CI8LVPE0w2w20R6NN86N2VSCT4DbnCgQCzBkkGTqfIOzs/8xf9uAoR/lRgGIFlzppbEIgBoyfArXWuEpEXfdPCnRZ/LKiaTgX8iQc6X9a8G873gkf0jJU8WSUIU/5d0ZDCo0NxIMlRws8yX7jS4D39mFdcmbupA==
Received: from MW4SPR01MB0004.namprd02.prod.outlook.com (2603:10b6:303:75::21) by CO6PR02MB7810.namprd02.prod.outlook.com (2603:10b6:303:ae::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7982.17; Wed, 18 Sep 2024 19:43:22 +0000
Received: from MW4SPR01MB0004.namprd02.prod.outlook.com ([fe80::abda:6db8:d594:3ad3]) by MW4SPR01MB0004.namprd02.prod.outlook.com ([fe80::abda:6db8:d594:3ad3%6]) with mapi id 15.20.7982.012; Wed, 18 Sep 2024 19:43:22 +0000
From: Michael Jones <michael_b_jones@hotmail.com>
To: Richard Barnes <rlb@ipv.sx>
Thread-Topic: [OAUTH-WG] Re: Call for adoption - PIKA
Thread-Index: AQHbCHzINGleKGFO9kCAofTYHbGEcrJa+wiggAKh6oCAAFDzkA==
Date: Wed, 18 Sep 2024 19:43:21 +0000
Message-ID: <MW4SPR01MB0004D7F8EB9345C7C2B5853BB7622@MW4SPR01MB0004.namprd02.prod.outlook.com>
References: <CADNypP80YnzxOc_NDbFqK0bv=i0Ys1s8hYHwo-PqhUPbAWs4sg@mail.gmail.com> <SJ0PR02MB7439153AD9ACAC9C1C5563A4B7602@SJ0PR02MB7439.namprd02.prod.outlook.com> <CAL02cgR0LDDq_ZD1MXy3T-qapKrx0DywvXiKi6m+0T4PPH4RNg@mail.gmail.com> <SJ0PR02MB743983DC316ADED427CBB3F4B7602@SJ0PR02MB7439.namprd02.prod.outlook.com> <CAL02cgSA5LzHuj92Ar3QPFYStPYGTpR2YA75RQichOcwQbMdNQ@mail.gmail.com>
In-Reply-To: <CAL02cgSA5LzHuj92Ar3QPFYStPYGTpR2YA75RQichOcwQbMdNQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MW4SPR01MB0004:EE_|CO6PR02MB7810:EE_
x-ms-office365-filtering-correlation-id: 80474232-7273-4f17-863e-08dcd81a2746
x-microsoft-antispam: BCL:0;ARA:14566002|8060799006|9400799024|7092599003|15080799006|461199028|12050799009|19110799003|56899033|102099032|1602099012|4302099013|440099028|3412199025;
x-microsoft-antispam-message-info: lBsCE4ouYrT3rIMwz2TXilGjOl41adVfZYA8mw+7ZgGDujIHhopbPfVs/NhKgsl6iGPHGSXvEhDxm+Icek6T9CaVM1bJIHD7Vl5Ff4wnMsA7dXLXdTOxwWOyYcpfD0QIaY40jPk5Y7ukds7xSatPqj5S/eLb6gowWVIW+iJMns80eY2VsA90jPbSVk31vFMSwTrWPK5LZusAszG15A00tZq3pCFTgQliLeo2i5ckNtQVyd9/moTND2QjWCDfWaBpKZtlYAlJ45KwdHLB5UjUIrve9sHTjmoBl7sap44k5wGcb8Et0JUDWltO8/usii2fY2D3E9Efqqyw4sGwWdcT0GlxkJFSdiLzgIYmAEEfaYJV93FiF9aLAcXBpcjGuQ7C9VeKdI2VojlM0TsOY6MmLk+YfZmL5Y2cbr/B3fC/2ZRu7COjy8CBJmHNt7a3hRWqXyWn4YqEHznK2UGP2nozgiBzVED/T3xmFk3SEkEo0SKJwbu87IYu+mJFT4fuKodl3ynhJXZMcayBNg/GkSad13VCR+eFWMX/gaT1NqE+lahODMdZKYMKnebGu7ThiLBWEhtAJFkh+GuRv+oNMeg2LIxiJI5XGVfCt7jXjgo3UoPTo907zzPYRhBxGsnkDra4hzCMqNkGqPppDc2laElxTie/JmUaq2fNgbBH80822SnhTM/X08Rhh8K5617xFFa10yjbeEduWr1piKS8atp6GmIBPmO0ahK9DlaNolTLzTDnR3Y26sLVtEDBOjD4ragqizRuyCa+uQU5PlBFnBy68n5TWtVVmM+w8Q1p09Bkpfz4BELhnUlr3OQ7hky4uhKSHTQXGbAEUJsWTWseWIIIvbmlMrVwpiflkbw7njBlggtX6Cog3vpHtAPFEP7I4tfg
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: x38NFhnQwEk+o0nVB28eHnusu1/82LePQYDX4bHAD4jgFp+rPyeUlD46JzxMHbpbOJ4hk3kstlxPudFtTFXoTJEKS6UqBhvItj9ycIAvZt3t8lYLQcZjzXCsZlZ6+AIp3PEw1mkRXX4ZfWQnl12mDiRVjM2DSF7fvxFQQfJ2eQWj/IoHdytQLk95F+CaGxvwTaP+xTmCRDkuKuUx/m7xzCiBHOm9JLIQyXml24aqxYDsVz2nQxXAAZ1VWnEAKiNewIOXNmmEput99NmY0n+8m8Ub4TCOCONHKywdVpRWAyP/g25yrsWcigYF4NbEJgV/DYb2Yic3cOr2BGs/x83BeoGlMOw207b3/gQN3BCIenStauAqnuWyfBiURscAnSj94Kn5/qDbJ6Gg4/1JpH+1B54xOo3Kjqi80Am/wYVg4mw7bC2BlxiJj2B1P5lWBPX985VEVHiqyGYAWMN2SxBIZo8EoA/u9p20cYYgGjslUa/YTUb+OfstjFDNQo6AtGo9w2IjusNWnMWbXEUhuCTIk40sMfUOuZxxr8wqNVBZwQdRm+PICDchvZGS9KldnwbfG1b4hS+WcCPxnZaPG+xMjKNJ2QjM07YENtRVAGvY3FvIzNrGeTILEXgp5u5UaeXeX+5xmkVBUSHW+/tBzmmcGch4s17amLs4JxVN78QkvGyCM8IWAvNeOYTA6HmSNpaaGYvLtTuw6ezIXSpMh2SUnmG+WQXEULBaq8PdJKzpX0aja3jfSohUCwAomATBeRmkm1nKiIJWhe4b0HkyBTevQs9tYLbO6uOrmAAx+uHNW0I6ylUmqf/L/dq3k1YFO7NxC+aK2QkoWx/Ko3YmB+mdty4pZGYT86gkGN4pUDoW1GAjvvXwaimM99k4bLdHO/1YGHlxjOkCCICqDQH0RjCIXh/tkozv7TPDM0dCh/lCxxOrfRw+/i/N6Uyr9CcKrP6eP87rpkkpUMqvTInqdKIKYg8AW6SGyn5mfIU663Vf75tvnu5LUCjr/fNIjWir7O7gcOQWgB1T9trOfKbSlsaBas3X+KslPOYG36mKZWPKPCmBwMzzHkiB3EUMRvL6ZT5DWx0s/gQHSvNNPUib5CnwtLd6CZCXVJr2+5upAZj2ACwA4GuPqm8lGMgMefet8oMI5sD+zOk9cjSAkFQSbZyr9uvcayHitb/IPcrTMbHM6bL8+IDqEWt0U0P3H9TPo/xAwdmhjL3aFz2Fk+pB9EnLMtXibHmXI5AvmPMh4IQwreU=
Content-Type: multipart/alternative; boundary="_000_MW4SPR01MB0004D7F8EB9345C7C2B5853BB7622MW4SPR01MB0004na_"
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-7719-20-msonline-outlook-0f88b.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW4SPR01MB0004.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 80474232-7273-4f17-863e-08dcd81a2746
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2024 19:43:21.9276 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7810
Message-ID-Hash: AWVEB6AS6FHXG5HW72Y6HTSHOJEKZNK7
X-Message-ID-Hash: AWVEB6AS6FHXG5HW72Y6HTSHOJEKZNK7
X-MailFrom: michael_b_jones@hotmail.com
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.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2pdVy0gAEPQQ-ObCnFV5nNFGsgc>
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>
Hi Richard, We clearly had different expectations for the 2nd call for adoption. Yes, I was in the room in Vancouver but nowhere in the minutes<https://datatracker.ietf.org/meeting/120/materials/minutes-120-oauth-202407262000-00> does it say that the authors were not to incorporate the feedback from the 1st call for adoption to improve the specification before the 2nd call, nor do I remember that being said. Given that useful feedback was known to the authors as a result of the 1st call, I was quite surprised not to see the draft improved before the 2nd call by incorporating it, as were others. Yes, the problems were *acknowledged* in the presentation, but they could have been *corrected*. Not correcting them was a missed opportunity. As it is, once I reviewed the draft for the 2nd call and realized the feedback wasn’t incorporated, it felt to me like an attempt at a do-over – running the 2nd call on essentially the same content as the 1st, but hoping for a different outcome. Anyway, that’s my perception of the situation. Thank you for responding to my 6 points. I’m not going to go back-and-forth on them individually at the moment, as I think the chairs should first figure out what to do about the new call for adoption, the feedback received during it, and next steps. I will say that, given the legal and compliance issues raised by Vladimir and DW, I personally don’t feel like we’d be on solid ground to adopt the spec until at least the spec clearly says that the certificates used MUST NOT be TLS certificates. Sincerely, -- Mike From: Richard Barnes <rlb@ipv.sx> Sent: Wednesday, September 18, 2024 7:28 AM To: Michael Jones <michael_b_jones@hotmail.com> Cc: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>; oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] Re: Call for adoption - PIKA Hi Mike, We addressed these points in the presentation in YVR, where we had a successful IRL adoption call based on the premise that these could be worked in the WG post-adoption. You were in the room for that, so I'm surprised that these concerns are being re-raised now. The chairs advised us not to revise the draft before we confirmed that adoption call on the list. Nonetheless, here's a quick recap of what we said in YVR: 1. Application-level use of PKI -- Several developers have opined on-list that this is not a practical barrier, and that the resilience benefits of PIKA are worth the extra effort. 2. Reuse of keys -- The core idea here is to make PIKA signing certificates different from certificates you would use on a web server. For example, we can require that the PIKA signing certificate use a prefix, say containing a SAN for _pika.example.com<http://pika.example.com/> when authenticating the issuer URL <https://example.com<https://example.com/>>. 3. Authorities with paths not secured -- Paths are not secured today, with HTTPS-based discovery. Anyone who controls the domain on which an issuer is hosted can impersonate that issuer. PIKA is not making any change in that regard. 4. Odd hybrid -- I'm not sure how to respond to "odd" as an engineering concern. JOSE and X.509 have been intermixed since the "x5c" parameter was introduced. The layering here is actually quite clean: JWK and X.509 talk about different keys, with the X.509 keys "blessing" the JWKs. 5. Upgrade path -- There is a trade-off here between concreteness and future-proofing. Our proposal is to continue to have PIKA articulate a concrete, PKI-based mechanism, but also provide some notes on how one would update it to use different authority mechanisms. As to the direction of travel: The direction this document is trying to move is orthogonal to the axis you're talking about. The OAuth ecosystem already relies on X.509 in the ways we are relying on it here. We are just expressing that reliance in JWS instead of HTTPS. If, in the future, the OAuth ecosystem relies more on JWS in the places it currently uses X.509, we can make a PIKAv2 that takes that up. But that is not the world we live in today. Best, --Richard On Mon, Sep 16, 2024 at 6:23 PM Michael Jones <michael_b_jones@hotmail.com<mailto:michael_b_jones@hotmail.com>> wrote: Hi Richard. Thanks for the quick response. What surprises me is that a lot of substantive feedback was communicated during the prior call for adoption and as far as I can tell, none of the problems identified were corrected in the draft before the second call for adoption. Incorporating it could have both solved the real problems identified and likely increased working group consensus. I would really appreciate it if you could send a reply to my note saying *how* you plan to address each of the points raised – certainly the 5 main points but possibly also the 6th bonus point “direction of travel”. Again, none of this feedback is new. It’s a synopsis of issues that you were already aware of from the first call for adoption. Thank you, -- Mike From: Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> Sent: Monday, September 16, 2024 2:10 PM To: Michael Jones <michael_b_jones@hotmail.com<mailto:michael_b_jones@hotmail.com>> Cc: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com<mailto:rifaat.s.ietf@gmail.com>>; oauth <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Re: Call for adoption - PIKA Hi Mike, This is a call for *adoption*, not a WGLC. Our thinking was that these were fine problems for the WG to work on. The adoption question is whether we believe the WG will succeed at that, i.e., whether we pretty much know how to solve the problems. As your email points out, there have been a bunch of good discussions about these problems, and broad agreement on solutions. We will get a draft out in time for Dublin with a first pass at getting them reflected in text. But resolving these problems should not be a blocker to adoption. Thanks, --Richard On Mon, Sep 16, 2024 at 3:55 PM Michael Jones <michael_b_jones@hotmail.com<mailto:michael_b_jones@hotmail.com>> wrote: I regret to have to report that the issues that I believe resulted in the first call for adoption failing, despite being discussed on-list and at IETF 120, have not been addressed in the specification<https://www.ietf.org/archive/id/draft-barnes-oauth-pika-01.html>. I did have a productive conversation with Richard in Vancouver, which resulting in him mentioning some of the problems in his presentation<https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>. Here are the problems that have not been addressed since the first call for adoption: 1. Application-level use of PKI trust chains. As I wrote in my response to the first call for adoption<https://mailarchive.ietf.org/arch/msg/oauth/rPPI9E8fwN1NiMM1TkaQUfFYEDI/>, “Other than for TLS certificates, the OAuth and JOSE specs generally steer clear of dependence upon X.509 certificates. Especially for a spec focused on JWK Sets, it’s odd to require an X.509 certificate to secure them.” This problem is acknowledged in Issue 1 of Slide 7 of Richard’s presentation<https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>. As I also wrote<https://mailarchive.ietf.org/arch/msg/oauth/zvIsbxHTFC4YXozOgOfQutR6GN8/>, “application-level X.509 … is an anachronism that OAuth and JOSE have moved away from”. 2. Reuse of keys intended for one purpose for a different purpose. PIKA uses WebPKI keys for signing things that are not Web resources. Key reuse is not a good security practice. This problem is acknowledged in Issue 2 of Slide 7 of Richard’s presentation<https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>. 3. Authorities with paths not secured. In OAuth, authorities such as issuers can have a path component in their URL. But the spec says “The contents of this field MUST represent a certificate chain that authenticates the domain name in the iss field” – meaning that the path component of the issuer is not secured. 4. Odd hybrid of JWKs and X.509. The spec uses both JSON Web Keys and X.509 certificates in the trust evaluation, which is an odd intermixing of technologies with overlapping purposes. Architecturally, it would be cleaner to go all in on one or the other. This is evident in Slide 5 of Richard’s presentation<https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>. 5. Upgrade path not defined. As Slide 7 of Richard’s presentation<https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01> says, “Need to make sure that systems using PIKA have a clear upgrade/interop path to alternatives to application-level certificates (e.g., OpenID Federation)”. This is a point that I know John Bradley made to Richard in person in Vancouver. This problem is not addressed in the specification. I’m also personally uncomfortable with the direction of travel embraced by this specification. For over a decade, we’ve been consciously working to move OAuth away from X.509 and towards JOSE and this specification goes in the opposite direction. As documented above, these problems were discussed and acknowledged. Therefore, it’s disappointing to me that the updated draft didn’t address these previously identified issues. Therefore, I believe this specification should not be adopted, as the problems that caused it to not be previously adopted have not been addressed. Sincerely, -- Mike From: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com<mailto:rifaat.s.ietf@gmail.com>> Sent: Tuesday, September 3, 2024 3:47 AM To: oauth <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: [OAUTH-WG] Call for adoption - PIKA All, As per the discussion in Vancouver, this is a call for adoption for the Proof of Issuer Key Authority (PIKA) draft: https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by Sep 17th. Regards, Rifaat & Hannes _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-leave@ietf.org<mailto:oauth-leave@ietf.org>
- [OAUTH-WG] Call for adoption - PIKA Rifaat Shekh-Yusef
- [OAUTH-WG] Re: Call for adoption - PIKA Neil Madden
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Falk Andreas
- [OAUTH-WG] Re: Call for adoption - PIKA Joel Kamp
- [OAUTH-WG] Re: Call for adoption - PIKA Ethan Heilman
- [OAUTH-WG] Re: Call for adoption - PIKA Rohan Mahy
- [OAUTH-WG] Re: Call for adoption - PIKA Joseph Salowey
- [OAUTH-WG] Re: Call for adoption - PIKA Pieter Kasselman
- [OAUTH-WG] Re: Call for adoption - PIKA Kristina Yasuda
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Vladimir Dzhuvinov
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA David Waite
- [OAUTH-WG] Re: Call for adoption - PIKA Watson Ladd
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes