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

[Dick Hardt <[e-mail]>]

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]
https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/



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

> 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 <[e-mail]> 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
> - 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/
>
> [image: image.gif]
>
>
>
>
> ᐧ
>
> On Thu, May 28, 2020 at 2:47 PM Justin Richer <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> ᐧ