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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 May 2020 13:32:12 +0300

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" <[email-masked]> 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" <[email-masked]> 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/

---

From: David Skaife <[email-masked]>
Date: Thu, 28 May 2020 21:56:55 +0100

Hi,

Now that the deadline for new names has passed, I'll submit my lists of
which names I would and wouldn't object to (each list in alphabetical
order).

*Wouldn't object to:*
GATAR    Grant Authorization To Access Resources
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
TxAuth      Transmission of Authority

*Object to:*
AAuthZ    Alternative Authorization Protocol (AAuthZ)
Reasoning - I don't like the concept of using "alternative" (alternative to
what?), and the acronym looks like a typo.

AZARP    AuthoriZed Access to Resources Protocol
Reasoning - I don't like the acronym, it's a bit clunky.

AZARAP    AuthoriZation And Resource Access Protocol
Reasoning - I don't like the acronym, it's a bit clunky.

BeBAuthZ    Back-end Based Authorization Protocol
Reasoning - I don't agree that the protocol will be completely back-end
based as we will still have the client-side redirect optionality. Also it's
hard to pronounce the acronym.

BYOAuthZ    Build-Your-Own Authorization Protocol
Reasoning - I don't think we want people to be building their own, as this
suggests we're creating a framework rather than a protocol.

CPAAP    Comprehensive Privileged Authentication Authorization Protocol
Reasoning - Bad acronym and the expanded version doesn't make sense to
me..

DAZARAP    Delegated AuthoriZation And Resource Access Protocol
Reasoning - Awful acronym.

DIYAuthZ    Do-It-Yourself Authorization Protocol
Reasoning - I don't think we want people to be doing it for themselves, as
this suggests we're creating a framework rather than a protocol.

RefAuthZ    Refactored Authorization Protocol
Reasoning - Refactored from what? I don't like the concept.

ReAuthZ    Reimagined Authorization Protocol
Reasoning - What are we reimagining? I don't like the concept. Also
"Re-Auth" would be misinterpreted.

TIAAP    Tokenized Identity and Access Protocol
Reasoning - Too much focus on on identity (which is part of the charter but
not the core part of it), and a hard pronounce acronym.

TIDEAuth    Trust via Intent Driven Extension Auth
Reasoning - The expanded name is too clunky and doesn't make sense to me.

TIDYAuth    Trust via Intent Driven Yield Auth
Reasoning - I don't understand what is meant by "intent driven yield".

TIEAuth    Trust via Intent Extension Auth
Reasoning - "Trust via Intent Extension" sounds confusing to me and I don't
really know what it means.

TINOA   This Is Not OAuth
Reasoning - I don't like the concept of referring to OAuth in the name.

TXAuth    Testable eXtensible Authorization
Reasoning - I don't know why "testability" features so prominently in the
name, as that isn't something unique to what we're looking to create.

TXAuth      Truly eXtensible Authorization
Reasoning - I don't like the expanded name, "truly eXtensible" sounds lame
to me.

WRAC    Web Resource Authorization Collaboration
Reasoning - I believe this one was discounted already due to trademark
issues, but either way I don't like it. The inclusion of the word
"collaboration" doesn't make sense to me in this context.

XAuthZ    eXtensible authoriZation protocol
Reasoning - I don't think "extensibility" is enough of a defining/unique
characteristic of what we're looking to create here to justify this name.

Many thanks,
David Skaife

On Fri, May 22, 2020 at 11:32 AM Yaron Sheffer <[email-masked]>
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.
>
>     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
>
>
>         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
>
>         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):
>
>         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).
>
>         (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
>
>         [2]
> https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/
>         [3]
> https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/
>
>
>
>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 28 May 2020 17:47:34 -0400

Thanks to everyone in the community for suggesting names, and thanks to the chairs for putting this list together.

Here’s my personal take on the candidates.

Wouldn’t Object:

* TxAuth      Transmission of Authority
	This is my personal favorite of the lot because it avoids the “authorization/authentication” question and gets at the heart of what this protocol does: delegation, which is to say, transmitting the authority to do something from one party to another. That delegation allows for authorized access to resources, but can also allow different rights to flow as needed. Additionally, “tx” has long been used to stand for “transmission” in computer science and networking.

* AZARP    AuthoriZed Access to Resources Protocol
	The use of “AZ” to stand for “authorized” is awkward, but the pronunciation kinda works as something memorable. The expansion is a twist of words to make it fit, and I like that less.
	Resource access is only part of the story, but it’s an important part. This leaves out what we want to do around non-authorization cases (like identity conveyance).

* AZARAP    AuthoriZation And Resource Access Protocol
	I like the expansion here more than the one for AZARP but I like the acronym less with the additional “A”.
	Same comment as above for AZ standing for Authorization.
	Same comment as above for resource access.

* DAZARAP    Delegated AuthoriZation And Resource Access Protocol
	I like the expansion here, but the acronym is awkward and weak. 
	Same comment as above for AZ standing for Authorized.
	Same comment as above for resource access.

* GNAP    Grant Negotiation and Authorization Protocol
	This is ok, but it has a couple downsides. The pronunciation of a hard “g” or not is going to potentially be confusing, as is the fact that it looks like it’s part of the GNU project because of that.
	The term “Grant” is one of the more confusing things that was introduced in OAuth 2, and while it’s established in the lexicon today, I’ve yet to meet many engineering teams that actually know what a “grant” is. Most think it’s another name for the authorization code.
	Also it means “to bite”, which may or may not be desirable.

* NIRAD    Negotiation of Intent Registration and Authority Delegation
	This is a somewhat weak construct, but it mostly works. It spells out more what the protocol will do (if we go with the currently proposed solution designs) than what it solves, but that might be ok.
	It makes me think of NORAD (a positive, they do weather radar and track Santa Claus each year), but also “nimrod”, a pejorative term. And before anyone chimes in with “But Nimrod was a mighty hunter of ancient times”, it doesn’t mean that to any modern listener.

* GATAR      Grant Authorization To Access Resources 
	This one isn’t bad, and I can appreciate the “guitar” pronunciation and imagery. As above, resource access isonly part of the story.
	Same comment about “Grant” as above in GNAP.

Object:

* AAuthZ    Alternative Authorization Protocol (AAuthZ)
	It’s an alternative to what, exactly? And what happens when someone makes an alternative to it?
	The focus on “Authorization” as a core part of the name tells only part of the story. 
	Assuming the “Z” is pronounced as its letter name (which is implied by the capitalization), there’s an issue with pronouncing the final “Z” as either “Zee” or “Zed” depending on dialect. If it’s not pronounced as a letter, it’s really difficult to say the consonants “thz" together in a way that can be heard and understood.

* BeBAuthZ    Back-end Based Authorization Protocol
	The definition of “back end” is going to change depending on your perspective in the stack, but even if it were consistent, the flexibility around user interaction is a huge motivator for many getting involved in this work.
	This is close to “BBAuth”, which was a commercial predecessor to OAuth 1, so much that it’s nearly impossible to disambiguate when talking.
	Same comment as above focus on Authorization.
	Same comment as above about Zed/Zee confusion.

* BYOAuthZ    Build-Your-Own Authorization Protocol
	This is the opposite of what we’re doing here. We don’t want a bunch of disparate pieces that people can use to build a protocol, we want a protocol with the right kind of flexibility to fit different use cases. This name tells developers that they aren’t getting a solution and incompatibility is likely.
	Same comment as above focus on Authorization.
	Same comment as above about Zed/Zee confusion.

* CPAAP    Comprehensive Privileged Authentication Authorization Protocol
	This makes me think of CPAP, a breathing assistance device. Not something I’m keen to call to mind in the middle of a global pandemic of a respiratory disease.
	The expansion doesn’t really tell me anything.
	What does “privileged” mean here, and does it apply to the authentication (which seems implied)?

* DIYAuthZ    Do-It-Yourself Authorization Protocol
	As above in BYOAuthZ, this is the opposite of what we’re trying to do by creating a standard. 
	Same comment as above focus on Authorization.
	Same comment as above about Zed/Zee confusion.

* GranPro    GRAnt Negotiation Protocol
	The acronym is a really awkward construction. 
	As above, “grant” is an often misunderstood term from OAuth 2. Plus, the “grant” isn’t really what’s being negotiated here.

* IDPAuthZ    Intent Driven Protocol for Authorization
	“IDP” is already well understood in this space to mean “identity provider”, so we should not try to overload it.
	Same comment as above focus on Authorization.
	Same comment as above about Zed/Zee confusion.

* PAuthZ    Protocol for Authorization
	It was suggested this would be pronounced “paws” but I can’t think of a single reason someone looking at the word would try to pronounce it that way. 
	It’s also completely generic and doesn’t say anything about the work.
	Same comment as above focus on Authorization.
	Same comment as above about Zed/Zee confusion.

* RefAuthZ    Refactored Authorization Protocol
	Refactored from what? What if someone refactors this? What are the factors?
	Same comment as above focus on Authorization.
	Same comment as above about Zed/Zee confusion.

* ReAuthZ    Reimagined Authorization Protocol
	The short form is already a short term for “re-authorization”, which is not what we are doing.
	Reimagined from what, and by whom?
	The expansion sounds like it’s imaginary and not real.
	Same comment as above focus on Authorization.
	Same comment as above about Zed/Zee confusion.

* TIAAP    Tokenized Identity and Access Protocol
	I don’t think “tokenized” is used in a meaningful way here. It produced “tokens”, but tokenization is the splitting up of an input into pieces, which is not what’s happening here.

* TIDEAuth    Trust via Intent Driven Extension Auth
	The expansion is really awkward.
	It sounds like it’s an extension to an existing protocol (something that we are explicitly NOT doing per the charter).
	
* TIDYAuth    Trust via Intent Driven Yield Auth
	I actually really like the acronym but the expansion is super awkward. What is being yielded here?

* TIEAuth    Trust via Intent Extension Auth
	What is “intent extension”? 
	As above, it sounds like an extension not a protocol.

* TINOA   This Is Not OAuth
	This says nothing about what this work is, only what it isn’t. And on that regard, it doesn’t matter that this isn’t OAuth. OAuth 2 isn’t OAuth 1, either. 
	And given that ease of transition from OAuth 2 is part of the charter, this isn’t a helpful distinction.

* TXAuth    Testable eXtensible Authorization
	I don’t get the focus on “testable” in the name. Testable in what way? Can other protocols not be tested?
	Extensibility is not a differentiating feature of this work.

* TXAuth      Truly eXtensible Authorization
	Extensibility is not a differentiating feature of this work.
	What makes something “truly extensible” as opposed to “not truly extensible”?

* XAuthZ    eXtensible authoriZation protocol
	Extensibility is not a differentiating feature of this work.
	The acronym is just pulling random letters from the middle of words in the expansion to try to work.
	Same comment as above focus on Authorization.
	Same comment as above about Zed/Zee confusion.

* WRAC     Web Resource Access Collaboration
	This is not a collaboration protocol or system. Collaboration, within computer science, is established to refer to when two or more :people: work and communicate together. This protocol does not facilitate human communication, and so the use of this term is not appropriate here. 
	This is very close to “wrack” which is a common enough English verb, as in “wracked nerves” or “to wrack one’s brain”, which derives from the medieval torture process of stretching someone over a rack. This