Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7642)

Warren Parad <wparad@rhosys.ch> Sun, 17 September 2023 10:51 UTC

Return-Path: <wparad@rhosys.ch>
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 38D73C14CE42 for <oauth@ietfa.amsl.com>; Sun, 17 Sep 2023 03:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, 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=rhosys.ch
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 c1kOuMSRSYUN for <oauth@ietfa.amsl.com>; Sun, 17 Sep 2023 03:51:41 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 C9AD7C14CE36 for <oauth@ietf.org>; Sun, 17 Sep 2023 03:51:41 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-523029050d0so1031385a12.0 for <oauth@ietf.org>; Sun, 17 Sep 2023 03:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; t=1694947900; x=1695552700; 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=W9mqu6TvyJm8E/KxKcu9+PCrSsmtzRlH5HWeWfxj4C8=; b=axzw2s34fWP08ytilSgzv9vmAXzOqk+cGOJLU0qQSTM6kSyjnih9VGQ2riwP44KG90 18MeJVvcRu/ixuqcM/jajTYsWNYBCNYVrfQ4lvCPjNxyjQcFK5An+gEIj1Rr86we/Alm Oi0tAWsalyCW5k+3V+1B1DO7mM3Kn8EKcF/ku2BWt0Zax1EeWBjyIdDx+M4U0XIq8zGR ez16IOczbPZG269ozg52Sh8fpWnIpRr+GiyYV7mnS8OgTdME1O5i9iR5Q6XBnKhnKeLA la1nrRcW+1DqYBXS+RkrNQ/u2m9uyZU6UY9/C7WhphwV/SlNo+7OE2gugsvQVyjK1NeX XTJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694947900; x=1695552700; 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=W9mqu6TvyJm8E/KxKcu9+PCrSsmtzRlH5HWeWfxj4C8=; b=nosWJXVDCY2devvlZAkNZN5/CaCfQr4EFTYtsf3jpKZU2NXQqV89Qs1T2UTUIex31Y qtNZdM8aiFTrGjFWiucjdkWYSIEdmS/HMlXKgzJF/cOUszeIoKJm0W9wdXavl7hRcakB CwExXJNCM4nX1BtUKnxCLvJEqtWDa/h6Nb3QNKdEdk0MbEcS4qudF1G0hJWeqCbt23gf GE7TnkvgwMaF0fTjZdSO2oWyatFUBJuRGEXLco/+aG5fDQQU1nHB0XW6yMCGF/hLnf4n 1S6zxcuWbxlgPswSp8nhBoHoCwkBaW44nedAC9RgH6w2oZGtpWXL67H/vdogTfAPzCPz 8NVw==
X-Gm-Message-State: AOJu0Yya6TlkZnCxj6HIhZMs+28Kn0RgKLHh+lkxMoFHQr9yBxvhNQu8 mPSJzvIsaiYFYRWBdBl35LFZkKULE7zVChS1lz2V
X-Google-Smtp-Source: AGHT+IGnLQUZvbL1YyHyvFjB+WxXJkzmCAX6IV/4fYx6eSlms+Nkz4SUBzdwvjg9RoFRQokh0UDGfNgZ+UuAnG0CgfM=
X-Received: by 2002:a05:6402:268d:b0:522:580f:8304 with SMTP id w13-20020a056402268d00b00522580f8304mr5486367edd.1.1694947900024; Sun, 17 Sep 2023 03:51:40 -0700 (PDT)
MIME-Version: 1.0
References: <20230917090031.C27FC7FDC1@rfcpa.amsl.com> <CAGBSGjqwqs-zNm-FOUEZwXGp4_0E=9VCA3k+zJ5snsm1HZaneA@mail.gmail.com>
In-Reply-To: <CAGBSGjqwqs-zNm-FOUEZwXGp4_0E=9VCA3k+zJ5snsm1HZaneA@mail.gmail.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Sun, 17 Sep 2023 12:51:28 +0200
Message-ID: <CAJot-L0iORRVYOHh9=VzdydSO548_GpP68oUe7ZdtRnFJFm3JQ@mail.gmail.com>
To: Aaron Parecki <aaron=40parecki.com@dmarc.ietf.org>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, w.fast.8@gmail.com, oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007e81bf06058bcff3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nuSpach8UgVcGyXTttCulGGemzc>
Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7642)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Sep 2023 10:51:46 -0000

It does look confusing if we only look at that one sentence, but as soon as
you pull in the whole paragraph, it seems pretty clear

https://www.rfc-editor.org/rfc/rfc6749

> For example, an end-user (resource owner) can grant a printing
>    service (client) access to her protected photos stored at a photo-
>    sharing service (resource server), without sharing her username and
>    password with the printing service.  Instead, she authenticates
>    directly with a server trusted by the photo-sharing service
>    (authorization server), which issues the printing service delegation-
>    specific credentials (access token).


Arguably the only improvement here would be to outline the full case, by
adding something like:

> The printing service (client) uses the credentials (access token) to
> access the photo-sharing service (resource server), by sending the
> credentials to the server. When receiving the credentials (access token),
> the photo-sharing service (resource server) verifies the credentials using
> the trusted server (authorization server).


But I think that's wholly unnecessary, since everything has been defined in
this case. You can't mistake the resource server for the authorization
server, because the resource server has already been defined to be the
*photo-sharing
service.* That means the *(authorization server)* identification appositive
can only apply to the trusted server. The errata breaks the pattern of the
paragraph and introduces confusion because it fails to define the terms
authorization server and access token, which arguably is the whole point of
the example.

On Sun, Sep 17, 2023 at 12:35 PM Aaron Parecki <aaron=
40parecki.com@dmarc.ietf.org> wrote:

> I disagree with this errata. The original text is correctly representing
> that the "photo-sharing service" trusts the authorization server. The
> suggested text is ambiguous because it does not make clear which party is
> trusting which other party.
>
> Aaron
>
> On Sun, Sep 17, 2023 at 11:00 AM RFC Errata System <
> rfc-editor@rfc-editor.org> wrote:
>
>> The following errata report has been submitted for RFC6749,
>> "The OAuth 2.0 Authorization Framework".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7642
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Wilhelm Fast <w.fast.8@gmail.com>
>>
>> Section: 1
>>
>> Original Text
>> -------------
>>  Instead, she authenticates directly with a server trusted by the
>> photo-sharing service (authorization server), which issues the printing
>> service delegation-
>> specific credentials (access token).
>>
>> Corrected Text
>> --------------
>> Instead, she directly authenticates with a trusted server, the
>> authorization server, which issues delegation-specific credentials, known
>> as access tokens, to the printing service for controlled and secure access.
>>
>> Notes
>> -----
>> The sentence is confusing, and the reader might confuse the Authorization
>> Server with the Resource Server.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC6749 (draft-ietf-oauth-v2-31)
>> --------------------------------------
>> Title               : The OAuth 2.0 Authorization Framework
>> Publication Date    : October 2012
>> Author(s)           : D. Hardt, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Web Authorization Protocol
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>