[Txauth] WG name preferences (Hankins Parichabutr)

Hankins Parichabutr <hankins.parichabutr@gmail.com> Thu, 04 June 2020 00:53 UTC

Return-Path: <hankins.parichabutr@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DDE683A0821 for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 17:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8UWeggcuv_MT for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 17:53:11 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF71C3A0809 for <txauth@ietf.org>; Wed, 3 Jun 2020 17:53:10 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id c15so1491329uar.9 for <txauth@ietf.org>; Wed, 03 Jun 2020 17:53:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=X5NCa54vLVLa015UIOlE+Xv70ZOcTvU0hP05rxU5CiA=; b=rYvyH3+FNrt0Aiz1qHndtHhJDySpfm996k/lexo3vYm4xrS83l1+BMSDbrWuLiM7Fj QyM4c0a2Cbsv3BTitO1z3gTEOHRLCRsqFOcqU/XF4DWOqi18mNjCzS9ZqZYpJIAxo4KF 3vPCLHVIEVMlvTAx9j1y0GpJjNeDUpuWGJYOT3kWORTV2p2VJf/jXJfxpoYJO3gSfwHW osxkQ4r1Z7MQEveJt+gJ1Y/DPZrKl1WbfZQ7oTZo6JXfWfWnBu02BtYb3EEAJeVIq/Al voPkVxPUEBZzPi/I4WkTxjdtx+ZOVKZnXis408/dmS8Mr+ozS/kV8g2pqBBNRnMmV8IT Uz3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=X5NCa54vLVLa015UIOlE+Xv70ZOcTvU0hP05rxU5CiA=; b=Dd0LreY7cygRg8RRUBrMsPOoKPsYSKugCLK11268YaRT5Njnp1TIWOs+LiXH8eJLVo FmsH72b0dWBN9OHI9PKYkG6stiJaiXXvHbCp/LhDH/7DS6RYXAuimuKxnYfxh+xh7FOl rzb6lfAXzpyEBvDvT2J0WKEq6R0TYtfHDw/uPTxGonL8RpQmNyPsQccyI/9qpLu3vnCR 44o/9o0wt4OtgzfJyXkE8/oENx/v+IGHJo2L7gGvY2uMh1vbkSUUb08P12htGtP+3G6a QYx2O+W9OLYknx6qGl2ILtNCzee32SBV7jey7VWdL9j8/MkSHt1TYJDoXdvYga48xKRR 4HAg==
X-Gm-Message-State: AOAM532O1WZVIemBQRuMn8w4LsB0oCQ94dRKh1TNHxDrsYw4ufz5tewk 40NY3TcMlIG7DJFFid/76b6JJ7hh7dxYeFZJWD8OcGNcg9E=
X-Google-Smtp-Source: ABdhPJydtBBEVEDrYxrSKd3nPkrAbVBpBQ/Vi6DOHuUZer4Mjpfr+idmXZSKY3FOCNoe1rBn6ZJBoZThLHs1kvd9D2c=
X-Received: by 2002:a9f:3150:: with SMTP id n16mr1991671uab.9.1591231988370; Wed, 03 Jun 2020 17:53:08 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.3419.1591224087.8861.txauth@ietf.org>
In-Reply-To: <mailman.3419.1591224087.8861.txauth@ietf.org>
From: Hankins Parichabutr <hankins.parichabutr@gmail.com>
Date: Wed, 3 Jun 2020 20:52:31 -0400
Message-ID: <CAOvbAbX_aPmpSr4qynq7qV99B6wWhHSFtJBwgUyp9O0oCC4W-w@mail.gmail.com>
To: txauth@ietf.org
Content-Type: multipart/related; boundary="0000000000006c8f5e05a73791fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/gIcnJlQ7BtD4DnxWScCYfH0p1ok>
Subject: [Txauth] WG name preferences (Hankins Parichabutr)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2020 00:53:14 -0000

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
        * 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


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

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

On Wed, Jun 3, 2020 at 6:41 PM <txauth-request@ietf.org> wrote:

> Send Txauth mailing list submissions to
>         txauth@ietf.org
> 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
>         txauth-request@ietf.org
> You can reach the person managing the list at
>         txauth-owner@ietf.org
> 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 <dick.hardt@gmail.com>
> To: Justin Richer <jricher@mit.edu>
> Cc: "txauth@ietf.org" <txauth@ietf.org>
> 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 <jricher@mit.edu> 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 <dick.hardt@gmail.com> 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 <jricher@mit.edu> 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 <dick.hardt@gmail.com> 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 <jricher@mit.edu> 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
>>>> Txauth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>> ᐧ
>> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth