Re: [GNAP] Relationship between Authentication and Authorization ?
Denis <denis.ietf@free.fr> Mon, 29 March 2021 10:39 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 856343A176B for <txauth@ietfa.amsl.com>; Mon, 29 Mar 2021 03:39:10 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 0CvW4b5nRpqh for <txauth@ietfa.amsl.com>; Mon, 29 Mar 2021 03:39:02 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767E03A1789 for <txauth@ietf.org>; Mon, 29 Mar 2021 03:39:00 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.53.231]) by mwinf5d40 with ME id mAeq2400J4zJUWJ03AeqUr; Mon, 29 Mar 2021 12:38:58 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 29 Mar 2021 12:38:58 +0200
X-ME-IP: 90.79.53.231
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf.org
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@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> <3c103293-56a1-4be5-e2a3-12eb82d13238@free.fr> <91D11E67-34AB-4426-803C-7B5A6F50537F@mit.edu> <d73466fd-4b4e-f5a1-3ee6-05184ecdfc0e@free.fr> <FBFB67BC-2A1F-4114-991B-BE1915BA287C@mit.edu>
From: Denis <denis.ietf@free.fr>
Message-ID: <af49865c-ad7f-c5e0-edfa-eede0e83bfcc@free.fr>
Date: Mon, 29 Mar 2021 12:38:50 +0200
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: <FBFB67BC-2A1F-4114-991B-BE1915BA287C@mit.edu>
Content-Type: multipart/alternative; boundary="------------9A2AB8EF9F419184280F8DE4"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/GmIqN_K0Cg18XVRYtzGTa9RjCbc>
Subject: Re: [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: Mon, 29 Mar 2021 10:39:11 -0000
Hi Justin,
Since your response only deals with the AS, but not the RS nor the RO,
it is not a response to my question which was:
How will a RS or a RO be bootstrapped for working with a GNAP "sub"
claim or a "sub_id" claim ?
> The subject identifier is whatever identifier the AS knows the subject
> as. If they log in using only a FIDO token and the AS asserts that key
> value as the identifier, then that’s what it will be. If they sign up
> with an email address or make a username or get assigned a random
> number, that’s what it will be. Or they could sign up using any number
> of those and the AS still assigns them a random value, because it’s
> always the AS that determines which value to assign the number.
When looking at Section 3.2 (Access Tokens), the client (and hence the
end-user) has currently /no practical way/ to indicate which of its
attributes should be placed into an access token,
The only reference within Section 3.2 is pointing to the empty Section
12. Among the many examples, there is not a single example that
addresses the case of attributes being placed into an access token.
Nevertheless, it seems that in your opinion, only the AS, but NOT the
client (and hence the end-user), SHALL have control at all of what kind
of /subject identifier/ claim will be placed inside the access token.
Then after, invoking the postulate "the access token SHALL remain opaque
to the client (and hence the end-user)", it seems that in your opinion,
the end-user SHALL have no way to verify
whether its privacy has been respected. If this is not an architecture
built along "spy by design" principles, I don't know what else it might be.
It is important to re-read two of the current definitions:
*Privilege*: right *or attribute* associated with a subject.
*Access Toke*n: data artifact representing a set of rights *a**nd/or
attributes*.
In the current draft, the case of rights is indeed addressed while *the
case of attributes is fully ignored*.
> The RS is not involved in any subject information. Identity APIs, like
> OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP.
Really ? Do you mean that an access token should not contain a "sub"
claim nor a "sub_id" claim and if it does, the RS SHALL ignore such
claims ?
In the "OAuth Access Token JWT Profile", there is the following sentence
in Section 6 (Privacy Considerations) :
This profile mandates the presence of the "sub" claim in every JWT
access token, making it possible for resource servers to rely on
that
information for performing tasks such as correlating incoming
requests with /data stored locally for the authenticated
principal/.
This sentence clearly makes a relationship between the value present in
the "sub" claim and "/data stored locally for the //*authenticated
*//principal/".
However, note that the "OAuth Access Token JWT Profile" fails to allow
the client (and hence the end-user) to control his privacy, since the
client
cannot choose which value will be placed in the "sub" claim and also
because access tokens are considered to be opaque for the clients in OAuth.
> If there is a subject identifier either included in or referenced by
> the access token, that is /up to any agreements between the AS and RS/
> that lead to the ability of the AS to create the tokens the RS can
> trust. All of this is outside the scope of the core GNAP protocol and
> invisible to the client.
You are using the following words "/up to any agreements between the AS
and RS/". This mandates prior agreements between ASs and RSs
and in such a case the architecture will be non-scalable over the
Internet. The trust relationship between a RS and an AS is unilateral:
The RS trusts the AS to issue appropriate access tokens corresponding to
the requests of its clients.
From an end-user point of view, if there cannot be *transparency*
because of the access token opacity,**then there cannot be *confidence
*about GNAP .
Denis
> — Justin
>
>> On Mar 26, 2021, at 1:27 PM, Denis <denis.ietf@free.fr
>> <mailto:denis.ietf@free.fr>> wrote:
>>
>> Hi Justin,
>>
>> Let me rephrase the last question: How will a RS or a RO be
>> bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?
>>
>> Denis
>>
>>> GNAP doesn’t have anything too say about anybody authenticating
>>> directly to the RS. If that happens, it’s out of the view and out of
>>> scope of GNAP.
>>>
>>> — Justin
>>>
>>>> On Mar 26, 2021, at 1:06 PM, Denis <denis.ietf@free.fr
>>>> <mailto:denis.ietf@free.fr>> wrote:
>>>>
>>>> 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