Re: [Txauth] Key handle vs client id & handle

Tom Jones <> Mon, 27 July 2020 02:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EB673A15F0 for <>; Sun, 26 Jul 2020 19:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ghJznb_4o_-t for <>; Sun, 26 Jul 2020 19:15:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 415EE3A15E9 for <>; Sun, 26 Jul 2020 19:15:36 -0700 (PDT)
Received: by with SMTP id t6so2876259ooh.4 for <>; Sun, 26 Jul 2020 19:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fYNFZ5v+8E7CUjhMndioVY11XMIZ7sMiA65CdzPl9Do=; b=kgxQbIrsC6BgN5TCMOFiNttJHWZ9M2DrTmcFPN+itPHwLQBa9Nfn1Qz34yeEtyYRMr qZ5YAf80Pvib1HITq1J+klO6pttIxolQiJrNgkMAc+WCMg4HmF4AHA5BOUdUgbQsplhj SMYQsJe/D0BvfHe9ygRtpGpYD9kwiXPCV/A/eghR0LZX/gr48mPPGS37xawOJB+aaQAP FXqFtck6sIBrlBo7R9zns5wxq2Nkwl0r2k8KXA0db4bzGi5YtteucvVsxCTMimGrobwL jT6Jq2dJcfQzx01WI0M5yX57N3nkQpw7D8TTHwcEuA5PRfoWeMXvdzZ8Cbhpmcc3sm/E WzYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fYNFZ5v+8E7CUjhMndioVY11XMIZ7sMiA65CdzPl9Do=; b=GMp1CK+XGuwKAGRcepwwq2bItisnG9P8GiY+7br7BuKQZprOJ8jxaInNYHOoevlWvR kSH6w6/ZTLKnYLjYoF/66wIWVTMQV9uosBC1mqolCVO3qoauB3Y+TCdKRbxycbW1Ov+Z X0aFh19l8gg0b3aa39IX6/8W3iNbM6+SFmx3XEE5OocyOA+nODUeEhXlA+Yixk/KZcAY aHqSpW2QUKifJPOibBti1AXtaHqCQNZhykQbn6qe82D2M5HmvKkePwF4j9hPGgJ1LWlE VE+itpI1RULIwYmdI5ZiZ4ePjbgsBmYYT+V7at239ZHsDmwah5CJNEXxXUkcgSHG47RK 7THA==
X-Gm-Message-State: AOAM530wimbjqPM3mNHZiGjgv0g+JNGSd8R5kXext+1eEp1NiEkZdblv n4JqOVQFEPJBHxgfo/2M/KrZvI4DyX/+ftQ5N2c=
X-Google-Smtp-Source: ABdhPJysDaCfULAaFg0q7BTrFZ/H+oE1IGXoD2/N9c9cLl3Rst1YluSs84wNcuJiJZi7yND9Ev6yZbe3XZahE5Y2wPw=
X-Received: by 2002:a4a:ac8c:: with SMTP id b12mr5522237oon.27.1595816135278; Sun, 26 Jul 2020 19:15:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Jones <>
Date: Sun, 26 Jul 2020 19:15:23 -0700
Message-ID: <>
To: Francis Pouatcha <>
Cc: Dick Hardt <>, Justin Richer <>, Mike Jones <>, Fabien Imbault <>, Mike Varley <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000dec4f005ab62e513"
Archived-At: <>
Subject: Re: [Txauth] Key handle vs client id & handle
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2020 02:15:40 -0000

one other tf could be "I am bound the terms of the GDPR".
If we go that way at all, I would also recommend a MUST or at least a
SHOULD "jurisdiction" field.
GNAP may as well take the moral high ground, it is pretty much empty space
right now.
Peace ..tom

On Sun, Jul 26, 2020 at 6:55 PM Francis Pouatcha <> wrote:

