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

Steinar Noem <steinar@udelt.no> Wed, 03 June 2020 12:37 UTC

Return-Path: <steinar@udelt.no>
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 F10733A10A3 for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 05:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=udelt-no.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 tBTJ65mCirT8 for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 05:37:07 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 1A5463A10A4 for <txauth@ietf.org>; Wed, 3 Jun 2020 05:37:07 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id k4so101935oik.2 for <txauth@ietf.org>; Wed, 03 Jun 2020 05:37:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CRcaZywlU+3bu8+GledIkni2ud35mTAgMItxF9zHbFQ=; b=fSya4IjesHS36XDFhXLd0ByeSqDwDPm2WESy5QjM8mV4KxxoM3D4DCCOs8Xg/zLFj1 sesKXf+/gZB4veumuv68DgRgto9OsX1+Np6nlDiClu7bcqsqanhfHCdRopkbXjStjlzc tOA+4iadXi53h2yF0uy8Z9JE1SYmCa1BtR7E6kUnWhpOztr1ak7Vac3IWd8Qg7KgqMz1 ICIXAEdW9Cb+rtiymPZQfjWCbxvn4PRGD+wKJchBh9uMaNlMbsWnU79cACFfMWwPWF/P Bq08+oy/DLxn4JpoyF7Spbtne+boC9uU+zRsHQjKeLVcUxC/Iasfaw8/mAk55TB2Fk9i ecgg==
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=CRcaZywlU+3bu8+GledIkni2ud35mTAgMItxF9zHbFQ=; b=WU6RCgi2XaAFK6x7jMnTg9Z5qFHwFXqgsiSL+ELnr97AVBWnTBDuZp7BXIn2FH+vyz cUE+gSNpZeRfdHOWBlirKGseCa51NpzT8jT3DPEtypuDrE3D1/VZcpth0GeXYQpFm5P+ sa+X3uM7CVBd9AKOhY7lWmS7CqZ3vXQXhhQdEUb9ZxXOqH6dojNkMMZ4NpqSx5+JOrO+ FmZB2tRKrgxfq2wJqJy+wB2bwOU+BkrkNr3hTdoKnFWOBmN6LPwhsVCtdcRKmu4pJj8N fDzXmGRaWRlpmHUghZuyVa74pHDZ+f90Oulo0Br9Att3DjVMAg998lzkkR+Zy6ixBcf/ sZrw==
X-Gm-Message-State: AOAM531+KfT87YuNAR9i2Qlt7aMEcwpToDRi9VYFmgBzxLAaxtj7/7Cm 808BcjJXXFSwqLzY+xgf+a19iXU7zsStk0Uu18eolA==
X-Google-Smtp-Source: ABdhPJzJfj74LVuqz5urdgkOSYW4ecjP75stuYFm9fmzizE+SVkn8c96wD3URqxQpNA4i/COG5h40qUk/cj6/V9MSLA=
X-Received: by 2002:aca:fccf:: with SMTP id a198mr6078602oii.91.1591187826162; Wed, 03 Jun 2020 05:37: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: Steinar Noem <steinar@udelt.no>
Date: Wed, 3 Jun 2020 14:36:55 +0200
Message-ID: <CAHsNOKfdim6ykGR7NJi_ck8uAREs0+EkyVMS42g0mLzLaxWfoA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000026505f05a72d492f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/yBCCadCtwaVkQ1McpHykUddYzsI>
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:37:10 -0000

Regarding the word "transmission":
I'm norwegian - so I often find it difficult to detect nuances in the
english language :)
I also know that the time for new suggestions has passed. But I wonder,
would "Transferral" be a better word in this case?

S

ons. 3. jun. 2020 kl. 14:28 skrev Justin Richer <jricher@mit.edu>du>:

> 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
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |