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 11EBBC14F5F3 for ; Wed, 18 Sep 2024 07:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=ipv-sx.20230601.gappssmtp.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 83BSTkFTOUa8 for ; Wed, 18 Sep 2024 07:28:11 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA40CC14F694 for ; Wed, 18 Sep 2024 07:28:11 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-3a08489f757so3198815ab.0 for ; Wed, 18 Sep 2024 07:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1726669690; x=1727274490; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uVOabBOmXl0VFADYV+xHEsPlKNAGGzSkyNeVdBUAjvI=; b=S/ixDtiTA5HJ1laSP4vuRVT70kHaSoTae948SKnbACzw25ad1bJ35umvLuZGXbtOi/ 6CWFdAzXMQw6IEj0TGkaADFufD8Fjbh0lBmwn25em1fGhyhbTuoHbS0v5eqOIJPC5ALd CVJ3++K36CxTLmxfLITTwxnoMBmJpmJSrUVop/UoAD2CJCws36HDfLQd1EBep0GV8jZC TpbG+95p2Nd5ao4RyL2OK66lnyGJbesVJf3r/oQxUrjY/WUptMWbB/afMuMc0XQjKCGg 9q2XOSCsugRGpKnCIoJPQEoQOeNtQuPDp18lDbTWHIdtzmt3tqhSQDfWU0PlXLXeW3WW GyHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726669690; x=1727274490; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uVOabBOmXl0VFADYV+xHEsPlKNAGGzSkyNeVdBUAjvI=; b=GfexqqkXV7Vt+3a7yX4WOn2Kwf/buhwz950g2op4QeQHLg6EyA6SBMPRa1FEyiMCNq UiHL44MYdcRd3qe/u6OvG/4nzyqxid8KNq9Rq896mfcKsu8VG2CJUU6LjdIt8d8QzpF4 ktjLCLYNDT1EMk/2c2Q3IX7EBCobFqJ0tquLZPYnsDPYjNMIxMM3qETXdjGuT1bKvKCf Bp/CgCex0GHt3Yg+dhKF5yELscgZvwLOHTajysJ3TZamTTixHojd/ElQ5T5nXFEIIPXB Ip1wTABYWIQblbirpZ+BmhvQ+ubfkD4wqJgo86tF0Yzw8AzxWwgmnx2TI8FsHCPvyBuY nNRw== X-Forwarded-Encrypted: i=1; AJvYcCUxJxT9ahKU5JpVabHzky0xb7ilgWfA1b5i2ahdQS1nz+m0Ws2UQNg4zb1L5M9R4tPKRhLy2A==@ietf.org X-Gm-Message-State: AOJu0Yxo37ckUCm/Nnxsz0JMXGfkCuX9/w+huUIEmmbNz7qS5bST3+b8 8EBQcFsUYegf4FFycCRJH2h1mrRr06MU9/27ZUaX24HrkMvNDDN/8615gMZhpzQD14MmG9KIfcw oWlSKkiJrcGTu2SfLMICObUck20Z+uJwrk7sTIg== X-Google-Smtp-Source: AGHT+IFwlCQFVfezT5CgaMdbAWUEyzOuaetR5kMiUg19Yi7Yp4A2QERJDcIAttG7U5hm87q8Q6Ro75xDBesaFfEgjPE= X-Received: by 2002:a05:6e02:b2b:b0:3a0:9903:42c3 with SMTP id e9e14a558f8ab-3a09903431bmr103758105ab.10.1726669690454; Wed, 18 Sep 2024 07:28:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 18 Sep 2024 10:27:59 -0400 Message-ID: To: Michael Jones Content-Type: multipart/alternative; boundary="0000000000008b6d210622659d09" Message-ID-Hash: UVXHQHQ7EVXQ4PZ2RFTD6IYSNCTH4C5F X-Message-ID-Hash: UVXHQHQ7EVXQ4PZ2RFTD6IYSNCTH4C5F X-MailFrom: rlb@ipv.sx 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 X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_Call_for_adoption_-_PIKA?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000008b6d210622659d09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 when authenticating the issuer URL < 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=E2=80=AFPM Michael Jones 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 fo= r > 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 =E2=80=93 certainly = the 5 > main points but possibly also the 6th bonus point =E2=80=9Cdirection of t= ravel=E2=80=9D. > > > > Again, none of this feedback is new. It=E2=80=99s a synopsis of issues t= hat you > were already aware of from the first call for adoption. > > > > Thank you= , > > -- Mike > > > > *From:* Richard Barnes > *Sent:* Monday, September 16, 2024 2:10 PM > *To:* Michael Jones > *Cc:* Rifaat Shekh-Yusef ; oauth > *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 wheth= er > 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=E2=80=AFPM Michael Jones > 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 > . I did > have a productive conversation with Richard in Vancouver, which resulting > in him mentioning some of the problems in his presentation > . > Here are the problems that have not been addressed since the first call f= or > adoption: > > > > 1. *Application-level use of PKI trust chains.* As I wrote in my > response to the first call for adoption > , > =E2=80=9COther than for TLS certificates, the OAuth and JOSE specs gen= erally steer > clear of dependence upon X.509 certificates. Especially for a spec fo= cused > on JWK Sets, it=E2=80=99s odd to require an X.509 certificate to secur= e them.=E2=80=9D > This problem is acknowledged in Issue 1 of Slide 7 of Richard=E2=80=99= s > presentation > . > As I also wrote > , > =E2=80=9Capplication-level X.509 =E2=80=A6 is an anachronism that OAut= h and JOSE have moved > away from=E2=80=9D. > 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 i= n > Issue 2 of Slide 7 of Richard=E2=80=99s presentation > > . > 3. *Authorities with paths not secured.* In OAuth, authorities such > as issuers can have a path component in their URL. But the spec says = =E2=80=9CThe > contents of this field *MUST* represent a certificate chain that > authenticates the domain name in the iss field=E2=80=9D =E2=80=93 mean= ing 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 interm= ixing > 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=E2=80=99s > presentation > > . > 5. *Upgrade path not defined.* As Slide 7 of Richard=E2=80=99s presen= tation > > says, =E2=80=9CNeed to make sure that systems using PIKA have a clear > upgrade/interop path to alternatives to application-level certificates > (e.g., OpenID Federation)=E2=80=9D. This is a point that I know John = Bradley made > to Richard in person in Vancouver. This problem is not addressed in t= he > specification. > > > > I=E2=80=99m also personally uncomfortable with the *direction of travel* = embraced > by this specification. For over a decade, we=E2=80=99ve been consciously= working > to move OAuth away from X.509 and towards JOSE and this specification goe= s > in the opposite direction. > > > > As documented above, these problems were discussed and acknowledged. > Therefore, it=E2=80=99s disappointing to me that the updated draft didn= =E2=80=99t 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 > *Sent:* Tuesday, September 3, 2024 3:47 AM > *To:* oauth > *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 > To unsubscribe send an email to oauth-leave@ietf.org > --0000000000008b6d210622659d09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike,

