Re: [Txauth] Call for charter consensus - TxAuth WG

Dick Hardt <dick.hardt@gmail.com> Fri, 20 March 2020 18:04 UTC

Return-Path: <dick.hardt@gmail.com>
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 DB96B3A0D7B for <txauth@ietfa.amsl.com>; Fri, 20 Mar 2020 11:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4gnmmYvpzim5 for <txauth@ietfa.amsl.com>; Fri, 20 Mar 2020 11:04:33 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 A15C63A0D76 for <txauth@ietf.org>; Fri, 20 Mar 2020 11:04:30 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id v16so372969ljk.13 for <txauth@ietf.org>; Fri, 20 Mar 2020 11:04:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C1HsyseHK+V2afEiOYYur+vbdRSBRo2WNZPcs/n1HQ0=; b=L98Prj+DVyXosJjYneGBJs6vzrwZzWWeS+j18VQwIBreaG3+ZSJ1v/72TwQMWIHyOl 3H+i1NLX3wE7zTl5Wj3r+Cj4L7Pydw+KoaRsp6Ndm5JS5DTcwMKNbTMv5zkoY9ETOVyW EaF2/79L/R9jYqCTHhWuqPHRQ5VjtXP/ZbIEThpMQymdSbQSeHi0bg+OJgz1ESX4CKdg N8YTbuT6sl/7LS/BmLRM5L2onyhVgTbLZ1c8eLKY5iRe3UId6/GUChsniNL1jPPGmztn vAm0rcngYojZbozVIFIrtl34LxTTRW3L4wSdKVfiY4kqLzZtY/WWTfBAlFpVF3tHFVpx a7rw==
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:cc; bh=C1HsyseHK+V2afEiOYYur+vbdRSBRo2WNZPcs/n1HQ0=; b=Fqz7zDxlCGx01mpTZUCsYaqNt9KulPX0Q2ZoUfgQknqRJxQY/FZ1AJTGtbk7Rd0oh4 OJB9nsgY7djIVoEa2bOLBA2A4hG+k9ZyYYRVq7kgZM75xR13fTqCRooNeot0luJTLpv5 /tbAEgnr8aCdTIZSbK5APwhKWeeLeWCaF+USAV0OBxigkpfM6K69j4r3IVIQLCQ1pZ1H Uv+CHVr8Zusp5ujmOclkKvOknfHQqqC/8RrGdkdQaOoME3PwJMa1NIZAiMyYvBc+vpcS +BsqrN0PKdWZ1PYIgN1NECx5pAyAh38hVxKEZnhaYk2yXTiUYQkEbyI37yAUDbsHBrYP Sk3A==
X-Gm-Message-State: ANhLgQ28Kaf1LS58awmKuu+h3XXNcemqj5ZflR25jNp98VTVyCUxAthP 9lGHeG0LPubNCm3RpwVDyHwqmuqgflXAM8oRBdE=
X-Google-Smtp-Source: ADFU+vtVadQdfEhZEuxdpjblvsyUpBm7cP4En0iCcEKLu3YjYmdKIEzMyLhfi0/X9EOO6B+2G7N6lysduVWuLmQHXHM=
X-Received: by 2002:a2e:9d84:: with SMTP id c4mr6280022ljj.51.1584727462246; Fri, 20 Mar 2020 11:04:22 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR00MB0686B5459E642FE6E65686F7F5F60@MN2PR00MB0686.namprd00.prod.outlook.com> <CABzCy2DGw5tcFgiwqzZgZKvXEaBbg0_sGD6xtdVdopfkyDhaxw@mail.gmail.com> <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu>
In-Reply-To: <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 20 Mar 2020 11:03:55 -0700
Message-ID: <CAD9ie-tbAcT7mHXJO_gGx2ZqGkfTgjLjhd8GVVVcPu19Y7jj0A@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Nat Sakimura <sakimura@gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000073fb5e05a14d1d35"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BwsSrxcpCFTxs5sZgLXa5N7lRsw>
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
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: Fri, 20 Mar 2020 18:04:45 -0000

