Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11

Francis Pouatcha <fpo@adorsys.de> Thu, 16 July 2020 20:05 UTC

Return-Path: <fpo@adorsys.de>
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 11DA13A0C0A for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 13:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 (1024-bit key) header.d=adorsys.de
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 ahZCOmKvT04w for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 13:05:41 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 112ED3A0C0C for <txauth@ietf.org>; Thu, 16 Jul 2020 13:05:40 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id z15so8349299wrl.8 for <txauth@ietf.org>; Thu, 16 Jul 2020 13:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bq37XJE9iinHP6K1pNJWIijP0OuVDHUKxj67zTygdKU=; b=L0Gvamh/OwPdjgxA2Ly/hTgZjgbKYJPAzM0tsULRZ4S4750tVj7HkywCcMIzfsHMKS iLQGvAiQvCWKy9eef5koY+oJyX2bkE+X1c5JtadQYKZln40aVEPa2rv3BS5q0p+vhATG SIwXm51K9WEYb4Wa3sH8FDwbejioVTk0aAS/0=
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=Bq37XJE9iinHP6K1pNJWIijP0OuVDHUKxj67zTygdKU=; b=RJ50XLw82A9hexZBBKl8J6xprZ9elsNWc0lhF6kPzr2SNkES/v8gJPRypZ+b8SAl2x eYHV4NWpStjAg/6aPxK/LbvvGKNwFB/ZzoF+nPpjZuHve5tuJdm6P9whraVD2XBeHX45 995YEhaimjRtPKVHKfjruSmXHK6QhwtGfbLmaqzahRENZit2z0fjFjyxncQmPry2qLre 2NUTh0Jt5Ys2/NKYhx8PFc5YWhFRIQ64Y+AY1wWgzrz7T69CFbkg5i4mjMirmMnXUc5y T0JDRxsupmqFip6Y0ltlwTFPe+IH4w82X0VYpTQYlJnpP2zhJ9PfkTeLHUSvrIFwikrv 2+Bg==
X-Gm-Message-State: AOAM530Uf2aEol1CeGNx3ItAAn8nW792VDSh6k4TVfOIywgbuiW3hN9F Tp4AkoFXVpScxcWIAf7d7y7DneCGgR2Ro3HvHyM4mNLPEo4=
X-Google-Smtp-Source: ABdhPJxZM0rM0WV1uxRXAat9+y84iSBvaLNkEVN1XPWmLtiV/OfSzFPuJ9Ga35YFUWbZjyQXjpYMcm+bMv+RfzUtkMA=
X-Received: by 2002:adf:c382:: with SMTP id p2mr6423226wrf.283.1594929938738; Thu, 16 Jul 2020 13:05:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com> <CAD9ie-vV4oh9Qk3Y0sPeewo4jby_S6a=HKTZnoqByxJ6tCHJ+Q@mail.gmail.com> <CAOW4vyOQYvHBBPjMSNx9=S66_JY4RVcVi2DiqL8OjXUyvzxg=w@mail.gmail.com> <CAD9ie-tou5mTnWVguNygj-D6xUdTRjqvxi-+jhC6NbDFY8ZVJQ@mail.gmail.com> <CAOW4vyM0LycEf8q1T4jF=1g8aFyeLw1b4z9emNKWOG=+4iGgzw@mail.gmail.com> <CAM8feuSWeianPu=BD0WVTv5oB+U4ZkjhtKjnAG9RFk15VqJqWA@mail.gmail.com> <CAOW4vyNTXso=tusCrzDVgM63xH4hDsx6epO6tAhh1YekbWBA0A@mail.gmail.com> <f00c75a5-f930-81a6-a50e-2eeffedac691@free.fr> <CAOW4vyOHO1We4UpCPJBKYvj22rsFd1EN6fAXw8w6YOYTUDhF=g@mail.gmail.com> <aa1381a2-5b11-f7c7-a547-cddb36732c0b@free.fr> <CAD9ie-t7ZFrODeXy=Xzvsv-6gvUY=KjW0ETf8vJYkW2p=G4boQ@mail.gmail.com>
In-Reply-To: <CAD9ie-t7ZFrODeXy=Xzvsv-6gvUY=KjW0ETf8vJYkW2p=G4boQ@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Thu, 16 Jul 2020 16:05:27 -0400
Message-ID: <CAOW4vyN26rnOFb+vsaxgaMzeBOsyeSUBougvjHuhQkHyYhnn2w@mail.gmail.com>
To: txauth@ietf.org
Cc: Dick Hardt <dick.hardt@gmail.com>, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="00000000000070c6bf05aa9490cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/CBSqUClXHzP4PbKnJg8bi1b7KTI>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 20:05:45 -0000

Hello Dick, Denis,

here is an updated version of the diagram following Dick's advice to
collapse responses and some clarifications as raised by Denis:

+----+  +------+  +---+  +---+  +---+
|User|  |Client|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
  |(1) ServiceRequest      |      |
  |-------->|       |      |      |
  |         |(2) ServiceIntent:AuthZChallenge
  |         |<----->|      |      |
  |         |       |      |      |
  |         |(3) AuthZRequest(AuthZChallenge)
  |         |------------->|      |
  |         |       |      |(4) ConsentRequest:Grant
  |         |       |      |<---->|
  |         |(5) GrantAccess(AuthZ)
  |         |<-------------|      |
  |         |       |      |      |
  |         |(6) ServiceRequest(AuthZ):ServiceResponse
  |         |<----->|      |      |
  |(7) ServiceResponse     |      |
  |<--------|       |      |      |
  +         +       +      +      +

Nomenclature of Arrows:
---> designate a request.
<--- designates a response.
<--> request with immediate response.

Step, Action and Interaction:
This diagram describes actions and not interactions:
- Each step carries a number.
- An action with immediate response is collapsed into a single step (2, 4,
6).
- An action with deferred response is represented by two steps (1&7, 3&5).
- An action might be carried out using many interactions and might for the
purpose of transport involve more parties (see redirect interaction bellow)

(1) ServiceRequest
This is the service request sent by the User to the Client. This can be a
simple file read request or a complex payment initiation request.

(2) ServiceIntent:AuthZChallenge
In order to discover authorization requirements, the Client sends
a ServiceIntent request to the RS. The response to a ServiceIntent request
is an AuthZChallenge.
The content of an AuthZChallenge can be similar to the oAuth2 RAR.
The content of the AuthZChallenge can be:
- An identification challenge. Generally when the RS can not associate the
ServiceRequest with an RO.
- An AuthZ exemption. Generally when the RS needs no further AuthZ to
fulfill the Client request.
- Details on the requested AuthZ, including instructions on which GSs the
Client can approach for AuthZ; instructions on which attributes are
requested for each of these GSs.

(3) AuthZRequest(AuthZChallenge)
The Client sends an AuthZRequest to the GS including the AuthZChallenge.
This request can be similar to the oAuth2 PAR request.

(4) ConsentRequest:Grant
GS sends a consent request to RO. The way a GS connects with the RO to
collect RO's consent (Grant) is dependent on the interaction mode. This is
also valid for the nature of the Grant returned by the RO to the GS.
- In the case of a "redirect interaction", GS will use the transport
infrastructure provided by the Client to instruct the User to send the RO
to the GS authorization endpoint (in most cases, user and RO are
identical). In the case of oAuth2 AuthCode flow, the Grant provided by the
RO is stored by the GS (AS) at the AuthZ endpoint, then mapped to an
authCode that is transported by the User (User Agent) through the Client to
the token endpoint of the GS.
- In the case of a "decoupled interaction", GS will directly contact RO and
collect consent in a direct interaction with the RO (see CIBA). This
diagram assumes GS can evaluate the AuthZChallenge to find out how to
locate the RO. As there is a direct interaction between the GS and the RO,
the form/nature of the Grant is left to the discretion of the concrete
interaction mode.
- In the case of an "embedded interaction", GS will allow the Client to
directly collect the Consent (Grant) of the RO in a direct interaction
between the Client and the User (also assuming in most cases, that user and
RO are identical); and then send it to the GS in exchange of the AuthZ. We
say the interaction between GS and RO is embedded in the communication with
the Client.

(5) GrantAccess(AuthZ)
>From evaluating the Grant provided by the client, the GS produces a
corresponding access token and returns it to the Client.
Note that GS knowledge of the original or target RS is not necessary for
the issuance of the access token, unless GS is required to bind the token
to a target RS.

