Re: [Txauth] Call for WG name preferences - process clarification

Justin Richer <jricher@mit.edu> Wed, 03 June 2020 12:27 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FA63A108F for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 05:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 BPsSE8v3UueD for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 05:27:56 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73803A108D for <txauth@ietf.org>; Wed, 3 Jun 2020 05:27:55 -0700 (PDT)
Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 053CRpbY019624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 08:27:52 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <C6A36A7B-8A00-4D7B-A96A-75E4519BBFA2@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F2F0EDAA-CC38-47E0-A87B-CFFBC25D6127"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 3 Jun 2020 08:27:51 -0400
In-Reply-To: <CAD9ie-tyrfwmOeC1LTuqEQsLor1iJqCtD9Qb_LyeLOjbvTHGpw@mail.gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
To: Dick Hardt <dick.hardt@gmail.com>
References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <CAD9ie-tyrfwmOeC1LTuqEQsLor1iJqCtD9Qb_LyeLOjbvTHGpw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/MMmaJ-xVtxLNlrgqDiGQoByEmLc>
Subject: Re: [Txauth] Call for WG name preferences - process clarification
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 12:27:59 -0000

I wanted to provide feedback on this point specifically:

> 
> * TxAuth      Transmission of Authority
> 
> - I think this name is misleading. As it is Justin's favorite, I'll elaborate more than I have on the others ... starting with definitions of the words:
> 
> Transmission: 
> the action or process of transmitting something or the state of being transmitted. "the transmission of the virus"
> 
> Transmit: 
> cause (something) to pass on from one place or person to another.
> 
> Authority:
> a power or right delegated or given; authorization: "Who has the authority to grant permission?"
> 
> Authorization:
> the act of authorizing. permission or power granted by an authority; sanction.
> 
> Building on these definitions, "Transmission of Authority" means passing a power to another person. The power is the ability to authorize. 
> 
> Someone familiar with a certificate authority (CA), a related area, "transmission of authority" could mean the CA passing authority to another entity, which would then be another CA. 
> 
> Using OAuth terms, the AS has the authority to issue tokens to the client. The AS is not passing the authority to issue tokens to the client. 

I think you’ve got an odd twist of the words in your interpretation here. The authority is embodied in the access token, the result of the delegation process. This authority is transmitted from the RO through the AS to the client, via the token. I don’t think it at all implies that the AS is transmitting authority to issue tokens. If that’s an issue with this name, then it should also be an issue with any suggestion with “Grant” in the name because it could imply that the AS is granting the client authority to make its own tokens, by the same leap of logic. 

It’s very important to see that the AS holds authority only in trust from the resource owner, who has the actual power to grant authority. The transmission of authority in OAuth as in our proposed work is from the resource owner to the client, embodied by the access token issued by the AS. It’s from a party with authority, normally a user but sometimes not, to a piece of software — not another user directly. This is the core of the entire “grant” concept.

It isn’t misleading at all.

 — Justin

