[OAUTH-WG] Re: Call for adoption - PIKA

Richard Barnes <rlb@ipv.sx> Tue, 25 June 2024 20:56 UTC

Return-Path: <rlb@ipv.sx>
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 97EFBC1840DA for <oauth@ietfa.amsl.com>; Tue, 25 Jun 2024 13:56:32 -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 512lteHXLcSD for <oauth@ietfa.amsl.com>; Tue, 25 Jun 2024 13:56:28 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7FAC14CF17 for <oauth@ietf.org>; Tue, 25 Jun 2024 13:56:28 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id e9e14a558f8ab-376243a112cso22912335ab.3 for <oauth@ietf.org>; Tue, 25 Jun 2024 13:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1719348987; x=1719953787; 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=6SQRpiCS3/bnQrFB1nXdgurCDi9ObCmx8X/naZIAXWs=; b=hXJ9A1EjmJJ2BKhfsfnThzb3S9DwQQkuZoxxqCQSEZAps3v2A16y31GLY5NJoCuts4 n/hirqMUpIbFITmzappVee6kAaT7A7oZ+RneLA5GpIM/PZCNwzAPLSSDtlrEx8o+XVws i79Pkn6xm+GilxHj8Gfo+2W6vc7TW9Z6D+3bYU0oklLOCzf/7Vr4tRScDHsGNF75M44s Vs4mROecgtM5bab6kFY0sgIeJaPpZ27XUTgPhv1z+Fm335IDnpSSzPgielj1h3bHk28c MgaqNiIB8aMup3XcSsB8F76gIMiK6xw+GSzqYJxGBEYrt/cFv0VlAe08I1W2+k8xgEys igkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719348987; x=1719953787; 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=6SQRpiCS3/bnQrFB1nXdgurCDi9ObCmx8X/naZIAXWs=; b=LMfO02ILUuBkU3FNbsjRUpqIYSgUNg+syxA+yzOc4puCVbmxlzOkJGa7D+kA1ef/dz 4OmXAy+BE79o6FkiHcLxRGs2XNxBsWqZFWK4Aff1kiirk2o2/TLB7YClVd7P32TGTECo 5pCpSokyj4rWwQ63s/aXizCp2IpfnoOE0rr1cgHoINkn1EdjD96Qv7GOeJs9c/y+KwLn X+flcBGUuh7k3ckDlN+JNKDv10L3ttuB8ONqd/2A6cI6nn2y5quazoxQkTyq7aDJklMz HA2WqQZzJjNJC86FyZNdSAtRnOGwjSutH/+7i8rA/OVYSMvpUGw0Wh8fLcLHXJ/0WmCC 9dqQ==
X-Gm-Message-State: AOJu0YxvHVGv4wERsfGtQF4d3C2bbFEYderVyDJUfRGJhXFOSshRA6tb uFLQdcmHkbRMfTpBEF4fdQIZHni00CRWPj/aC46yqZBUNmij8IQFtiGMklhYNlIHDrS9CSx7ch6 rVdOrZ0MMpdoTNyXdmXJEAAe5g2ssWMafd8oz7g==
X-Google-Smtp-Source: AGHT+IGJKG46oqDeKRzisBiqjuYvyJrDsVmI2sAmLbgIrqYhyVVWk+Q/13x4vamRvwZCGjSUH308Zqj4j9L06L/G82c=
X-Received: by 2002:a05:6e02:b4b:b0:375:86bb:2142 with SMTP id e9e14a558f8ab-3763e0607bfmr111326185ab.24.1719348987357; Tue, 25 Jun 2024 13:56:27 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP9GmF4vp1uzLXK0YYZAHUDjK7RHbhEb4MCXkB7N3Oq4+w@mail.gmail.com>
In-Reply-To: <CADNypP9GmF4vp1uzLXK0YYZAHUDjK7RHbhEb4MCXkB7N3Oq4+w@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 25 Jun 2024 16:56:14 -0400
Message-ID: <CAL02cgQYom9P+yGMODkHNE125mZnQxRdUTNQbP4ck4y48cgGTA@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a30b01061bbd2145"
Message-ID-Hash: T32PX2C24635C5HRMRHSPI5U3VPZIORB
X-Message-ID-Hash: T32PX2C24635C5HRMRHSPI5U3VPZIORB
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 <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/_lJHrMSURjypHLjIqjZOrLKox3s>
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 all,

Replying to the top of the thread again to recap the arguments so far.
(Hoping the chairs will give us a moment more to discuss before calling
cloture.)

It seems like Sharon, Rohan, Watson, and I are all on the same page w.r.t.
the X.509-based mechanisms in the current draft.  In particular, we're all
developers of relying party software, and it seems like we're all OK with
doing X.509 (contra Mike's point about application-level X.509).

If I understand Mike and Giuseppe correctly, they want to be less
prescriptive about how the PIKA signer establishes their authority for an
"iss" value, so that an OP could use some other mechanism (e.g., OpenID
Federation).  It sounds like Mike at least is OK with the draft aside from
this point.

I would be open to adding some optionality in the authority mechanism here,
but I'm wary of losing the concrete interop that we get with the draft as
it is.  So we would need at least a strong recommendation for X.509, even
if something else can be used if the parties agree to it.  I would be more
comfortable doing something along the lines of what Rohan suggests, namely
defining a concrete, X.509-based thing here, and extending it to support
other mechanisms via follow-on specs as needed.  If there were a single
additional mechanism that people wanted, as opposed to a generic "[insert
authority mechanism here]", that would also be more palatable to me.

Additional feedback would be useful on a couple of points:

1. From RPs: Is the X.509 requirement onerous to you?  Or is there enough
library support out there that it's not a big deal?
2. From OPs: Is signing using a key bound to an X.509 certificate workable
for you?  Or do you need some other authority framework?
3. From everyone: Is the general mechanism here useful, assuming we can
align on some set of authority frameworks?

Thanks,
--Richard


On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
wrote:

> All,
>
> This is an official 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 *June 24th*.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>