Re: [Txauth] Txauth Digest, Vol 9, Issue 56

[Nigel Hamilton <[e-mail]>]

Hi,

Unfortunately AuthX doesn't pass the trademark smoke test [1].

If you would like to suggest a name before the deadline - please check if
the name is already registered as a trademark.

Cheers

NIge

1. https://trademarks.ipo.gov.uk/ipo-tmcase/page/Results/1/UK00003310084

On Thu, May 28, 2020 at 5:17 PM <[e-mail]> wrote:

> Send Txauth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/txauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Txauth digest..."
> Today's Topics:
>
>    1. Name suggestion for next round... (Vijay IETF)
>    2. Re: Name suggestion for next round... (Justin Richer)
>    3. Re: Name suggestion for next round... (Yaron Sheffer)
>    4. Re: Name suggestion for next round... (Vijay IETF)
>    5. unsolicited feedback on naming (Wayne Chang)
>
>
>
> ---------- Forwarded message ----------
> From: Vijay IETF <[e-mail]>
> To: [e-mail]
> Cc:
> Bcc:
> Date: Thu, 28 May 2020 15:08:37 +0530
> Subject: [Txauth] Name suggestion for next round...
> Hi,
>
> I'd like to suggest AuthX for inclusion in the next round...
>
> Why AuthX?
>
> The group's draft charter includes concepts, not in words but perhaps by
> induction, from the realms of identity, authorization, and authentication.
>
> 1. The X in AuthX indicates that.
> 2. It's simple.
> 3. Avoids the unproductive conversations on the semantics of Transaction.
> 4. It indicates that the group is open to exploring all things X (known,
> unknown) wrt identity, authorization, authentication.
>
> No matter how narrow we try to scope the charter down, those are
> inescapable and related concepts.
>
> Witness the massive confusion thrust upon developers arising from OIDC and
> OAuth2 specifications coming from two different organizations on concepts
> that in my mind are inseparable from a systems perspective.
>
> Specifications that are not self contained are confusing at minimum. And
> do a disservice to the wider community at worst when they punt on something
> fundamental and related as being out of scope.
>
> If we are breaking from the past then it behoves upon us to not repeat the
> mistakes from the past.
>
> - Vijay
>
>
>
> ---------- Forwarded message ----------
> From: Justin Richer <[e-mail]>
> To: Vijay IETF <[e-mail]>
> Cc: [e-mail]
> Bcc:
> Date: Thu, 28 May 2020 10:37:18 -0400
> Subject: Re: [Txauth] Name suggestion for next round...
> Hi Vijay,
>
> Sorry to say this, but according to the process put forward by the chairs,
> the cut-off for suggesting new names has already passed. Now the group is
> looking for feedback on the existing list of candidates, not for additional
> candidates.
>
> In addition, AuthX is an existing company name in this space:
> https://www.authx.com/
>
>  — Justin
>
> > On May 28, 2020, at 5:38 AM, Vijay IETF <[e-mail]> wrote:
> >
> > Hi,
> >
> > I'd like to suggest AuthX for inclusion in the next round...
> >
> > Why AuthX?
> >
> > The group's draft charter includes concepts, not in words but perhaps by
> induction, from the realms of identity, authorization, and authentication.
> >
> > 1. The X in AuthX indicates that.
> > 2. It's simple.
> > 3. Avoids the unproductive conversations on the semantics of Transaction.
> > 4. It indicates that the group is open to exploring all things X (known,
> unknown) wrt identity, authorization, authentication.
> >
> > No matter how narrow we try to scope the charter down, those are
> inescapable and related concepts.
> >
> > Witness the massive confusion thrust upon developers arising from OIDC
> and OAuth2 specifications coming from two different organizations on
> concepts that in my mind are inseparable from a systems perspective.
> >
> > Specifications that are not self contained are confusing at minimum. And
> do a disservice to the wider community at worst when they punt on something
> fundamental and related as being out of scope.
> >
> > If we are breaking from the past then it behoves upon us to not repeat
> the mistakes from the past.
> >
> > - Vijay
> > --
> > Txauth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/txauth
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Yaron Sheffer <[e-mail]>
> To: Justin Richer <[e-mail]>, Vijay IETF <[e-mail]>
> Cc: <[e-mail]>
> Bcc:
> Date: Thu, 28 May 2020 17:56:39 +0300
> Subject: Re: [Txauth] Name suggestion for next round...
> Please see here for the latest on the name selection process:
> https://mailarchive.ietf.org/arch/msg/txauth/Gr_FZOKAmIeZOjPvVK_2JyaVIZY/
>
> The deadline is June 4, 0800 UTC.
>
> Thanks,
>         Yaron
>
> On 5/28/20, 17:37, "Txauth on behalf of Justin Richer" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>     Hi Vijay,
>
>     Sorry to say this, but according to the process put forward by the
> chairs, the cut-off for suggesting new names has already passed. Now the
> group is looking for feedback on the existing list of candidates, not for
> additional candidates.
>
>     In addition, AuthX is an existing company name in this space:
> https://www.authx.com/
>
>      — Justin
>
>     > On May 28, 2020, at 5:38 AM, Vijay IETF <[e-mail]>
> wrote:
>     >
>     > Hi,
>     >
>     > I'd like to suggest AuthX for inclusion in the next round...
>     >
>     > Why AuthX?
>     >
>     > The group's draft charter includes concepts, not in words but
> perhaps by induction, from the realms of identity, authorization, and
> authentication.
>     >
>     > 1. The X in AuthX indicates that.
>     > 2. It's simple.
>     > 3. Avoids the unproductive conversations on the semantics of
> Transaction.
>     > 4. It indicates that the group is open to exploring all things X
> (known, unknown) wrt identity, authorization, authentication.
>     >
>     > No matter how narrow we try to scope the charter down, those are
> inescapable and related concepts.
>     >
>     > Witness the massive confusion thrust upon developers arising from
> OIDC and OAuth2 specifications coming from two different organizations on
> concepts that in my mind are inseparable from a systems perspective.
>     >
>     > Specifications that are not self contained are confusing at minimum.
> And do a disservice to the wider community at worst when they punt on
> something fundamental and related as being out of scope.
>     >
>     > If we are breaking from the past then it behoves upon us to not
> repeat the mistakes from the past.
>     >
>     > - Vijay
>     > --
>     > Txauth mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/txauth
>
>     --
>     Txauth mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/txauth
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Vijay IETF <[e-mail]>
> To: Justin Richer <[e-mail]>
> Cc: [e-mail]
> Bcc:
> Date: Thu, 28 May 2020 21:13:12 +0530
> Subject: Re: [Txauth] Name suggestion for next round...
> Hi Justin,
>
> Thanks. My bad. Suggesting a name of a company that exists is a
> terrible idea. I should have done my homework. Sorry about that!
>
> Was flooded by DNSOP WG emails and lost track of the cut-off dates and the
> name selection process thread.
>
> I give up. Naming is hard.
>
> I do find the process to "strongly object" in order to eliminate a popular
> vote a bit odd.
>
> Is there a precedent for this mode of selection in any setting within
> IETF? Genuinely curious since I am new to the working internals of IETF.
>
>
> On Thu, 28 May 2020 at 20:07, Justin Richer <[e-mail]> wrote:
>
>> Hi Vijay,
>>
>> Sorry to say this, but according to the process put forward by the
>> chairs, the cut-off for suggesting new names has already passed. Now the
>> group is looking for feedback on the existing list of candidates, not for
>> additional candidates.
>>
>> In addition, AuthX is an existing company name in this space:
>> https://www.authx.com/
>>
>>  — Justin
>>
>> > On May 28, 2020, at 5:38 AM, Vijay IETF <[e-mail]> wrote:
>> >
>> > Hi,
>> >
>> > I'd like to suggest AuthX for inclusion in the next round...
>> >
>> > Why AuthX?
>> >
>> > The group's draft charter includes concepts, not in words but perhaps
>> by induction, from the realms of identity, authorization, and
>> authentication.
>> >
>> > 1. The X in AuthX indicates that.
>> > 2. It's simple.
>> > 3. Avoids the unproductive conversations on the semantics of
>> Transaction.
>> > 4. It indicates that the group is open to exploring all things X
>> (known, unknown) wrt identity, authorization, authentication.
>> >
>> > No matter how narrow we try to scope the charter down, those are
>> inescapable and related concepts.
>> >
>> > Witness the massive confusion thrust upon developers arising from OIDC
>> and OAuth2 specifications coming from two different organizations on
>> concepts that in my mind are inseparable from a systems perspective.
>> >
>> > Specifications that are not self contained are confusing at minimum.
>> And do a disservice to the wider community at worst when they punt on
>> something fundamental and related as being out of scope.
>> >
>> > If we are breaking from the past then it behoves upon us to not repeat
>> the mistakes from the past.
>> >
>> > - Vijay
>> > --
>> > Txauth mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>
>
> ---------- Forwarded message ----------
> From: Wayne Chang <[e-mail]>
> To: [e-mail]
> Cc:
> Bcc:
> Date: Thu, 28 May 2020 12:16:57 -0400
> Subject: [Txauth] unsolicited feedback on naming
> hi all, good to meet you. adding $0.02 on naming as an outsider, using
> good, bad, ugly descriptors:
>
>         * AAuthZ    Alternative Authorization Protocol (AAuthZ)
> ugly, tough to pronounce and looks like a typo of AuthZ
>
>         * AZARP    AuthoriZed Access to Resources Protocol
> ugly, initialism doesn't imply function
>
>         * AZARAP    AuthoriZation And Resource Access Protocol
> ugly, initialism doesn't imply function
>
>         * BeBAuthZ    Back-end Based Authorization Protocol
> bad, "back-end" is way too broad
>
>         * BYOAuthZ    Build-Your-Own Authorization Protocol
> bad, "BYO" means "bring your own" to me
>
>         * CPAAP    Comprehensive Privileged Authentication Authorization
> Protocol
> ugly, unclear how to pronounce, looks close to "CRAAP"
>
>         * DAZARAP    Delegated AuthoriZation And Resource Access Protocol
> ugly, initialism doesn't imply function
>
>         * DIYAuthZ    Do-It-Yourself Authorization Protocol
> bad, DIY implies amateurish and backyard
>
>         * GNAP    Grant Negotiation and Authorization Protocol
> bad, initialism doesn't imply function
>
>         * GranPro    GRAnt Negotiation Protocol
> ugly, .+pro or has hints of proprietary
>
>         * IDPAuthZ    Intent Driven Protocol for Authorization
> ugly, IdP already means identity provider to lots of folks
>
>         * NIRAD    Negotiation of Intent Registration and Authority
> Delegation
> bad, expansion is too wordy and intent registration is unclear to external
> stakeholders
>
>         * PAuthZ    Protocol for Authorization
> bad, initialism does not imply function
>
>         * RefAuthZ    Refactored Authorization Protocol
> bad, "Ref" means reference to lots of folks as in you're trying to define
> the gold standard
>
>         * ReAuthZ    Reimagined Authorization Protocol
> ugly, implies that you might authorize _again_
>
>         * TIAAP    Tokenized Identity and Access Protocol
> ugly, "tokenized" anything has charged meanings to technologists and
> non-technologists alike
>
>         * TIDEAuth    Trust via Intent Driven Extension Auth
> bad, i like "TIDEAuth" but Trust via Intent Driven Extension is just
> semantic soup
>
>         * TIDYAuth    Trust via Intent Driven Yield Auth
> bad, tidy implies small, driven yield means nothing to me
>
>         * TIEAuth    Trust via Intent Extension Auth
> good
>
>         * TINOA   This Is Not OAuth
> ugly
>
>         * TXAuth    Testable eXtensible Authorization
> good, except "Testable" doesn't sound like the main priority here?
>
>         * TxAuth      Transmission of Authority
> good
>
>         * TXAuth      Truly eXtensible Authorization
> good, not sure about "Truly" because we will no doubt encounter limits
> ourselves
>
>         * XAuthZ    eXtensible authoriZation protocol
> bad, best expanded form here, but XAuthZ is not aesthetic to me
>
> is there a reason we didn't call it TXAuth/TxAuth and have it stand for
> Transaction Authorization? either of those would be my first choice. i
> understand that the name picking period is over.
>
>
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>