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

[Dick Hardt <[e-mail]>]

Hey Justin,

Per your comment "Extensibility is not a differentiating feature of this
work.", extensibility is explicitly called out in the charter (and is not
in the OAuth WG charter):


The group will define extension points for this protocol to allow for
flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of
possession
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces
of information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation
process (including identifiers and identity assertions)

Milestones to include:
<snip>
- Guidelines for use of protocol extension points


[1] https://datatracker.ietf.org/wg/txauth/about/
ᐧ

On Thu, May 28, 2020 at 2:47 PM Justin Richer <[e-mail]> wrote:

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