[Txauth] WG name preferences (Hankins Parichabutr)

[Hankins Parichabutr <[e-mail]>]

Here are my name preferences for the WG...

*Wouldn't Object:*

        * TxAuth      Transmission of Authority
        * AZARP    AuthoriZed Access to Resources Protocol
        * GNAP    Grant Negotiation and Authorization Protocol
        * NIRAD    Negotiation of Intent Registration and Authority
Delegation
        * PAuthZ    Protocol for Authorization
        * TIAAP    Tokenized Identity and Access Protocol

I feel these all have the right mix of identifiable/unique short names,
along with expansions that both describe and define the overall subject
area we're addressing - without imposing any hard-edges if you know what I
mean.

*Object:*

All the other candidates, for reasons including:
+ not describing or defining anything (eg. "Alternative", "BYO", "DIY",
"Reimagined")
+ being too hard-edged (eg. "Testable", "This is not...", "Truly",
"Refactored")
+ prone to pre-conceived notions (eg. anything with "Extension")
+ being an acronym looking for a name (eg. "CPAAP", "AZARAP", "GranPro",
"TIDYAuth"

Thanks for your consideration,
Hankins Parichabutr
. . . . . . . . . . . . . . . . . . . . .


On Wed, Jun 3, 2020 at 6:41 PM <[e-mail]> wrote:

> Send Txauth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/txauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Txauth digest..."
> Today's Topics:
>
>    1. Re: Call for WG name preferences - process clarification
>       (Dick Hardt)
>
>
>
> ---------- Forwarded message ----------
> From: Dick Hardt <[e-mail]>
> To: Justin Richer <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Bcc:
> Date: Wed, 3 Jun 2020 15:40:54 -0700
> Subject: Re: [Txauth] Call for WG name preferences - process clarification
> The criteria is not "sufficiently descriptive of the work", it is
> "descriptive of the work".
>
> wrt. your comment: "I don’t agree with you that extensibility was not a
> design factor in OAuth 2, either."
>
> I did not say that, I said:
>
> "was not a *major* consideration in creating OAuth 2.0"
> [image: image.gif]
> Of course it was a consideration, but extensibility did not have the
> prominence it has in the proposed charter.
>
> Having said all of that, I don't think "extensible" is the best adjective
> for the work, but I don't think it is objectionable per the criteria.[image:
> image.gif]
> [image: image.gif]
>
> On Wed, Jun 3, 2020 at 12:36 PM Justin Richer <[e-mail]> wrote:
>
>> My objection is that it is not a *sufficient* description of the work.
>> Please understand that I agree that extensibility is important, as it’s
>> been built into XYZ across all of the various dimensions in our proposed
>> charter from the project’s inception. However, there’s a lot more going on
>> here and I don’t thing simply saying it’s “extensible” is any more helpful
>> than saying it’s “new”. OAuth 2 is already pretty extensible, and people
>> are extending it today to do a lot of important things. I don’t agree with
>> you that extensibility was not a design factor in OAuth 2, either.
>>
>>  — Justin
>>
>> On Jun 3, 2020, at 12:25 PM, Dick Hardt <[e-mail]> wrote:
>>
>> Justin
>>
>> Your objection to extensibility is:
>>
>> "Extensibility is not a differentiating feature of this work."
>>
>>
>> I don't see "differentiating feature"  in our selection criteria[1],
>>
>> We do have the following selection criteria:
>>
>> "4. Descriptive of protocol"
>>
>> And given how we are explicit in the extensibility, I would consider it
>> descriptive of the protocol.
>>
>> As to the original OAuth 1.0 charter (which talks about extending OAuth
>> 1.0 to create OAuth 1.1), extensibility was not a focus area, and
>> definitely was not a major consideration in creating OAuth 2.0. I think
>> careful considerations of extension points will allow this work to be a
>> protocol rather than a framework, not the other way around. As an example,
>> in the current XAuth document, both the authorization and claims objects
>> contain name spaced schemas so that the protocol can be extended with other
>> schemas than the original schemas. For example, there are other schemas for
>> identity claims than what is in OpenID Connect.
>>
>>
>>
>> [1]
>> https://mailarchive..ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/
>> <https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/>
>>
>>
>>
>> On Wed, Jun 3, 2020 at 5:19 AM Justin Richer <[e-mail]> wrote:
>>
>>> Hi Dick,
>>>
>>> Yes, I am pretty familiar with the charter text, but thank you for
>>> posting it to the group as a reminder.
>>>
>>> The original charter text for the OAuth WG[1] does in fact call out
>>> extensibility explicitly in several places, including:
>>>
>>> The Working Group will produce one or more documents
>>> suitable for consideration as Proposed Standard that will:
>>>
>>>  ...
>>> * Provide guidelines for extensibility.
>>>
>>>
>>> The difference here is that we’re being more explicit about what is
>>> extensible and how, in the charter. But one of the biggest innovations in
>>> OAuth 2, as I’m sure you know, is that it allowed for explicit
>>> extensibility in ways that OAuth 1 did not: grant types, token types,
>>> scopes (and therefore resource types), client auth types (and therefore
>>> client types), etc. The very fact that OAuth 2 is a *framework*
>>> fundamentally speaks to its goals of extensibility.
>>>
>>> The TxAuth charter text that you quoted carries much of that tradition
>>> forward, which is why I said that extensibility is not a :defining: feature
>>> of this work. It’s absolutely a feature and an important one, but
>>> extensibility itself is hardly new or unique as a goal. What’s unique is
>>> :what: we’re targeting for extensibility points, which is why those are
>>> listed below in the proposed charter text.
>>>
>>> I also worry that a focus on ‘extensibility’ above all else will slide
>>> us back into the world of incompatible framework pieces. As the proposed
>>> charter also states that we’re building a protocol, not a framework, this
>>> is counter to what we’re coming together for.
>>>
>>>  — Justin
>>>
>>> [1]
>>> https://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2009-05-13.txt
>>>
>>> On Jun 2, 2020, at 5:58 PM, Dick Hardt <[e-mail]> wrote:
>>>
>>> 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/
>>>
>>> <image.gif>
>>>
>>>
>>>
>>>
>>> ᐧ
>>>
>>> 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
>>>>
>>>
>>> ᐧ
>>
>>
>> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>