[Txauth] WG name preferences

Aaron Parecki <aaron@parecki.com> Thu, 04 June 2020 02:15 UTC

Return-Path: <aaron@parecki.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 BC46B3A0D3C for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 19:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CuWMyth92a5f for <txauth@ietfa.amsl.com>; Wed, 3 Jun 2020 19:15:31 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 83EF73A0D3B for <txauth@ietf.org>; Wed, 3 Jun 2020 19:15:31 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id q8so4606533iow.7 for <txauth@ietf.org>; Wed, 03 Jun 2020 19:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=9sNR0oPyogpzjDiX+UJDXaAmUXl2vCJAF4fyHPfpZUI=; b=Ik6fAbNojceMAhNgfZdQ5mWy61H0DxMqKKe55lt+h27v1ah5dH5fmBZHt7jLj54lm/ mhsFd24C8UEs7i8EygXiaZSiG1QMDh1hB117EIntzrxUsRPbnd/pEjL4BgARPEi4JPho Zyv32GHQb+KElXtCUHOWJ0RtJIbZt5g/OIar+2zEy7ca4gouIimX63+JM7wheDDkkphF bJLSd/TG+UFnVZKNx2+AHKEZAMVb0qCUKaobyhpugTKb5KcCqqkXpHpEzKi2rOczAXQ7 fZnjVLLf2uurKfTUvxHPJaJh9MTGpkRlWkdNufe/Urh9XAVBNrO+V7sW3paFTvTQnBXa p7PQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9sNR0oPyogpzjDiX+UJDXaAmUXl2vCJAF4fyHPfpZUI=; b=OzQ4uYlNWPGYC3WIQqzT+E6vcRHsLZk/bfbtdKxSQpp74r/CVR32GnzWDO24tJVCvo TBeswVfNhNphzZH8BdaKgXNiHcD7Kw7UVKPOPWi4JSCEwXMmQNsyg1YNpGZCxUmaCW1b K3wN4pVOyqx4iDjAKXwfEuffpdfobsMU5ptTsQp4dI5dCaNOl2QperqqbBMlCgDmMft6 JsfnzA7AUlhfy9RIZesrg1PiStuw5PQFiUkcWqkOIcbr8JW2C9vAfwP0Mca7zQreeeqX MsC4is/mL1WkGvZl88o4KLtp80ecLht5cvSAZWgVfyQvl4pmiyOMEfAoBAqYGf1+RElC YNiQ==
X-Gm-Message-State: AOAM530wor0magZ9pd8B4bcij30589bAuf/Hiazq8TSh5MSE5uynjrh7 eHGgFOJAkVm+XgFjXtqYgW6KovRmnRs=
X-Google-Smtp-Source: ABdhPJxSt/34h93PjK6KNFSbU5bOVlI3vhZ6NNT+icR0+/U+G8yle0kg0lUG5rLkUblCL/3KKiE8Jw==
X-Received: by 2002:a02:3402:: with SMTP id x2mr2389614jae.11.1591236930096; Wed, 03 Jun 2020 19:15:30 -0700 (PDT)
Received: from mail-il1-f173.google.com (mail-il1-f173.google.com. []) by smtp.gmail.com with ESMTPSA id p69sm741293ili.75.2020. for <txauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 19:15:29 -0700 (PDT)
Received: by mail-il1-f173.google.com with SMTP id d1so4556977ila.8 for <txauth@ietf.org>; Wed, 03 Jun 2020 19:15:29 -0700 (PDT)
X-Received: by 2002:a05:6e02:5a9:: with SMTP id k9mr2195970ils.291.1591236928735; Wed, 03 Jun 2020 19:15:28 -0700 (PDT)
MIME-Version: 1.0
From: Aaron Parecki <aaron@parecki.com>
Date: Wed, 3 Jun 2020 19:15:17 -0700
X-Gmail-Original-Message-ID: <CAGBSGjovjLEJin_N1fzA675Kwgg_HPdK6SwxQQhq4ON+sG8yaA@mail.gmail.com>
Message-ID: <CAGBSGjovjLEJin_N1fzA675Kwgg_HPdK6SwxQQhq4ON+sG8yaA@mail.gmail.com>
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e426d505a738b757"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/MX7aXVKXhwdwjSq3aYNwKSVjrtk>
Subject: [Txauth] WG name preferences
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 02:15:34 -0000

