Re: [Txauth] Call for WG name preferences

Justin Richer <jricher@mit.edu> Fri, 05 June 2020 14:59 UTC

Return-Path: <jricher@mit.edu>
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 E9AF73A0812 for <txauth@ietfa.amsl.com>; Fri, 5 Jun 2020 07:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kFd9aeHA_vFz for <txauth@ietfa.amsl.com>; Fri, 5 Jun 2020 07:59:13 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CED3A07E6 for <txauth@ietf.org>; Fri, 5 Jun 2020 07:59:10 -0700 (PDT)
Received: from [192.168.1.14] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 055Ex6gn021007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Jun 2020 10:59:07 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <1E2C45F5-3879-47ED-BDAD-5C3271D70D78@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_334B113E-F7C9-4326-B871-121A2BC00A11"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 5 Jun 2020 10:59:06 -0400
In-Reply-To: <CH2PR00MB0678F2BD3C70191D28A639E5F5890@CH2PR00MB0678.namprd00.prod.outlook.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
References: <9FD428B4-F3C1-426B-9677-611F5FEC85C8@gmail.com> <CH2PR00MB0678F2BD3C70191D28A639E5F5890@CH2PR00MB0678.namprd00.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/ZaZ3i6m9N_AYj9fxZLBiOdjdrgc>
Subject: Re: [Txauth] Call for 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: Fri, 05 Jun 2020 14:59:16 -0000

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/src/master/Financial_API_Lodging_Intent.md>

https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent <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 <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://tools.ietf.org/html/draft-ietf-oauth-par>

https://medium.com/oauth-2/pushed-authorization-requests-draft-adopted-by-oauth-working-group-a1060007150f <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 <mailto:Txauth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>