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

Nigel Hamilton <nige@123.do> Thu, 28 May 2020 19:23 UTC

Return-Path: <nige@123.do>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B7A3A0A81 for <txauth@ietfa.amsl.com>; Thu, 28 May 2020 12:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=123-do.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vGC1Xvgphfo for <txauth@ietfa.amsl.com>; Thu, 28 May 2020 12:23:22 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D713A0A3B for <txauth@ietf.org>; Thu, 28 May 2020 12:23:21 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id y5so8545014iob.12 for <txauth@ietf.org>; Thu, 28 May 2020 12:23:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=123-do.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hIFC+Bq/7+g6m04DXDr7qSXrATn1FpmziNnYoMpZg6U=; b=ndkEKqpbcvvqGjGinR2BRoAAQ2GcNzZmajEq9sh5f3V8gKqGxbGDfT/bD4J8WFQK9b c5xStvHVa0X2kJSMT9tlhpNP7oFK9Nm06v12d8Geexu1RPofHfh+K874GA6yj6K2oTqA Sj9dbgtOigUWgBmNacE8SBp2tEibgP+WKdefR3uJjjeACwMSnf7M4xXAkwcVz7UY9XmT 7Q8xpeDifcwePUiiPSA51eE1gTEJPn4sVWvK+OFrLfG7MrbD2vy7jpdIkuCBFMsdlv/F uT6bqi6PrhvsCgmJzIw1OCx7AKWIDe+a7mxkdgrNXZn169mVtAxpBTXKA7jBmQYA92Ws TPtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hIFC+Bq/7+g6m04DXDr7qSXrATn1FpmziNnYoMpZg6U=; b=e0wO5epQEf5UQK5maz/ZDMgN/i3rO93ETZJouFut5epwguIde1/Lm6AkW5qONhvFks zj4FxBQBmFgp7SfZmS+jEGYmZ3ku0R/GPYiXWd/0Dy4b5FQt1k1oAYYyJSbYVJ3W3ls3 ZjHwW1zZ4dpxh0WwyCcMV2kb1W06eKeSJc2p81Nc8fzzL8NBlc7go49uuqlxA7d2+R4+ Xb5nVrv2Yby99kIt2VrLX6uaUgA6csvAzDi4ptnP2C5URL8gCiVS3pHx7c6DKUgEasFs /WvMI0CkaZ17zvmGoqpK8/+8uxzh0eG7yNIml0rKNYUXN7SCKt4Lo3yiYlfmWJTeCpLn hxHA==
X-Gm-Message-State: AOAM530a+yU/8/nkiHFTiBapAOL3BaGNBIqMZObZn5JkaT7kiUuqq5Ms MXtU9EWD2CUogFGtum9g8wxTFlc9EGrPLQoppavBADynJZ5FAw==
X-Google-Smtp-Source: ABdhPJzDyxrNrih4zSgVky0a+vgsaGtcFnQR6Gv2f1Hhz0L3n/YFwrsS3fxU/fzQPee6lbgLS7xX8kH89KnwB1/cCkE=
X-Received: by 2002:a05:6602:2dca:: with SMTP id l10mr3652264iow.163.1590693800604; Thu, 28 May 2020 12:23:20 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.2351.1590682645.8861.txauth@ietf.org>
In-Reply-To: <mailman.2351.1590682645.8861.txauth@ietf.org>
From: Nigel Hamilton <nige@123.do>
Date: Thu, 28 May 2020 20:23:09 +0100
Message-ID: <CADbPLe3NM8yiWWRuycN4shCMvgREDgUPuCmf_N4phQqipP-Avw@mail.gmail.com>
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ee8d0b05a6ba42b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/G3XX9RjYaGIGPDt838EhqlOIaf8>
Subject: Re: [Txauth] Txauth Digest, Vol 9, Issue 56
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2020 19:23:25 -0000

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 <txauth-request@ietf.org> wrote:

> Send Txauth mailing list submissions to
>         txauth@ietf.org
>
> 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
>         txauth-request@ietf.org
>
> You can reach the person managing the list at
>         txauth-owner@ietf.org
>
> 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 <vijay.ietf@gmail.com>
> To: txauth@ietf.org
> 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 <jricher@mit.edu>
> To: Vijay IETF <vijay.ietf@gmail.com>
> Cc: txauth@ietf.org
> 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 <vijay.ietf@gmail.com> 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
> > Txauth@ietf.org
> > https://www.ietf.org/mailman/listinfo/txauth
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Yaron Sheffer <yaronf.ietf@gmail.com>
> To: Justin Richer <jricher@mit.edu>du>, Vijay IETF <vijay.ietf@gmail.com>
> Cc: <txauth@ietf.org>
> 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" <
> txauth-bounces@ietf.org on behalf of jricher@mit.edu> 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 <vijay.ietf@gmail.com>
> 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
>     > Txauth@ietf.org
>     > https://www.ietf.org/mailman/listinfo/txauth
>
>     --
>     Txauth mailing list
>     Txauth@ietf.org
>     https://www.ietf.org/mailman/listinfo/txauth
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Vijay IETF <vijay.ietf@gmail.com>
> To: Justin Richer <jricher@mit.edu>
> Cc: txauth@ietf.org
> 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 <jricher@mit.edu> 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 <vijay.ietf@gmail.com> 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
>> > Txauth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>
>
> ---------- Forwarded message ----------
> From: Wayne Chang <wyc@fastmail.fm>
> To: txauth@ietf.org
> 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
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>