> +1 Tom's input.
> This discussion about Key Handle vs. client id & handle wouldn't exist if
> GNAP had the notion of TF defining how the GS/RS/Clients identify
> and authenticate each other.
> A simple TF can describe the standard case (happy path) without having to
> foresee all eventualities.
> A GNAP profile will also be simple as it will keep out everything else
> (e.g. US Healthcare, PSD2).
> BR
> /Francis
> On Sun, Jul 26, 2020 at 9:43 PM Tom Jones <>
> wrote:
>> You should consider a trust framework to be first of all a set of
>> qualifying criteria above and beyond the literal meaning of the standard.
>> Ours is focused on US Healthcare, but lots of others make sense. The
>> international R&E org is the basis for the openid federation doc.
>> Secondarily the trust framework could vet members so that they made
>> affirmative statements about their compliance.
>> Tertiary they tf could mandate testing of the members. That is the case
>> for US Healthcare.
>> the tf could be blank for sites with no moral scruples whatsoever. (the
>> majority of sites i am sure.)
>> Peace ..tom
>> On Sun, Jul 26, 2020 at 6:18 PM Dick Hardt <> wrote:
>>> Hi Francis
>>> While a Trust Framework concept looks to make sense for PSD2 use cases,
>>> there are lots of other use cases.
>>> How would you see existing OAuth 2 and OIDC concepts fitting into a
>>> Trust Framework concept?
>>> /Dick
>>> ᐧ
>>> On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha <> wrote:
>>>> I just read through some work being done by Tom at the FIRE (Federated
>>>> Identifiers for Resilient Ecosystems) working group and it confirms my
>>>> intention of suggesting the consideration of a "Trust Framework" as a
>>>> context defining how to handle the client_id.
>>>> The procedure the GS applies to trust a client is derived from the
>>>> "Trust Framework" that governs the environment in which GS and Client are
>>>> operating.
>>>> In the European PSD2 ecosystem, National Country Authorities (a.k.a
>>>> Market Authorities or Regulators):
>>>> - delegate the production of client certificates to Trust Service
>>>> Providers (TSPs). TSPs are known certification authorities (CAs) in the
>>>> corresponding countries.
>>>> - maintain a register of Certified Third Party Providers (TPPs) at the
>>>> European Banking Association (EBA), where the validity of the TPP license
>>>> can be verified, in addition to the client certificate.
>>>> Designing an authorization framework around the PSD2 ecosystem, there
>>>> is no need to maintain any static or dynamic client_id. Each request is
>>>> associated with an SSL client certificate called QWAC (Qualified Website
>>>> Assertion Certificate).
>>>> - This certificate can be verified as the GS maintains a list of all
>>>> known TSP's CA authorized to release PSD2 client certificates.
>>>> - This certificate also contains the list of roles assigned to the TPP
>>>> by the regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI
>>>> (account information), PSP_IC (card) sufficient for the client access
>>>> control in the PSD2 trust framework.
>>>> - This certificate contains a permanent "Competent Authority" that
>>>> uniquely identifies the NCA issuing the TPP license.
>>>> - This certificate contains a permanent "Authorization Number" that is
>>>> unique in the context of the NCA.
>>>> - so AuthorizationNumber@CompetentAuthority is globally unique in the
>>>> context of the PSD2 trust framework.
>>>> Given these facts, GS implementing PSD2 do not need to register
>>>> clients.
>>>> - Each request of the client to the GS can be mTLS secured using the
>>>> QWAC.
>>>> - GS can extract all information needed to perform authorization from
>>>> that certificate.
>>>> This use case does not need an extra client_id at the protocol level.
>>>> This is:
>>>> - based on the experience we are making implementing PSD2,
>>>> - based on my reading Tom's FIRE use case in the health sector on the
>>>> sharing of Patient Health Information (PHI) among health care providers,
>>>> I suggest GNAP introduces the notion of "Trust framework" that governs
>>>> the environment in which RS, GS and Client interoperate. We can then
>>>> delegate the decision on specifying the necessity and functions of a
>>>> client_id to the trust framework.
>>>> On Thu, Jul 16, 2020 at 7:58 PM Tom Jones <>
>>>> wrote:
>>>>> I have been working on different level s of identifier, but from the
>>>>> mobile app perspective. That's the hardest case as you need to boot strap
>>>>> trust. I suspect that in the web site case you will need these levels.
>>>>> Transport, application, real world.
>>>>> If anyone wants to work on these, let me know and I'll get you the
>>>>> links in Kantara.
>>>>> thx ..Tom (mobile)
>>>>> On Thu, Jul 16, 2020, 2:47 PM Justin Richer <> wrote:
>>>>>> For all of these, I still say we should have different levels of
>>>>>> identifier. A “client ID” should identify the client, and not be used as a
>>>>>> stand-in for other things.
>>>>>> Off the top of my head I think we might want to have identifiers,
>>>>>> assertions, proofs, and other trust-binding items for:
>>>>>>  - Organizations
>>>>>>  - Devices
>>>>>>  - Software applications
>>>>>>  - Software instances
>>>>>>  - Software versions
>>>>>> So if we’re going to talk about identifying these aspects, we should
>>>>>> tackle each as its own thing and not mush it all into “client_id”. That
>>>>>> way, hopefully, GNAP can have a much better idea what a “client” is than
>>>>>> OAuth 2 currently does.
>>>>>>  — Justin
>>>>>> On Jul 16, 2020, at 4:34 PM, Dick Hardt <> wrote:
>>>>>> One client identifier was a simplistic example. Org A may have
>>>>>> numerous clients, perhaps in different teams, perhaps in different
>>>>>> services, each with their own policy at Org B.
>>>>>> When one of the Org A clients makes a call to the Org B AS, it needs
>>>>>> to identify itself with some identifier so that Org B knows which policy to
>>>>>> enforce. Why not the Client ID?
>>>>>> I also agree with your comments that other client identification
>>>>>> situations are different, and forcing the same identification model on them
>>>>>> does not make sense, but I fail to see the value throwing out a concept
>>>>>> (client_id) that has worked well for the use cases it was designed for.
>>>>>> ᐧ
>>>>>> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer <>
>>>>>> wrote:
>>>>>>> I think that the cross-organizational trust model is an interesting
>>>>>>> one, and in fact it’s one of the things that’s pushed me away from a
>>>>>>> client_id. In the scenario that you describe, “client_id” is used to
>>>>>>> represent something that it was never meant to represent: the organization
>>>>>>> running the software, not the software itself. It isn’t a client_id, and
>>>>>>> while in OAuth 2 the client_id could be co-opted to carry that information,
>>>>>>> it’s considered bad practice to share client_ids between multiple pieces of
>>>>>>> software.
>>>>>>> I would argue that to address this use case properly, there should
>>>>>>> be another level of identifier to bridge that trust that the software can
>>>>>>> present, showing that it is a part of Organization A, and not Organization
>>>>>>> C. This isn’t a client identifier, it’s an organization identifier, and it
>>>>>>> should be separate. You might want to identify both the client instance as
>>>>>>> well as the organization it’s a part of, for example. This is part of the
>>>>>>> motivation behind putting “organizational data” within scope for the client
>>>>>>> to send to the AS, after all.
>>>>>>> Therefore, I strongly disagree that this scenario “requires” a
>>>>>>> client_id to be solved. In fact, I think that solving this scenario with a
>>>>>>> client_id is an anti-pattern that stems from OAuth 2’s over-reliance on
>>>>>>> client_id as a persistent identifier within the protocol, and we can and
>>>>>>> should do better with GNAP. It’s very similar to Mike Jones’s referenced
>>>>>>> federation document, where the client_id is co-opted as a means of
>>>>>>> bootstrapping client registration and discovery, or in the Solid
>>>>>>> Authentication specification which stuffs a WebID into the client_id field.
>>>>>>> With OAuth 2’s ecosystem, we’ve used the tools that we had to solve
>>>>>>> our problems, and come up with some very clever solutions. What I’m trying
>>>>>>> to argue to this community is that we are in a position to create our own,
>>>>>>> better tools.
>>>>>>>  — Justin
>>>>>>> On Jul 16, 2020, at 2:00 PM, Dick Hardt <>
>>>>>>> wrote:
>>>>>>> Justin,
>>>>>>> While I agree that the assumption in OAuth 2 that all Clients have a
>>>>>>> client_id is problematic, the requirement for a client_id in many use cases
>>>>>>> is still there, and it does not represent a piece of software, but a
>>>>>>> relationship between parties.
>>>>>>> Organization A writes client software that calls resources managed
>>>>>>> by the AS in Organization B. The client_id represents Organization A to
>>>>>>> Organization B. Organization B does not care what software Organization A
>>>>>>> is running, and there may be numerous pieces of software at Organization A
>>>>>>> that use the same client_id. The access granted by Organization B to
>>>>>>> Organization A needs to be able to be different than the rights granted to
>>>>>>> Organization C.
>>>>>>> I agree that we don't want to force all clients to have a client_id,
>>>>>>> and as discussed, there are a variety of inputs for an AS to accept calls
>>>>>>> from a piece of software, and often, that will be a particular
>>>>>>> *instance* of the software, but we also don't want to force clients
>>>>>>> to all be treated the same, because they are not..
>>>>>>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer <>
>>>>>>> wrote:
>>>>>>>> Exactly — when we start to look at it as managing the lifecycle of
>>>>>>>> a piece of software, instead of a registration at the AS, we can start
>>>>>>>> thinking in different terms what “trusting” the client means in the context
>>>>>>>> of what the client is doing. That trust could come from some kind of signed
>>>>>>>> attestation about the software (like the OAuth 2 DynReg software
>>>>>>>> statement), or it could come from some externally fetchable item (like a
>>>>>>>> Solid WebID, a DID, or the OIDC Federation extension), or it could come
>>>>>>>> from someone sitting at a console and typing in information and getting
>>>>>>>> back an identifier. And none of these need to pretend to be a global
>>>>>>>> “client id” for it to work. The world of clients is much more diverse than
>>>>>>>> OAuth 2 likes to admit, and we see that with trying to nail down a
>>>>>>>> “confidential” vs. “public” vs. “dynamic” vs. “static” vs. “automatic” vs.
>>>>>>>> “ephemeral” vs. … any number of other things.
>>>>>>>> OAuth 2 only needs client IDs because the front channel needs a way
>>>>>>>> to pass client identifiers when the client can’t authenticate itself
>>>>>>>> directly. We tried to get rid of this restriction with PAR and JAR
>>>>>>>> together, but there turned out to be corner cases in OAuth 2’s world that
>>>>>>>> still needed client_id, and implementations assumed it would be there
>>>>>>>> anyway.
>>>>>>>> In GNAP, we can avoid that problem from the beginning by looking at
>>>>>>>> the model differently and understanding where we’re coming from, and why.
>>>>>>>>  — Justin
>>>>>>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault <
>>>>>>>>> wrote:
>>>>>>>> +1 on that.
>>>>>>>> We can then see it more as life cycle management of the client than
>>>>>>>> registration per say, and this comes with many benefits compared to the
>>>>>>>> current client_id.
>>>>>>>> Fabien
>>>>>>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer <>
>>>>>>>> wrote:
>>>>>>>>> I not only agree with Mike Jones that “automatic registration”
>>>>>>>>> should be part of the process, but I would argue that that kind of model
>>>>>>>>> should be a default mode of operation. If you have an identifier that you
>>>>>>>>> can send to short-circuit that, great! But we should focus on having the
>>>>>>>>> capability of inlining a lot of this information wherever possible. This is
>>>>>>>>> already the direction that the input proposals are heading.
>>>>>>>>> So I kind-of agree that “registration” is in scope for the
>>>>>>>>> protocol in general, and since both XYZ and Xauth have mechanisms that
>>>>>>>>> allow the client to present a key and get back an identifier that it can
>>>>>>>>> use in the future we have something equivalent.
>>>>>>>>> But I think there’s a little more to it than that: Ultimately, I
>>>>>>>>> think we should question thinking in terms of “registration”, a model which
>>>>>>>>> has hampered the OAuth 2 model in a lot of use cases. For example, the
>>>>>>>>> federation draft Mike Jones references below hacks the “client_id”
>>>>>>>>> parameter and makes it point to a document that the AS has to fetch. This
>>>>>>>>> construct is done for two reasons: (1) Oauth requires a “client_id” in the
>>>>>>>>> request and (2) it’s difficult to pass information by value to the AS due
>>>>>>>>> to front-channel restrictions. Since we’re defining a new protocol, we
>>>>>>>>> don’t need to hack that functionality into a “client ID” or equivalent and
>>>>>>>>> instead we can pass that information directly in the protocol. If we don’t
>>>>>>>>> assume that the client *has* to have a client ID equivalent, but it *can*
>>>>>>>>> have one in a set of defined circumstances, then I think we are in a much
>>>>>>>>> better spot. This is the reasoning for XYZ’s model of having clients
>>>>>>>>> identified by the key, and that key can potentially be passed by a
>>>>>>>>> reference identifier.
>>>>>>>>> I think all of the use cases that Mike Varley presents below are
>>>>>>>>> all valid directions, with the caveat that we shouldn’t assume a client
>>>>>>>>> should be presenting an ID at all steps. Mechanisms like software
>>>>>>>>> statements should be presentable apart from a client ID, as should
>>>>>>>>> on-device keys. We’re probably going to want extensions for device posture
>>>>>>>>> and other forms of attestation as well.
>>>>>>>>> This is one of the domains that I think we can clearly surpass
>>>>>>>>> OAuth 2’s flexibility and capabilities if we are willing to look past OAuth
>>>>>>>>> 2’s assumptions of what’s needed inline in the protocol.
>>>>>>>>>  — Justin
>>>>>>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley <
>>>>>>>>>> wrote:
>>>>>>>>> Is client registration in scope for the protocol?
>>>>>>>>> A generic way of handling clients (via ID or Handle or Key or
>>>>>>>>> whatever) is to have processing rule on the AS such as “if the AS
>>>>>>>>> recognizes the client ID (and authentication of that client ID) then it may
>>>>>>>>> process the request on behalf of that client. If the AS does not recognize
>>>>>>>>> the client ID, it must treat this as a new client registration and evaluate
>>>>>>>>> any authorization evidence the client provides before enabling the client
>>>>>>>>> and mapping policies to that client” (this means dynamic or automatic
>>>>>>>>> clients need to provide additional assertions / software statements
>>>>>>>>> whatever to register their ID.
>>>>>>>>> Something like this allows for very flexible systems:
>>>>>>>>> System A can be unknown to the AS but can dynamically registered
>>>>>>>>> each time with an appropriate software statement
>>>>>>>>> System B can have a fairly stable client ID at the AS, but rotate
>>>>>>>>> that ID every month through automatic registration (with an assertion it
>>>>>>>>> got from the AS during a pre-registration for example)
>>>>>>>>> System C can pre-register with the AS for a client ID because it
>>>>>>>>> doesn’t deal with software statements etc…
>>>>>>>>> …
>>>>>>>>> And even ‘StatelessAS’ can operate by never storing client IDs
>>>>>>>>> because it will always just rely on the software statements.
>>>>>>>>> I think a client registration protocol that allows these scenarios
>>>>>>>>> would be very useful in GNAP, but hopefully avoiding having to define what
>>>>>>>>> ‘evidence’ the AS needs to accept for each scenario.
>>>>>>>>> Thanks,
>>>>>>>>> MV
>>>>>>>>> *From: *Txauth <> on behalf of Mike Jones <
>>>>>>>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>>>>>>>> *To: *Dick Hardt <>om>, "" <
>>>>>>>>>>gt;, Justin Richer <>
>>>>>>>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>>>>>>> I agree that there are significant differences between statically
>>>>>>>>> and dynamically registered clients and that’s appropriate to be able to
>>>>>>>>> syntactically differentiate between them at runtime.  For one thing, the
>>>>>>>>> resource requirements at the authorization server can be very different.
>>>>>>>>> We should also be thinking about how to include what the OpenID
>>>>>>>>> Connect Federation spec
>>>>>>>>> calls
>>>>>>>>> “Automatic Registration”.  This lets the client encode a registration
>>>>>>>>> request reference in the client ID, so no static or dynamic registration
>>>>>>>>> even occurs.  See
>>>>>>>>> <>
>>>>>>>>> .
>>>>>>>>>                                                        -- Mike
>>>>>>>>> *From:* Dick Hardt <>
>>>>>>>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>>>>>>>> *To:*; Justin Richer <>du>; Mike
>>>>>>>>> Jones <>
>>>>>>>>> *Subject:* Key handle vs client id & handle
>>>>>>>>> + Mike as he had interest in this topic
>>>>>>>>> My understanding is that an existing OAuth 2 client would use
>>>>>>>>> their current client id as their key handle, and a dynamic client (one that
>>>>>>>>> was not pre-registered) would be given a key handle by the AS.
>>>>>>>>> There are potentially some significant differences between a
>>>>>>>>> registered client, and a dynamic client to an AS.
>>>>>>>>> The AS is likely to know the identity of a registered client, and
>>>>>>>>> have different policies between the two types of clients. For example, a
>>>>>>>>> registered client may have access to a 'write" scope, while a dynamic
>>>>>>>>> client does not.
>>>>>>>>> The AS may have 100s or 1000s of registered clients, but a dynamic
>>>>>>>>> client may have 10Ms or 100Ms of instances, which may dictate
>>>>>>>>> separate storage services. Additionally, internal to the AS, which systems
>>>>>>>>> can write to the registered client store is going to be different than the
>>>>>>>>> dynamic client store.
>>>>>>>>> In XYZ, subsequent calls to the AS, both registered clients and
>>>>>>>>> dynamic clients pass a key handle, so there is no easy way to differentiate
>>>>>>>>> between the two.
>>>>>>>>> While the AS could embed semantics in the key handle identifier to
>>>>>>>>> indicate which identifiers are pre-registered vs dynamic, there are many
>>>>>>>>> cases where the AS does need to know the difference, so making the
>>>>>>>>> difference a feature of GNAP seems like a better path.
>>>>>>>>> This email and any attachments are for the sole use of the
>>>>>>>>> intended recipients and may be privileged, confidential or otherwise exempt
>>>>>>>>> from disclosure under law. Any distribution, printing or other use by
>>>>>>>>> anyone other than the intended recipient is prohibited. If you are not an
>>>>>>>>> intended recipient, please contact the sender immediately, and permanently
>>>>>>>>> delete this email and its attachments.
>>>>>>>>> --
>>>>>>>>> Txauth mailing list
>>>>>> --
>>>>>> Txauth mailing list
>>>>> --
>>>>> Txauth mailing list
>>>> --
>>>> Francis Pouatcha
>>>> Co-Founder and Technical Lead
>>>> adorsys GmbH & Co. KG
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG