Re: [Txauth] name process

[Dick Hardt <[e-mail]>]

Hi Simon

I'm a big fan of the PR process having spent time at Amazon, but I think
that protocol adoption will come from solving the communities problems
significantly better than existing protocols. The name may get in the way
of people understanding what the protocol solves (hence not having
"transactional" in the name).

OAuth 2 was not compatible with OAuth 1, so I don't think compatibility is
a requirement. OAuth 2 solved the same problems as OAuth 1, but with
additional features.

There does seem to be rough consensus that calling it OAuth 3 would be
confusing as this work is broader in scope that OAuth 1 or OAuth 2.

I agree that "Auth" part of the name is confusing as it could be
authorization or authentication. I lost that naming battle a long time ago
though, and most people understand it is authorization, although many do
think it is for authentication. Having said that, the "auth" aspect is the
most recognizable part of the OAuth brand.

Let's see what we get in the name brainstorming ...



On Fri, Apr 24, 2020 at 1:00 AM Simon Moffatt <[e-mail]>
wrote:

> FWIW, my 2c on naming things in general.
>
> The first thing the 101 book of new product/campaign/solutions creation
> would say, is to write the launch press release of the thing you're
> creating.  That might seem counter-intuitive, but does a few things.
> Articulates to a team what you're *aiming to achieve*, helps you
> *visualize* and more importantly, helps a team generate a *"not to do"*
> list. If the item doesn't help with delivering the items in press release,
> park them.
>
> That press release will contain salient points: *who* are you helping
> with *what*, and *why* you're the best at doing it. If you have that, you
> retro fit the name to fit a) target audience b) value proposition.
>
> When it comes to naming, I guess there seems to be a few conflicting
> techniques being used. AFAIK, "Txauth" is not backwards compatible with
> OAuth2. So any naming would need to indicate independence in order to build
> trust and understanding.
>
> As an orthogonal point always seems odd to me to use a placeholder like "
> oauth.xyz" which looks incompatible with OAuth2. Isn't that a bit like an
> alien trying to make a drink with baked beans instead of coffee beans?
>
> The generic use of the "*auth*" could also be seen to pre-loaded.
> Authentication vendors as well as authorization vendors have jumped on this
> bandwagon rightly and wrongly. They have bizdev to worry about, but the
> point being, that anyone sees the word "auth" in either connotation, is
> going to have a set of unmovable biases.
>
> Is that something you want to compete with? What is authentication? What
> is authorization? That is a transaction? What is transactional
> authorization?
>
> The process seems to be going down two routes - "same, but different"
> somethingAuth or authSomething, in an attempt to attract interest from
> existing practitioners.
>
> Alternatively, you go down the island naming route (entirely different,
> isolated, catchy) - different and potentially back by an acronym.
>
> SM
>
>
>
> On 24/04/2020 5:35 am, Dick Hardt wrote:
>
> Here is proposed naming process. Feel free to provide feedback and
> suggestions. Again, if you don't care, then also feel free to opt out of
> participating!
>
> 1. agree on criteria / metrics for name
>
> Nigel posted some metrics that the Perl community used for the replacement
> to Perl 6. That seems like a good place to start
>
> I'll post another thread with the metrics.
>
>
> 2. brainstorm names
>
> The fun part! All suggestions are welcome.
>
>
> 3. rank names according to metrics
>
> Nigel has volunteered to build a page to list all suggestions with metrics
>
> ᐧ
>
> --
> [image: ForgeRock] <https://www.forgerock.com/> *Simon Moffatt*
> Product Management  |  ForgeRock
> *t* (44) 7903 347 240  |  *e* [e-mail]
> *twitter* @simonmoffatt  |  *web* www.forgerock.com
>