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

[Nat Sakimura <[e-mail]>]

While there is some good point to your critique to GNAP, I still seem to
like it, partly because I grew up in the country where gnu migration
happens every summer, and especially because we need to establish Grant as
the properly understood term in relation to OAuth.

Best,

Nat

On Tue, Jun 2, 2020 at 10:18 PM Justin Richer <[e-mail]> wrote:

> Hi everyone, I just wanted to remind the community that feedback on the
> potential names is needed by the chairs by this Thursday, June 4th. Please
> post your comments to the list before then!
>
> Remember, they’re looking for feedback in the form of “wouldn’t object”
> and “would object”, and all objections should have specific reasons.
>
>  — Justin
>
> On May 28, 2020, at 5: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
>
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en