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

From: Justin Richer <[email-masked]>
Date: Tue, 2 Jun 2020 09:17:56 -0400

Hi everyone, I just wanted to remind the community that feedback on the potential names is needed by the chairs by this Thursday, June 4th. Please post your comments to the list before then!

Remember, they’re looking for feedback in the form of “wouldn’t object” and “would object”, and all objections should have specific reasons.

 — Justin

> On May 28, 2020, at 5:47 PM, Justin Richer <[email-masked]> wrote:
> 
> Thanks to everyone in the community for suggesting names, and thanks to the chairs for putting this list together.
> 
> Here’s my personal take on the candidates.
> 
> 
> 
> Wouldn’t Object:
> 
> * TxAuth      Transmission of Authority
> 	This is my personal favorite of the lot because it avoids the “authorization/authentication” question and gets at the heart of what this protocol does: delegation, which is to say, transmitting the authority to do something from one party to another. That delegation allows for authorized access to resources, but can also allow different rights to flow as needed. Additionally, “tx” has long been used to stand for “transmission” in computer science and networking.
> 
> * AZARP    AuthoriZed Access to Resources Protocol
> 	The use of “AZ” to stand for “authorized” is awkward, but the pronunciation kinda works as something memorable. The expansion is a twist of words to make it fit, and I like that less.
> 	Resource access is only part of the story, but it’s an important part. This leaves out what we want to do around non-authorization cases (like identity conveyance).
> 
> * AZARAP    AuthoriZation And Resource Access Protocol
> 	I like the expansion here more than the one for AZARP but I like the acronym less with the additional “A”.
> 	Same comment as above for AZ standing for Authorization.
> 	Same comment as above for resource access.
> 
> * DAZARAP    Delegated AuthoriZation And Resource Access Protocol
> 	I like the expansion here, but the acronym is awkward and weak. 
> 	Same comment as above for AZ standing for Authorized.
> 	Same comment as above for resource access.
> 
> * GNAP    Grant Negotiation and Authorization Protocol
> 	This is ok, but it has a couple downsides. The pronunciation of a hard “g” or not is going to potentially be confusing, as is the fact that it looks like it’s part of the GNU project because of that.
> 	The term “Grant” is one of the more confusing things that was introduced in OAuth 2, and while it’s established in the lexicon today, I’ve yet to meet many engineering teams that actually know what a “grant” is. Most think it’s another name for the authorization code.
> 	Also it means “to bite”, which may or may not be desirable.
> 
> * NIRAD    Negotiation of Intent Registration and Authority Delegation
> 	This is a somewhat weak construct, but it mostly works. It spells out more what the protocol will do (if we go with the currently proposed solution designs) than what it solves, but that might be ok.
> 	It makes me think of NORAD (a positive, they do weather radar and track Santa Claus each year), but also “nimrod”, a pejorative term. And before anyone chimes in with “But Nimrod was a mighty hunter of ancient times”, it doesn’t mean that to any modern listener.
> 
> * GATAR      Grant Authorization To Access Resources 
> 	This one isn’t bad, and I can appreciate the “guitar” pronunciation and imagery. As above, resource access isonly part of the story.
> 	Same comment about “Grant” as above in GNAP.
> 
> 
> 
> Object:
> 
> * AAuthZ    Alternative Authorization Protocol (AAuthZ)
> 	It’s an alternative to what, exactly? And what happens when someone makes an alternative to it?
> 	The focus on “Authorization” as a core part of the name tells only part of the story. 
> 	Assuming the “Z” is pronounced as its letter name (which is implied by the capitalization), there’s an issue with pronouncing the final “Z” as either “Zee” or “Zed” depending on dialect. If it’s not pronounced as a letter, it’s really difficult to say the consonants “thz" together in a way that can be heard and understood.
> 
> * BeBAuthZ    Back-end Based Authorization Protocol
> 	The definition of “back end” is going to change depending on your perspective in the stack, but even if it were consistent, the flexibility around user interaction is a huge motivator for many getting involved in this work.
> 	This is close to “BBAuth”, which was a commercial predecessor to OAuth 1, so much that it’s nearly impossible to disambiguate when talking.
> 	Same comment as above focus on Authorization.
> 	Same comment as above about Zed/Zee confusion.
> 
> * BYOAuthZ    Build-Your-Own Authorization Protocol
> 	This is the opposite of what we’re doing here. We don’t want a bunch of disparate pieces that people can use to build a protocol, we want a protocol with the right kind of flexibility to fit different use cases. This name tells developers that they aren’t getting a solution and incompatibility is likely.
> 	Same comment as above focus on Authorization.
> 	Same comment as above about Zed/Zee confusion.
> 
> * CPAAP    Comprehensive Privileged Authentication Authorization Protocol
> 	This makes me think of CPAP, a breathing assistance device. Not something I’m keen to call to mind in the middle of a global pandemic of a respiratory disease.
> 	The expansion doesn’t really tell me anything.
> 	What does “privileged” mean here, and does it apply to the authentication (which seems implied)?
> 
> * DIYAuthZ    Do-It-Yourself Authorization Protocol
> 	As above in BYOAuthZ, this is the opposite of what we’re trying to do by creating a standard. 
> 	Same comment as above focus on Authorization.
> 	Same comment as above about Zed/Zee confusion.
> 
> * GranPro    GRAnt Negotiation Protocol
> 	The acronym is a really awkward construction. 
> 	As above, “grant” is an often misunderstood term from OAuth 2. Plus, the “grant” isn’t really what’s being negotiated here.
> 
> * IDPAuthZ    Intent Driven Protocol for Authorization
> 	“IDP” is already well understood in this space to mean “identity provider”, so we should not try to overload it.
> 	Same comment as above focus on Authorization.
> 	Same comment as above about Zed/Zee confusion.
> 
> * PAuthZ    Protocol for Authorization
> 	It was suggested this would be pronounced “paws” but I can’t think of a single reason someone looking at the word would try to pronounce it that way. 
> 	It’s also completely generic and doesn’t say anything about the work.
> 	Same comment as above focus on Authorization.
> 	Same comment as above about Zed/Zee confusion.
> 
> * RefAuthZ    Refactored Authorization Protocol
> 	Refactored from what? What if someone refactors this? What are the factors?
> 	Same comment as above focus on Authorization.
> 	Same comment as above about Zed/Zee confusion.
> 
> * ReAuthZ    Reimagined Authorization Protocol
> 	The short form is already a short term for “re-authorization”, which is not what we are doing.
> 	Reimagined from what, and by whom?
> 	The expansion sounds like it’s imaginary and not real.
> 	Same comment as above focus on Authorization.
> 	Same comment as above about Zed/Zee confusion.
> 
> * TIAAP    Tokenized Identity and Access Protocol
> 	I don’t think “tokenized” is used in a meaningful way here. It produced “tokens”, but tokenization is the splitting up of an input into pieces, which is not what’s happening here.
> 
> * TIDEAuth    Trust via Intent Driven Extension Auth
> 	The expansion is really awkward.
> 	It sounds like it’s an extension to an existing protocol (something that we are explicitly NOT doing per the charter).
> 	
> * TIDYAuth    Trust via Intent Driven Yield Auth
> 	I actually really like the acronym but the expansion is super awkward. What is being yielded here?
> 
> * TIEAuth    Trust via Intent Extension Auth
> 	What is “intent extension”? 
> 	As above, it sounds like an extension not a protocol.
> 
> * TINOA   This Is Not OAuth
> 	This says nothing about what this work is, only what it isn’t. And on that regard, it doesn’t matter that this isn’t OAuth. OAuth 2 isn’t OAuth 1, either. 
> 	And given that ease of transition from OAuth 2 is part of the charter, this isn’t a helpful distinction.
> 
> * TXAuth    Testable eXtensible Authorization
> 	I don’t get the focus on “testable” in the name. Testable in what way? Can other protocols not be tested?
> 	Extensibility is not a differentiating feature of this work.
> 
> * TXAuth      Truly eXtensible Authorization
> 	Extensibility is not a differentiating feature of this work.
> 	What makes something “truly extensible” as opposed to “not truly extensible”?
> 
> * XAuthZ    eXtensible authoriZation protocol
> 	Extensibility is not a differentiating feature of this work.
> 	The acronym is just pulling random letters from the middle of words in the expansion to try to work.
> 	Same comment as above focus on Authorization.
> 	Same comment as above about Zed/Zee confusion.
> 
> * WRAC     Web Resource Access Collaboration
> 	This is not a collaboration protocol or system. Collaboration, within computer science, is established to refer to when two or more :people: work and communicate together. This protocol does not facilitate human communication, and so the use of this term is not appropriate here. 
> 	This is very close to “wrack” which is a common enough English verb, as in “wracked nerves” or “to wrack one’s brain”, which derives from the medieval torture process of stretching someone over a rack. This 
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 3 Jun 2020 01:57:26 +0900

While there is some good point to your critique to GNAP, I still seem to
like it, partly because I grew up in the country where gnu migration
happens every summer, and especially because we need to establish Grant as
the properly understood term in relation to OAuth.

Best,

Nat

On Tue, Jun 2, 2020 at 10:18 PM Justin Richer <[email-masked]> wrote:

> Hi everyone, I just wanted to remind the community that feedback on the
> potential names is needed by the chairs by this Thursday, June 4th. Please
> post your comments to the list before then!
>
> Remember, they’re looking for feedback in the form of “wouldn’t object”
> and “would object”, and all objections should have specific reasons.
>
>  — Justin
>
> Thanks to everyone in the community for suggesting names, and thanks to
> the chairs for putting this list together.
>
> *Wouldn’t Object:*
> This is my personal favorite of the lot because it avoids the
> “authorization/authentication” question and gets at the heart of what this
> protocol does: delegation, which is to say, transmitting the authority to
> do something from one party to another. That delegation allows for
> authorized access to resources, but can also allow different rights to flow
> as needed. Additionally, “tx” has long been used to stand for
> “transmission” in computer science and networking.
>
> The use of “AZ” to stand for “authorized” is awkward, but the
> pronunciation kinda works as something memorable. The expansion is a twist
> of words to make it fit, and I like that less.
> Resource access is only part of the story, but it’s an important part.
> This leaves out what we want to do around non-authorization cases (like
> identity conveyance).
>
> This is ok, but it has a couple downsides. The pronunciation of a hard “g”
> or not is going to potentially be confusing, as is the fact that it looks
> like it’s part of the GNU project because of that.
> The term “Grant” is one of the more confusing things that was introduced
> in OAuth 2, and while it’s established in the lexicon today, I’ve yet to
> meet many engineering teams that actually know what a “grant” is. Most
> think it’s another name for the authorization code.
> This is a somewhat weak construct, but it mostly works. It spells out more
> what the protocol will do (if we go with the currently proposed solution
> designs) than what it solves, but that might be ok.
> It makes me think of NORAD (a positive, they do weather radar and track
> Santa Claus each year), but also “nimrod”, a pejorative term. And before
> anyone chimes in with “But Nimrod was a mighty hunter of ancient times”, it
> doesn’t mean that to any modern listener.
>
> This one isn’t bad, and I can appreciate the “guitar” pronunciation and
> imagery. As above, resource access isonly part of the story.
> *Object:*
> Assuming the “Z” is pronounced as its letter name (which is implied by the
> capitalization), there’s an issue with pronouncing the final “Z” as either
> “Zee” or “Zed” depending on dialect. If it’s not pronounced as a letter,
> it’s really difficult to say the consonants “thz" together in a way that
> can be heard and understood.
>
> The definition of “back end” is going to change depending on your
> perspective in the stack, but even if it were consistent, the flexibility
> around user interaction is a huge motivator for many getting involved in
> this work.
> This is close to “BBAuth”, which was a commercial predecessor to OAuth 1,
> so much that it’s nearly impossible to disambiguate when talking.
> This is the opposite of what we’re doing here. We don’t want a bunch of
> disparate pieces that people can use to build a protocol, we want a
> protocol with the right kind of flexibility to fit different use cases.
> This name tells developers that they aren’t getting a solution and
> incompatibility is likely.
> This makes me think of CPAP, a breathing assistance device. Not something
> I’m keen to call to mind in the middle of a global pandemic of a
> respiratory disease.
> As above, “grant” is an often misunderstood term from OAuth 2. Plus, the
> “grant” isn’t really what’s being negotiated here.
>
> “IDP” is already well understood in this space to mean “identity
> provider”, so we should not try to overload it.
> It was suggested this would be pronounced “paws” but I can’t think of a
> single reason someone looking at the word would try to pronounce it that
> way.
> I don’t think “tokenized” is used in a meaningful way here. It produced
> “tokens”, but tokenization is the splitting up of an input into pieces,
> which is not what’s happening here.
>
> It sounds like it’s an extension to an existing protocol (something that
> we are explicitly NOT doing per the charter).
>
> This says nothing about what this work is, only what it isn’t. And on that
> regard, it doesn’t matter that this isn’t OAuth. OAuth 2 isn’t OAuth 1,
> either.
> This is not a collaboration protocol or system. Collaboration, within
> computer science, is established to refer to when two or more :people: work
> and communicate together. This protocol does not facilitate human
> communication, and so the use of this term is not appropriate here.
> This is very close to “wrack” which is a common enough English verb, as in
> “wracked nerves” or “to wrack one’s brain”, which derives from the medieval
> torture process of stretching someone over a rack. This
>
> --
> Txauth mailing list
> [email-masked]

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Dick Hardt <[email-masked]>
Date: Tue, 2 Jun 2020 14:58:46 -0700

Hey Justin,

Per your comment "Extensibility is not a differentiating feature of this
work.", extensibility is explicitly called out in the charter (and is not
in the OAuth WG charter):

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

[1] https://datatracker.ietf.org/wg/txauth/about/
ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Tue, 2 Jun 2020 14:58:37 -0700

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

*Would not Object*

- 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)

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

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

Milestones to include:
<snip>

- 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*

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

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

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

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

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

- Not all the identity in this work is tokenized.

- 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.

- 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 <[email-masked]> 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" <[email-masked]> 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" <[email-masked]> 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):
>
>         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
> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Wed, 3 Jun 2020 08:19:07 -0400

Hi Dick,

Yes, I am pretty familiar with the charter text, but thank you for posting it to the group as a reminder.

The original charter text for the OAuth WG[1] does in fact call out extensibility explicitly in several places, including:

The Working Group will produce one or more documents
suitable for consideration as Proposed Standard that will:
 ...
* Provide guidelines for extensibility.

The difference here is that we’re being more explicit about what is extensible and how, in the charter. But one of the biggest innovations in OAuth 2, as I’m sure you know, is that it allowed for explicit extensibility in ways that OAuth 1 did not: grant types, token types, scopes (and therefore resource types), client auth types (and therefore client types), etc. The very fact that OAuth 2 is a *framework* fundamentally speaks to its goals of extensibility. 

The TxAuth charter text that you quoted carries much of that tradition forward, which is why I said that extensibility is not a :defining: feature of this work. It’s absolutely a feature and an important one, but extensibility itself is hardly new or unique as a goal. What’s unique is :what: we’re targeting for extensibility points, which is why those are listed below in the proposed charter text.

I also worry that a focus on ‘extensibility’ above all else will slide us back into the world of incompatible framework pieces. As the proposed charter also states that we’re building a protocol, not a framework, this is counter to what we’re coming together for.

 — Justin

[1] https://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2009-05-13.txt

> On Jun 2, 2020, at 5:58 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hey Justin,
> 
> Per your comment "Extensibility is not a differentiating feature of this work.", extensibility is explicitly called out in the charter (and is not in the OAuth WG charter):
> 
> 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
> - 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>
> [1] https://datatracker.ietf.org/wg/txauth/about/ <https://datatracker.ietf.org/wg/txauth/about/>
> ᐧ
> 
> On Thu, May 28, 2020 at 2:47 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Justin Richer <[email-masked]>
Date: Wed, 3 Jun 2020 08:27:51 -0400

I wanted to provide feedback on this point specifically:

> - 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: 
> 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 <[email-masked] <mailto:[email-masked]>> 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.
> 
> On 5/21/20, 11:53, "Yaron Sheffer" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     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" <[email-masked] <mailto:[email-masked]>> 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):
> 
>         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).
> 
>         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

---

From: Steinar Noem <[email-masked]>
Date: Wed, 3 Jun 2020 14:36:55 +0200

Regarding the word "transmission":
I'm norwegian - so I often find it difficult to detect nuances in the
english language :)
I also know that the time for new suggestions has passed. But I wonder,
would "Transferral" be a better word in this case?

S

ons. 3. jun. 2020 kl. 14:28 skrev Justin Richer <[email-masked]>:

> 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.
>
>>         (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.
>>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no |

---

From: Justin Richer <[email-masked]>
Date: Wed, 3 Jun 2020 09:01:47 -0400

I think “Transferral” would have been fine to communicate the concept, but I was looking for something that more naturally went with “tx” since Dick has said he would be fine with a different expansion of “Tx” in the name “TxAuth”. Using “tx” to mean “transmission” or “transmitter” is even more common in computer science than using “tx" to mean “transaction”, and there you see it along side “rx” to mean “receiver” or “reception”. 

 — Justin

> On Jun 3, 2020, at 8:36 AM, Steinar Noem <[email-masked]> wrote:
> 
> I'm norwegian - so I often find it difficult to detect nuances in the english language :) 
> I also know that the time for new suggestions has passed. But I wonder, would "Transferral" be a better word in this case?   
> 
> S
> 
> ons. 3. jun. 2020 kl.. 14:28 skrev Justin Richer <[email-masked] <mailto:[email-masked]>>:
> | [email-masked] <mailto:[email-masked]> | [email-masked] <mailto:[email-masked]>  | +47 955 21 620 <> | www.udelt.no <http://www.udelt.no/> | 
> -- 
> Txauth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Jun 2020 09:24:39 -0700

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.

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Jun 2020 09:25:12 -0700

Justin

Your objection to extensibility is:

"Extensibility is not a differentiating feature of this work."

I don't see "differentiating feature"  in our selection criteria[1],

We do have the following selection criteria:

"4. Descriptive of protocol"

And given how we are explicit in the extensibility, I would consider it
descriptive of the protocol.

As to the original OAuth 1.0 charter (which talks about extending OAuth 1.0
to create OAuth 1.1), extensibility was not a focus area, and
definitely was not a major consideration in creating OAuth 2.0. I think
careful considerations of extension points will allow this work to be a
protocol rather than a framework, not the other way around. As an example,
in the current XAuth document, both the authorization and claims objects
contain name spaced schemas so that the protocol can be extended with other
schemas than the original schemas. For example, there are other schemas for
identity claims than what is in OpenID Connect.

[1]

On Wed, Jun 3, 2020 at 5:19 AM Justin Richer <[email-masked]> wrote:

> The original charter text for the OAuth WG[1] does in fact call out
> extensibility explicitly in several places, including:
>
> The difference here is that we’re being more explicit about what is
> extensible and how, in the charter. But one of the biggest innovations in
> OAuth 2, as I’m sure you know, is that it allowed for explicit
> extensibility in ways that OAuth 1 did not: grant types, token types,
> scopes (and therefore resource types), client auth types (and therefore
> client types), etc. The very fact that OAuth 2 is a *framework*
> fundamentally speaks to its goals of extensibility.
>
> The TxAuth charter text that you quoted carries much of that tradition
> forward, which is why I said that extensibility is not a :defining: feature
> of this work. It’s absolutely a feature and an important one, but
> extensibility itself is hardly new or unique as a goal. What’s unique is
> :what: we’re targeting for extensibility points, which is why those are
> listed below in the proposed charter text.
>
> I also worry that a focus on ‘extensibility’ above all else will slide us
> back into the world of incompatible framework pieces. As the proposed
> charter also states that we’re building a protocol, not a framework, this
> is counter to what we’re coming together for.
>
>  — Justin
>
> [1]
> https://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2009-05-13.txt
>
> - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
>> This is ok, but it has a couple downsides. The pronunciation of a hard
>> “g” or not is going to potentially be confusing, as is the fact that it
>> looks like it’s part of the GNU project because of that.
>> This is a somewhat weak construct, but it mostly works. It spells out
>> more what the protocol will do (if we go with the currently proposed
>> solution designs) than what it solves, but that might be ok.
>> Assuming the “Z” is pronounced as its letter name (which is implied by
>> the capitalization), there’s an issue with pronouncing the final “Z” as
>> either “Zee” or “Zed” depending on dialect. If it’s not pronounced as a
>> letter, it’s really difficult to say the consonants “thz" together in a way
>> that can be heard and understood.
>>
>> This says nothing about what this work is, only what it isn’t. And on
>> that regard, it doesn’t matter that this isn’t OAuth. OAuth 2 isn’t OAuth
>> 1, either.
>> This is very close to “wrack” which is a common enough English verb, as
>> in “wracked nerves” or “to wrack one’s brain”, which derives from the
>> medieval torture process of stretching someone over a rack. This
>>
>> --
>> Txauth mailing list
>> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Wed, 3 Jun 2020 15:36:44 -0400

My objection is that it is not a sufficient description of the work. Please understand that I agree that extensibility is important, as it’s been built into XYZ across all of the various dimensions in our proposed charter from the project’s inception. However, there’s a lot more going on here and I don’t thing simply saying it’s “extensible” is any more helpful than saying it’s “new”. OAuth 2 is already pretty extensible, and people are extending it today to do a lot of important things. I don’t agree with you that extensibility was not a design factor in OAuth 2, either.

 — Justin

> On Jun 3, 2020, at 12:25 PM, Dick Hardt <[email-masked]> wrote:
> 
> Justin
> 
> And given how we are explicit in the extensibility, I would consider it descriptive of the protocol. 
> 
> As to the original OAuth 1.0 charter (which talks about extending OAuth 1.0 to create OAuth 1.1), extensibility was not a focus area, and definitely was not a major consideration in creating OAuth 2.0. I think careful considerations of extension points will allow this work to be a protocol rather than a framework, not the other way around. As an example, in the current XAuth document, both the authorization and claims objects contain name spaced schemas so that the protocol can be extended with other schemas than the original schemas. For example, there are other schemas for identity claims than what is in OpenID Connect.
> 
> 
> 
> [1] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ <https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/>
> 
> 
> 
> On Wed, Jun 3, 2020 at 5:19 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Dick,
> 
> [1] https://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2009-05-13.txt <https://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2009-05-13.txt>
> 
>> On Jun 2, 2020, at 5:58 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hey Justin,
>>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Jun 2020 15:40:54 -0700

The criteria is not "sufficiently descriptive of the work", it is
"descriptive of the work".

wrt. your comment: "I don’t agree with you that extensibility was not a
design factor in OAuth 2, either."

I did not say that, I said:

"was not a *major* consideration in creating OAuth 2.0"
Of course it was a consideration, but extensibility did not have the
prominence it has in the proposed charter.

Having said all of that, I don't think "extensible" is the best adjective
for the work, but I don't think it is objectionable per the criteria.[image:
image.gif]