> ᐧ
> 
> On Fri, May 22, 2020 at 3:32 AM Yaron Sheffer <yaronf.ietf@gmail.com <mailto:yaronf.ietf@gmail.com>> wrote:
> Thank you David for pointing out the loophole in my previous mail. As a result, we have decided to limit the time when new names may be proposed. If you have new name ideas, please make sure to share them until 0800 UTC, Tuesday, May 26.
> 
> All others, if you want to make sure you are commenting on the full name list, please hold off until after Monday.
> 
> Apologies for the process confusion, we are building it as we go.
> 
> Thanks,
>         Yaron
> 
> On 5/21/20, 11:53, "Yaron Sheffer" <yaronf.ietf@gmail.com <mailto:yaronf.ietf@gmail.com>> wrote:
> 
>     Thank you to those who contributed early replies!
> 
>     As a refinement/clarification to the process below: we are now focusing on discussion and making sure there are no strong objections, rather than voting on people's favorite name.
> 
>     With that in mind, we strongly encourage people to attach an explanation to each name they object to. Therefore for names that are on neither of your lists ("wouldn't object to" and "object to"), our default assumption is that you would NOT object to them.
> 
>     With the process now finalized, please take a few minutes and provide us with your name lists. As a reminder, the deadline is 0800 UTC June 4, 2020.
> 
>     Thanks,
>         Yaron
> 
> 
>     On 5/19/20, 23:34, "Yaron Sheffer" <yaronf.ietf@gmail.com <mailto:yaronf.ietf@gmail.com>> wrote:
> 
>         Hi!
> 
>         After reviewing the community feedback and discussions with the AD, we’d like to again launch a process to elicit feedback on naming.  Our proposal is below.  We’d appreciate any clarifying questions, proposed improvements or objections by 0800 UTC, Thursday, May 21st .
> 
>         Thanks,
>                 Yaron and Dick  
> 
>         PS, I’m sharing the load with Dick and taking point on this consensus call -- Yaron
> 
>         ----
> 
>         Before we submit the draft charter [1] to the IESG, we wanted to explore the name of the group. During the chartering discussions, some people objected to the BoF name being the WG name.  We’d like to get consensus on what the WG name should be.  Our first attempt to elicit input [2] wasn’t successful, and this is a second attempt to get consensus from the community.
> 
>         To get to consensus, we want to gather preferences on the currently known WG name candidates. Our goal is not to select the most popular name -- it is to select a name everyone can live with and ensure that we understand and weigh any objections there might be with that choice.  To that end, we’d like to elicit your name preferences in the following way:
> 
>          (1) In previous discussions, the following candidate names have been voiced (we have listed only these names that received at least one vote previously):
> 
>         * AAuthZ    Alternative Authorization Protocol (AAuthZ)
>         * AZARP    AuthoriZed Access to Resources Protocol
>         * AZARAP    AuthoriZation And Resource Access Protocol
>         * BeBAuthZ    Back-end Based Authorization Protocol
>         * BYOAuthZ    Build-Your-Own Authorization Protocol
>         * CPAAP    Comprehensive Privileged Authentication Authorization Protocol
>         * DAZARAP    Delegated AuthoriZation And Resource Access Protocol
>         * DIYAuthZ    Do-It-Yourself Authorization Protocol
>         * GNAP    Grant Negotiation and Authorization Protocol
>         * GranPro    GRAnt Negotiation Protocol
>         * IDPAuthZ    Intent Driven Protocol for Authorization
>         * NIRAD    Negotiation of Intent Registration and Authority Delegation
>         * PAuthZ    Protocol for Authorization
>         * RefAuthZ    Refactored Authorization Protocol
>         * ReAuthZ    Reimagined Authorization Protocol
>         * TIAAP    Tokenized Identity and Access Protocol
>         * TIDEAuth    Trust via Intent Driven Extension Auth
>         * TIDYAuth    Trust via Intent Driven Yield Auth
>         * TIEAuth    Trust via Intent Extension Auth
>         * TINOA   This Is Not OAuth
>         * TXAuth    Testable eXtensible Authorization
>         * TxAuth      Transmission of Authority
>         * TXAuth      Truly eXtensible Authorization
>         * XAuthZ    eXtensible authoriZation protocol
> 
>         We would ask that you consider these names, and respond to the list with your selection of the following two categories:
> 
>         * “Wouldn’t Object” -- this is not necessarily your preferred name, but you would be comfortable with it being the name of the WG (choose as many names as you want)
>         * “Object” -- you would be uncomfortable with the WG being named in this way (choose as many names as you want; please provide an explanation)
> 
>         (2) If your preferred name isn’t in the list per (1), you can send a note to the mailing list stating that you’d like the WG to consider a new name.  Please ensure the name adheres to the previously discussed naming criteria at [3]. We still request that you provide your other preferences and objections.
> 
>         (3) If you previously sent in your preferences, but a new name suggestion or someone’s objection changed your mind, then send another message to the mailing list with your revised preferences.  For the purposes of consensus, we’ll assume that everyone who hasn’t commented on a new name introduced per (2) “objects” to it (i.e., we want to hear positive confirmation of preference on new names).
> 
>         (4) Please provide your input by 0800 UTC June 4, 2020.
> 
>         With that input, our plan is to assess rough consensus in the following way:
> 
>         (a) See if there is consensus for a name identified given the “wouldn’t object to being the WG name” preference and the level of “would object” feedback
> 
>         (b) If there isn’t clear consensus with (a), but a significantly reduced set of candidates around which there is enthusiasm, the chairs will share the results and request feedback
> 
>         (c) If rough consensus appears to be reached through steps (a) – (b), revisit the objections to this candidate name, elicit additional objections and see if they change the consensus.
> 
>         Regards,
>                 Yaron and Dick
> 
>         [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ <https://datatracker.ietf.org/doc/charter-ietf-txauth/>
>         [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/ <https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/>
>         [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ <https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/>
> 
> 
> 
> 
> -- 
> Txauth mailing list
> Txauth@ietf.org <mailto:Txauth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth