Re: [Txauth] A model with a User Consent Element (with a clean figure)

Dick Hardt <dick.hardt@gmail.com> Mon, 13 July 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 5F4B23A1618 for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 11:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 8dDHyE-pEA2X for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 11:04:13 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 6E4353A1647 for <txauth@ietf.org>; Mon, 13 Jul 2020 11:03:28 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id z24so19029092ljn.8 for <txauth@ietf.org>; Mon, 13 Jul 2020 11:03:28 -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=9k/PYWvx9abCyurO/0Dkr8xdBrbLJhBnDZvx9rjCcIk=; b=Ms6QU3RT8QIG3QOPRvLaMt2AmFuW/L1c/fkUflzrVl6e0Nt3W/FXBctqz3fZu8ux6U yTpus0lcaiZtThaOjV+7oQ5oYni5k1wYGxosuErx4wnRz3ZiPYHM1C42LGRYEhIxyYiE Jd9P+Y3fKqOpEoIn3AXVSaLyD8DOQEaYT087wa2GgJUMq6wi29hoS5p9cT7pkrEI++UD VvbGPcWqS6WhNPo1MTgPN6sRgFNi6FbaQOMnV7tAY7OVHkYpYnVmNqqNIF7FL+Teboxp TJ3BOZ/VLKC/ALsRQerrEhrg2zoYlARsL4xL8LjvgPpBffd9lEMqwFMiV29hYHHNm7qe bZbw==
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=9k/PYWvx9abCyurO/0Dkr8xdBrbLJhBnDZvx9rjCcIk=; b=KcHozboS31Il/BISxOpw3ebqsN+3AMsua+Zvg+koqsK1Qtwuhw3LauHM9LFROuPuEJ 5osYmHFhoWk2oC5z7+w59AiRXw3j3gXuwWXRG+2TiAuH0LWkD+jISzK/fDLDYkQDv5Z9 97IMfReARnHdaurYF34b1cU6UW5BXqyCw+lR7lgXUEqrCh3bdOry4dJXNk2JJPNgyorZ /gKME1gBFy6hC6nXNmsubzui2W+0h3S5LnklO5+1BozH2N6JHksv0pWKyKv7Qw4KWSaS YqU/kV3HjEW78H70a/G4gJnHzHuBusVRc4XtTnAkQPne6N9+ryJmdS96Rxla0XMk5yAZ +CrQ==
X-Gm-Message-State: AOAM532aaWqhPa+DP8Ff2HtHK2AjY28hfeUuJe6LyPzLyJlhvsGOk++m vPHU7RTKw9bF2VkBxdwWzp1aPNGj5xbFRie3tqA=
X-Google-Smtp-Source: ABdhPJxeKjgU/qzTr5OhyrLpXBYZ8256Wa9xBzGBAI0NNPTh1bljBU3+rep+U697BLWhEOG4HLzvMzHaWvK33OZyMWg=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr456703ljh.110.1594663406310; Mon, 13 Jul 2020 11:03:26 -0700 (PDT)
MIME-Version: 1.0
References: <f7cdae74-ac8d-2069-db53-d4f8623c43de@free.fr> <ead88d07-83a6-07f7-4d78-0ee35f599d98@free.fr> <CAD9ie-tbzzUUUFKj3Vmr+Q0GkUbhy8C6nU05=TJaCWJoOzz7pg@mail.gmail.com> <325bc015-1547-c56c-c1fe-67a97165785d@free.fr> <CAD9ie-s57vKSNW-jiUfEVFiYR9FeBaVMsvYyCD_JoQ-GPMnOcw@mail.gmail.com> <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>
In-Reply-To: <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 13 Jul 2020 11:02:49 -0700
Message-ID: <CAD9ie-sQ3GAtbNm0t7ZDG-__zA5c6uaxWzXcDsp6q02J6R=3=Q@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000de98d405aa568132"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/9u1XpRmS7s-l-1sEIZJR9s5D7pc>
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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: Mon, 13 Jul 2020 18:04:18 -0000

