Re: [Txauth] Call for WG name preferences - done!

Yaron Sheffer <> Fri, 05 June 2020 15:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 703F93A0793 for <>; Fri, 5 Jun 2020 08:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iMlBODoq01b6 for <>; Fri, 5 Jun 2020 08:09:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62D813A078A for <>; Fri, 5 Jun 2020 08:09:41 -0700 (PDT)
Received: by with SMTP id g28so10010455qkl.0 for <>; Fri, 05 Jun 2020 08:09:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=HXpl6HVHPnIgDHemOGMUzr/dB0uCdW6MQfEEBLACK9k=; b=C1IePVYgHSzV44t7bvOXvfSTveio79DXsoO5DcGKuamspC6cM2lylIga1E50npujsW 0QjKtyGU0x7i8C9ltoKpLxHeax0EQ5586tzM5F2V+nqUnnQazHDEGRfmRGhd7R8VM2Fp LFpcjSqo8JtgZK+jSrJDFO1hFp3CTifOpzYi/OwaLn9aNYZ0tzvOFxiy7o0ngF6ArGXy 8BfsAKcyNiVCvoTEzznweK5B5k8k8ruWsvvJjalA3jlB6ji0EwspIHHU6caiGU/uBcRh ZvMH0+lZeZzXD9AWt1by95xy/egC+28UAyLOCUkn/tPtySsmnquY6GMzmO3r2dNF237f lilQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=HXpl6HVHPnIgDHemOGMUzr/dB0uCdW6MQfEEBLACK9k=; b=RaZQ20skTfFo2uJHegAU+/3W35vvn3KLMxvo6BABO0V0iq+aWR23t3IOlN3ro8AOPz JA4VR7YrwKnQbTp8I16pRxaMix9LHlBH55GyEnBAFPtvmOGWKpLDehCsNx0b38DqRHON VHIRQjEW/BOHSqd+d89P/CQSD53mOt8Z/AX/6dwo8BlWYcUOTvJ6fnmULOCFskp4LjVy IF2MMmkPWh7XIzycicsfbgykY0TCRug5dMKBSMnkYvGI9zNMEAyQhDnA00dd0+51nisj TGPQJWUxXFBcUnOo78OI6HRJoJ1uqvqk+24I/xcSioF8LvnpwdQ5EtFHuT0KJWO6IeI3 J5JA==
X-Gm-Message-State: AOAM530Z1N8KW9xXeg0z7sE1mzxgpxQ27bfLw/VrXruOTtTPK8RLM63v StkUz5pOeJbB2yq+xXutxOk=
X-Google-Smtp-Source: ABdhPJxc/foxLXZeLELYE0vazum8IBcklXXITzONensznd7Rs81/LpB6YiX84AAso3aCwqO6iFExGw==
X-Received: by 2002:a37:67c7:: with SMTP id b190mr10157933qkc.228.1591369780360; Fri, 05 Jun 2020 08:09:40 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id w94sm24521qte.19.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 08:09:39 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.37.20051002
Date: Fri, 05 Jun 2020 18:09:36 +0300
From: Yaron Sheffer <>
To: Justin Richer <>, Mike Jones <>
CC: "" <>
Message-ID: <>
Thread-Topic: [Txauth] Call for WG name preferences - done!
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3674225378_1658071922"
Archived-At: <>
Subject: Re: [Txauth] Call for WG name preferences - done!
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jun 2020 15:09:44 -0000

Folks, we are past the deadline for name selections. Thank you all who shared their thoughts on time. Dick and I will go through all the responses and (most hopefully) will be able to announce the group’s consensus and submit it to the AD and IESG.





From: Justin Richer <>
Date: Friday, June 5, 2020 at 17:59
To: Mike Jones <>
Cc: Yaron Sheffer <>om>, "" <>
Subject: Re: [Txauth] Call for WG name preferences


Since there seems to be some confusion by a few people about the term “Intent” and its inclusion here, I wanted to clarify that for people. There is a protocol feature is variously known as “intent registration” or “lodging intent”, where the party starting the process (the client) makes a statement about what it wants to do and is then given the tools to complete the next steps to do that. It’s a key feature of the pattern we’re looking to codify in this group’s work.


The FAPI working group in the OIDF has done a lot of work around it, and you see this style in a bunch of different financial APIs dating back decades:



Torsten Lodderstedt has a great blog post that touches on it as well:


And it’s the basis behind OAuth 2.0’s Pushed Authorization Request (PAR) extension that’s happening now:



To be clear, I’m not saying this is sufficient for it driving the name, but I do think it’s important that people be familiar with this terminology as its likely to come up again as the work progresses. 


 — Justin

On Jun 4, 2020, at 7:25 PM, Mike Jones <> wrote:



    * GNAP    Grant Negotiation and Authorization Protocol – The focus on grants is correct.  And it’s a snappy name.

    * GranPro    GRAnt Negotiation Protocol – The focus on grants is correct.  Pronounceable.

    * NIRAD    Negotiation of Intent Registration and Authority Delegation – Cool sci-fi sounding name.

    * PAuthZ    Protocol for Authorization – Accurate description.

    * RefAuthZ    Refactored Authorization Protocol – Accurate description.

    * ReAuthZ    Reimagined Authorization Protocol – Accurate description.

    * WRAC (Web Resource Authorization Collaboration) - Pronounced like RACK – Cool name, with history going back to OAuth WRAP.

    * XAuthZ    eXtensible authoriZation protocol – Accurate description.


Wouldn't object to:

    * AAuthZ    Alternative Authorization Protocol (AAuthZ)

    * AZARP    AuthoriZed Access to Resources Protocol

    * AZARAP    AuthoriZation And Resource Access Protocol

    * BeBAuthZ    Back-end Based Authorization Protocol

    * DAZARAP    Delegated AuthoriZation And Resource Access Protocol

    * TINOA   This Is Not OAuth


Object to:

    * BYOAuthZ    Build-Your-Own Authorization Protocol – Too cheesy.

    * CPAAP    Comprehensive Privileged Authentication Authorization Protocol – Too much like a medical device name.

    * DIYAuthZ    Do-It-Yourself Authorization Protocol – Too cute.

    * IDPAuthZ    Intent Driven Protocol for Authorization – IDP already means something else.

    * TIAAP    Tokenized Identity and Access Protocol – I don’t know what “tokenized” is referring to here.

    * TIDEAuth    Trust via Intent Driven Extension Auth – I don’t know what “intent” is referring to here.

    * TIDYAuth    Trust via Intent Driven Yield Auth – I don’t know what “intent” is referring to here.

    * TIEAuth    Trust via Intent Extension Auth – I don’t know what “intent” is referring to here.

    * TXAuth    Testable eXtensible Authorization – I don’t know what “testable” is referring to here.

    * TxAuth      Transmission of Authority – It’s delegation of authority – not transfer of authority.

    * TXAuth      Truly eXtensible Authorization – Too cute.


                                                       -- Mike


Txauth mailing list