Subject: [Txauth] WG name preferences

From: Aaron Parecki <[email-masked]>
Date: Wed, 3 Jun 2020 19:15:17 -0700

Alright here's mine:

Would not object:

    * TxAuth - Transmission of Authority - This is my favorite, there's a
lot of precedent for "tx" to mean "transmit", and using "authority" is a
nice way to sidestep the authn vs authz nonsense. It also does describe
what the protocol is doing, which is delegation. (If there was a nice
shorthand for Delegation of Authority that would have been better, but
"DegAuth" and "DAuth" are just terrible.

    * GNAP - Grant Negotiation and Authorization Protocol - I don't hate
it, but I agree with Justin on the downsides: ambiguous pronunciation,
potential confusion with GNU, and the use of "grant" which so far hasn't
been a core concept in the new proposals. Also, any acronym that ends with
"P" will have people saying "GNAP Protocol" which is redundant like "ATM
Machine".

    * GATAR - Grant Authorization to Access Resources - Not my favorite,
but at least the pronunciation isn't super ambiguous, and like Justin said,
resource access is not the entire story.

    * TIDYAuth - Trust via Intent Driven Yield Auth - I like the acronym,
but the expansion makes little sense. I'm putting it in my "wouldn't
object" list because if we go with this, in reality nobody will use the
expanded form anyway and it will just be the short name.

Here are my objections along with the reasoning:

    * AAuthZ    Alternative Authorization Protocol
    * ReAuthZ    Reimagined Authorization Protocol
    * RefAuthZ    Refactored Authorization Protocol
    * TINOA   This Is Not OAuth

These define it in relation to something else, which is never a good idea.

    * BYOAuthZ    Build-Your-Own Authorization Protocol
    * DIYAuthZ    Do-It-Yourself Authorization Protocol

Sounds unprofessional.

    * TXAuth    Testable eXtensible Authorization
    * TXAuth      Truly eXtensible Authorization
    * XAuthZ    eXtensible authoriZation protocol

While extensibility is definitely important, I don't think it is a core
value of the protocol. If anything we're trying to specify more details
than OAuth 2.0 did at the start, which was one of the major criticisms it
got.

    * BeBAuthZ    Back-end Based Authorization Protocol
    * TIAAP    Tokenized Identity and Access Protocol
    * PAuthZ    Protocol for Authorization

These are awkward to pronounce.

    * TIEAuth    Trust via Intent Extension Auth
    * TIDEAuth    Trust via Intent Driven Extension Auth

These aren't great to pronounce, and also have a very awkward expansion
that is clearly a backronym.

    * IDPAuthZ    Intent Driven Protocol for Authorization

"IDP" is already a commonly used term in this space and it would cause
significant confusion to redefine it this way.

    * AZARP    AuthoriZed Access to Resources Protocol
    * AZARAP    AuthoriZation And Resource Access Protocol
    * DAZARAP    Delegated AuthoriZation And Resource Access Protocol
    * GranPro    GRAnt Negotiation Protocol

A few of these sound silly and I'm not sure I could say them with a
straight face, also not a fan of the "AZ -> Authorized" expansion.

    * CPAAP    Comprehensive Privileged Authentication Authorization
Protocol

Looks too much like CPAP, and "craap", would not be googleable if I said
this out loud to someone.

    * NIRAD    Negotiation of Intent Registration and Authority Delegation

Not a fan of how similar this is to NORAD.

    * WRAC (Web Resource Authorization Collaboration) - Pronounced like RACK

A reasonable acronym with easy enough pronunciation, but I'm not a fan of
"collaboration" in the expansion at all. This is not a collaboration
system, that term is already heavily used in other types of software.

---
Aaron Parecki
https://aaronparecki.com