Re: [GNAP] Will GNAP support Zero Trust Architecture?
Alan Karp <alanhkarp@gmail.com> Mon, 22 March 2021 20:25 UTC
Return-Path: <alanhkarp@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 882D63A0E7E for <txauth@ietfa.amsl.com>; Mon, 22 Mar 2021 13:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 9Dq88h_A2j5r for <txauth@ietfa.amsl.com>; Mon, 22 Mar 2021 13:25:54 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 9E6D03A0E7F for <txauth@ietf.org>; Mon, 22 Mar 2021 13:25:54 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id z10so12025695qkz.13 for <txauth@ietf.org>; Mon, 22 Mar 2021 13:25:54 -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=r5gAd2TyHtxzT8kMYV3Y/bQiMYOCOc4UCUiFvZYTYDs=; b=pCfNlhoabXwo5F3UhX5a+xeP63HbT9HsBa8KUZOQwxQiJsu2OcVlDgW8nt/AnyLbji xYLhUD0c8e49Lz+rdmztG9WZNasqxygPrOhyCP9uLUmX7FZjRUQmG7X0Si4pWfjTYJhP GSgytMZdBCFdHZRRGy/M6BUsgXmMWUyV8N89fYx1o7sUQ1KsJ5lQjtVD7ch9rUnb+Eg8 lGGJXqOxozaUW6wGgsB1zP7jinTwfegkAEoTSZ5LDjfbKrBCDF423OD8Ov2Tvy58qmFo NtgQWKaLPshYmjM4pwj9zvjrKkoirZPQybN9z5iWCvEdmccsVasDoTObXz6axM9VDudt E02Q==
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=r5gAd2TyHtxzT8kMYV3Y/bQiMYOCOc4UCUiFvZYTYDs=; b=RiTCla+AYH2CZtD/qENKqEe0nGW+eeTHboIjwMqCVe1krCU7iI5C2mRjcz01VNuK3l NrYmbQcm98cfegmetkgcPBqN08J+Ft7rOyvNNMGWUT/c8D6gOPep0M/brf6j5ClZALD8 fGxGlzQQKx2ZVLIQuOfylMpTkqseIhz2ls2cu2E3KXdFLzX5+8nys2gCaEzEfa0Zez+r 5GGk7Y5BJowZezW5JIH+REdxysBwSYoWu7rJdpVDsXb/OC2VxECh23yGS13l8wu2927G Qs0q9howFoCaaMG4VqXY2U1udTuO3DM6uRcUKXiNVUBThmMiBu8Q4H4cxMyjV5dPtwQO xR/g==
X-Gm-Message-State: AOAM5331XiaSoAw8IZswD0ma0IyB34ZYwmhjLvf9z5pMvYmjUEUSDCbg RA1L/HQ8kN6DrVQIdwAO4M/mO9hJhXOTzL7nn5A=
X-Google-Smtp-Source: ABdhPJyXVAr5/W9weHtyYs5ipamU/M4i44xscfPd8jKsgzX9cR1PGwI+ZMuwf0Fb/xrxH0i440DPetcXvZTpIEazcIw=
X-Received: by 2002:a37:3c8:: with SMTP id 191mr1958562qkd.90.1616444752736; Mon, 22 Mar 2021 13:25:52 -0700 (PDT)
MIME-Version: 1.0
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <CANYRo8gMQYJXcb0FU2VCVcdbBLsopZ5Wfyo3hd1Pd5tmOSs0SA@mail.gmail.com> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <CANYRo8iPeeM3rLP9BYid2B71NzU7fR6J9Ra4=PSODTFE7i75Zg@mail.gmail.com> <CEECEE23-24D0-4C0C-B39E-9FDFF9E1E13D@mit.edu>
In-Reply-To: <CEECEE23-24D0-4C0C-B39E-9FDFF9E1E13D@mit.edu>
From: Alan Karp <alanhkarp@gmail.com>
Date: Mon, 22 Mar 2021 13:25:41 -0700
Message-ID: <CANpA1Z2S8Y3+U+jOa-ZbTzsZ9hkybCnGfzx0kP8VF=Z=Se4uew@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Adrian Gropper <agropper@healthurl.com>, Benjamin Kaduk <kaduk@mit.edu>, GNAP Mailing List <txauth@ietf.org>, Mark Miller <erights@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000049352d05be25dfad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/zG86anwR55U9tzp9NPzMZnbj3ig>
Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture?
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <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, 22 Mar 2021 20:26:00 -0000
Justin Richer <jricher@mit.edu> wrote: > > But with all that in mind, I think the key here is going to be looking at > what the inputs to the AS are, and how those can be defined in an > interoperable way for AS’s that can accept them. I think there’s a lot of > room for innovation and flexibility here that doesn’t break the trust model > or core use cases. If I have an AS-RS set that won’t accept my favorite > flavor of policy engine inputs, then I can decide not to use that one. But > this is a very different question than saying the RS itself needs to accept > my own AS — and we can’t keep conflating these two models. > > I agree. The point of having an AS-RO is to allow RO to specify a policy for which of RO's access tokens should be delegated under what conditions. AS-RS should not need to understand those policies. The flow would be - RO contacts AS-RS and gets one or more access tokens. - RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO. - A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO. - That user presents the access token delegated by AS-RO when invoking the resource. AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made. AS-RS does not need to understand the policy behind granting the delegation by AS-RO. -------------- Alan Karp On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote: > Adrian, > > I think this shows the problem with the terminology as it’s been applied > in this conversation, which I’ve tried to shine light on before. What you > and others are calling the “RS” is really the “AS and RS working together” > — everything to the right of the line. When Denis had brought up > “eliminating the AS” in another thread, what he’d really done is labeled > everything to the right of the line as the “RS”. Of course, the irony here > is that everything to the right of the line used all be called the “AS” or > simply “server” in the OAuth 1 days. As you say below, I don’t want the > client to have visibility on what happens on that side. > > Note well: The Google+ logo labeled “IdP” in the diagram is not the AS, as > far as GNAP is concerned. It does not issue an access token that the RS > will accept. The elements to the left of the line could be a lot of things, > but they are NOT the AS — by definition. The client lives over on the left, > but so do any external inputs to the AS. These could be policy inputs on > behalf of the RO, they could be presentation artifacts, they could be > federated logins, they could be the output of policy decisions. How the AS > comes to trust those things is up to the AS’s implementation. It’s > something we can talk about, but ultimately GNAP won’t be in any position > to dictate because in practice some AS’s are simply going to internalize > all policies and we will never successfully force those open. > > But with all that in mind, I think the key here is going to be looking at > what the inputs to the AS are, and how those can be defined in an > interoperable way for AS’s that can accept them. I think there’s a lot of > room for innovation and flexibility here that doesn’t break the trust model > or core use cases. If I have an AS-RS set that won’t accept my favorite > flavor of policy engine inputs, then I can decide not to use that one. But > this is a very different question than saying the RS itself needs to accept > my own AS — and we can’t keep conflating these two models. > > So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the AS, > not by subsuming or eliminating it. It is in fact the AS, not the client > and not the RS, that will request and consume the results of a > privacy-preserving zero-trust policy query thing. Anything that happens > downstream from that is of little concern to the zero-trust components > because, as you point out, it’s on the “other side” of the line. > > I think we got this basic component model pretty right in OAuth: the AS > and RS and client working together. Where OAuth misses the mark is the > assumption that the user has to log in to the AS through a webpage and > interact directly, thereby proving they’re the RO. It’s this latter space > where I think we can both push innovation and also address the important > and compelling use cases like the ones you’re bringing. > > — Justin > > On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com> > wrote: > > I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary > (the dotted line in the diagram) as being the RS. I don't expect any > visibility into what's going on on the right. > > My problem with the framing you propose is that requests are going to the > RS (or the AS-RS) and I don't want to share my policies with the AS-RS. I > want to keep the RS and AS-RS as ignorant as possible. > > Adrian > > On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote: > >> Adrian, >> >> What you’re discussing below, in terms of logging in to a site, is not >> approaching the RS. You are in fact approaching the client, and identifying >> both the AS and RS to the client. The client is a client *of your >> identity* in this model, and the RS is part of the identity provider. >> It’s really important that we don’t conflate the RS and client in this way >> as it leads to a lot of confusion downstream and a lot of broken trust >> boundaries. >> >> With that model in mind, approaching the “RS" and providing it your >> identity is really just a case of the “federated login to AS” pattern that >> we discussed on the WG call. The user here approaches an RS, which has its >> own AS. To share things from this RS, the RO has to authenticate to the >> RS’s AS. This particular AS allows the RO to do so using an external >> identity — in which case, the AS is now a “client” of a separate, >> disconnected (but layered) delegation. The ultimate client that eventually >> calls the RS down the way may or may not know about these layers. >> >> <PastedGraphic-1.png> >> This same AS, which is closely tied to the RS and trusted by the RS, >> might also take in FIDO credentials, or DIDs, or any number of other proof >> mechanisms. The output of this is an access token the RS trusts, but the >> input is up to the AS. The RS is not what you’re logging in to. >> >> — Justin >> >> On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com> >> wrote: >> >> I too am in favor of avoiding consolidation and correlation. Right now, >> when I approach a service provider (RS) for the first time, I'm offered the >> opportunity to identify my persona as: email, sign-in with Google, >> Facebook, or Apple. I know there are people who try to create one-off email >> addresses but that is mostly a waste of time. >> >> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I >> have a way to start out my RS relationship pseudonymously. >> >> When I want my resource to be discovered or shared I will post that RS >> URL including my pseudonym. If I then want to introduce a mediator in front >> of my AS or messaging service endpoint, I have that option. If I want to >> keep requests away from the mediator, I would publish an encryption key >> along with my pseudonym. >> >> - Adrian >> >> >> >> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote: >> >>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote: >>> > >>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote: >>> >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the Principle >>> Of Least >>> >> Authority (POLA) in a recent comment >>> >> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 >>> >> I recommend it. >>> >> >>> >> We might expect a protocol with authorization in the title to use >>> authority >>> >> as a core principle. I advocate for a GNAP design that maximizes the >>> power >>> >> of the RO, to be seen as a human rights issue when the RO is a human. >>> This >>> >> causes me to ask how to combine better security with better human >>> rights in >>> >> GNAP. >>> >> >>> >> Who should have the least authority in the GNAP design? >>> >> >>> >> The AS derives authority as a delegate of the RO. If we ask the RO to >>> >> partition limited authority across dozens of different ASs by domain >>> and >>> >> function, then we are not using technology to empower the individual. >>> >> Probably the opposite, as we introduce consent fatigue and burden >>> normal >>> >> people to partition their lives into non-overlapping domains. >>> >> >>> >> My experience says we should aim for one AS per persona because that >>> maps >>> >> into the way we manage our public and private identities. POLA would >>> then >>> >> teach care in keeping ASs and RSs related to work / public separate >>> from >>> >> ASs and RSs related to private life so that a policy vulnerability in >>> our >>> >> delegation to an AS would have the least likelihood of harm. >>> > >>> > Thinking about how least authority/least privilege would apply to GNAP >>> > seems like a useful exercise. I do want to point out some potential >>> > pitfalls with one-AS-per-persona that we can also be aware of. If >>> > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's >>> > identity in effect also serves as a persona identity and there are >>> privacy >>> > considerations to that. If, on the other hand, the >>> > multiple-personas-per-AS (presumably corresponding to multiple humans) >>> > route is taken, we should consider whether that would lead to various >>> > (e.g., market) forces driving consolidation to just a handful of >>> > super-popular AS services. That topic is a current matter of concern >>> to >>> > some IETF participants. >>> > >>> >>> Hi Ben, big +1 to this. This is something that we discussed ages ago in >>> the UMA working group, and it’s one of the biggest problems with the >>> personal AS (and personal data store) model. This kind of thing makes >>> RS-first trust models really difficult in practice. >>> >>> As a strawman, let’s say that I’ve got software that wants to access my >>> medical information. It calls an RS and requests access, but it hasn’t been >>> granted anything yet. Now I as the RO have set up the RS so that it talks >>> to my personal AS, that only I use. In addition to the RS having to be able >>> to figure out which medical records are being requested from the context of >>> the unauthenticated request (which means it needs identifiers in the URL or >>> something similar for the RS to be able to tell, assuming that it protects >>> data for more than one person). So this client software doesn’t know who I >>> am and doesn’t know my medical record information, makes a completely >>> unauthorized request to the RS, and the RS says “Go to Justin’s personal AS >>> to get a token”. The client can now make a direct correlation between the >>> data that’s being protected at the RS and the person running the AS that >>> protects it. Importantly, this client makes this call with no prior >>> relationship to the RS and no really auditable way to track it down after >>> the fact. This is a design feature in the good case, and terrifying in the >>> bad case. >>> >>> If the RS instead says “welcome to Medicine Doctor RS, please talk to >>> the Medicine Doctor AS to get access”, we haven’t exposed anything at all. >>> And from the perspective of both the patient and the RS, this is more >>> privacy-preserving, and it’s really the least surprising option. Once the >>> client gets to the AS, it can start a negotiation of figuring out who the >>> RO is for the information being accessed. >>> >>> On top of this, the usability expectations of people managing their own >>> AS, or set of AS’s for multiple personas to keep things separate, is a huge >>> burden. Even in the tech community, I know people who can’t reliably manage >>> more than one email address for different purposes. I wouldn’t expect my >>> partner to do that — they have trouble enough balancing all the logins and >>> sessions required for different kids remote schooling, I couldn’t imagine >>> them having to understand all the requirements for managing multiple >>> authorization servers and associated policies. I also don’t expect any >>> person to “manage keys” — I’ve been on the internet for decades and I can >>> barely keep tabs on my GPG keys, and only use them when I am forced to. >>> This is exactly the kind of “market pressure” that I think Ben mentions >>> above, people will just want to outsource that to someone else, and the >>> reality will be a few popular providers. >>> >>> In which case, we could end up doing a ton of work to allow an RS choice >>> only to end up with a world where the RS ends up making a limited choice >>> anyway. We see how that plays out with OpenID Connect — RP’s could allow >>> arbitrary IdPs but they choose Google because it works and that’s where the >>> users are. (And that’s not to say anything of the proprietary OIDC-like >>> protocols, but that’s another discussion). >>> >>> For further reading on these topics, I recommend both “Why Johnny Can’t >>> Encrypt” and “Why CSCW Systems Fail”. >>> >>> So what does this have to do with GNAP? I think we can be clear-eyed on >>> what kinds of expectations we have for the participants. If we expect users >>> (RO’s) to have to set up the AS-RS relationship, or expect them to carry >>> their AS, or manage their personal keys — I think we’ve lost the battle for >>> relevance. >>> >>> — Justin >> >> >> >
- [GNAP] Will GNAP support Zero Trust Architecture? Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Benjamin Kaduk
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Denis
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Fabien Imbault
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Denis
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Denis
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Justin Richer
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- Re: [GNAP] Will GNAP support Zero Trust Architect… Alan Karp
- Re: [GNAP] Will GNAP support Zero Trust Architect… Adrian Gropper
- [GNAP] Relationship between Authentication and Au… Denis
- Re: [GNAP] Relationship between Authentication an… Justin Richer
- Re: [GNAP] Relationship between Authentication an… Denis
- Re: [GNAP] Relationship between Authentication an… Justin Richer
- Re: [GNAP] Relationship between Authentication an… Denis
- Re: [GNAP] Relationship between Authentication an… Adrian Gropper
- Re: [GNAP] Relationship between Authentication an… Denis
- Re: [GNAP] Relationship between Authentication an… Adrian Gropper
- [GNAP] Alice a J&J COVID vaccine Denis
- Re: [GNAP] Alice a J&J COVID vaccine Adrian Gropper