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

Justin Richer <jricher@mit.edu> Wed, 03 June 2020 12:19 UTC

Return-Path: <jricher@mit.edu>
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 BC63A3A1080 for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 05:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 F-65m4AAjo6a for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 05:19:12 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6D43A108F for <txauth@ietf.org>; Wed, 3 Jun 2020 05:19:11 -0700 (PDT)
Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 053CJ7HN017515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 08:19:07 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <3E18041D-DDF1-4DFD-ACA2-8C37E46495D7@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F341B5CE-2728-4793-A998-7076F9A6EF26"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 3 Jun 2020 08:19:07 -0400
In-Reply-To: <CAD9ie-t6VcJ8JVyy=M-M8JreejzOCL6YdgTqry1Hbbt3Cz5M1Q@mail.gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
To: Dick Hardt <dick.hardt@gmail.com>
References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <C20CD45E-6AEE-452F-ABE9-243CABAC2AD4@mit.edu> <CAD9ie-t6VcJ8JVyy=M-M8JreejzOCL6YdgTqry1Hbbt3Cz5M1Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/FDYA0YdkPEzhlWCXTCTUG1eeqOY>
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: Wed, 03 Jun 2020 12:19:18 -0000

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/ <https://datatracker.ietf.org/wg/txauth/about/>
> ᐧ
> 
> On Thu, May 28, 2020 at 2:47 PM Justin Richer <jricher@mit.edu <mailto: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 <mailto:Txauth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>