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

Dick Hardt <dick.hardt@gmail.com> Wed, 03 June 2020 22:41 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 2342A3A084F for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 15:41:27 -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 hDrqUrO5uqkp for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 15:41:24 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 6D79C3A0852 for <txauth@ietf.org>; Wed, 3 Jun 2020 15:41:23 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id w15so2333021lfe.11 for <txauth@ietf.org>; Wed, 03 Jun 2020 15:41:23 -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=aF8Q3hvmOwLkP214cNzuwz3hA9UC7UYpTBM8/jF+KKc=; b=bLzRuLBCPuGs3pRMBJLKuTQhCdUaOJjfxYD8qtazGXB1HB1ELDrIQVTET/U1MMndLM 1qJUzF+y2uV+LSMnlkUUly7rut6yrJdpc0PE53G0vBxSNLstMGzfhqJn31pxe/B7+aio /K/49FrG5dOGvOSmA3aA376M4OuoNWdn2ccNlGe7UgTkgLqKGFRGGhhbiRC1OxEJoo6W cdGBqKzjkH3PLKQ5khAUKvKDiie8vmSRrFWSdQqyrjUUyFtDh+xzvY5FxTvyVfaoxj9I 077EOLVRpdd8t3RlKeIqeuTK1O/TEUVb92CbKP8jzvIcNfejM6xyWg6LmFsEmhPi1vh/ /vYQ==
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=aF8Q3hvmOwLkP214cNzuwz3hA9UC7UYpTBM8/jF+KKc=; b=hFqgcQQRLir8sU9RGfftykYqWQgzaFXiFpB1TMCwK++Z39DJs5ajxYRtvfam5ytC8Z ONgs0Nr7bAk0FkxoCVxeiuF0H2YDEO+mtp2mreKDjSnw6OK4uK3Nm1BvNix/Onl5VpBv m8jr4dTVdrBl4eCtUNcBxI1+RBJbEu3/eaQaRLtm/iHEQDwKGFOqXefMaOwL3ogh34C6 RrRMUo2fRD0HDzRYHDzGG2f0ICLAPw6xcpPwHUDcwb7xvY2aIjimlOZHZZu94vMZ7aUg p5o2YWbN9eCNv0HCJ1yAl3q+tOEKaXjTgJT3E1r1QWXOgnAX+HTUCZV/a82ov6e2maRO TXYQ==
X-Gm-Message-State: AOAM533710M5MTbiZXhmzNjqd6wwH+o2I28XAFSUd/lnvtP1YQpNs8Dd xVGntUrfH0s2xFRj1s7H2dZUiep3GeeYoLbdVfcdQFzR/UI=
X-Google-Smtp-Source: ABdhPJyAgObOXsx6JFHl9ZFbZlEUJevbc2RRpJO3q1xSTDN8fO2u1EM/rYWIIaXf9zhafgRu3OYofQLXdP7iXJyrJoY=
X-Received: by 2002:a19:f11c:: with SMTP id p28mr899019lfh.0.1591224081198; Wed, 03 Jun 2020 15:41:21 -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> <CAD9ie-t6VcJ8JVyy=M-M8JreejzOCL6YdgTqry1Hbbt3Cz5M1Q@mail.gmail.com> <3E18041D-DDF1-4DFD-ACA2-8C37E46495D7@mit.edu> <CAD9ie-sH34LT0fVW-AJ77+y5+6GMUe8doeQaO77SDycm5vHwpA@mail.gmail.com> <CFC29E37-8C72-4EF3-8C59-007972FE5A8B@mit.edu>
In-Reply-To: <CFC29E37-8C72-4EF3-8C59-007972FE5A8B@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 03 Jun 2020 15:40:54 -0700
Message-ID: <CAD9ie-s5OeQkU4EVrr=mCj94K9+raS=wBJFGggz0ZqkaniihAg@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/related; boundary="0000000000001e4da205a735ba3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/WknFETrKjgaGNZb7eoE5meFJ7ak>
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 22:41:27 -0000

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