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

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 05 June 2020 15:09 UTC

Return-Path: <yaronf.ietf@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 703F93A0793 for <txauth@ietfa.amsl.com>; Fri, 5 Jun 2020 08:09:44 -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_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: 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 iMlBODoq01b6 for <txauth@ietfa.amsl.com>; Fri, 5 Jun 2020 08:09:41 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 62D813A078A for <txauth@ietf.org>; Fri, 5 Jun 2020 08:09:41 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id g28so10010455qkl.0 for <txauth@ietf.org>; Fri, 05 Jun 2020 08:09:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id w94sm24521qte.19.2020.06.05.08.09.37 (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 <yaronf.ietf@gmail.com>
To: Justin Richer <jricher@mit.edu>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
CC: "txauth@ietf.org" <txauth@ietf.org>
Message-ID: <3C69EF55-FC4D-44D1-A619-8736936E4E6D@gmail.com>
Thread-Topic: [Txauth] Call for WG name preferences - done!
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3674225378_1658071922"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/I65b74SSfDO2IGJNXkI513462VY>
Subject: Re: [Txauth] Call for WG name preferences - done!
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: 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.

 

Thanks,

                Yaron

 

From: Justin Richer <jricher@mit.edu>
Date: Friday, June 5, 2020 at 17:59
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
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:

 

https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md

 

https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent

 

 

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

 

https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

 

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

 

https://tools.ietf.org/html/draft-ietf-oauth-par

 

https://medium.com/oauth-2/pushed-authorization-requests-draft-adopted-by-oauth-working-group-a1060007150f

 

 

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 <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

 

Prefer:

    * 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
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth