Re: [Txauth] Call for WG name preferences - process clarification

[Dick Hardt <[e-mail]>]

I was waiting for others to post before I posted, but I'll post now to get
some more conversation going ...


*Would not Object*
* GNAP    Grant Negotiation and Authorization Protocol

- This one is my favorite as it captures what is being the protocol does.
In the OAuth 2.0 and OpenID Connect specifications, the user and
authorization server "grant" something.
Using "grant" as a noun covers both access tokens and user identifiers and
claims, which are all part of the charter[1].
Negotiation is a new feature of this work and covers client / AS
negotiation and client / RO negotiation.


[1] https://datatracker.ietf.org/wg/txauth/about/ proposed charter
introduction sentence, "This group is chartered to develop a fine-grained
delegation protocol for authorization and API access, as well as requesting
and providing user identifiers and claims.",

wrt. pronounciation, it could be gee-nap, guh-nap, or nap (as in gnaw) --
while not ideal, we can teach everyone the pronunciation as was done with
OAuth (which could be pronounced oath rather than o-auth)


* PAuthZ    Protocol for Authorization
* GranPro    GRAnt Negotiation Protocol

- not as good as GNAP, but no objection as they are correct in what is
happening

* XAuthZ    eXtensible authoriZation protocol

Extensibility was not a focus in OAuth 2.0, in contrast to the proposed
charter which explicitly includes extensibility in the work and milestones:

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

* TXAuth    Testable eXtensible Authorization
* TXAuth      Truly eXtensible Authorization

- not as good as XAuthZ as the confusion of AuthZ and AuthN is clarified in
XAuthZ, and Testable and Truly are distracting, but create backronyms for
"txauth".

*Would Object*

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

- these names are descriptive of what work is not rather than what it is

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

- these names make it sound like a hobby and not professional


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

- these names focus on the resource, and ignore the identity aspect of the
work

* BeBAuthZ    Back-end Based Authorization Protocol

- back-end based is a confusing adjective. Could be interpreted to mean
that it is all back channel authorization, which is not correct.

* CPAAP    Comprehensive Privileged Authentication Authorization Protocol

- similar to BeBAuthZ, "Comprehensive" and "Privileged" imply something
other than what is happening
- authentication is not in the charter scope

* TIAAP    Tokenized Identity and Access Protocol

- Not all the identity in this work is tokenized.

* NIRAD    Negotiation of Intent Registration and Authority Delegation
* IDPAuthZ    Intent Driven Protocol for Authorization
* TIDEAuth    Trust via Intent Driven Extension Auth
* TIDYAuth    Trust via Intent Driven Yield Auth
* TIEAuth    Trust via Intent Extension Auth

- All of these use intent in the description. I don't see how Intent is a
descriptive adjective. The word "intent" is not in the charter anywhere.


* TxAuth      Transmission of Authority

- I think this name is misleading. As it is Justin's favorite, I'll
elaborate more than I have on the others ... starting with definitions of
the words:

Transmission:
the action or process of transmitting something or the state of being
transmitted. "the transmission of the virus"

Transmit:
cause (something) to pass on from one place or person to another.

Authority:
a power or right delegated or given; authorization: "Who has the authority
to grant permission?"

Authorization:
the act of authorizing. permission or power granted by an authority;
sanction.

Building on these definitions, "Transmission of Authority" means passing a
power to another person. The power is the ability to authorize.

Someone familiar with a certificate authority (CA), a related area,
"transmission of authority" could mean the CA passing authority to another
entity, which would then be another CA.

Using OAuth terms, the AS has the authority to issue tokens to the client.
The AS is not passing the authority to issue tokens to the client.





   -



ᐧ

On Fri, May 22, 2020 at 3:32 AM Yaron Sheffer <[e-mail]> wrote:

