[OAUTH-WG] Re: OAuth Client ID Metadata Document

Dick Hardt <dick.hardt@gmail.com> Mon, 08 July 2024 19:17 UTC

Return-Path: <dick.hardt@gmail.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 386D1C1F73DE for <oauth@ietfa.amsl.com>; Mon, 8 Jul 2024 12:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tcjBnfWyCzyE for <oauth@ietfa.amsl.com>; Mon, 8 Jul 2024 12:17:35 -0700 (PDT)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 B9471C1F73C2 for <oauth@ietf.org>; Mon, 8 Jul 2024 12:17:35 -0700 (PDT)
Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e02748b2402so4681259276.0 for <oauth@ietf.org>; Mon, 08 Jul 2024 12:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720466255; x=1721071055; darn=ietf.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/gzw+EHWt2GhSnOGOgUevdZdgE9xpKHGpWgsqcPzXGw=; b=UuJDxrQ3TZ6PVb/tWufLm367PVNWxwqXd0lKEVuOyL+60VFoV6DMmuAGKTqQ65TRPa sPJjvWgATuV4dDhBjg5q7ueBDLYhWaiPoM/6XACfY9FgcdbBIptQxGvzIK4OZwCVzVsc 03zYqtCJmN47/KEz/yTid3gC43nM8ljt3SKqt2m/e3BcAmMAmHefy/xbf4RksheuC9Tp 5c1Age05oXNYGj1ubE7KcKzng/2ui3N3Ouwn6s8MZMr94/Mc0iSnPEG7rqAUS3TfFvuB IrISaGIaccrpxZSMFm5CV8XNqrKDr71Mq+X8eNoHgJR37AaqkDDPMBZRmzIbx4gBCJlA 3GNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720466255; x=1721071055; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/gzw+EHWt2GhSnOGOgUevdZdgE9xpKHGpWgsqcPzXGw=; b=PHE6Qkb9uwLgZfDqAuR9nkgrxLUkPmW3mK6CKqMiV5bzWDtdurEUJBHJ8uOkXs27mV lOlh+sSf06fp3qzFY25AkwcfDumq5Qt3cqaaKn4qDN1Kwq+PTuNeah3zjsFPtugRA3LD 64PFhf25TP0k268L6qWoZDcvPcjrRlgZl3ZKwrHHHFof+o0dUNv/VX4u7TILWMC0SWHM WVNF29fAJB6lZJN58sYQEHARBAyH9Xt7FcENjkIyhU3EzWoaLUI1wxkhajHsY+f1Sk9Y jEV/hLqEUeJxHGDZADYQDO/LMUX3f2lhZgIGMY4sRM1sjYRzfjddzhQqILWRixsGSosy 06ng==
X-Forwarded-Encrypted: i=1; AJvYcCUaNDJ2w8cGuSEUnwO63kJLqJnPn01/eUaEifmxwHaiNKm3qmf9pfKdAx/Z4ReRfQdpd/aubhlf7E7ffIAKhQ==
X-Gm-Message-State: AOJu0YxDH/RaZuoLcCM0orRrrPKTyqJNV7yNTLItW00wn7EvTXQAR1VY yvyw15Dr9G1Iu5lua8pPj9iQij69KNUzVBVG66D1SZgEwyiafjsE1J8XHdCrI5UssvSSCAd9LP5 /O+okWJGBqnOp6m1Z4U6Mcw2mEbo=
X-Google-Smtp-Source: AGHT+IGIzmAxV2DumR9RT/knmhRDIxViUV6uvCJNdjtXgiRF6HTsx2BgknU8rZZGEpwf1Hi2UuKldjUh7uJxdDxvYFQ=
X-Received: by 2002:a5b:70b:0:b0:e03:62b7:e683 with SMTP id 3f1490d57ef6-e041b05ca8cmr767024276.25.1720466254728; Mon, 08 Jul 2024 12:17:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAGBSGjrU03__4Wt+PiDuR5Z=b5y7GnBwzOiibE1v_Y11NV+Fpg@mail.gmail.com> <BB9F5666-3FD7-4B38-A9E5-C7777FEE14E0@brandedcode.com> <CAD9ie-tp+EsPR2eQMXCrxFnrZr-BfRzS1bg_pm68uEhjmytggg@mail.gmail.com> <A7950258-8328-4B2E-B857-46383224BD21@brandedcode.com>
In-Reply-To: <A7950258-8328-4B2E-B857-46383224BD21@brandedcode.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 08 Jul 2024 12:16:57 -0700
Message-ID: <CAD9ie-sDwJ3UZq9XtqwkKv7etjKP=9SeJYzhJN6WyEMpiBNAhA@mail.gmail.com>
To: "Emelia S." <emelia@brandedcode.com>
Content-Type: multipart/alternative; boundary="000000000000f6145b061cc14390"
Message-ID-Hash: 4WQFOJN2FES3ZV2BHEAAMABX222QSA3B
X-Message-ID-Hash: 4WQFOJN2FES3ZV2BHEAAMABX222QSA3B
X-MailFrom: dick.hardt@gmail.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@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: Dick.Hardt@gmail.com
Subject: [OAUTH-WG] Re: OAuth Client ID Metadata Document
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3gwtrBK-irsQZIUR09l_ggrf-ck>
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>

On Mon, Jul 8, 2024 at 11:33 AM Emelia S. <emelia@brandedcode.com> wrote:

> I would suggest that if an AS were to implement to competing
> specifications for what a client_id means, then it'd be up to the
> implementor to decide what is used when. E.g., it'd be difficult to support
> both OpenID Federation and this I-D simultaneously without some degree of
> work on the implementors' behalf to try to decide which specification
> should be used (both have client_id's as URIs, but operate very differently)
>

Why would there be any difference between the two? OpenID Connect does not
dictate where the client metadata comes from.

The only real mechanism for "claim" here would be through some sort of DNS
> proof, but that requires either some sort of binding between the client
> identifier metadata document and the DNS record, or some pre-existing
> relationship with the AS where the AS provides the value for the proof. I'd
> be inclined to consider this out of scope, and just allow AS's to provide
> access to resources as they see fit (no different to dynamic client
> registration)
>

Per my comments in GitHub, do we want to be able to treat developers of
software that want localhost differently than people that deploy the
software that are able to deploy without registration?

If so, then standardizing how to claim your app may be useful.

There may not be a requirement to actually claim the app though. The
developer might be able to just enter a URI for the client and then have
access to additional features for development. I've not thought through all
the security implications of course!

Sorry we won't see you in Vancouver!

/Dick