Nat: thanks for chiming in. Useful insights as always!

Vittorio: I'll reinterpret your statement about "marketing" the work, to be
that we should solve real problems that people don't have solutions for
today.

*AS<->RS relationship*

TL;DR: I think the charter misses the mark in the AS<->RS relationship
being in scope and we should expand it.

In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast to
OAuth 1.0, but the interactions / communication between the AS and the RS
were out of scope, as the uses cases at the time had the AS and RS operated
by the same entity. New use cases have a weaker coupling between the AS and
RS, and to enable interop, extensions have been written for Token
Introspection, and JWT Profile for OAuth 2.0 Access Tokens .

The TxAuth charter includes introspection:


- Query of token rights by resource servers


-- but does not include the common design pattern where the RS can directly
interpret the token.

Here is proposed updated text to the line above to be broader in scope than
just a query:

- communication of token attributes between the authorization server and
resource server



*Architecture and Use Case documents*

TL;DR: Yes to use case doc, no to architecture doc.

I agree with Justin that an architecture document is unlikely to prove
useful long term. I disagree with him on the use cases. I don't think the
use cases need to be exhaustive, but example use cases helps everyone
understand everyone else's primary use cases. If your use case is not
similar to others, then you should write it up and the WG can decide if it
is in scope or not. If it is, it gets added to the use case document. I
would consider this a living document while working on the core protocol.
It would NOT be a use case document that scopes the WG work. The charter
does that. It would be a companion document to the core protocol. I
strongly think a use case document resolves many of the miscommunications
that happen where people are talking past each other, because they don't
understand each other's use case.

*Reusing Existing Technology*

TL;DR: we should be reusing existing specifications where ever possible.

Reading between the lines, I think the concern around identity may be that
the TxAuth charter implies that the WG is going to create
yet-another-identity-representation and ignore all the previous efforts. I
think creating yet-another-identity-representation to solve use cases that
are already solved with existing representations would be misguided effort.
My own interest in TxAuth is being able to use one protocol to request and
receive any existing and future identity representation. One of my
motivations for writing the XAuth document was to show how different
representations could be requested and received, as this was missing in
XYZ.  If a use case requires a new representation, then perhaps TxAuth may
be a place for that work to happen, but I think it is more likely to happen
in other forums.

It is not clear to me how, or if, reusing existing technology fits into the
charter, but I do strongly think it should be a tenet of the WG.

On a related note, I also strongly think that the existing OAuth 2.0 scopes
should be easily used in requests and responses. XAuth shows an example of
how that can be done.

/Dick




On Fri, Mar 20, 2020 at 6:39 AM Justin Richer <jricher@mit.edu> wrote:

> I agree with a lot of that argument. Let me see if I can more clearly
> restate what I was trying to say earlier in this thread: the relationships
> between the different parties are separable and depend on the kind of
> deployments and use cases that are being addressed by people. So in an
> OAuth/OIDC-style world, we’ve got three components (ignoring people), and
> three relationships between them:
>
> C<->AS
>
> C<->RS
>
> AS<->RS
>
> For authorization, these map to “how to get a token”, “how to use a
> token”, and “how to interpret a token”. For authentication, it’s
> additionally “how do I get the authentication info”, “how do I ask for a
> profile”, and “how do I know whose profile this is”. I still believe this
> is a good separation of concerns. The client doesn’t need to know what’s in
> the access token, or if it’s a reference or self-contained, or really
> concern itself at all with what the RS does with it. Are there overlaps?
> Certainly — the client needs to know how to ask for a token that the RS
> will accept for what the client is going to do, and to do that the client
> needs to be able to describe what it wants to do in a way that the AS can
> interpret and map to a set of rights that the RS will eventually interpret.
>
> I believe the proposed charter already covers this split with the
> following items:
>
> - Fine-grained specification of access
> - Approval of access to multiple resources and APIs in a single interaction
> - Separation between the party authorizing access and the party operating
> the client requesting access
> - Revocation of active tokens
> - Query of token rights by resource servers
>
> It’s the combination of the rich request and the lifecycle management that
> puts the AS and RS in scope. I think things like declaring a single token
> format are absolutely out — if you want to use JWT, or CWT, or UUID’s,
> that’s all just fine. However, something that I think is in scope is
> defining a structure for what a token represents. And I think that if we
> can do that in this WG in a general way, then that’s useful. Because then
> that structure can be represented by mapping to a token format or an
> introspection response or a database entry. I think Nat’s comments on ABAC
> are important: we are going to need a place to put those attributes.
> Whether they’re communicated to the RS through the token itself or through
> some other channel is, I strongly believe, a matter of deployment choice.
>
> So, what can the charter say to make this more clear?
>
> All that said, I’m against having an architecture document as a working
> group output. In my experience, when a WG puts its effort into a formal
> architecture doc *as a deliverable*, there is a lot of conjectural energy
> that goes into what might be a good idea, and then not all of it works out
> when you try to hammer the details of making that architecture into a real
> engineered thing.You end up baking in assumptions and abstractions that
> don’t make sense anymore, and then trying to engineer solutions around
> those when they don’t fit right. If the architecture can’t change in light
> of new information, which is the case with an RFC, then it becomes a
> shackle instead of a scaffold. But a malleable document that the group can
> use as a guide while engineering the actual parts — yes, that makes sense.
> The architecture can be refactored and changed as decisions are made and
> things come into focus. I feel the same about use case documents as formal
> artifacts.
>
> Thanks, Nat.
>  — Justin
>
> On Mar 20, 2020, at 2:19 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> I thought I should keep my mouth shut as anything I say may be deemed
> biased as my other hat is the chairman of OIDF, but here is my 2c.
>
> As Torsten indicated, there is much to be desired to standardize the AS -
> RS communication patterns. You may say that the charter includes it, but I
> cannot read it out of the charter just like Torsten could not. As a new
> protocol, it would be good to include it.
>
> In this respect, I am not sure if we should start off from OAuth 2.0 and
> OIDC model. If we are creating a new protocol, I feel that we should
> architect is more fully. Not mentioning AS - RS relationship to me feels
> like an indication of this failure. For that matter, I feel that the first
> output of the group should be an architecture document that takes the
> concerns from all the relevant stakeholders/actors in.
>
> We should also be cognizant of the access control models like ABAC. For
> that, decoupling of identity (= set of claims) assertion and authorization
> is a necessity. We could optimize it but the base case should take care of
> it. (In this respect, I am feeling that OIDC has perhaps over-optimized.)
> So, I feel that at least as the first step, TxAuth should concentre on the
> Access Control. If I were to go one step further, it should be modelled so
> that it can consume various identity assertions (authenticated identity in
> ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable
> Credentials, X.509 certificates (such as in eIDAS and Japanese National ID
> scheme)  etc. We are not going to get to a unified identity world anytime
> soon.
>
> Cheers,
>
> Nat Sakimura
>
>
> On Wed, Mar 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=
> 40microsoft.com@dmarc.ietf.org> wrote:
>
>> I believe it's significant that four people have expressed concerns with
>> including digital identity in the charter (the only concerns voiced as far
>> as I can tell).  At a minimum, I believe that that warrants making the
>> inclusion or exclusion of digital identity a discussion topic during the
>> upcoming virtual BoF, before adopting any charter.
>>
>> It would be my proposal to initially charter without digital identity and
>> see how far we get with our energies intentionally focused in that way.  If
>> the working group decides to recharter to include digital identity, that
>> can always happen later, after the authorization-focused work has matured,
>> and once there's a clear case to actually do so.
>>
>>                                 -- Mike
>>
>> -----Original Message-----
>> From: Justin Richer <jricher@mit.edu>
>> Sent: Tuesday, March 17, 2020 2:20 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <
>> torsten@lodderstedt.net>; txauth@ietf.org
>> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
>>
>> While I understand the concerns around identity in the charter, and I had
>> initially not included it, I was convinced that the kind of identity
>> protocol that we’re looking at here is a minor addition to the
>> authorization and delegation end of things.
>>
>> As you know, much of what’s in OIDC is there to fix problems with OAuth 2
>> when it’s used for identity. If OAuth 2 had solved those problems
>> internally, then OIDC would be much, much simpler and smaller. We’re now
>> starting at a base where those problems don’t exist, but we don’t yet know
>> what other problems there might be.
>>
>> The market has shown us that the most common application of OAuth 2 is
>> far and away access to identity information along side access to an API. I
>> think we need to pay attention to that and not make this separate just
>> because we did it that way before. And some of the proposed innovations,
>> including getting and sending VC’s, are all about identity.
>>
>> Furthermore, this charter does not specify the document and specification
>> structure of the components, nor does it specify the publication order or
>> timing of any documents. I personally think that the identity layer should
>> be separable to an extent, to the point of publishing that layer in its own
>> spec alongside the core authorization delegation system. However, that does
>> not mean that it should be developed elsewhere.
>>
>> If there is better language to tighten the aspects of an identity
>> protocol that we will explicitly cover, then I would welcome you to suggest
>> an amended text to the charter. However, I believe there is enough interest
>> within the community to work on identity in the context of this protocol,
>> including a large number of people being OK with it in the charter, that it
>> would not be a reasonable thing to remove it.
>>
>>  — Justin
>>
>> > On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=
>> 40microsoft.com@dmarc.ietf.org> wrote:
>> >
>> > 1.  Do you support the charter text provided at the end of this email?
>> Or do you have major objections, blocking concerns or feedback (if so
>> please elaborate)?
>> >
>> > I share the concerns about including identity in the charter that were
>> expressed by Torsten and agreed with by David Skaife.  I'll note that Kim
>> Cameron previously expressed concerns about including identity in his
>> earlier charter critique at
>> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/
>> .
>> >
>> > I'm fine with refactoring the authorization protocol.  But identity
>> should be decoupled from the TxAuth work to focus its scope on areas where
>> innovation is being proposed.  Digital identity can always be added as a
>> layer if needed, just as OpenID Connect layered identity onto OAuth 2.0.
>> >
>> > Please revise the charter to remove digital identity from the scope of
>> the work.
>> >
>> > 2.  Are you willing to author or participate in the development of the
>> drafts of this WG?
>> >
>> > Yes
>> >
>> > 3.  Are you willing to help review the drafts of this WG?
>> >
>> > Yes
>> >
>> > 4.  Are you interested in implementing drafts of this WG?
>> >
>> > Not at this time.
>> >
>> >                               -- Mike
>> >
>> > -----Original Message-----
>> > From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt
>> > Sent: Saturday, March 7, 2020 7:18 AM
>> > To: Yaron Sheffer <yaronf.ietf@gmail.com>
>> > Cc: txauth@ietf.org
>> > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG
>> >
>> > Hi,
>> >
>> >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>> >>
>> >> Hi Everyone,
>> >>
>> >> It appears that momentum is forming around the proposed formation of a
>> TxAuth working group.  We’d like to more formally gauge interest in
>> proceeding with this work.  Please do so by responding to the following
>> questions:
>> >>
>> >> 1.  Do you support the charter text provided at the end of this
>> email?  Or do you have major objections, blocking concerns or feedback (if
>> so please elaborate)?
>> >
>> > I‘m in although I have to admit I‘m slightly concerned the scope of the
>> charter is too broad, e.g. identify alone is a huge topic.
>> >
>> > We need to keep an eye on this aspect in order to make sure, the group
>> is able to work effectively and the specs we will be producing are as
>> simple as possible and foster interoperability.
>> >
>> >>
>> >> 2.  Are you willing to author or participate in the development of the
>> drafts of this WG?
>> >
>> > yes
>> >
>> >>
>> >> 3.  Are you willing to help review the drafts of this WG?
>> >
>> > yes
>> >
>> >>
>> >> 4.  Are you interested in implementing drafts of this WG?
>> >
>> > yes
>> >
>> > best regards,
>> > Torsten.
>> >
>> >>
>> >> The call will run for two weeks, until March 21. If you think that the
>> charter should be amended In a significant way, please reply on a separate
>> thread.
>> >>
>> >> The feedback provided here will help the IESG come to a decision on
>> the formation of a new WG. Given the constraints of the chartering process,
>> regardless of the outcome of this consensus call, we will be meeting in
>> Vancouver as a BoF.
>> >>
>> >> Thanks,
>> >> Yaron and Dick
>> >>
>> >> --- Charter Text Follows ---
>> >>
>> >> This group is chartered to develop a fine-grained delegation protocol
>> for authorization, identity, and API access. This protocol will allow an
>> authorizing party to delegate access to client software through an
>> authorization server. It will expand upon the uses cases currently
>> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth
>> 2.0) to support authorizations scoped as narrowly as a single transaction,
>> provide a clear framework for interaction among all parties involved in the
>> protocol flow, and remove unnecessary dependence on a browser or user-agent
>> for coordinating interactions.
>> >>
>> >> The delegation process will be acted upon by multiple parties in the
>> protocol, each performing a specific role. The protocol will decouple the
>> interaction channels, such as the end user’s browser, from the delegation
>> channel, which happens directly between the client and the authorization
>> server (in contrast with OAuth 2.0 which is initiated by the client
>> redirecting the user’s browser). The client and AS will involve a user to
>> make an authorization decision as necessary through interaction mechanisms
>> indicated by the protocol. This decoupling avoids many of the security
>> concerns and technical challenges of OAuth 2.0 and provides a non-invasive
>> path for supporting future types of clients and interaction channels.
>> >>
>> >> Additionally, the delegation process will allow for:
>> >>
>> >> - Fine-grained specification of access
>> >> - Approval of AS attestation to identity claims
>> >> - Approval of access to multiple resources and APIs in a single
>> interaction
>> >> - Separation between the party authorizing access and the party
>> operating the client requesting access
>> >> - A variety of client applications, including Web, mobile,
>> single-page, and interaction-constrained applications
>> >>
>> >> 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 identity)
>> >>
>> >> Additionally, the group will provide mechanisms for management of the
>> protocol lifecycle including:
>> >>
>> >> - Discovery of the authorization server
>> >> - Revocation of active tokens
>> >> - Query of token rights by resource servers
>> >>
>> >> Although the artifacts for this work are not intended or expected to
>> be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will
>> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new
>> protocol where possible.
>> >>
>> >> This group is not chartered to develop extensions to OAuth 2.0, and as
>> such will focus on new technological solutions not necessarily compatible
>> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be
>> developed in the OAuth Working Group, including functionality back-ported
>> from the protocol developed here to OAuth 2.0.
>> >>
>> >> The group is chartered to develop mechanisms for applying
>> cryptographic methods, such as JOSE and COSE, to the delegation process.
>> This group is not chartered to develop new cryptographic methods.
>> >>
>> >> The initial work will focus on using HTTP for communication between
>> the client and the authorization server, taking advantage of optimization
>> features of HTTP2 and HTTP3 where possible, and will strive to enable
>> simple mapping to other protocols such as COAP when doing so does not
>> conflict with the primary focus.
>> >>
>> >> Milestones to include:
>> >> - Core delegation protocol
>> >> - Key presentation mechanism bindings to the core protocol for TLS,
>> detached HTTP signature, and embedded HTTP signatures
>> >> - Identity and authentication conveyance mechanisms
>> >> - Guidelines for use of protocol extension points
>> >>
>> >>
>> >> --
>> >> 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
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>