> Thank you David for pointing out the loophole in my previous mail. As a
> result, we have decided to limit the time when new names may be proposed.
> If you have new name ideas, please make sure to share them until 0800 UTC,
> Tuesday, May 26.
>
> All others, if you want to make sure you are commenting on the full name
> list, please hold off until after Monday.
>
> Apologies for the process confusion, we are building it as we go.
>
> Thanks,
>         Yaron
>
> On 5/21/20, 11:53, "Yaron Sheffer" <[e-mail]> wrote:
>
>     Thank you to those who contributed early replies!
>
>     As a refinement/clarification to the process below: we are now
> focusing on discussion and making sure there are no strong objections,
> rather than voting on people's favorite name.
>
>     With that in mind, we strongly encourage people to attach an
> explanation to each name they object to. Therefore for names that are on
> neither of your lists ("wouldn't object to" and "object to"), our default
> assumption is that you would NOT object to them.
>
>     With the process now finalized, please take a few minutes and provide
> us with your name lists. As a reminder, the deadline is 0800 UTC June 4,
> 2020.
>
>     Thanks,
>         Yaron
>
>
>     On 5/19/20, 23:34, "Yaron Sheffer" <[e-mail]> wrote:
>
>         Hi!
>
>         After reviewing the community feedback and discussions with the
> AD, we’d like to again launch a process to elicit feedback on naming.  Our
> proposal is below.  We’d appreciate any clarifying questions, proposed
> improvements or objections by 0800 UTC, Thursday, May 21st .
>
>         Thanks,
>                 Yaron and Dick
>
>         PS, I’m sharing the load with Dick and taking point on this
> consensus call -- Yaron
>
>         ----
>
>         Before we submit the draft charter [1] to the IESG, we wanted to
> explore the name of the group. During the chartering discussions, some
> people objected to the BoF name being the WG name.  We’d like to get
> consensus on what the WG name should be.  Our first attempt to elicit input
> [2] wasn’t successful, and this is a second attempt to get consensus from
> the community.
>
>         To get to consensus, we want to gather preferences on the
> currently known WG name candidates. Our goal is not to select the most
> popular name -- it is to select a name everyone can live with and ensure
> that we understand and weigh any objections there might be with that
> choice.  To that end, we’d like to elicit your name preferences in the
> following way:
>
>          (1) In previous discussions, the following candidate names have
> been voiced (we have listed only these names that received at least one
> vote previously):
>
>         * AAuthZ    Alternative Authorization Protocol (AAuthZ)
>         * AZARP    AuthoriZed Access to Resources Protocol
>         * AZARAP    AuthoriZation And Resource Access Protocol
>         * BeBAuthZ    Back-end Based Authorization Protocol
>         * BYOAuthZ    Build-Your-Own Authorization Protocol
>         * CPAAP    Comprehensive Privileged Authentication Authorization
> Protocol
>         * DAZARAP    Delegated AuthoriZation And Resource Access Protocol
>         * DIYAuthZ    Do-It-Yourself Authorization Protocol
>         * GNAP    Grant Negotiation and Authorization Protocol
>         * GranPro    GRAnt Negotiation Protocol
>         * IDPAuthZ    Intent Driven Protocol for Authorization
>         * NIRAD    Negotiation of Intent Registration and Authority
> Delegation
>         * PAuthZ    Protocol for Authorization
>         * RefAuthZ    Refactored Authorization Protocol
>         * ReAuthZ    Reimagined Authorization Protocol
>         * TIAAP    Tokenized Identity and Access Protocol
>         * TIDEAuth    Trust via Intent Driven Extension Auth
>         * TIDYAuth    Trust via Intent Driven Yield Auth
>         * TIEAuth    Trust via Intent Extension Auth
>         * TINOA   This Is Not OAuth
>         * TXAuth    Testable eXtensible Authorization
>         * TxAuth      Transmission of Authority
>         * TXAuth      Truly eXtensible Authorization
>         * XAuthZ    eXtensible authoriZation protocol
>
>         We would ask that you consider these names, and respond to the
> list with your selection of the following two categories:
>
>         * “Wouldn’t Object” -- this is not necessarily your preferred
> name, but you would be comfortable with it being the name of the WG (choose
> as many names as you want)
>         * “Object” -- you would be uncomfortable with the WG being named
> in this way (choose as many names as you want; please provide an
> explanation)
>
>         (2) If your preferred name isn’t in the list per (1), you can send
> a note to the mailing list stating that you’d like the WG to consider a new
> name.  Please ensure the name adheres to the previously discussed naming
> criteria at [3]. We still request that you provide your other preferences
> and objections.
>
>         (3) If you previously sent in your preferences, but a new name
> suggestion or someone’s objection changed your mind, then send another
> message to the mailing list with your revised preferences.  For the
> purposes of consensus, we’ll assume that everyone who hasn’t commented on a
> new name introduced per (2) “objects” to it (i.e., we want to hear positive
> confirmation of preference on new names).
>
>         (4) Please provide your input by 0800 UTC June 4, 2020.
>
>         With that input, our plan is to assess rough consensus in the
> following way:
>
>         (a) See if there is consensus for a name identified given the
> “wouldn’t object to being the WG name” preference and the level of “would
> object” feedback
>
>         (b) If there isn’t clear consensus with (a), but a significantly
> reduced set of candidates around which there is enthusiasm, the chairs will
> share the results and request feedback
>
>         (c) If rough consensus appears to be reached through steps (a) –
> (b), revisit the objections to this candidate name, elicit additional
> objections and see if they change the consensus.
>
>         Regards,
>                 Yaron and Dick
>
>         [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/
>         [2]
> https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/
>         [3]
> https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/
>
>
>
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>