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

Dick Hardt <dick.hardt@gmail.com> Tue, 02 June 2020 21:59 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4803A07E2 for <txauth@ietfa.amsl.com>; Tue, 2 Jun 2020 14:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhSNol9M6Bn5 for <txauth@ietfa.amsl.com>; Tue, 2 Jun 2020 14:59:14 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 0F0733A07E0 for <txauth@ietf.org>; Tue, 2 Jun 2020 14:59:14 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id o9so158599ljj.6 for <txauth@ietf.org>; Tue, 02 Jun 2020 14:59:13 -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 :cc; bh=xG7I+U6MpmWE3FW53nKKkci+kYEkBRcBJvp/k7suKTM=; b=dA2OSE1OfXxelE0E6FvTsExynZa1OQK8SUa5SdpCq3zg8PfYQiizHJrf1SkaHiDpK9 EvhYTRInRCBd1WJx4N24ZDnGEOO6b90nMUsN9uU6GlAjqI4NJyJRPDieNJ61uprQLHKA 7cu3WpeoiA71Ba194G2LplF5fBXA+pKAnSbGgTJKImnSG5HYoicWo0/pCJi+2otjPgbX LKOiqDnCWsPGJBx49MUyv1MKTkfeSOTgJgRAAdBhoyIjNRSU04mV9HC0Kz8eGwRbqVY1 jsho/BEv41wkLQBn082KB9MS8Z2S+YQkDRvXASGq+Sj9zFvMznWo4JB6BlqEzKOZE/WP /qtA==
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:cc; bh=xG7I+U6MpmWE3FW53nKKkci+kYEkBRcBJvp/k7suKTM=; b=iLlQ3GTt1084bT/zYDEknHjmGXiVFI4Cyh+gSs9mlrDJjXejTMU2QKaoRLHY85HBd/ ABLvWfXzNTe9Csl3NsGjWvfbSFmL/i5Uv+K8tt3qySMmNrjhCBqgYaFPwMCdHvEylbi2 kHLLvhifu6gWm3BJMR3+Iff9dqGr7S5LJxhPPI3KgrWwhFaQ1jFn767y2oShqw4oZ4BW 4s1HiYBo09yhtP9pfdvmEHf7ZvyF45FjlC8LJPFP/U7JS+ScM5STDQYyR27EuZzleQP5 lcRTGgSiwyX3zMEki9mpS8fT8VVp+vNXBBlNWXcfyu3dSVXhlACwyI7Ocf/Jlz/Y/Kl/ dlGg==
X-Gm-Message-State: AOAM532KijBr6mqF1lhZKnL21WQHUvr/thufQxJNJmi1a9teFYBAnu8H fDFWlmaAZo6/JmrvV8CiJt9qAeMrM1Lh3ZTWlTU=
X-Google-Smtp-Source: ABdhPJwNqMLkjHIv6ZUc6bH4SIhfl/Q2bodi6kRMwv6wYa3b71+w70ylGqTFWEOC5Zj7/ptkC9JuIR5jDypAqyBlzNY=
X-Received: by 2002:a2e:140a:: with SMTP id u10mr553734ljd.56.1591135152048; Tue, 02 Jun 2020 14:59:12 -0700 (PDT)
MIME-Version: 1.0
References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <C20CD45E-6AEE-452F-ABE9-243CABAC2AD4@mit.edu>
In-Reply-To: <C20CD45E-6AEE-452F-ABE9-243CABAC2AD4@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 2 Jun 2020 14:58:46 -0700
Message-ID: <CAD9ie-t6VcJ8JVyy=M-M8JreejzOCL6YdgTqry1Hbbt3Cz5M1Q@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000087111805a7210513"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/uq0V0tXKC2psKNWduP42VyUwz6g>
Subject: Re: [Txauth] Call for WG name preferences - process clarification
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: Tue, 02 Jun 2020 21:59:17 -0000

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