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

Dick Hardt <dick.hardt@gmail.com> Wed, 03 June 2020 16:25 UTC

Return-Path: <dick.hardt@gmail.com>
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 22AB63A0884 for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 09:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1GbBR8DKrF6F for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 09:25:12 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 D67E53A07DC for <txauth@ietf.org>; Wed, 3 Jun 2020 09:25:11 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id n23so3507518ljh.7 for <txauth@ietf.org>; Wed, 03 Jun 2020 09:25:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VP9jWjxsX8XLAoGtbAiLCjIAyzOSOBdq2WPApwH7Rv4=; b=UUJx1N7BRirwXMqa0woyC2cW9BwChNAoUh/0ki5z7cXn0J5S3nWUNiYNsBUxmcg5Ug 3wHab4MRMwrs3g+it0WdnoLiafeAIuZv90cNW5uJ9Fnt3BfNV5WSKMi0uMbNzs2tkjPX ZKRL16kHp6P3TChdyZaVl5yNH2tvai3EG1e1paQRm+2Ez2QRCQqjqUEhV07wGj7iirpG 62dOIXoeo6ecF9WEXeuzfMyEjuCxzHhT3bK1nmak2VmrIaOp6cp1PViqmlX48ukmEzq9 iVlVyYG/Ndh3bVOxpxk3b8PzuulAveIR7ynoFThJ0pTmIA+lU6UsBf+IFgWmjqLM0+Kk pA/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VP9jWjxsX8XLAoGtbAiLCjIAyzOSOBdq2WPApwH7Rv4=; b=uQWBtzMYIhbFf92rMtmuCw1MUwU7HUXR9kLR/GJYaPGwp2MtvLHP3GytMO5AqMP8wv MYxOCiCHL3YBigOy+6lcAE9WRKjasQ5T22TCCyutFSlib9E6+TGUo1Doc2aG5CZCVLPe ENzWbkiA49f/Cf6gdMoCOdsUz/Jx0RUQ4ugdNqbDHd8o7ZNHPO3+Q/B7kPD5sRlz8Szg 3YPuEtr3feCzWr8fNGcf+fqL6aTaFqB+EjHJEo6s2bx87NfquBb5tOyX7TBr32Pk8XBQ 8F5rAbZCM87a+P/+Ahfvn9WXdmICSfTIEQ8nwZWgic7opbIlXX3Mj+ajgW0HD7pd/fyg mcXQ==
X-Gm-Message-State: AOAM533yAJoPWivHTFa27qyUcUNzRN7Cun2jH2vTFiBVMpiqnmNKB9J8 LIuYD/39SvagVRk1RckPReYUq45SF8QjAtk9ZgA=
X-Google-Smtp-Source: ABdhPJzvQrBZ3z+aXMpa81NOJdkcdRYjGFCTJeNlanNeypj6xYIARLz5pNHmGafPqavs+4qxp+gpD53WuiumhM2lFFw=
X-Received: by 2002:a2e:3a19:: with SMTP id h25mr9558lja.213.1591201506069; Wed, 03 Jun 2020 09:25:06 -0700 (PDT)
MIME-Version: 1.0
References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <CAD9ie-tyrfwmOeC1LTuqEQsLor1iJqCtD9Qb_LyeLOjbvTHGpw@mail.gmail.com> <C6A36A7B-8A00-4D7B-A96A-75E4519BBFA2@mit.edu>
In-Reply-To: <C6A36A7B-8A00-4D7B-A96A-75E4519BBFA2@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 3 Jun 2020 09:24:39 -0700
Message-ID: <CAD9ie-uYMrtX6aFs5W1iupD6A66SvRRq-sLy1TFeXo+CeJ=wPQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008926c905a73078b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/G--NV7yBx3CaBPKYEGzZLD1HUvQ>
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 16:25:15 -0000

No surprise that you don't think it is misleading, as you did not think
that transaction was misleading.

While one way of interpreting "Transmission of Authority" is as you
describe, I think that for others an "authority" is who can make
assertions, which is what the AS does, and is what a Certificate Authority
does. The client uses those assertions, just as a server uses a TLS
certificate.

Using the movie ticket analogy, where the movie ticket is a bearer token,
the ticket holder does not think they have any "authority" to access the
movie, they think they have been granted access to the movie.






ᐧ

On Wed, Jun 3, 2020 at 5:27 AM Justin Richer <jricher@mit.edu> wrote:

> 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>
> 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> 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> 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/
>>         [2]
>> https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/
>>         [3]
>> https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/
>>
>>
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>