(6) ServiceRequest(AuthZ):ServiceResponse
Client uses the GS provided AuthZ to send the service request to RS. Recall
that AuthZ (token) can be, but must not be bound to an RS.

(7) is self explaining.

One of our upcoming exercises will be to challenge this abstract protocol
flow with existing interactions (and if possible associated use cases) to
see if we are missing something. After an agreement on the abstract
protocol flow we can make sure each interaction provides a mapping to step
1 to 7.

/Francis

On Thu, Jul 16, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> Hi Francis
>
> Thanks for drafting the sequence diagram and descriptions! I really like
> where. you are going with it.
>
> As our objective is to provide an abstraction,  what do you think of
> collapsing steps 2&3, 5&6, and 8&9 in the diagram?
>
> Per the discussion to your post, there is also some tuning of the
> descriptions of each step. I would also add in which steps are optional.
>
> Referencing other parts of the document would be useful, as this
> abstraction is intended to be a high level guide to the protocol, so adding
> other top level sections to the document, even if they are thin, would help
> the reader in grasping the possible flows.
>
> /Dick
>
> On Thu, Jul 16, 2020 at 9:57 AM Denis <denis.ietf@free.fr> wrote:
>
>> Hello Francis,
>>
>> Hello Denis,
>>
>> On Thu, Jul 16, 2020 at 8:45 AM Denis <denis.ietf@free.fr> wrote:
>>
>>> Hello  Francis,
>>>
>>> The first two steps of your scenario are nice, in particular the second
>>> one:
>>>
>>> (2) Service Intent: In order to discover *authorization requirements*,
>>> the Client sends a service intent to the RS.
>>>
>>> This means that the client first contacts the RS, instead of the GS.
>>>
>>
>>> However, the third step is missing to disclose to the client these "*authorization
>>> requirements*", in particular which AS(s),
>>> it may contact, which attributes are requested and how/when/where the
>>> user consent is gathered.
>>>
>>> The response (2) AuthZ Challenge carries the reference to the GS. Mean
>> the resource server instructs the Client on which GS to approach for
>> authorization.
>>
>> This information was not mentioned in your description.
>>
>>
>>> Unless the scenario is mandating all the RSs to trust one and only one
>>> GS and the client to have a relationship with that GS,
>>> the remaining steps of this scenario do not work.
>>>
>>> Can you elaborate why it shall not work for many GSs?
>>
>> Your answer above mentions : "which GS to approach for authorization". It
>> uses the singular whereas it should use the plural.
>>
>> In addition, indicating only which GS*s* (plural) is insufficient, since
>> the RS also needs to indicate to the Client which attributes
>> are requested for each of these GSs.
>>
>> Your description is also silent to explain how/when/where the user
>> consent is gathered.
>>
>>
>>>
>> Step (5) mandates the GS to know who the owner of a given RS is
>>>
>> Step (5) mandates the GS to know the RO, as owner of the target Resource,
>> but not the RS (Resource Server). Resource not-equals RS.
>>
>> , and thus mandates the client to disclose to the GS the identity of the
>>> RS.
>>>
>>
>> No. Here there is no requirement from GS to know the RS.
>>
>> In your are using the terminology of RFC 6749, then page 5 states:
>>
>> In OAuth, the client requests access to resources controlled by the
>> resource owner and hosted by the resource server.
>>
>> In order to make sure that the right RO is in charge of the appropriate
>> RS, the GS needs to maintain a mapping between the RS and the RO.
>> The client does not know who the ROs are.
>>
>>
>>
>>> The consequence is the following : this scenario, *as well as the
>>> scenario described in draft-hardt-xauth-protocol-13*, allows the GS to
>>> act as Big Brother.
>>>
>> No.
>>
>> If the GS is in a position to know when a client is attempting to make an
>> access to a given RS, then it can maintain logs of these events.
>>
>> RS will find a way to validate AuthZ produced by any GS.
>>
>> No. A RS trusts some GSs for some kinds of attributes. It does not trust
>> all the GSs that might exist in the world.
>>
>> Means RS must trust that very GS or trust somebody that trusts that very
>> GS (e.g. CA).
>>
>> Trust relationships are not necessarily transitive (nor bilateral).
>>
>> GS must not know the RS but must understand the Resource and trust the
>> Resource Owner, so that GS can validate the RO Grant.
>>
>> It would be interesting if you could elaborate on the last part of this
>> sentence :
>> "[GS] must understand the Resource and trust the Resource Owner, so that
>> GS can validate the RO Grant".
>>
>> Denis
>>
>>
>> /Francis
>>
>>>
>>> Denis
>>>
>>> Hello Fabian,
>>>
>>> On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault <fabien.imbault@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> That's interesting, however the important logic is actually implemented
>>>> within (5). And so for the reader, it might be quite difficult to
>>>> understand what we're after (compared to oauth2 for instance). So in my
>>>> view, this kind of schema has its place, but not at the start of the
>>>> document where we should primarily be concerned about explaining why
>>>> someone should read the document..
>>>>
>>>> It's also not easy to understand :
>>>> - why we sometimes use different labels between requests and responses
>>>> (for instance, 5 and 6)
>>>>
>>> Will need support in drafting the correct terms. The main purpose of
>>> this diagram is to help sharpen the definition of terms and verbs used in
>>> the draft.
>>>
>>> - sometimes we use "grant" and sometimes "authZ", and it doesn't seem
>>>> very clear what is the difference in use
>>>>
>>> IMO: the granting is the process of given permission.
>>> - RO can grant his Consent to the User or Client
>>> - GS can turn the RO Grant into an AuthZ.
>>> - Client can use AuthZ to access a Resource.
>>>
>>> A terminology section would be great to clarify.
>>>>
>>> Yes. There is a terminology section in there. We need to bring the
>>> wissing words into the list and sharpen those already there.
>>>
>>>>
>>>> If I understand correctly your remark in 5, you think the
>>>> request/response scheme (as in XYZ) may be misleading.
>>>>
>>> No. XYZ does IMO exactly  that. Just try to be more abstract for a
>>> better description of the models.
>>>
>>>
>>>> On the contrary, I think it allows support rich interaction scenarios
>>>> (and especially the ones you describe) with greater flexibility.
>>>>
>>> Flexibility shall not be put ahead of formal correctness.
>>>
>>>
>>>> For instance, some would disagree with the assertion that the goal is
>>>> for the GS to gather consent (see discussion on putting that on client
>>>> side). A fixed interaction schema has the downside of not permitting other
>>>> setups.
>>>>
>>> This discussion is the result of the lack of sharp terminology. Most of
>>> the time mixing up gathering consent (the act) and the way consent is
>>> gathered and transported from RO to GS (the interaction).
>>> /Francis
>>>
>>>
>>>> Fabien
>>>>
>>>> On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha <fpo=
>>>> 40adorsys.de@dmarc.ietf.org> wrote:
>>>>
>>>>> Hello Dick,
>>>>>
>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2. Abstract Protocol Flow
>>>>>>>>> I am missing an abstract protocol flow like the one defined in
>>>>>>>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's an interesting point. GNAP also has identity claims, so the
>>>>>>>> abstract flow is somewhat different (there is no Authorization Grant from
>>>>>>>> the RO), and not all steps always happen. (there may not be steps (E) and
>>>>>>>> (F) with a Resource Server)
>>>>>>>>
>>>>>>>> Would you elaborate on what you think would be useful here, that is
>>>>>>>> not in the specific flows?
>>>>>>>>
>>>>>>> A diagram that generalizes the steps, independently of interaction
>>>>>>> mode is essential for the reader's navigation of the rest of the
>>>>>>> document. This is what #section-1.2 of RFC6749 does. I hope we can produce
>>>>>>> a similar diagram.
>>>>>>>
>>>>>>> A subsection of
>>>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>>>>> could be defined for this.
>>>>>>>
>>>>>>
>>>>>> Interaction modes are one dimension where the steps could be
>>>>>> generalized, but some steps are optional. For example, the User may not
>>>>>> interact with the GS, and the GS may interact with the RO. The Client may
>>>>>> only want claims, and there would be no step of the Client calling the RS.
>>>>>>
>>>>>> A generalized diagram would need to include all optional steps so
>>>>>> that it did not mislead a reader into thinking the diagram included all
>>>>>> general steps, but it does not seem that is what you are asking for as you
>>>>>> wrote:
>>>>>>
>>>>>> A subsection of
>>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>>>> could be defined for this."
>>>>>>
>>>>>> Perhaps you can share how you think the diagram would look?
>>>>>>
>>>>> find below my proposal of an abstract sequence diagram.
>>>>>
>>>>> +----+  +------+  +---+  +---+  +---+
>>>>> |User|  |Client|  |RS |  |GS |  |RO |
>>>>> +----+  +------+  +---+  +-+-+  +-+-+
>>>>>   |(1) Service Request     |      |
>>>>>   |-------->|       |      |      |
>>>>>   |         |(2) Service Intent   |
>>>>>   |         |------>|      |      |
>>>>>   |         |(3) AuthZ Challenge  |
>>>>>   |         |<------|      |      |
>>>>>   |         |(4) AuthZ Request    |
>>>>>   |         |------------->|      |
>>>>>   |         |       |      |(5) Consent Request
>>>>>   |         |       |      |----->|
>>>>>   |         |       |      |(6) Grant Consent
>>>>>   |         |       |      |<-----|
>>>>>   |         |(7) Grant Access (Token)
>>>>>   |         |<-------------|      |
>>>>>   |         |(8) Service Request (Token)
>>>>>   |         +------>+      |      |
>>>>>   |         |(9) Service Response |
>>>>>   |         |<------|      |      |
>>>>>   |(10) Service Response   |      |
>>>>>   +<--------|       |      |      |
>>>>>   +         +       +      +      +
>>>>>
>>>>> (1) Service Request: This is the service request sent by a User to the
>>>>> Client. This can be a simple file read request or even a complex payment
>>>>> initiation request.
>>>>>
>>>>> (2) Service Intent: In order to discover authorization requirements,
>>>>> the Client sends a service intent to the RS.
>>>>>
>>>>> (3) AuthZ Challenge: The response to a service intent request is
>>>>> generally an AuthZ Challenge. The content of this AuthZ Challenge, can be
>>>>> an identification challenge, an AuthZ exemption, or details on requested
>>>>> AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.
>>>>>
>>>>> (4) AuthZ Request : the Client sends an AuthZ Request to the GS
>>>>> including the AuthZ Challenge. This request can be similar to the oAuth PAR
>>>>> request.
>>>>>
>>>>> (5) Requests Consent : GS sends consent request to RO.
>>>>> Remark: The abstract protocol flow does not display a response of the
>>>>> request (4) to the Client. This is IMO a general misunderstanding. This
>>>>> protocol wants the GS to collect a consent from the RO.
>>>>> - In the case of a "redirect interaction", GS will use transport
>>>>> infrastructure provided by the Client to instruct the User to send the RO
>>>>> to the GS (in most cases, user and RO are identical).
>>>>> - In the case of a "decoupled interaction", GS will directly contact
>>>>> RO and collect consent in a direct interaction with the RO (see CIBA).
>>>>> - In the case of an "embedded interaction", GS will allow the Client
>>>>> to directly collect the Consent of the RO in a direct interaction with the
>>>>> User.
>>>>>
>>>>> (6) Grant Consent : RO return a Consent Grant to GS.
>>>>>
>>>>> (7) Grant Access : GS produces the corresponding access token and
>>>>> returns it to Client.
>>>>>
>>>>> (8) Service Request : Client uses the access token to send the service
>>>>> request to RS.
>>>>>
>>>>> (9) and (10) are self explaining....
>>>>>
>>>>> One of our upcoming exercises will be to challenge this abstract
>>>>> protocol flow with existing interactions (and if possible associated use
>>>>> cases) to see if we are missing something. After an agreement on the
>>>>> abstract protocol flow we can make sure each interaction provides a mapping
>>>>> to step 1 to 10.
>>>>>
>>>>> I will strip the rest of the post here. And bring further responses in
>>>>> separate mails.
>>>>>
>>>>> Best regards.
>>>>> /Francis
>>>>>
>>>>>> ᐧ
>>>>>>
>>>>> --
>>>>> Francis Pouatcha
>>>>> Co-Founder and Technical Lead
>>>>> adorsys GmbH & Co. KG
>>>>> https://adorsys-platform.de/solutions/
>>>>> --
>>>>> Txauth mailing list
>>>>> Txauth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>
>>>
>>> --
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead
>>> adorsys GmbH & Co. KG
>>> https://adorsys-platform.de/solutions/
>>>
>>>
>>>
>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead
>> adorsys GmbH & Co. KG
>> https://adorsys-platform.de/solutions/
>>
>>
>>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/