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

[Dick Hardt <[e-mail]>]

No surprise that you don't think it is misleading, as you did not think
that transaction was misleading.

While one way of interpreting "Transmission of Authority" is as you
describe, I think that for others an "authority" is who can make
assertions, which is what the AS does, and is what a Certificate Authority
does. The client uses those assertions, just as a server uses a TLS
certificate.

Using the movie ticket analogy, where the movie ticket is a bearer token,
the ticket holder does not think they have any "authority" to access the
movie, they think they have been granted access to the movie.






ᐧ

On Wed, Jun 3, 2020 at 5:27 AM Justin Richer <[e-mail]> wrote:

> I wanted to provide feedback on this point specifically:
>
>
> * 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.
>
>
> I think you’ve got an odd twist of the words in your interpretation here.
> The authority is embodied in the access token, the result of the delegation
> process. This authority is transmitted from the RO through the AS to the
> client, via the token. I don’t think it at all implies that the AS is
> transmitting authority to issue tokens. If that’s an issue with this name,
> then it should also be an issue with any suggestion with “Grant” in the
> name because it could imply that the AS is granting the client authority to
> make its own tokens, by the same leap of logic.
>
> It’s very important to see that the AS holds authority only in trust from
> the resource owner, who has the actual power to grant authority. The
> transmission of authority in OAuth as in our proposed work is from the
> resource owner to the client, embodied by the access token issued by the
> AS. It’s from a party with authority, normally a user but sometimes not, to
> a piece of software — not another user directly. This is the core of the
> entire “grant” concept.
>
> It isn’t misleading at all.
>
>  — Justin
>
> ᐧ
>
> 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
>>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>