Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (5234)

John Bradley <ve7jtb@ve7jtb.com> Mon, 15 January 2018 12:59 UTC

Return-Path: <ve7jtb@ve7jtb.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 B68A1127978 for <oauth@ietfa.amsl.com>; Mon, 15 Jan 2018 04:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGlFVR3ZwyCe for <oauth@ietfa.amsl.com>; Mon, 15 Jan 2018 04:59:00 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F5B127867 for <oauth@ietf.org>; Mon, 15 Jan 2018 04:59:00 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id d54so1935076qtd.4 for <oauth@ietf.org>; Mon, 15 Jan 2018 04:59:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bMoUB8exv5bLaZPL6LBQDcKymWj0cf+FEUt+K9pzH+U=; b=F1VGORlMIO7W4tUwzcpEMwE4BDsM6LIo660Uw1dVVejlgoSvA+bUXbfgemye46IIl8 XHERDYkjJvW8n5iw7p2G6KhPYHKSWMWelYyUxKwhxuraeb+hidVrnujHc+aCIJGU7dYz O8xnzJ3X3fVJrGmDx6305TaZqJox5csyxNiI2lAEJ0WmjIde70YLu2Lk2LnIRfNlmt5I fSdigupwpJCUenKhNrXfQHcVOpFIXBur+yrCkvdNn27dO0JocxbYf0nzh81QEIUkvUow mawOcuT0wGS3LuxM1y939R+6qK/z3t6VDGmypJl2JSuXMn05P09q+NvyxFd0qCFdnYlX IWsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bMoUB8exv5bLaZPL6LBQDcKymWj0cf+FEUt+K9pzH+U=; b=hbpLPgFy17FzE6dgCtAlSA1+8Zr5bebSaAOANO2dBUdBacEU/KqJFZp0o7wXC38LLw v93g5JvyLk+Z+LSdY2jA5hijELTbUBcpwfE3xslUgeOoZgEmADWoPe7tJJEW2Or9jnky qjB3QoWNPw0lI5/Bgbap+iMHEppR+L33mnW/3K/TgwnKyx1hlMCLbqJLKWQ2ZlcKbutD tqPumFoa9+hccjp5IXE4hMLtGVeUmD1SlrZ1LWGwdcOLS//wjTL60QjCo8TrEAOgbnUP vA9lGbRb/ysfd9MHUllGlXKfDKEKgHjwcMKCqWYTMtX5VLU5Cjhj/UD1alpB/05Ylb5L H86g==
X-Gm-Message-State: AKwxytfBnfe7jXeraCXyt6BgWM4aVYDG2REJAEQfcLUnhBgPoO42P4ZQ GnylbL1XSZz/8YEkmScApyplcg==
X-Google-Smtp-Source: ACJfBouXiCwxuCduC561188XRr1GrhPFcHzN8Bjwx9cOgsP8CsM2Xga89g5K7pL5++80/FGtsa73/g==
X-Received: by 10.200.58.36 with SMTP id w33mr5788921qte.76.1516021139059; Mon, 15 Jan 2018 04:58:59 -0800 (PST)
Received: from [192.168.8.100] ([181.201.16.241]) by smtp.gmail.com with ESMTPSA id i31sm17560573qtb.34.2018.01.15.04.58.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jan 2018 04:58:58 -0800 (PST)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <099BFE69-EBB4-4F38-9352-312D1FD55578@ve7jtb.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8EA2F8B0-0A34-499A-B713-65FBF31D5B3B"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 15 Jan 2018 09:58:54 -0300
In-Reply-To: <20180112115640.EC930B80C15@rfc-editor.org>
Cc: Dick Hardt <dick.hardt@gmail.com>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, randip.malakar@gmail.com, oauth@ietf.org
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20180112115640.EC930B80C15@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PJeDZ1-qpYRXLFDiZK08RsXADuE>
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (5234)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 15 Jan 2018 12:59:03 -0000

The term resource owner in the spec is a bit strange but well defined in the front matter of the spec.

resource owner
      An entity capable of granting access to a protected resource.
      When the resource owner is a person, it is referred to as an
      end-user.

The individual using the client, and granting access to the resource is by definition the resource owner.
It is true that there may be other resource owners of the same resource and perhaps some business process that is also responsible for granting the scope to the end-user’s client.

The point of trisection is the ability of the client to maintain the confidentiality of its credential.   
I don’t think this proposed change is an improvement as proposed.

Perhaps I am missing the authors intent.

Regards
John B. 

> On Jan 12, 2018, at 8:56 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:
> http://www.rfc-editor.org/errata/eid5234
> 
> --------------------------------------
> Type: Technical
> Reported by: Randip Kumar Malakar <randip.malakar@gmail.com>
> 
> Section: 2.1.
> 
> Original Text
> -------------
>   public
>      Clients incapable of maintaining the confidentiality of their
>      credentials (e.g., clients executing on the device used by the
>      resource owner, such as an installed native application or a web
>      browser-based application), and incapable of secure client
>      authentication via any other means.
> 
> Corrected Text
> --------------
>   public
>      Clients incapable of maintaining the confidentiality of their
>      credentials (e.g., clients executing on the device used by the
>      third-party (not resource owner but another end user), such as an
>      installed native application or a web
>      browser-based application), and incapable of secure client
>      authentication via any other means.
> 
> Notes
> -----
> I think in case of public client type, it should state as "e.g. the clients executing on the device used by third-party and not the actual resource owner" as mentioned in the original RFC. I let the author or experts to review my remark. Thanks.
> 
> 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