Alright here's mine:

Would not object:

    * TxAuth - Transmission of Authority - This is my favorite, there's a
lot of precedent for "tx" to mean "transmit", and using "authority" is a
nice way to sidestep the authn vs authz nonsense. It also does describe
what the protocol is doing, which is delegation. (If there was a nice
shorthand for Delegation of Authority that would have been better, but
"DegAuth" and "DAuth" are just terrible.

    * GNAP - Grant Negotiation and Authorization Protocol - I don't hate
it, but I agree with Justin on the downsides: ambiguous pronunciation,
potential confusion with GNU, and the use of "grant" which so far hasn't
been a core concept in the new proposals. Also, any acronym that ends with
"P" will have people saying "GNAP Protocol" which is redundant like "ATM

    * GATAR - Grant Authorization to Access Resources - Not my favorite,
but at least the pronunciation isn't super ambiguous, and like Justin said,
resource access is not the entire story.

    * TIDYAuth - Trust via Intent Driven Yield Auth - I like the acronym,
but the expansion makes little sense. I'm putting it in my "wouldn't
object" list because if we go with this, in reality nobody will use the
expanded form anyway and it will just be the short name.

Here are my objections along with the reasoning:

    * AAuthZ    Alternative Authorization Protocol
    * ReAuthZ    Reimagined Authorization Protocol
    * RefAuthZ    Refactored Authorization Protocol
    * TINOA   This Is Not OAuth

These define it in relation to something else, which is never a good idea.

    * BYOAuthZ    Build-Your-Own Authorization Protocol
    * DIYAuthZ    Do-It-Yourself Authorization Protocol

Sounds unprofessional.

    * TXAuth    Testable eXtensible Authorization
    * TXAuth      Truly eXtensible Authorization
    * XAuthZ    eXtensible authoriZation protocol

While extensibility is definitely important, I don't think it is a core
value of the protocol. If anything we're trying to specify more details
than OAuth 2.0 did at the start, which was one of the major criticisms it

    * BeBAuthZ    Back-end Based Authorization Protocol
    * TIAAP    Tokenized Identity and Access Protocol
    * PAuthZ    Protocol for Authorization

These are awkward to pronounce.

    * TIEAuth    Trust via Intent Extension Auth
    * TIDEAuth    Trust via Intent Driven Extension Auth

These aren't great to pronounce, and also have a very awkward expansion
that is clearly a backronym.

    * IDPAuthZ    Intent Driven Protocol for Authorization

"IDP" is already a commonly used term in this space and it would cause
significant confusion to redefine it this way.

    * AZARP    AuthoriZed Access to Resources Protocol
    * AZARAP    AuthoriZation And Resource Access Protocol
    * DAZARAP    Delegated AuthoriZation And Resource Access Protocol
    * GranPro    GRAnt Negotiation Protocol

A few of these sound silly and I'm not sure I could say them with a
straight face, also not a fan of the "AZ -> Authorized" expansion.

    * CPAAP    Comprehensive Privileged Authentication Authorization

Looks too much like CPAP, and "craap", would not be googleable if I said
this out loud to someone.

    * NIRAD    Negotiation of Intent Registration and Authority Delegation

Not a fan of how similar this is to NORAD.

    * WRAC (Web Resource Authorization Collaboration) - Pronounced like RACK

A reasonable acronym with easy enough pronunciation, but I'm not a fan of
"collaboration" in the expansion at all. This is not a collaboration
system, that term is already heavily used in other types of software.

Aaron Parecki