We addressed these = points in the presentation in YVR, where we had a successful IRL adoption c= all 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 a= re being re-raised now.=C2=A0 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 o= pined 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.=C2=A0 For examp= le, we can require that the PIKA signing certificate use a prefix, say cont= aining a SAN for _pika.example.com = when authenticating the issuer URL <http= s://example.com>.

3. Authorities with paths= not secured -- Paths are not secured today, with HTTPS-based discovery.=C2= =A0 Anyone who controls the domain on which an issuer is hosted can imperso= nate that issuer.=C2=A0 PIKA is not making any change in that regard.
=

4. Odd hybrid -- I'm not sure how to respond to &qu= ot;odd" as an engineering concern.=C2=A0 JOSE and X.509 have been inte= rmixed since the "x5c" parameter was introduced.=C2=A0 The layeri= ng here is actually quite clean: JWK and X.509 talk about different keys, w= ith the X.509 keys "blessing" the JWKs.

= 5. Upgrade path -- There is a trade-off here between concreteness and futur= e-proofing.=C2=A0 Our proposal is to continue to have PIKA articulate a con= crete, PKI-based mechanism, but also provide some notes on how one would up= date it to use different authority mechanisms.

As to the direction of travel: The direction this document is trying to mo= ve is orthogonal to the axis you're talking about.=C2=A0 The OAuth ecos= ystem already relies on X.509 in the ways we are relying on it here.=C2=A0 = We are just expressing that reliance in JWS instead of HTTPS.=C2=A0 If, in = the future, the OAuth ecosystem relies more on JWS in the places it current= ly uses X.509, we can make a PIKAv2 that takes that up.=C2=A0 But that is n= ot the world we live in today.

Best,
--Richard

On Mon, Sep 16, 2024 at 6:23=E2=80=AFPM Michael Jo= nes <michael_b_jones@hotm= ail.com> wrote:

Hi Richard.=C2=A0 Tha= nks for the quick response.

=C2=A0<= /span>

What surprises me is = that a lot of substantive feedback was communicated during the prior call f= or adoption and as far as I can tell, none of the problems identified were = corrected in the draft before the second call for adoption.=C2=A0 Incorporating it could have both solved th= e real problems identified and likely increased working group consensus.=

=C2=A0<= /span>

I would really apprec= iate it if you could send a reply to my note saying *how* you plan t= o address each of the points raised =E2=80=93 certainly the 5 main points b= ut possibly also the 6th bonus point =E2=80=9Cdirection of travel=E2=80=9D.

=C2=A0<= /span>

Again, none of this f= eedback is new.=C2=A0 It=E2=80=99s a synopsis of issues that you were alrea= dy aware of from the first call for adoption.

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank you,=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=

=C2=A0<= /span>

