Re: [Txauth] WG name: TxAuth? XAuth? Something else?

Roman / Ben

Is there a reason we can't change the name of the list, or create a new
list when the WG is formed?

On Tue, Mar 17, 2020 at 6:10 AM Justin Richer <jricher@mit.edu> wrote:

> And another thought — there’s a pretty decent chance that we’ll end up
> branding this whole effort OAuth 3 in the future.
>
> The list is named ‘txauth’. Therefore, calling what we’re working on
> anything different from that seems silly and premature.
>
> I say we just stick with TxAuth to match the list and avoid the whole
> naming discussion entirely.
>
>  — Justin
>
> On Mar 16, 2020, at 9:56 PM, Justin Richer <jricher@mit.edu> wrote:
>
> Yes, naming things is hard — but I still believe in the name TxAuth. We’re
> moving beyond OAuth, and taking the process of getting an authorization
> delegated to the client software as a multi-step, multi-party transaction
> is, I believe, the key insight that’s letting us move beyond OAuth’s
> limitations here. It’s not just about going to the AS first — we had that
> in OAuth 1 and we’re patching that into OAuth 2 with PAR. I really think
> it’s about the transaction at the core.
>
> Having come of age in the 1990’s, I have particular dislike for XAuth. It
> sounds too “X-TREME” and “X-CITING”, and if you read either of those with a
> growling yell in your head then you know exactly what I’m talking about.
> And to Dick’s rationale for the name below, I absolutely do NOT see this
> work as “OAuth with all the extra features”. I think that does a disservice
> to the kind of change we have an opportunity to make here.
>
>  — Justin
>
> On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Hello everyone
>
> I prompted a thread around the name of the protocol a while back:
>
> https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/
>
> As Justin stated "naming is hard"
>
> Wearing my marketing hat I want to ensure that the name will be
> perceived properly in the broader community.
>
> A recent example that comes to mind are the privacy related works on the
> browser storage API. Given that name, one would think that it is local
> storage. It is actually about browser cookies.
>
> Justin discussed his reasons for TxAuth in the thread above (and I'm sure
> in other places)
>
> I chose XAuth in my draft to reflect the eXtensibility goal that we have
> over OAuth -- and XAuth is OAuth but with an X to reflect all the extra
> features. =)
>
> Other suggestions?
>
> This will be an agenda item in the BoF -- but the name will NOT be an open
> discussion item -- we will summarize what has been discussed on the list
> and perhaps do a poll of options presented unless consensus is obvious from
> this thread.
>
> /Dick
>
>
>
>
>
> ᐧ
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>