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 >>> >> >> ᐧ > > >
- Re: [Txauth] Call for WG name preferences - proce… Yaron Sheffer
- Re: [Txauth] Call for WG name preferences - proce… David Skaife
- Re: [Txauth] Call for WG name preferences - proce… Yaron Sheffer
- Re: [Txauth] Call for WG name preferences - proce… David Skaife
- Re: [Txauth] Call for WG name preferences - proce… Justin Richer
- Re: [Txauth] Call for WG name preferences - proce… Justin Richer
- Re: [Txauth] Call for WG name preferences - proce… Nat Sakimura
- Re: [Txauth] Call for WG name preferences - proce… Dick Hardt
- Re: [Txauth] Call for WG name preferences - proce… Dick Hardt
- Re: [Txauth] Call for WG name preferences - proce… Justin Richer
- Re: [Txauth] Call for WG name preferences - proce… Justin Richer
- Re: [Txauth] Call for WG name preferences - proce… Steinar Noem
- Re: [Txauth] Call for WG name preferences - proce… Justin Richer
- Re: [Txauth] Call for WG name preferences - proce… Dick Hardt
- Re: [Txauth] Call for WG name preferences - proce… Dick Hardt
- Re: [Txauth] Call for WG name preferences - proce… Justin Richer
- Re: [Txauth] Call for WG name preferences - proce… Dick Hardt
- Re: [Txauth] Call for WG name preferences - proce… Bron Gondwana
- Re: [Txauth] Call for WG name preferences - proce… Mike Varley