[GNAP] Relationship between Authentication and Authorization ?
Denis <denis.ietf@free.fr> Fri, 26 March 2021 17:07 UTC
Return-Path: <denis.ietf@free.fr>
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 282423A2547 for <txauth@ietfa.amsl.com>; Fri, 26 Mar 2021 10:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.018
X-Spam-Level:
X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 WTqYgSF-zOWG for <txauth@ietfa.amsl.com>; Fri, 26 Mar 2021 10:07:11 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B7853A2445 for <txauth@ietf.org>; Fri, 26 Mar 2021 10:06:47 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d85 with ME id l56i2400H4zJUWJ0356iK8; Fri, 26 Mar 2021 18:06:44 +0100
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 26 Mar 2021 18:06:44 +0100
X-ME-IP: 90.79.53.231
To: txauth@ietf.org, Justin Richer <jricher@mit.edu>
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <CAM8feuS0YOWC-wpz=0GP1x-7EV6fdx0puimkS6AXJP=ZtYM8aA@mail.gmail.com> <CANYRo8hQjcEWrwK=scpopVSnzYQ6AiObk2RoLSS+U=V1jxo1EQ@mail.gmail.com> <CAM8feuT+noLdtUYaUGfzhezTea+Uy6+9xWfb814TOg4w0u_tOA@mail.gmail.com> <CANYRo8hHUqSoDHjGRpm6qZLSm=3rd8E5OEFjreDvDyMvjHOdUw@mail.gmail.com> <CAM8feuTJawB+msiSrYUeen15eHLDcOzD4diy6++DNoYYcHqMug@mail.gmail.com> <CAM8feuTqMXF4b+ZaEJpkfeTJeBsuf227VNC3p1sDGJByFUn8jA@mail.gmail.com> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <CANpA1Z3x2vZXsvtcKfvFMyrWKv0XxXVWaJ=B3eaTStmbFc+gXA@mail.gmail.com> <E1008110-FBE9-42F2-8649-6ECCF0459D7D@mit.edu> <CANpA1Z2kRZPLPY6qgAJ6KjxbwGTR6B4ZUq=JGsR-6g_STBrqNg@mail.gmail.com> <CANYRo8gXtwAi8f6iHmNfgoY7E1ism+mWJYJriccugHfus+EDmg@mail.gmail.com> <5773FA7B-6891-4227-A8CA-2F506909B8CD@mit.edu> <CANYRo8iG0KKe39Ws2avP59BNn0yJtGt3y6jQ8_zr5rmkNUbt-g@mail.gmail.com> <FFE20253-6086-43D2-84D4-C8E1BC9E6613@mit.edu>
From: Denis <denis.ietf@free.fr>
Message-ID: <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr>
Date: Fri, 26 Mar 2021 18:06:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <FFE20253-6086-43D2-84D4-C8E1BC9E6613@mit.edu>
Content-Type: multipart/alternative; boundary="------------93F7E09FFA01472A6B23BD51"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/ETdho4rPUSUKgbID3uBNoZM43KM>
Subject: [GNAP] Relationship between Authentication and Authorization ?
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: Fri, 26 Mar 2021 17:07:22 -0000
Hi everybody,
The content of this thread has nothing to do any more with its original
title which was: "Will GNAP support Zero Trust Architecture?"
Since I am going to use some sentences of this thread to open a new
topic, I changed the title of this thread into :
"Relationship between Authentication and Authorization ?"
At the moment, I got the impression that nobody agrees any more about
*what GNAP is or is not, what it should address and what it should not
address*.
The components of the model are becoming more numerous and hazy. A new
terminology is sometimes being used, but is not yet present in the last
published draft.
I still can't understand any of the new terms that are being used
(*AS-RS* and *AS-RO*), _which are still left undefined_.
The last exchanges look more as conversations between workers during the
construction of the Babel tower.
Last year, my first remark was to mention that a section or an Annex
explaining the common points and the differences with OAuth 2.0
would be useful. Such section or Annex still does not exist.
Justin wrote:
/If an RS allows a username/password HTTP Basic auth in addition to
accepting access tokens, it can do so, but //
//GNAP doesn’t have anything to say about the Basic auth use, or
even its relation to any access tokens or RO’s or anything else./
Let us split the end of this sentence into two parts:
"/GNAP doesn’t have anything //to say about the Basic auth use/": If an
authentication exchange is necessary, the draft document should
describe, for completeness,
the HTTP error code that will be returned.
"/or even its relation to any access tokens or RO’s or anything else/".
Let us suppose that a RS supports FIDO as an authentication mechanism to
authenticate its end-users.
FIDO provides the major advantage that, for every RS, a different
identifier is used by every end-user. This prevents end-users accounts
correlations between RSs by using
such identifiers. In practice, a FIDO identifier is a pseudonym.
At this very moment, the RS is able to identify and authenticate its
end-users using FIDO pseudonyms. Now, let us raise the following question:
How will a RS be bootstrapped for working with a GNAP "sub" claim or a
"sub_id" claim, whereas FIDO is already being used ?
Denis
> Adrian,
>
> I disagree, I believe that what I have laid out is exactly separating
> the concerns into working components.
>
> Like OAuth before it, GNAP is a protocol negotiate access for a client
> instance to an RS, using an AS as the facilitator of that delegated
> negotiation. (Unlike OAuth, it’s importantly also for negotiating user
> information to the client directly from the AS with no RS involved,
> but that’s an aside for the purposes of our conversation here).
>
> If a particular GNAP RS also allows other kinds of processes to enable
> access to it, that is completely fine, but outside of GNAP. If an RS
> allows a username/password HTTP Basic auth in addition to accepting
> access tokens, it can do so, but GNAP doesn’t have anything to say
> about the Basic auth use, or even its relation to any access tokens or
> RO’s or anything else. If an RS accepts structured access tokens
> signed by trusted keys that don’t come from an AS through a negotiated
> request — again, that’s fine, but GNAP is silent about the RS doing
> that. If the RS acts as “its own AS” then it’s really just an RS and
> an AS living in the same box. Again, that’s fine, and super common
> with OAuth today.
>
> GNAP is solving the problem of connecting the client to the RS through
> means of an AS. Other solutions are possible and many of them can be
> deployed right alongside, but that’s not the corner of the world that
> GNAP is solving. GNAP should be concerned about how these other
> technologies can be used alongside it. I think there’s a lot of room
> for the things that you’re talking about, and more importantly for
> solving the use cases that you’re bringing. But GNAP should be more
> than a single-point solution, and so we need to balance these
> concerns. The conceptual framework of an AS that takes in lots of
> different information and spits out access tokens is exactly the
> abstraction layer that is necessary for making these use cases
> interoperable.
>
> — Justin
>
>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper <agropper@healthurl.com
>> <mailto:agropper@healthurl.com>> wrote:
>>
>> @Justin, there’s no separation of concerns here. No partition between
>> processor and controller. No data minimization. And, I see no obvious
>> reason to make this the core of GNAP.
>>
>> The one thing we can probably all agree on is that there’s only one
>> RS and one RO.
>>
>> The core of GNAP, in my opinion, can be built and explained around
>> this simple design. The RS is a processor. The RO is a controller.
>> The RS bears only security responsibility. The RS bears no privacy
>> responsibility. The RO delegates this to the RS but this is not
>> authorization as the A in GNAP.
>>
>> The RO retains all rights to delegate within the scope of things that
>> the RS is willing to support using various token formats and endpoint
>> options. Some of these options may do all sorts of things for all
>> sorts of clients and user-agents but these are options.
>>
>> For example, if a request comes to the RS that is not in the form of
>> an access token, then it either gets sent to the RO or their agent,
>> or it gets logged and dumped. One such option, common in healthcare,
>> is “Break the Glass” where the RS is acting as an authorization
>> server because the user-agent is making a request instead of
>> presenting an access token. GNAP can offer this as an option but it
>> is not our core.
>>
>> Adrian
>>
>>
>>
>> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <jricher@mit.edu
>> <mailto:jricher@mit.edu>> wrote:
>>
>> I have a big problem with this line:
>>
>> > the RS and AS-RS only see access tokens. The requests (from
>> RO') that resulted in an access token are none of their business.
>>
>> In the trust model we’ve been discussing, the requests that
>> result in access tokens are *solely the business of AS-RS*, since
>> AS-RS is the only entity that’s allowed, and trusted by the RS,
>> to create access tokens for the RS. That is its entire job, the
>> entire reason it exists in the system. By definition the party
>> generating tokens for use at the RS is the AS for that RS, I
>> don’t care how you deploy it. If RO wants to give access to
>> someone else (who isn’t an “RO" anymore, they’re another
>> end-user), then that end user’s client software will need to talk
>> to AS-RS to get its own access token.
>>
>> Now here’s the trick: when the end user’s client instance talks
>> to AS-RS, that does NOT mean that AS-RS needs to know all the
>> details and policy reasons that it should give an access token to
>> that client instance. It doesn’t even need to know the existence
>> of another end user. It doesn’t need identity, it doesn’t need
>> policy. Sure, it COULD handle all of that internally, and many
>> will, but the protocol doesn’t demand it.
>>
>> This means that the first client instance, the one that gets the
>> access token, can also be given something alongside the access
>> token that it can then hand to another piece of software (or to a
>> person to hand eo their piece of software). This artifact is not
>> an access token. This artifact could be something structured that
>> the client understands, and can make derivatives of, and present
>> back to the AS-RS for getting new access tokens. There could be
>> multiple different flavors of this kind of artifact for different
>> kinds of environments and groups. But what they all have in
>> common is that they can potentially be used to request more
>> access tokens within some context at the AS-RS.
>>
>> — Justin
>>
>>
>>
>>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper
>>> <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote:
>>>
>>> My issue is with Alan's:
>>>
>>> "7. Another user agent (RO') can contact any holder of the
>>> access token or the service's policy agent (AS-RS) to get a
>>> delegated access token."
>>>
>>>
>>> I would prefer "7A.Another user agent (RO') can contact any
>>> holder of the access token." by default so that the AS-RS does
>>> not see the requests. In other words, the RS and AS-RS only see
>>> access tokens. The requests (from RO') that resulted in an
>>> access token are none of their business.
>>>
>>> The reality is that RO' can discover a resource RS and can share
>>> whatever information with RS-AS they want and the RO may not
>>> even know about it unless the RS decides to let them know
>>> somehow. This seems to be a drawback of the capabilities approach.
>>>
>>> In terms of privacy and control, I, as the RO, want a
>>> contract with the RS that says that I or my agent (AS-RO) must
>>> sign an access token. This is a fundamental audit requirement.
>>> Without it, a rogue RS and AS-RS can do all sorts of things and
>>> the RO would never know. I understand that a rogue RS might not
>>> support an honest contemporaneous log of access tokens presented
>>> so there's a trust issue here that I seems unavoidable unless I
>>> specify in my RO-RS contract that they use a separate
>>> contemporaneous log such as AS-RO for every access token
>>> presented and risk being sued if they process an access token
>>> without also updating the separate log.
>>>
>>> - Adrian
>>>
>>>
>>> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <alanhkarp@gmail.com
>>> <mailto:alanhkarp@gmail.com>> wrote:
>>>
>>> Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>>>
>>> Hi Alan,
>>>
>>> In all of my discussion, and in the spec itself, the RO
>>> is the :entity: in charge of approving rights. They’re
>>> probably a person. It might be software that makes a
>>> policy decision in some way, or a corporate entity, or
>>> something like that. But it’s not assumed to be a
>>> computational agent in the terms of the protocol itself.
>>> Would that recast what you’re saying below?
>>>
>>>
>>> Hmmm. I guess not. It's just that the person would be
>>> using some UI to express their decisions to what I called
>>> the user agent. That model fits in very nicely with what we
>>> did with Polaris, our virus safe computing environment for
>>> Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033
>>> <https://dl.acm.org/doi/10.1145/1151030.1151033>. The person
>>> would click on the icon for a Word file, and an instance of
>>> Word would open with only the permission needed to edit that
>>> one file. Same thing here. The client could ask for
>>> permission to use the resource, or permission could be
>>> granted implicitly when the user selects a resource
>>> associated with a specific client.
>>>
>>> --------------
>>> Alan Karp
>>>
>>>
>>> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer
>>> <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>>>
>>> Hi Alan,
>>>
>>> In all of my discussion, and in the spec itself, the RO
>>> is the :entity: in charge of approving rights. They’re
>>> probably a person. It might be software that makes a
>>> policy decision in some way, or a corporate entity, or
>>> something like that. But it’s not assumed to be a
>>> computational agent in the terms of the protocol itself.
>>> Would that recast what you’re saying below?
>>>
>>> — Justin
>>>
>>>> On Mar 25, 2021, at 12:36 PM, Alan Karp
>>>> <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com>> wrote:
>>>>
>>>> There seems to be some confusion about how AS-RO comes
>>>> into the picture, probably because of the "AS" part.
>>>> I'm going to try to clear up that confusion by more
>>>> carefully explaining what I mean.
>>>>
>>>> I'm assuming that RO is a computational agent
>>>> representing the person who is the resource owner,
>>>> something called the "user agent" in operating systems
>>>> lingo. I'm also assuming that it's possible to do
>>>> delegation, either locally or by token exchange with
>>>> AS-RS. All delegations are potentially sub-scoped, but
>>>> you may also want to delegate with full scope to have a
>>>> separately revocable access token.
>>>>
>>>> Here's an example of how things work in a capability
>>>> oriented system.
>>>>
>>>> 1. Someone, the service owner, creates a service.
>>>> 2. The service owner contracts with an policy agent
>>>> (AS-RS) to create and manage access tokens for that
>>>> service (RS).
>>>> 3. A person wishing to create a resource at RS uses
>>>> their user agent (RO) to contact the service
>>>> owner's policy agent (AS-RS) and gets back an
>>>> access token for that resource.
>>>> 4. That user agent (RO) can
>>>> 1. use that access token to invoke the resource, or
>>>> 2. delegate an access token to a client of the
>>>> user agent's (RO) choice, or
>>>> 3. contract with a policy agent (AS-RO) to manage
>>>> those delegations on behalf of the user agent
>>>> (RO), or
>>>> 4. specify a policy with the service's policy
>>>> agent (AS-RS).
>>>> 5. A client can contact any holder of the access token
>>>> (the user agent (RO) or its policy agent (AS-RO))
>>>> or the service's policy agent (AS-RS) to get a
>>>> delegated access token.
>>>> 6. That client can delegate that token to another client.
>>>> 7. Another user agent (RO') can contact any holder of
>>>> the access token or the service's policy agent
>>>> (AS-RS) to get a delegated access token.
>>>> 8. The other user agent (RO') can
>>>> 1. use that access token to invoke the resource, or
>>>> 2. delegate it to a client of its choice, or
>>>> 3. contract with a policy agent (AS-RO') of its
>>>> choosing to manage those delegations on its
>>>> behalf, or
>>>> 4. specify a policy with the service's policy
>>>> agent (AS-RS).
>>>> 9. and so on
>>>>
>>>> When any of these computational agents, user agents
>>>> (ROs) or clients acting on their behalf, invokes the
>>>> resource, AS-RS verifies that the access token is a
>>>> valid delegation, i.e., proper sub-scoping, hasn't been
>>>> revoked, and that it authorizes the request being made
>>>> before telling the service (RS) to honor the request.
>>>> At no point does the service's policy agent (AS-RS)
>>>> know which computational agent did any particular
>>>> delegation. (Token exchange can be done as anonymously
>>>> as possible.) In particular, the policy agents (AS-RO)
>>>> need not be the same, or even compatible with, the
>>>> service's policy agent (AS-RS). GNAP specifies the
>>>> protocol between requesters, invokers, delegators (for
>>>> token exchange) of tokens and AS-RS. That protocol
>>>> need not be used between user agents (RO), clients, or
>>>> other policy agents (AS-RO), but it is likely to be.
>>>>
>>>> -------------
>>>> Alan Karp
>>>>
>>>>
>>>> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer
>>>> <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>>>>
>>>> The way I’m thinking about Adrian’s use case is
>>>> that what we’re calling the “AS-RO” isn’t an “AS”
>>>> in the traditional OAuth/GNAP sense, at least not
>>>> exactly. This is the agent that the RO can use to
>>>> set policies and manage consent on their behalf,
>>>> and I’ve been arguing that it fits better into this
>>>> vaguely-defined “interaction component” aspect of
>>>> the current AS definition, and it’s not currently
>>>> separated from the AS definition. The “AS-RS” maps
>>>> to what we’d call the “AS” in OAuth/GNAP
>>>> traditionally, it’s what the RS trusts to issue
>>>> tokens. In traditional OAuth the AS-RO and AS-RS
>>>> are always the same thing, from a functional
>>>> protocol perspective. An important point here is
>>>> that from a client’s perspective, they’re only
>>>> talking to the AS-RS since that’s where the client
>>>> gets its tokens, because at the end of the day the
>>>> client just wants to call the API at the RS and
>>>> doesn’t care how that happens (from a protocol
>>>> standpoint).
>>>>
>>>> Note well: Even thought I don’t believe that
>>>> “AS-RO” is an authorization server at all, I’m
>>>> going to keep using that term below for consistency
>>>> with previous discussion.
>>>>
>>>> So we have these fundamental relationships around
>>>> getting the client to access the RS:
>>>>
>>>> 1. RS trusts AS-RS to issue tokens that RS will
>>>> accept, validate, and process for requests from client
>>>> 2. Client trusts AS-RS to issue tokens that client
>>>> can use at RS
>>>> 3. RO trusts RS to protect RO’s api through
>>>> delegated access
>>>>
>>>> On top of that, we’ve got some additional aspects
>>>> that we’re discussing:
>>>>
>>>> 4. RO trusts AS-RO to manage RO’s policies at runtime
>>>> 5. AS-RS trusts AS-RO to assert RO’s policies for
>>>> access to RS
>>>> 6. Client trusts whatever AS-RS sends client to
>>>> deal with, including possibly RO-AS at runtime,
>>>> because of (2)
>>>>
>>>> What I have been saying is that 4/5/6 are optional
>>>> details of how RS-AS runs things, and I think this
>>>> also maps with Adrian’s view of choice, since if my
>>>> RS’s AS-RS doesn’t allow me to plug in my own AS-RO
>>>> then I would be motivated to pick a different RS
>>>> who’s AS-RS lets me do just that. The same way I’d
>>>> pick a different RS if their surrounding services
>>>> didn’t accept my preferred federation login and I
>>>> didn’t want to make another account. Of course,
>>>> market forces being as they are, I might not have
>>>> much of an actionable choice in RS, but GNAP can’t
>>>> change that.
>>>>
>>>> What we can do is make it possible for AS-RS to
>>>> talk to AS-RO, both in philosophy of the protocol
>>>> design and in concrete hooks to support (6) above.
>>>>
>>>> Separately, we can approach the issue of making 1/2
>>>> above more dynamic. This was UMA2’s “federated
>>>> authorization” approach, and is behind a lot of the
>>>> “bring your own AS” models out there. The problem
>>>> with these is that we know from many years of
>>>> experience that most RS’s aren’t interested in
>>>> doing anything of the sort.
>>>>
>>>> So with GNAP we can instead allow 4/5/6 to vary in
>>>> a predictable and consistent way, letting the RS
>>>> keep control over 1/2, thereby enabling choice in
>>>> (3). We don’t have to be the ones who define the
>>>> all of the details of every permutation of (5) to
>>>> enable this, though. Some of this is going to be
>>>> configuration out of band, some of it’s going to be
>>>> communication at runtime. This is where VC’s,
>>>> ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of
>>>> other tech can come in and help out. I don’t think
>>>> we need to put all the details for using these into
>>>> core, nor do I think we’ll pull of The Great And
>>>> Ultimate Abstraction for using these and other
>>>> approaches. But we can at least start talking about
>>>> “AS-RS” in such a way that it no longer assumes
>>>> it’s always the same party dealing with the RO
>>>> directly.
>>>>
>>>> — Justin
>>>>
>>>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>> wrote:
>>>>>
>>>>> To reframe it closer to GNAP:
>>>>> - AS = AS-RO, that's where you find the RO
>>>>> policies. The AS issues access tokens to the client.
>>>>> - the RO policies could be a) defined locally or
>>>>> b) in relationship with the RS
>>>>>
>>>>> There have been several ideas related to the AS-RS
>>>>> relationship b:
>>>>> b1) the RS issues capabilities (which can be
>>>>> further attenuated by the RO)
>>>>> b2) Adrian also discussed a DID based solution
>>>>> b3) there was also an alternative ACL proposal
>>>>> from Denis (+ preflight)
>>>>>
>>>>> Fabien
>>>>>
>>>>>
>>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>> wrote:
>>>>>
>>>>> Ok so I get you correctly:
>>>>> - what matters is the RQ (could be a RO or a
>>>>> end-user or both : we don't really care at a
>>>>> high-level, they're all treated as entities
>>>>> that make a request)
>>>>> - the policy is able to handle those different
>>>>> cases, based on its own internal delegation
>>>>> protocol
>>>>> - currently that requires AS-RS and AS-RO, but
>>>>> maybe it can be simplified
>>>>>
>>>>> To answer to Denis, here's what I understood:
>>>>> - RO trusts AS-RS (and then handles its own
>>>>> policies within AS-RO)
>>>>> - end-user trusts AS-RO (through its client)
>>>>>
>>>>> Could probably work but that's a fairly
>>>>> different model compared to OAuth2 (and of
>>>>> today's GNAP), with different frontiers
>>>>> between the AS and the RS.
>>>>>
>>>>> Please do not hesitate to correct me if I'm wrong.
>>>>>
>>>>> Fabien
>>>>>
>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper
>>>>> <agropper@healthurl.com
>>>>> <mailto:agropper@healthurl.com>> wrote:
>>>>>
>>>>> I believe there are alternatives to having
>>>>> two kinds of ASs. The problem may be a
>>>>> side-effect of deciding to switch away
>>>>> form treating the RO as different from the
>>>>> RQ. That leads to downstream privacy
>>>>> issues. Our desire for architectural
>>>>> simplicity is admirable but that may have
>>>>> been a step too far.
>>>>>
>>>>> There may also be solutions based on
>>>>> different types of tokens, as in different
>>>>> capabilities (tokens signed by the RS) vs.
>>>>> tokens signed by the AS. I’m not sure
>>>>> about that but Alan might have more to say.
>>>>>
>>>>> Adrian
>>>>>
>>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien
>>>>> Imbault <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>> wrote:
>>>>>
>>>>> Thanks. The general problem statement
>>>>> is clear.
>>>>>
>>>>> The proposed solution a bit less (to
>>>>> me). I understood that from point 2,
>>>>> Alan involves 2 ASs. You said :
>>>>> "There’s no obvious reason to have two
>>>>> types of ASs". Do you see an alternative ?
>>>>>
>>>>> Regarding the last item, I don't think
>>>>> that naming RQ by end-user created the
>>>>> problem. It might just highlight the
>>>>> asymmetry, which fundamentally exists.
>>>>>
>>>>> Fabien
>>>>>
>>>>>
>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian
>>>>> Gropper <agropper@healthurl.com
>>>>> <mailto:agropper@healthurl.com>> wrote:
>>>>>
>>>>> Recap:
>>>>> 1 - Justin (I think) introduced
>>>>> the idea of an AS on the RS trust
>>>>> boundary side.
>>>>> 2 - I said the RO should not have
>>>>> to share policies with the RS.
>>>>> 3 - Alan invented the concept of
>>>>> AS-RO and AS-RS to separate two
>>>>> kinds of PDPs.
>>>>>
>>>>> The thing is that step 2 is not
>>>>> symmetrical. The RO has a
>>>>> legitimate privacy interest in
>>>>> keeping their policies private and
>>>>> minimizing the leakage of
>>>>> information about requests that
>>>>> are posed against those policies.
>>>>>
>>>>> The RS, on the other hand, should
>>>>> be publishing its policies (e.g.
>>>>> what it’s selling or what
>>>>> jurisdiction it’s in or what
>>>>> tokens or scopes it supports). The
>>>>> RS has no obvious privacy interest
>>>>> in GNAP. It’s just an enforcer.
>>>>>
>>>>> There is one other privacy
>>>>> interest to consider around the RS
>>>>> and that is the requesting party
>>>>> (the end-user that is not the RO
>>>>> :-) might prefer to share
>>>>> attributes with the RS instead of
>>>>> the RO or something controlled by
>>>>> the RO. This case could be an
>>>>> “extension” to GNAP and might
>>>>> result in a split AS as a
>>>>> solution. This problem was
>>>>> introduced when the editors
>>>>> decided to replace RQ with
>>>>> end-user. Obviously, the RO
>>>>> end-user has no privacy interests
>>>>> relative to itself.
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 25, 2021 at 3:24 AM
>>>>> Fabien Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> I was referring to "By my
>>>>> definition, this model has two
>>>>> ASs since both are processing
>>>>> requests into tokens". If
>>>>> there's no reason to have 2
>>>>> types of ASs, that's fine then.
>>>>> But I'm a bit lost in where we
>>>>> stand with the idea.
>>>>>
>>>>> Could you recap?
>>>>>
>>>>> Fabien
>>>>>
>>>>> Le jeu. 25 mars 2021 à 08:16,
>>>>> Adrian Gropper
>>>>> <agropper@healthurl.com
>>>>> <mailto:agropper@healthurl.com>>
>>>>> a écrit :
>>>>>
>>>>> There’s no obvious reason
>>>>> to have two types of ASs.
>>>>> Any AS that is executing
>>>>> the policies of the RS can
>>>>> look to GNAP like the RS
>>>>> itself. Why would GNAP
>>>>> expose that interface to
>>>>> anyone?
>>>>>
>>>>> Adrian
>>>>>
>>>>> On Thu, Mar 25, 2021 at
>>>>> 3:11 AM Fabien Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Note : I'm not sure
>>>>> that's a good idea,
>>>>> but having 2 types of
>>>>> ASs is not that easy
>>>>> to grasp.
>>>>>
>>>>> Fabien
>>>>>
>>>>> Le jeu. 25 mars 2021 à
>>>>> 08:07, Fabien Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>>
>>>>> a écrit :
>>>>>
>>>>> The purpose of
>>>>> either handling
>>>>> policies locally
>>>>> or delegating them
>>>>> to the RO agent.
>>>>>
>>>>> Le jeu. 25 mars
>>>>> 2021 à 08:04,
>>>>> Adrian Gropper
>>>>> <agropper@healthurl.com
>>>>> <mailto:agropper@healthurl.com>>
>>>>> a écrit :
>>>>>
>>>>> What purpose
>>>>> would be
>>>>> served by GNAP
>>>>> splitting the
>>>>> AS into two
>>>>> components?
>>>>>
>>>>> Adrian
>>>>>
>>>>> On Thu, Mar
>>>>> 25, 2021 at
>>>>> 2:59 AM Fabien
>>>>> Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Isn't the
>>>>> AS-RO a
>>>>> component
>>>>> of the AS?
>>>>> Same idea
>>>>> as the
>>>>> interact
>>>>> component,
>>>>> it
>>>>> functionnally
>>>>> belongs to
>>>>> the AS
>>>>> role but
>>>>> could be
>>>>> deployed
>>>>> either as
>>>>> a monolith
>>>>> or as a
>>>>> separate
>>>>> component?
>>>>>
>>>>> Fabien
>>>>>
>>>>> Le jeu. 25
>>>>> mars 2021
>>>>> à 04:26,
>>>>> Adrian
>>>>> Gropper
>>>>> <agropper@healthurl.com
>>>>> <mailto:agropper@healthurl.com>>
>>>>> a écrit :
>>>>>
>>>>> Yes,
>>>>> but I
>>>>> would
>>>>> say
>>>>> it’s
>>>>> not
>>>>> the RO
>>>>> that
>>>>> wants
>>>>> the
>>>>> access
>>>>> token.
>>>>> It’s
>>>>> the RO
>>>>> that
>>>>> wants
>>>>> the
>>>>> client
>>>>> making
>>>>> the
>>>>> request
>>>>> to get
>>>>> an
>>>>> access
>>>>> token.
>>>>>
>>>>> Adrian
>>>>>
>>>>> On
>>>>> Wed,
>>>>> Mar
>>>>> 24,
>>>>> 2021
>>>>> at
>>>>> 11:22
>>>>> PM
>>>>> Alan
>>>>> Karp
>>>>> <alanhkarp@gmail.com
>>>>> <mailto:alanhkarp@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Adrian
>>>>> Gropper
>>>>> <agropper@healthurl.com
>>>>> <mailto:agropper@healthurl.com>>
>>>>> wrote:
>>>>>
>>>>>
>>>>> In
>>>>> this
>>>>> design,
>>>>> the
>>>>> AS
>>>>> is
>>>>> the
>>>>> AS-RS
>>>>> and
>>>>> the
>>>>> agent
>>>>> is
>>>>> the
>>>>> AS-RO.
>>>>> By
>>>>> my
>>>>> definition,
>>>>> this
>>>>> model
>>>>> has
>>>>> two
>>>>> ASs
>>>>> since
>>>>> both
>>>>> are
>>>>> processing
>>>>> requests
>>>>> into
>>>>> tokens.
>>>>> The
>>>>> problem
>>>>> with
>>>>> this
>>>>> is
>>>>> complexity
>>>>> and
>>>>> privacy.
>>>>> The
>>>>> RO
>>>>> may
>>>>> not
>>>>> want
>>>>> to
>>>>> share
>>>>> the
>>>>> request
>>>>> information
>>>>> with
>>>>> the
>>>>> AS-RS.
>>>>>
>>>>>
>>>>> More
>>>>> precisely,
>>>>> RO
>>>>> has
>>>>> no
>>>>> choice
>>>>> but
>>>>> to
>>>>> present
>>>>> the
>>>>> required
>>>>> information
>>>>> to
>>>>> AS-RS
>>>>> if
>>>>> RO
>>>>> wants
>>>>> an
>>>>> access
>>>>> token.
>>>>> However,
>>>>> RO
>>>>> does
>>>>> not
>>>>> want
>>>>> AS-RS
>>>>> to
>>>>> know
>>>>> the
>>>>> policy
>>>>> by
>>>>> which
>>>>> RO
>>>>> delegates
>>>>> tokens.
>>>>> That's
>>>>> why
>>>>> RO
>>>>> uses
>>>>> AS-RO
>>>>> for
>>>>> those
>>>>> delegations.
>>>>>
>>>>> --------------
>>>>> Alan
>>>>> Karp
>>>>>
>>>>>
>>>>> On
>>>>> Wed,
>>>>> Mar
>>>>> 24,
>>>>> 2021
>>>>> at
>>>>> 7:41
>>>>> PM
>>>>> Adrian
>>>>> Gropper
>>>>> <agropper@healthurl.com
>>>>> <mailto:agropper@healthurl.com>>
>>>>> wrote:
>>>>>
>>>>> Thank
>>>>> you
>>>>> for
>>>>> creating
>>>>> the
>>>>> issue.
>>>>> My
>>>>> definition
>>>>> of
>>>>> AS
>>>>> is
>>>>> independent
>>>>> of
>>>>> AS-RO
>>>>> or
>>>>> AS-RS.
>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421
>>>>> <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223#issuecomment-806280421>
>>>>> I
>>>>> also
>>>>> agree
>>>>> with
>>>>> Alan's
>>>>> definition
>>>>> based
>>>>> on
>>>>> delegation.
>>>>> An
>>>>> AS-RS
>>>>> would
>>>>> be
>>>>> a
>>>>> delegate
>>>>> of
>>>>> the
>>>>> RS.
>>>>>
>>>>>
>>>>> Based
>>>>> on
>>>>> that,
>>>>> I
>>>>> see
>>>>> it
>>>>> as
>>>>> obvious that
>>>>> the
>>>>> policy
>>>>> has
>>>>> to
>>>>> be
>>>>> accessible
>>>>> (defined
>>>>> locally?)
>>>>> in
>>>>> order
>>>>> for
>>>>> it
>>>>> to
>>>>> be
>>>>> run
>>>>> as
>>>>> the
>>>>> code
>>>>> that
>>>>> turns
>>>>> a
>>>>> request
>>>>> into
>>>>> an
>>>>> access
>>>>> token.
>>>>>
>>>>>
>>>>> The
>>>>> only
>>>>> other
>>>>> possibility
>>>>> is
>>>>> that
>>>>> the
>>>>> request
>>>>> is
>>>>> packaged
>>>>> by
>>>>> the
>>>>> AS
>>>>> and
>>>>> sent
>>>>> elsewhere
>>>>> (an
>>>>> agent)
>>>>> for
>>>>> evaluation
>>>>> against
>>>>> policy
>>>>> and
>>>>> a
>>>>> proto-token
>>>>> returned.
>>>>> In
>>>>> that
>>>>> case
>>>>> the
>>>>> AS
>>>>> is
>>>>> acting
>>>>> as
>>>>> a
>>>>> proxy
>>>>> and
>>>>> the
>>>>> PDP
>>>>> is
>>>>> elsewhere.
>>>>> I
>>>>> can
>>>>> imagine
>>>>> that
>>>>> an
>>>>> AS-RS
>>>>> would
>>>>> behave
>>>>> this
>>>>> way
>>>>> so
>>>>> that
>>>>> the
>>>>> proto-token
>>>>> could
>>>>> be
>>>>> turned
>>>>> into
>>>>> an
>>>>> access
>>>>> token
>>>>> by
>>>>> the
>>>>> AS-RS.
>>>>> Isn't
>>>>> this
>>>>> what
>>>>> Justin
>>>>> is
>>>>> proposing?
>>>>> In
>>>>> this
>>>>> design,
>>>>> the
>>>>> AS
>>>>> is
>>>>> the
>>>>> AS-RS
>>>>> and
>>>>> the
>>>>> agent
>>>>> is
>>>>> the
>>>>> AS-RO.
>>>>> By
>>>>> my
>>>>> definition,
>>>>> this
>>>>> model
>>>>> has
>>>>> two
>>>>> ASs
>>>>> since
>>>>> both
>>>>> are
>>>>> processing
>>>>> requests
>>>>> into
>>>>> tokens.
>>>>> The
>>>>> problem
>>>>> with
>>>>> this
>>>>> is
>>>>> complexity
>>>>> and
>>>>> privacy.
>>>>> The
>>>>> RO
>>>>> may
>>>>> not
>>>>> want
>>>>> to
>>>>> share
>>>>> the
>>>>> request
>>>>> information
>>>>> with
>>>>> the
>>>>> AS-RS.
>>>>>
>>>>> Adrian
>>>>>
>>>>> On
>>>>> Wed,
>>>>> Mar
>>>>> 24,
>>>>> 2021
>>>>> at
>>>>> 5:21
>>>>> PM
>>>>> Fabien
>>>>> Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Isn't
>>>>> that
>>>>> what
>>>>> the
>>>>> AS
>>>>> is
>>>>> supposed
>>>>> to
>>>>> be,
>>>>> only
>>>>> with
>>>>> the
>>>>> caveat
>>>>> that
>>>>> the
>>>>> policy
>>>>> is
>>>>> defined
>>>>> locally?
>>>>>
>>>>>
>>>>> Fabien
>>>>>
>>>>>
>>>>>
>>>>> Le
>>>>> mer.
>>>>> 24
>>>>> mars
>>>>> 2021
>>>>> à
>>>>> 20:17,
>>>>> Alan
>>>>> Karp
>>>>> <alanhkarp@gmail.com
>>>>> <mailto:alanhkarp@gmail.com>>
>>>>> a
>>>>> écrit :
>>>>>
>>>>> AS-RO
>>>>> is
>>>>> an
>>>>> AS
>>>>> that
>>>>> RO
>>>>> trusts
>>>>> to
>>>>> delegate
>>>>> RO's
>>>>> access
>>>>> tokens
>>>>> according
>>>>> to
>>>>> RO's
>>>>> policies.
>>>>>
>>>>>
>>>>> --------------
>>>>> Alan
>>>>> Karp
>>>>>
>>>>>
>>>>> On
>>>>> Wed,
>>>>> Mar
>>>>> 24,
>>>>> 2021
>>>>> at
>>>>> 9:36
>>>>> AM
>>>>> Fabien
>>>>> Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Hi
>>>>> Alan
>>>>> and
>>>>> Adrian,
>>>>>
>>>>>
>>>>> I've
>>>>> created
>>>>> issue
>>>>> AS-RO
>>>>> policy
>>>>> delegation
>>>>> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223
>>>>> <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223>)
>>>>> to
>>>>> capture
>>>>> your
>>>>> input.
>>>>>
>>>>> A
>>>>> first
>>>>> question
>>>>> that
>>>>> arises:
>>>>> can
>>>>> we
>>>>> give
>>>>> a
>>>>> definition
>>>>> to
>>>>> AS-RO?
>>>>>
>>>>> Thanks
>>>>> Fabien
>>>>>
>>>>> On
>>>>> Tue,
>>>>> Mar
>>>>> 23,
>>>>> 2021
>>>>> at
>>>>> 4:15
>>>>> PM
>>>>> Alan
>>>>> Karp
>>>>> <alanhkarp@gmail.com
>>>>> <mailto:alanhkarp@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Fabien
>>>>> Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Hi
>>>>> Alan,
>>>>>
>>>>>
>>>>> Yes,
>>>>> but
>>>>> in
>>>>> that
>>>>> flow,
>>>>> the
>>>>> token
>>>>> relationship
>>>>> between
>>>>> AS-RS
>>>>> and
>>>>> AS-RO
>>>>> is
>>>>> only
>>>>> secure
>>>>> if
>>>>> the
>>>>> tokens
>>>>> issued
>>>>> by
>>>>> AS-RS
>>>>> are
>>>>> cryptographically
>>>>> attenuable
>>>>> in
>>>>> the
>>>>> first
>>>>> place.
>>>>>
>>>>>
>>>>> Attenuated
>>>>> delegation
>>>>> is
>>>>> a
>>>>> requirement,
>>>>> but
>>>>> that
>>>>> doesn't
>>>>> have
>>>>> to
>>>>> be
>>>>> done
>>>>> cryptographically.
>>>>> Token
>>>>> exchange
>>>>> works
>>>>> just
>>>>> fine.
>>>>> SPKI
>>>>> and
>>>>> zcap-ld
>>>>> are
>>>>> examples
>>>>> of
>>>>> the
>>>>> crypto
>>>>> approach,
>>>>> and
>>>>> we
>>>>> used
>>>>> token
>>>>> exchange
>>>>> in
>>>>> the
>>>>> system
>>>>> for
>>>>> HP.
>>>>>
>>>>> --------------
>>>>> Alan
>>>>> Karp
>>>>>
>>>>>
>>>>> On
>>>>> Tue,
>>>>> Mar
>>>>> 23,
>>>>> 2021
>>>>> at
>>>>> 4:12
>>>>> AM
>>>>> Fabien
>>>>> Imbault
>>>>> <fabien.imbault@gmail.com
>>>>> <mailto:fabien.imbault@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Hi
>>>>> Alan,
>>>>>
>>>>>
>>>>> Yes,
>>>>> but
>>>>> in
>>>>> that
>>>>> flow,
>>>>> the
>>>>> token
>>>>> relationship
>>>>> between
>>>>> AS-RS
>>>>> and
>>>>> AS-RO
>>>>> is
>>>>> only
>>>>> secure
>>>>> if
>>>>> the
>>>>> tokens
>>>>> issued
>>>>> by
>>>>> AS-RS
>>>>> are
>>>>> cryptographically
>>>>> attenuable
>>>>> in
>>>>> the
>>>>> first
>>>>> place.
>>>>>
>>>>>
>>>>> Fabien
>>>>>
>>>>> On
>>>>> Mon,
>>>>> Mar
>>>>> 22,
>>>>> 2021
>>>>> at
>>>>> 9:26
>>>>> PM
>>>>> Alan
>>>>> Karp
>>>>> <alanhkarp@gmail.com
>>>>> <mailto:alanhkarp@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Justin
>>>>> Richer
>>>>> <jricher@mit.edu
>>>>> <mailto: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
>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>> <mailto:jricher@mit.edu>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On
>>>>>>> Mar
>>>>>>> 21,
>>>>>>> 2021,
>>>>>>> at
>>>>>>> 1:18
>>>>>>> PM,
>>>>>>> Benjamin
>>>>>>> Kaduk
>>>>>>> <kaduk@mit.edu
>>>>>>> <mailto:kaduk@mit.edu>>
>>>>>>> wrote:
>>>>>>> >
>>>>>>>
>>>>>>> >
>>>>>>> On
>>>>>>> Sat,
>>>>>>> Mar
>>>>>>> 20,
>>>>>>> 2021
>>>>>>> at
>>>>>>> 01:07:42AM
>>>>>>> -0400,
>>>>>>> Adrian
>>>>>>> Gropper
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> @Alan
>>>>>>> Karp
>>>>>>> <alanhkarp@gmail.com
>>>>>>> <mailto: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
>>>>>>> <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
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> TXAuth
>>>>> mailing
>>>>> list
>>>>> TXAuth@ietf.org
>>>>> <mailto:TXAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>> <https://www.ietf.org/mailman/listinfo/txauth>
>>>>>
>>>>> --
>>>>>
>>>>> TXAuth
>>>>> mailing
>>>>> list
>>>>> TXAuth@ietf.org
>>>>> <mailto:TXAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>> <https://www.ietf.org/mailman/listinfo/txauth>
>>>>>
>>>>> --
>>>>> TXAuth
>>>>> mailing
>>>>> list
>>>>> TXAuth@ietf.org
>>>>> <mailto:TXAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>> <https://www.ietf.org/mailman/listinfo/txauth>
>>>>>
>>>>
>>>
>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/txauth
>>> <https://www.ietf.org/mailman/listinfo/txauth>
>>>
>>
>
>
- [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