I'm going to just address the first part of your response so that we can
get clarity on that before diving into your later comments.

The calls between your proposal and XAuth are not inverted, your proposal
has a prior step. Step 1 in XAuth maps to Step 2 in your proposal, and Step
2 in XAuth is Step 3 in your proposal.

Below are 2 diagrams showing the same steps, the first keeping the existing
step labels for XAuth, the latter renaming the steps to correspond to your
proposal. This looks pretty similar to your diagram. What am I missing?

/Dick

DIAGRAM 1 (steps start at 0)

       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (0)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



DIAGRAM 2 (steps start at 1)

       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (3)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (1)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

ᐧ

On Mon, Jul 13, 2020 at 7:08 AM Denis <denis.ietf@free.fr> wrote:

> Hello Dick,
>
> You wrote: "This looks pretty similar to your protocol drawing".
>
> No. There is a fundamental difference with the sequencing of the flow of
> the exchanges where the (1) and (2) flows are inverted.
>
> In your figure:
>
> The Client makes calls to the GS (1)
> The Client makes calls to the RS (2)
>
> while in my figure:
>
> The Client makes calls to the RS (1)
> The Client makes calls to the AS (2)
>
> In your figure, the first flow is with the GS, whereas in my figure the
> first flow is with the RS and there is a good reason for that:
> the client first contacts the RS to know what the RS expects. The client
> indicates in its first exchange to the RS whether it wants to authenticate
> or to perform another operation.  In the case of an authentication
> operation, the RS may respond to the client that is supports FIDO U2F
> or that it is willing the client to present some attribute(s) from one or
> more AS.
>
> Then after the client has to figure out whether the user is using FIDO and
> if not whether the user has an account with one of the AS.
> In the later case, if there is a match then the client,* *after having
> received the user consent**, may contact the appropriate AS to ask
> for some attribute(s).
>
> The same fundamental difference applies with
> draft-richer-transactional-authz-06 (XYZ) where the first exchange is done
> with the AS:
> "The RC creates a transaction request and sends it to the AS".
>
> This answers also in details to one of your comments:
>
> What looks to be missing from your proposal is:
> A) The Client making a call to the RS to discover what it needs from a GS,
> and which GS to ask, prior to (1).
>
> This is not missing since this is the foundation of the architecture. The
> discovery mechanism at the RS has been described
> in details in an earlier email with the following title: "Support of FIDO
> and data minimization by RSs".
>
> The main figures are copied below (using ASCII):
>
>
>
>
>
>
>
>
>
> *  +-----------------------------------+---------------------------------+
>   +           Operation               +      Mathematical expression    +
> +-----------------------------------+---------------------------------+   +
> Authentication                    + Condition 1 OR Condition 2      +
> +-----------------------------------+---------------------------------+   +
> Operation A OR Operation Z        + Condition 3 AND Condition 4     +
> +-----------------------------------+---------------------------------+ **Conditions
> table: *
>
>
>
>
>
>
>
>
>
>
> *
> +-------------+--------------+-----------------------------+----------+   +
> Condition 1 + FIDO U2F 1.2 +                             +          +
> +-------------+--------------+-----------------------------+----------+   +
> Condition 2 + AS 1         + set 1 of a attributes types +          +
> +-------------+--------------+-----------------------------+----------+   +
> Condition 3 + AS 2         + set 2 of a attributes types + Scope 21 +
> +-------------+--------------+-----------------------------+----------+   +
> Condition 4 + AS 9         + set 3 of a attributes types-+          +
> +-------------+--------------+-----------------------------+----------+ *
> According to the operation announced by the Client, the RS returns to the
> Client both the mathematical expression
> associated with that operation and the conditions included in that
> mathematical expression. The Client may then
> present that information to the user in order to obtain the user consent
> in a standardized manner.
> Another comment you made is:
>
> What looks to be missing from your proposal is:
> B) A mechanism for the Client to prove to the GS that it has gathered
> consent from the User.
>
> The user consent should not be captured *by the GS*, since the GS would be
> in a position to apply a different consent decision
> without letting it know to the user (or to the client).
>
> The user consent must be captured *by the Client* and the Client must be
> able to verify that this consent has indeed been followed by the AS.
>
> The authorization data managed at the RS by the RO is used by the Client
> to query the consent of the user in a standardized manner.
> When, later on, the access token is returned to the Client by the AS, the
> Client (not the user) using that authorization data as well as
> the decision of the user is able to verify that the requested attributes
> (and no more) are indeed present into the access token.
>
> This is why access tokens may *not* be considered to be opaque to the
> Clients.
>
> In my earlier email copied below, six major differences with XAuth from 1)
> to 6) are listed.
>
> Denis
>
> From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
>
> 1.1 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1>.  Parties
>
>    The parties and their relationships to each other:
>
>        +--------+                           +------------+
>        |  User  |                           |  Resource  |
>        |        |                           | Owner (RO) |
>        +--------+                           +------------+
>            |      \                       /      |
>            |       \                     /       |
>            |        \                   /        |
>            |         \                 /         |
>        +--------+     +---------------+     +------------+
>        | Client |---->|     Grant     |     |  Resource  |
>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>        |        |<----|               |     |    (RS)    |
>        |        |     +---------------+     |            |
>        |        |-------------------------->|            |
>        |        |           (2)             |            |
>        |        |<--------------------------|            |
>        +--------+                           +------------+
>
>
> The lines without arrows represent relationships.
> The User trusts the Client
> The User trusts the GS
> The RO trusts the GS to issue access tokens for the RS
> The RS trusts the tokens issued by the RS
> The RO controls the RS
>
> The Client makes calls to the GS (1)
> The Client makes calls to the RS (2)
>
> This looks pretty similar to your protocol drawing.
>
> What looks to be missing from your proposal is:
>
> A) The Client making a call to the RS to discover what it needs from a GS,
> and which GS to ask, prior to (1).
> B) A mechanism for the Client to prove to the GS that it has gathered
> consent from the User.
>
> The current protocol does not require the GS to interact with either the
> User, the RO, or the RS -- which looks to me to meet your privacy goals.
>
> ᐧ
>
> On Fri, Jul 10, 2020 at 6:06 AM Denis <denis.ietf@free.fr> wrote:
>
>> Hi Dick,
>>
>> Hi Denis, thanks for sharing the model. I don't fully understand what is
>> going on, questions inserted:
>>
>> Responses are inserted.
>>
>>
>> FWIW: having paragraphs start with the step number (1), (2) etc. would
>> make it easier to map between the description and the diagram.
>>
>> On Thu, Jul 9, 2020 at 3:26 AM Denis <denis.ietf@free.fr> wrote:
>>
>>> This is a new thread.
>>>
>>> Preamble: This model is quite different from the XAuth model.
>>> In particular, a RO has no relationship with any AS and a Client does
>>> not need to be associated with any AS prior to any access to a RS.
>>>
>>> A key point of this model is that the user's consent is handled locally
>>> by the Client and hence no AS nor RS is handling a man machine interface
>>> for the user consent. This allows to support locally the user consent
>>> for multiple ASs while keeping all ASs ignorant about the choices of the
>>> user
>>> made for accessing a particular RS.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *       +--------+                           +------------+        |
>>> User  |                           |  Resource  |        |
>>> |                           | Owner (RO) |        +--------+
>>>                   +------------+            |
>>> \                              |            |
>>> \                             |            |
>>> \                            |            |
>>> \                           |     +-----------+     +---------------+
>>> +------------+     |           |---->| Authorization |     |            |
>>>     |           | (2) |  Server (AS)  |     |            |     |
>>> |<----|               |     |            |     |  Client   |
>>> +---------------+     |            |     |
>>> |-------------------------->|  Resource  |     |   User    |
>>> (1)             |   Server   |     |  Consent
>>> |<--------------------------|    (RS)    |     |  element
>>> |                           |            |     |
>>> |-------------------------->|            |------>     |
>>> |           (3)             |            |  (4)     |
>>> |<--------------------------|            |<------
>>> +-----------+                           +------------+ *
>>> The flow of operations is as follows:
>>>
>>> The Client (which may have been previously authenticated using FIDO)
>>>
>> Which party has the client authenticated to? The client authenticating
>> with FIDO is confusing to me. FIDO is usually how a user authenticates.
>>
>> If the user has previously opened a user account with the RS using FIDO,
>> then the client may be authenticated by the RS using FIDO.
>> In such a case, the user is already known to the RS under a pseudonym
>> specific to the RS. It may (or may not) have previously presented access
>> tokens
>> to that RS.
>>
>>  contacts the RS and after some dialogue with the RS selects an
>> operation
>> How does the client know which RS to contact?
>>
>> For a private usage, the user may use DuckDuckGo, while for business he
>> may use an application from his company which lists various services
>> available in the context of his job or his position. Some services may be
>> freely available to all the employees of the company with any
>> authentication,
>> e.g. the phone book of the employees may be freely available on the
>> intranet of the company, while some other services may require the user
>> to authenticate to the AS from the company.
>>
>>  that it wants to perform on the RS (1a). Note that it may also indicate
>> directly the operation that it wants to perform on the RS without any prior
>> dialogue.
>>
>>> In return (1b), the RS informs the Client about which attributes are
>>> needed by the RS for performing the requested operation and from which
>>> Attributes Servers
>>> they may be obtained.
>>>
>> (1a) and (1b) are not labeled. There is only (1)
>>
>> (1a) is the first exchange for (1) with the arrow from left to right,
>> while (1b) is the response with the arrow from right to left.
>> The same applies to the other exchanges i.e. (2) , (3) and (4).
>>
>>
>>> This information is specifically marked to indicate that it shall be
>>> handled by the "User Consent element" from the Client.
>>>
>> Why? What is the significance of this? Which information is marked?
>>
>> In the response, a specific identifier or a magic number is used to
>> indicate the start and the length of the information block
>> to be sent to the "User Consent element" supported by the Client.
>>
>> The presentation of that information is up to the man machine interface
>> supported by the "User Consent element" from the Client.
>>
>> Which information?
>>
>> The attributes that are needed by the RS for performing a requested
>> operation and from which Attributes Servers they may be obtained.
>>
>>
>>> The user can see which attributes are requested by the RS for performing
>>> the requested operation and, if it consents, the Client contacts one or
>>> more
>>> appropriate Authorization Servers (2a).
>>>
>> How does the client know which AS(s) to contact?
>>
>> For each AS trusted by the RS to perfom a given operation, the RS should
>> indicate a user-friendly name and a URL of the AS.
>>
>> The user consent is hence captured locally by the Client (i.e. there is
>>> no dialogue with any AS nor any RS).
>>>
>>
>> No dialogue with who? The client is calling the AS is it not?
>>
>> For the user consent, there is no external call since it is handled
>> locally. Afterwards, there is a call to the AS(s) selected by the user.
>>
>>
>>> When the Client got the access tokens from these authorization servers
>>> (2b), it sends all of them in a single request to the RS (3a).
>>>
>>
>> So the RS must trust the AS that issued the tokens. And the AS must trust
>> the Client to have gathered consent.
>>
>> Theses two assertions are correct.
>>
>> And the AS must have a relationship with the user.
>>
>> Only when the user chooses one AS while giving its consent, then the user
>> must have a relationship with the selected AS.
>>
>> It is unclear what role the RO is playing in this though. The RO and RS
>> look to be the same entity from all the other parties.
>>
>> A RO, as indicated on the figure, has only a relationship with one RS: it
>> has no relationship with any AS.
>> The RS trusts the AS but the AS does not know which RSs are trusting it.
>>
>>
>> From my current understanding, at a high level, this looks like it is
>> supported by GNAP with the addition of the discovery step (1).
>>
>> Well, it is fairly different :
>>
>> 1) The first major difference is that there is no arrow between the RO
>> and the AS. No protocol or "out-of-bands" means are necessary.
>>
>> 2) The second major difference is that there is no arrow between the AS
>> and the RS. No protocol is necessary.
>>
>> 3) The third major difference is that the AS does not know any RS. Note:
>> for backward compatibility reasons, an exception might exist for "old" Auth
>> 2.0 ASs.
>>
>> 4) The fourth major difference is that the XAuth spec. is rather vague to
>> describe when and by who the user consent is captured:
>>     XAuth states on page 4: "User consent is *often *required at the
>> GS". In that case, the GS is able to act as Big Brother. No other case is
>> described.
>> 5) The fifth major difference is that the data that is transferred to a
>> "User Consent Element" to capture the user consent. That data can be
>> standardized.
>>     Moreover, it will also be possible to standardize the dialogue
>> between the RO and the RS. The RO will then be able to manage remotely the
>> authorization tables.
>>     See my email sent on June 6, with the following subject: "Support of
>> FIDO and data minimization by RSs".
>>
>> 6) Another difference is the following: since there is no interaction
>> between the RO and the AS, "authorizations from the RO" as described in
>> XAuth do not exist.
>>
>> There have been a number of proposals for doing this discovery, and
>> perhaps now there are enough use cases to look at standardizing something.
>> No interaction is needed between the AS and the User as the Client is
>> providing enough "information" in the user object of the Grant Request
>> to satisfy the AS releasing the access tokens.
>>
>> Not sure I understand correctly this last sentence.
>>
>>
>> Perhaps as I understand the model in more detail I will understand what
>> is missing from GNAP (besides the discovery step).
>>
>> It would be hard to say "what is missing" from XAuth since the
>> foundations are not the same.
>>
>> In order to compare different architectures, there is the need to start
>> with the trust relationships.
>> Unfortunately, the word "trust" is absent in the main body of
>> draft-hardt-xauth-protocol-12. Hence,
>> the description of the trust relationships is missing.
>>
>> Denis
>>
>>
>> /Dick
>>
>> (I've skipped reviewing the delegation use case below until I understand
>> the simple use case)
>>
>>
>>> End of the story for a simple access
>>>
>>>
>>> Start of a subsequent story for a delegation case
>>>
>>> Let us now suppose that the RS is unable to fulfil the request by its
>>> own and that it needs to contact another RS. RS1 contacts RS2 (4a) and
>>> indicates the operation
>>> that it wants to perform on RS2 (that operation may not be the same as
>>> the original operation). In return (4b), RS2 informs RS1 about which
>>> attributes are needed
>>> by RS2 for performing the requested operation and from which Attributes
>>> Servers they may be obtained. RS1 forwards that information to the Client.
>>>
>>> This information is marked to indicate that it shall be handled by the
>>> "User Consent element" from the Client. The presentation of that
>>> information is up to the man machine
>>> interface from the Client. The user can see which attributes are
>>> requested by RS2 for performing the new requested operation and, if it
>>> consents, the Client contacts one or more
>>> appropriate Authorization Servers. The user consent is hence captured
>>> locally by the "User Consent element" from the Client. (i.e. there is no
>>> dialogue with any AS, nor RS1, nor RS2).
>>>
>>> When the Client got the access token(s) from the authorization
>>> server(s), it sends all of them in a single request to RS1. RS1 then
>>> forwards the additional access token(s) to RS2.
>>>
>>>
>>> Some observations:
>>>
>>> The user nor the Client are linked with any particular AS. A user may
>>> use today an AS of the Bank of America and may change tomorrow to the Bank
>>> of Missouri.
>>> As soon as he will be registered with the Bank of Missouri, he will be
>>> able to get access tokens from the AS of the Bank of Missouri. The AS of
>>> Bank of America
>>> has not been able to know where its access tokens have been used. This
>>> will be the same for AS of the Bank of Missouri. There is no need for any
>>> direct dialogue
>>> between any AS and any RS at the time a client is making an access.
>>> There is no need for any RO to contact any AS.
>>>
>>> This model has been constructed following a "Privacy by Design" approach.
>>> Denis
>>>
>>> --
>>> 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
>