[OAUTH-WG] Re: Product Support for RFC8414 well-known URIs
Rafael Freitas <r.pereira.freitas@gmail.com> Tue, 02 July 2024 13:27 UTC
Return-Path: <r.pereira.freitas@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 95DFFC14F61D for <oauth@ietfa.amsl.com>; Tue, 2 Jul 2024 06:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=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 3rUCRKqa7aB7 for <oauth@ietfa.amsl.com>; Tue, 2 Jul 2024 06:27:22 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 C2AB4C14F619 for <oauth@ietf.org>; Tue, 2 Jul 2024 06:27:22 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-706b53ee183so3564272b3a.1 for <oauth@ietf.org>; Tue, 02 Jul 2024 06:27:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719926842; x=1720531642; darn=ietf.org; h=content-transfer-encoding:from:content-language:subject:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=QRNCHFLt8VYM3YKhyLIbj925yczgyZoN0GmJOsu91NI=; b=bzantDewz7tIyA6+WG+gUhG6El9kFz9SeNpEMLdreSG8o1nFoWWL+j+XpSIKPWm8cr +V9gzWBLiaf8vfDb2wOMunPi027XtMDaADkP8k3Bs4q9KAf3oi8k6Dv2wbYzbd4r2B9f o3ParuciZwk4oIPgLYJO/ZiS+ylaHk9PPbkKynZtu2gWH3pzp0dIm/nAMclbeezRIY18 xM4IHhO9+cs1gbXPp1MXDLdlVtmrR4GBz6qbwZqNdPyH1m2edH/smJmKchrfqcEsMIL0 XFWU1cqQWvwb0ft9n9/s68rUnnx/7XrYOkH+kjSTU+1euidUqIi4pQMqbGgXehXjKBhO kzcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719926842; x=1720531642; h=content-transfer-encoding:from:content-language:subject:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=QRNCHFLt8VYM3YKhyLIbj925yczgyZoN0GmJOsu91NI=; b=NTColQolhbOJBKwKc3M8WOBYbOhFUYPtUeyEIPlAr+JB1ODm64OzszL+KOpak5p/T0 yT1KKdAkaEYfcraMopyUZsFVlb+EdZkBddOyqPtKj6yozb3e8WP5Kjq1gzsA2BAZfRsa 52s5BVcqMoDB51JC32RhsKpP2B1tBYOU6J1wO0fZelsHAz0LF5yaF+mqEvZCaTwz+kTO 4Oz7sb2wbgtpx5d8g6W7mT/U0AwtABeRBMXHwKeDi6+0wn73/CCchTP+2tbQenkFcUp4 Oiz5ATKDVgLYRYNBJqNE65IbeeZJ+1FzvMSdTENNyxloDCiVFEW6Am3UPVEem8eGZaru rK7g==
X-Gm-Message-State: AOJu0Yz+WLVhdijwto8hPnVor2zirWDXnO4evExNnIQrv3OUpFp+HhPO a68/D9tMCRDsFQpkua9ZoHjdbOBVUhA03ATVjcK1tAPyMB4gxHR6FCncUg==
X-Google-Smtp-Source: AGHT+IGOs2Bz0eNbI6IH9jcLc9a8NYwT3EK03EzE8W0bZoZnjomp5FmWCWO4zY2tRH2hKDaC++pMKg==
X-Received: by 2002:a05:6a20:6a21:b0:1bd:1eba:76e2 with SMTP id adf61e73a8af0-1bef6132791mr13710524637.7.1719926841777; Tue, 02 Jul 2024 06:27:21 -0700 (PDT)
Received: from ?IPV6:2804:1b3:6600:6159:c5ca:74bc:6fed:a5b4? ([2804:1b3:6600:6159:c5ca:74bc:6fed:a5b4]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7080295961fsm8712844b3a.93.2024.07.02.06.27.20 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jul 2024 06:27:21 -0700 (PDT)
Message-ID: <c85d15d1-419a-4b94-bcd7-af0aae651441@gmail.com>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: oauth@ietf.org
Content-Language: en-US
From: Rafael Freitas <r.pereira.freitas@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-MailFrom: r.pereira.freitas@gmail.com
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0
Message-ID-Hash: LSQXEF47XYXAD6KQDBLUXRXADN7FS7UE
X-Message-ID-Hash: LSQXEF47XYXAD6KQDBLUXRXADN7FS7UE
X-Mailman-Approved-At: Wed, 03 Jul 2024 10:03:24 -0700
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Product Support for RFC8414 well-known URIs
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/jjKyiyCdXk3B021RZLUyhZHapXQ>
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>
Date: Tue, 02 Jul 2024 13:28:49 -0000
X-Original-Date: Tue, 2 Jul 2024 10:26:33 -0300
But does the OpenID implementation really go against RFC 5785? I'm re-reading it and I don't think it does, I'll elaborate, citing said RFC: > 1. When this happens, it is common to designate a "well-known location" for such data, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated "well-known locations" and with pre-existing resources.(...) Here they clearly communicate a concern with avoiding collisions. > (...)To address this, this memo defines a path prefix in HTTP(S) URIs for these "well-known locations", "/.well-known/". Future specifications that need to define a resource for such site-wide metadata can register their use to avoid collisions and minimise impingement upon sites' URI space.(...) Here they talk about site-wide metadata, which is not necessarily domain-wide metadata. Nowadays it is fairly common for a site to have a path prefix instead of a sub-domain. > 3. (...) A well-known URI is a URI [RFC3986] whose path component begins with the characters "/.well-known/" (...) So, for example, for a well known URI of "oauth-authorization-server", the well-known URI would be "/.well-known/oauth-authorization-server". This does not specify that the path can not have any other components before this, it only says that any well known URLs must be prefixed with "/.well-known/". > (...)For example, if an application registers the name 'example', the corresponding well-known URI on 'http://www.example.com/' would be 'http://www.example.com/.well-known/example'. (...) I think this was a bad explanation because the word "example" appears in two places, generating some ambiguity. But note that they do not talk about a domain, but about an application. So I think it would follow that if the application registered the name (they don't talk about domains, but instead about names) 'http://www.myhoster.com/example' the corresponding well-known URI would be ''http://www.myhoster.com/example/.well-known/". > (...) Note that this specification defines neither how to determine the authority to use for a particular context, nor the scope of the metadata discovered by dereferencing the well-known URI; both should be defined by the application itself.(...) To me this part nails the point home. They never intented to specify how URIs are dereferenced. If they meant for well known URIs to always be at the root of the domain, you would have already determined the authority for a given domain, and the scope for the metadata. But they leave it to each application. So I think it is possible to respect both RFC 5785 and the OpenID Specification. And regardless, requiring well-known not to be a sub-path of a domain is rather impractical, to the point where I think it's more likely for this RFC to not be adopted than for every OAuth server to obtain it's own domain / subdomain registry.
- Re: [OAUTH-WG] Product Support for RFC8414 well-k… Filip Skokan
- [OAUTH-WG] Re: Product Support for RFC8414 well-k… Rafael Freitas
- [OAUTH-WG] Product Support for RFC8414 well-known… Daniel Fett
- Re: [OAUTH-WG] Product Support for RFC8414 well-k… Daniel Fett
- Re: [OAUTH-WG] Product Support for RFC8414 well-k… Benjamin Kaduk
- Re: [OAUTH-WG] Product Support for RFC8414 well-k… Daniel Fett
- Re: [OAUTH-WG] Product Support for RFC8414 well-k… Benjamin Kaduk
- Re: [OAUTH-WG] Product Support for RFC8414 well-k… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Product Support for RFC8414 well-k… Filip Skokan
- [OAUTH-WG] Re: Product Support for RFC8414 well-k… Giuseppe De Marco
- [OAUTH-WG] Re: Product Support for RFC8414 well-k… Michael Jones