[OAUTH-WG] Re: Orie Steele's Discuss on draft-ietf-oauth-resource-metadata-10: (with DISCUSS and COMMENT)
Orie Steele <orie@transmute.industries> Wed, 02 October 2024 21:49 UTC
Return-Path: <orie@transmute.industries>
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 066EAC169431 for <oauth@ietfa.amsl.com>; Wed, 2 Oct 2024 14:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level:
X-Spam-Status: No, score=-2.085 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
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 GEwfjZISWAAk for <oauth@ietfa.amsl.com>; Wed, 2 Oct 2024 14:49:54 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 665AFC180B4A for <oauth@ietf.org>; Wed, 2 Oct 2024 14:49:54 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id e9e14a558f8ab-3a3636ddad6so989755ab.2 for <oauth@ietf.org>; Wed, 02 Oct 2024 14:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1727905793; x=1728510593; 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=EGhNX/90OEBLJTT70rbyX+SabfGzT6g34FHRYEn7Krk=; b=IJ+HFVgbJdbr+yhzjdH/2hENarS7Myc6MorOEVH60h9OIfissEhjgxuWz9gbfGO3hU xhWCwDPlN2KCiJfOFQBYh0NGH56RDp1A7rlOR1j/KFTJ9+lWZIu3Vx0F/Q+2/A/tBgbD SYkRj6WNwbHYr3QsXC3mI8mIimdBg1aOyyJB1NGlFSsJnAKaiKNnk1AnP11qwvsnBLLX UVvk02POXxl85nHK5DI/CItfzHYsOhSAISX3x+05/jQa8YVJQSUwYDRsI8LbFWIu8l/m BiBPxTGvgDor4jfcvT4ff/eHtkHCJrMbyDk9V+wihoozu1GKZhF9xaFv674bkT4lVGGQ qQ/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727905793; x=1728510593; 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=EGhNX/90OEBLJTT70rbyX+SabfGzT6g34FHRYEn7Krk=; b=E9m9hvh2roXz0oSJU0WZ0gIOwLHt2v/hSW/PtaegzClPm+su8Q4wSuq9Ut3dQ2w0jR nSIxyuDa6mwWmrzHmtXnML2dbM5BNvYPNYEO6elgYl1Rs1INyb5Vuaq2E9UZt6++b9XC EwPNZGtUdSuXSnMLSDRT85mf2sQ5CRvQNMsyzku8aDmqmHjfmVemZCbQg9QiZ9l3OIOs p/rZPqmwIWUmglvH0BqMqmlCt9/GHILtBvDsKdlAVSxz6weF3kmNvjUGbw6iHuojLqeM lzzSe+jm2VTVf6DQVHw1bi7Oe80ZsZ4hreYn58dUPF3fME8bFZ0AmIMuLEAhzYKxb3BX 7gjA==
X-Forwarded-Encrypted: i=1; AJvYcCUZFwPXTv4KX7h9fXWdY4DHfQVpeZ55sF5uuU8MmYidXvq77M6+C0LZEyPvUcec9yQP5T1pQQ==@ietf.org
X-Gm-Message-State: AOJu0YzfS6H1Pyh0GUUHwgOH6kdseEAB5woMjxSrPUUiW8HScRrNb15M lVC1bpXUwQvXqaLymQkG558sQqkvR67zgi3gmhLUTuf433Gzud1fcRXmXEWJFmKfobqZ0YgZBNY Rlz3m3QtrZABdQkxNyhhXWv3jTfgvnUlPtstRiw==
X-Google-Smtp-Source: AGHT+IEa2eVYJQsBBWQ/1AndCxguuhJQLB73hipogbp7D6kTnlrq8aFXJWpOMo7EjTEwaR9Yy27/7I+f06bZobxKeNc=
X-Received: by 2002:a05:6e02:1386:b0:3a0:92e5:af68 with SMTP id e9e14a558f8ab-3a36594a26emr42745195ab.15.1727905793197; Wed, 02 Oct 2024 14:49:53 -0700 (PDT)
MIME-Version: 1.0
References: <172780986106.795146.3754827883737941273@dt-datatracker-7bbd96684-zjf54> <PH0PR02MB7430C2C8DC6289BA1DAA520AB7772@PH0PR02MB7430.namprd02.prod.outlook.com> <PH0PR02MB7430B4D44B362D6EC95BE6B5B7702@PH0PR02MB7430.namprd02.prod.outlook.com> <CAN8C-_+Sb0upN1Qq0mKWeAeLj0tiJuqMcnVA10h83RyLquxZYA@mail.gmail.com> <A4755690-5B8E-4D25-AE34-3DE1AB4C3538@alkaline-solutions.com>
In-Reply-To: <A4755690-5B8E-4D25-AE34-3DE1AB4C3538@alkaline-solutions.com>
From: Orie Steele <orie@transmute.industries>
Date: Wed, 02 Oct 2024 16:49:41 -0500
Message-ID: <CAN8C-_+VZNzZqsGDRXZ7_37wfu_JDQ4-Q63NpnWLV9Zi0jdYtw@mail.gmail.com>
To: David Waite <david@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="0000000000000260880623856ba7"
Message-ID-Hash: JVXZBGPF2J6JAVPZRBJY2BBPNSXF3J2O
X-Message-ID-Hash: JVXZBGPF2J6JAVPZRBJY2BBPNSXF3J2O
X-MailFrom: orie@transmute.industries
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: The IESG <iesg@ietf.org>, "draft-ietf-oauth-resource-metadata@ietf.org" <draft-ietf-oauth-resource-metadata@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [OAUTH-WG] Re: Orie Steele's Discuss on draft-ietf-oauth-resource-metadata-10: (with DISCUSS and COMMENT)
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1VFHst9xvvP6AxW3lmwemx0mLCU>
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 David, I am clearing my discuss based on https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/59 For the sake of clarity, let's look at an example: http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick This would become: http://www.example.com/.well-known/oauth-protected-metadata/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick And would resolve to: HTTP/1.1 200 OK Content-Type: application/json { "resource": "http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick", "authorization_servers": ["https://as1.example.com", "https://as2.example.net"], "bearer_methods_supported": ["header", "body"], "scopes_supported": ["profile", "email", "phone"], "resource_documentation": "https://resource.example.com/resource_documentation.html" } See also: - https://datatracker.ietf.org/doc/html/rfc7320#section-2.4 - https://datatracker.ietf.org/doc/html/rfc8820#name-uri-queries You might constrain the query for .well-known/oauth-protected-metadata (for example, you could forbid common oauth query params) ... but you cannot constrain the query for the original protected resource URLs, without limiting the applicability of your proposed standard... it's possible I am incorrectly interpreting RFC7320 and RFC8820, but the spirit of what I am trying to say is: Do not tell applications that their resource identifiers that use query parameters are not resource identifiers. It's fine to warn them of the consequences of their design decisions on deploying oauth-protected-metadata, which you are already doing with the "SHOULD NOT" in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-11#section-1.2-3.2 . Regards, OS On Wed, Oct 2, 2024 at 1:27 PM David Waite <david@alkaline-solutions.com> wrote: > > > On Oct 2, 2024, at 11:38 AM, Orie Steele <orie@transmute.industries> > wrote: > > Hi Mike, > > Your PR looks good to me. > > My objection is limited to defining http based resource identifiers as > "URIs" that do not contain query, because this contradicts the common > interpretation of http resource identifiers which includes: > > The query component contains non-hierarchical data that, along with > data in the path component (Section 3.3), > *serves to identify a resource* within the scope of the URI's scheme > and naming authority > (if any). > > https://datatracker.ietf.org/doc/html/rfc3986#section-3.4 > > I don't believe you need to describe in any detail how query parameters > interact with well known URIs. > > > The challenge of course is that there is no canonical representation of a > query component, nor is the query component itself required to be in a > particular format like query parameters. The various HTTP implementations > _may_ restrict themselves to only support query parameters, and may further > do so in a way that does not preserve the original escaping or ordering. > > The resource identifier is meant to be understood by the client, which > often is not first party to the AS. This means that unlike Resource > Parameters in RFC 8707, allowing query parameters but not answering the > question on how such would be handled will have a stronger negative impact > on interoperability. > > Conveying queries in a metadata request also adds the risk that it will > share OAuth request information more broadly, e.g. if the well-known logic > and the protected resource logic are separated responsibilities. > > I would propose that a resource identifier is the URI with query and > fragment components _removed_, e.g. that all accepted query components > amount to a collection with the same metadata. This clarifies that the spec > does not attempt to restrict to only resource servers which do not use > query components. > > Otherwise, the protected resource metadata request needs to be modified to > include a query component, every possible query will be sent to this > endpoint, and we probably should note the potential of sharing request > information. > > -DW > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
- [OAUTH-WG] Orie Steele's Discuss on draft-ietf-oa… Orie Steele via Datatracker
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… Michael Jones
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… Michael Jones
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… Orie Steele
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… David Waite
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… Orie Steele
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… David Waite