From: Richard Barnes <rlb@ipv.sx>
Sent: Monday, September 16, 2024 2:10 PM
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

=C2=A0

Hi Mike,

=C2=A0

This is a call for *adoption*, not a WGLC.=C2=A0 Our= thinking was that these were fine problems for the WG to work on.=C2=A0 Th= e adoption question is whether we believe the WG will succeed at that, i.e.= , whether we pretty much know how to solve the problems.=C2=A0 As your email points out, there have been a bunch of good = discussions about these problems, and broad agreement on solutions.=C2=A0 W= e will get a draft out in time for Dublin with a first pass at getting them= reflected in text.

=C2=A0

But resolving these problems should not be a blocker= to adoption.

=C2=A0

Thanks,

--Richard

=C2=A0

On Mon, Sep 16, 2024 at 3:55=E2=80=AFPM Michael Jones <michael_b_jones= @hotmail.com> wrote:

I regret to have to r= eport that the issues that I believe resulted in the first call for adoptio= n failing, despite being discussed on-list and at IETF 120, have not been addressed in the specification.=C2=A0 I did have a productive conversation with Rich= ard in Vancouver, which resulting in him mentioning some of the problems in his presentation.=C2=A0 Here are the problems that have not been addres= sed since the first call for adoption:

=C2=A0<= u>

  1. Application-level use of PKI trust chains= .=C2=A0 As I wrote in my response to the first call for adoption, =E2=80=9COther than for TLS= certificates, the OAuth and JOSE specs generally steer clear of dependence= upon X.509 certificates.=C2=A0 Especially for a spec focused on JWK Sets, = it=E2=80=99s odd to require an X.509 certificate to secure them.=E2=80=9D=C2=A0 This problem is acknowledged in Issue 1 of Slide 7 of= Richard=E2=80=99s presentation.=C2=A0 As I also wrote, =E2=80=9Capplication-level X.509 =E2=80=A6 is an anachron= ism that OAuth and JOSE have moved away from=E2=80=9D.=
  2. Reuse of keys intended for one purpose fo= r a different purpose.=C2=A0 PIKA= uses WebPKI keys for signing things that are not Web resources.=C2=A0 Key = reuse is not a good security practice.=C2=A0 This problem is acknowledged in Issue 2 of Slide 7 of Richard=E2=80=99s presentation.
  3. Authorities with paths not secured.=C2=A0 In OAuth, authorities such as is= suers can have a path component in their URL.=C2=A0 But the spec says =E2= =80=9CThe contents of this field=C2=A0MUST=C2=A0represent a certificate chain that authenticates the domain name in the=C2=A0iss=C2= =A0field=E2=80=9D =E2=80=93 meaning that the path component of the issuer i= s not secured.
  4. Odd hybrid of JWKs and X.509.<= span style=3D"font-size:11pt">=C2=A0 The spec uses both JSON Web Keys and X= .509 certificates in the trust evaluation, which is an odd intermixing of t= echnologies with overlapping purposes.=C2=A0 Architecturally, it would be cleaner to go all in on one or the other.=C2= =A0 This is evident in Slide 5 of Richard=E2=80=99s presentation.
  5. Upgrade path not defined.=C2=A0 As Slide 7 of Richard=E2=80=99s presentation says, =E2=80=9CNeed to make sure that sy= stems using PIKA have a clear upgrade/interop path to alternatives to appli= cation-level certificates (e.g., OpenID Federation)=E2=80=9D.=C2=A0 This is= a point that I know John Bradley made to Richard in person in Vancouver.=C2=A0 This problem is not addressed in the specification.

=C2=A0<= u>

I=E2=80=99m also pers= onally uncomfortable with the direction of travel embraced by this specification.=C2=A0 For over a= decade, we=E2=80=99ve been consciously working to move OAuth away from X.5= 09 and towards JOSE and this specification goes in the opposite direction.<= /span>

=C2=A0<= u>

As documented above, = these problems were discussed and acknowledged.=C2=A0 Therefore, it=E2=80= =99s disappointing to me that the updated draft didn=E2=80=99t address thes= e previously identified issues.

=C2=A0<= u>

Therefore, I believe = this specification should not be adopted, as the problems that caused it to= not be previously adopted have not been addressed.

=C2=A0<= u>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sincerely,=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=

=C2=A0<= u>

From: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Sent: Tuesday, September 3, 2024 3:47 AM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] Call for adoption - PIKA

=C2=A0

All,

As per the discussion in Vancouver, this is a call=C2=A0for=C2=A0adoption= =C2=A0for the=C2=A0Proof of Issuer Key Authority (PIKA)=C2=A0draft:<= br> https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/<= br>
Please, reply on the mailing list and let us know if you are in favor or ag= ainst=C2=A0adopting=C2=A0this draft as WG document, by=C2=A0Sep 17th= .

Regards,=C2=A0
=C2=A0Rifaat & Hannes

_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org

--0000000000008b6d210622659d09--