On Wed, Jun 3, 2020 at 12:36 PM Justin Richer <[email-masked]> wrote:

> My objection is that it is not a *sufficient* description of the work.
> Please understand that I agree that extensibility is important, as it’s
> been built into XYZ across all of the various dimensions in our proposed
> charter from the project’s inception. However, there’s a lot more going on
> here and I don’t thing simply saying it’s “extensible” is any more helpful
> than saying it’s “new”. OAuth 2 is already pretty extensible, and people
> are extending it today to do a lot of important things. I don’t agree with
> you that extensibility was not a design factor in OAuth 2, either.
>
>  — Justin
>
> As to the original OAuth 1.0 charter (which talks about extending OAuth
> 1.0 to create OAuth 1.1), extensibility was not a focus area, and
>>> This is close to “BBAuth”, which was a commercial predecessor to OAuth
>>> 1, so much that it’s nearly impossible to disambiguate when talking.
>>> This makes me think of CPAP, a breathing assistance device. Not
>>> something I’m keen to call to mind in the middle of a global pandemic of a
>>> respiratory disease.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 04 Jun 2020 11:08:48 +1000

I'm just gonna do objections. I object to:

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

F&$^ no. If I wanted an abstract toolkit factory protocol interface, I'd go get OAuth2. Can we please pretty please focus on building an interoperable thing rather than a framework. Starting with a name that doesn't scream "framework".

*RefAuthZ* Refactored Authorization Protocol
*ReAuthZ* Reimagined Authorization Protocol

Re* sucks for a long term name.

*TINOA* This Is Not OAuth

"This is not" sucks for a long term name.
*
*
*WRAC* Web Resource Authorization Collaboration

I'd prefer not to explicitly be "web" because that's an environment constraint which suggests this won't be useful to non-web protocols.

*XAuthZ* eXtensible authoriZation protocol

Feels like it needs "Y" in there somewhere to collect the set of late-alphabet letters.

Mostly I'm only posting this because I know it sucks to not get feedback, and there have only been a few responses. To be honest though, which choice we make matters a lot less than making a choice. There's a meta thing about standards in general here and trying to please everybody by making everything optional and configurable to the point where nothing interoperates. Ho hum.

Bron.

On Fri, May 22, 2020, at 20:32, Yaron Sheffer wrote:
>  [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/
>  [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/
> 
> 
> 
> 
> -- 
> Txauth mailing list
> [email-masked]

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Mike Varley <[email-masked]>
Date: Thu, 4 Jun 2020 13:07:08 +0000

Hi all, here is my list:

Won’t Object:

GNAP
TIDYAuth
TxAuth/TXAuth

Object:
BeBauthZ (pronunciation)
CPAAP (medical device)
BYOAuthZ (‘bring-your-own-protocol is more like ‘no protocol’)
AZARAP/DAZARAP (pronunciation)
DIYAuthZ (like BYO- implies there is no structure)
PAuthZ (pronunciation – if we want PAUZ that would be ok)
RefAuthZ/ ReAuthZ (what would we call OAuth 4? 5? Everything is a refactor…)
XAuthZ (like it on paper, but pronunciation is struggle)

Thanks,

MV

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.