Re: [Txauth] Txauth Digest, Vol 9, Issue 46

[Justin Richer <[e-mail]>]

Yaron,

First, thanks for putting this process forward. While I think it’s strange that the only feedback allowed is either neutral or negative, I can understand what we’re doing in trying to cull the list.

I think there should be a default position that the chairs take if something is left off a list. I don’t think everyone is going to comment on all of them for every response, and the handling of omitted items should be handled clearly and consistently.

Since we have so many options, I would personally opt for omitted items being “object” but without specific reason, which might help cull things from the large choice field.

 — Justin

> On May 20, 2020, at 10:01 AM, Yaron Sheffer <[e-mail]> wrote:
> 
> Hi Fabien,
>  
> Thank you for the detailed response. I’m struggling though with those where you “don’t have a strong opinion”. Should we count them as “wouldn’t object” or are they really “object” and you don’t have a good explanation – which is totally fine.
>  
> Regards,
>                 Yaron
>  
> From: Txauth <[e-mail]> on behalf of Fabien Imbault <[e-mail]>
> Date: Wednesday, May 20, 2020 at 15:26
> To: <[e-mail]>
> Subject: Re: [Txauth] Txauth Digest, Vol 9, Issue 46
>  
> Thanks Yaron, sorry I had missed that. That's great.
> So here I go, of course that's a personal view and explanations should be taken as constructive criticisms.
>  
> Wouldn’t Object: 
> * TxAuth      Transmission of Authority -> seems good to me, even if Tx still makes me think more of transaction. The easiest to remember for me.
> * XAuthZ    eXtensible authoriZation protocol -> I like that AuthZ makes the scope clearer. Maybe a bit hard to pronounce and may look very nerdy to the average user (but I think it's still ok). 
> * GranPro    GRAnt Negotiation Protocol -> seems pretty clear
> Object: 
> * TXAuth    Testable eXtensible Authorization (doesn't seem production ready)
> * TXAuth      Truly eXtensible Authorization (don't know what would be a not truly extensible auth)
> * RefAuthZ    Refactored Authorization Protocol (same idea, refactored compared to what)
> * ReAuthZ    Reimagined Authorization Protocol (same idea)
> * AAuthZ    Alternative Authorization Protocol (same idea)
> * PAuthZ    Protocol for Authorization (too broad)
> * TINOA   This Is Not OAuth (so what?)
> * DIYAuthZ    Do-It-Yourself Authorization Protocol (people don't want DIY auth I think, they want secure stuff)
> * IDPAuthZ    Intent Driven Protocol for Authorization (too close to IDentity Provider)
> For the rest, I don't have strong opinions, it's just that they don't resonate well to me, and I struggle to remember them.
> Fabien
>  
>  
>> 
>> ---------- Forwarded message ----------
>> From: Yaron Sheffer <[e-mail] <mailto:[e-mail]>>
>> To: Fabien Imbault <[e-mail] <mailto:fabien.imbault@gmail..com>>, <[e-mail] <mailto:[e-mail]>>
>> Cc: 
>> Bcc: 
>> Date: Wed, 20 May 2020 14:54:35 +0300
>> Subject: Re: [Txauth] Txauth Digest, Vol 9, Issue 44
>> Hi Fabien,
>>  
>> Please see my email from yesterday for method and calendar.
>>  
>> https://mailarchive.ietf.org/arch/msg/txauth/sxMA2D3xkluRwJJGWcPOck7HlT8/ <https://mailarchive.ietf.org/arch/msg/txauth/sxMA2D3xkluRwJJGWcPOck7HlT8/>
>>  
>> Thanks,
>>                 Yaron
>>  
>> From: Txauth <[e-mail] <mailto:[e-mail]>> on behalf of Fabien Imbault <[e-mail] <mailto:[e-mail]>>
>> Date: Wednesday, May 20, 2020 at 13:38
>> To: <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [Txauth] Txauth Digest, Vol 9, Issue 44
>>  
>> Hi, 
>>  
>> Well, I guess the issue with the poll illustrates quite clearly why we need authorization in systems.
>>  
>> I'm not sure we really need more names right now, the brainstorming produced quite a large set of possibilities (which Nigel evaluated based on some common requirements), from which we need to choose. 
>> My personal opinion is that we need to keep things simple: find a way to decide on a name and start focusing on the specification itself.
>>  
>> Let's see what co-chairs propose in terms of method and calendar. 
>>  
>> Fabien
>>  
>>> 
>>> 
>>> ---------- Forwarded message ----------
>>> From: Nigel Hamilton <[e-mail]>
>>> To: [e-mail] <mailto:[e-mail]>
>>> Cc: 
>>> Bcc: 
>>> Date: Wed, 20 May 2020 06:20:40 +0100
>>> Subject: [Txauth] Name Game (contd)
>>> Hi,
>>>  
>>> It's a bit disappointing that the voting went awry. It's normal to go through a few iterations however.
>>>  
>>> I personally like WRAC - as it is distinctive and the expanded acronym helps to explain what it does. I just want to flag up, however, that there are some potential trademark problems with it. If it had been submitted prior to the first poll - it would have appeared in the lower list and not made the first voting round. 
>>>  
>>> Cheers
>>>  
>>> Nige
>>>  
>>> 
>>> 
>>> 
>>> ---------- Forwarded message ----------
>>> From: David Skaife <[e-mail] <mailto:[e-mail]>>
>>> To: Yaron Sheffer <[e-mail] <mailto:[e-mail]>>
>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>> Bcc: 
>>> Date: Wed, 20 May 2020 10:50:19 +0100
>>> Subject: Re: [Txauth] Call for WG name preferences
>>> Hi Yaron,
>>>  
>>> I think overall the proposed approach is sensible, however, I'm not sure it's a good idea to allow new names to be suggested at the same time as when people are stating which names they would and wouldn't object to. It's going to get very chaotic if new names are being suggested at the same time as this consensus check. Also, what happens if someone suggests a new name a few hours before the deadline giving very little time for people to confirm whether they object to it or not?
>>> 
>>> Would it not be more sensible to draw a line under new name suggestions before we then state our preferences?
>>> 
>>> 
>>> Many thanks,
>>> David Skaife
>>>  
>>> On Tue, May 19, 2020 at 9:34 PM Yaron Sheffer <[e-mail] <mailto:[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/ <https://datatracker.ietf.org/doc/charter-ietf-txauth/>
>>>> [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/ <https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/>
>>>> [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ <https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/>
>>>> 
>>>> 
>>>> -- 
>>>> Txauth mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> 
>>> 
>>> 
>>> ---------- Forwarded message ----------
>>> From: Yaron Sheffer <[e-mail] <mailto:[e-mail]>>
>>> To: David Skaife <[e-mail] <mailto:[e-mail]>>
>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>> Bcc: 
>>> Date: Wed, 20 May 2020 12:57:07 +0300
>>> Subject: Re: [Txauth] Call for WG name preferences
>>> Maybe, but the proposal makes it clear that the default for new names is that we consider everyone to “object” to them unless explicitly told otherwise.. So people will understand that the only way for a name to have a chance is to propose it early in the game.. 
>>>  
>>> Thanks,
>>>                 Yaron
>>>  
>>> From: David Skaife <[e-mail] <mailto:[e-mail]>>
>>> Date: Wednesday, May 20, 2020 at 12:50
>>> To: Yaron Sheffer <[e-mail] <mailto:[e-mail]>>
>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>> Subject: Re: [Txauth] Call for WG name preferences
>>>  
>>> Hi Yaron,
>>>  
>>> I think overall the proposed approach is sensible, however, I'm not sure it's a good idea to allow new names to be suggested at the same time as when people are stating which names they would and wouldn't object to. It's going to get very chaotic if new names are being suggested at the same time as this consensus check.. Also, what happens if someone suggests a new name a few hours before the deadline giving very little time for people to confirm whether they object to it or not?
>>> 
>>> Would it not be more sensible to draw a line under new name suggestions before we then state our preferences?
>>> 
>>> 
>>> Many thanks,
>>> David Skaife
>>>  
>>> On Tue, May 19, 2020 at 9:34 PM Yaron Sheffer <[e-mail] <mailto:[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/ <https://datatracker.ietf.org/doc/charter-ietf-txauth/>
>>>> [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/ <https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/>
>>>> [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ <https://mailarchive..ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/>
>>>> 
>>>> 
>>>> -- 
>>>> Txauth mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> Txauth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>> -- Txauth mailing list [e-mail] <mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>> Txauth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- Txauth mailing list [e-mail] https://www.ietf.org/mailman/listinfo/txauth 
> -- 
> Txauth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>