Re: [GNAP] Will GNAP support Zero Trust Architecture?

Adrian Gropper <agropper@healthurl.com> Thu, 25 March 2021 21:50 UTC

Return-Path: <agropper@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023B13A0AB4 for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 14:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 EzRVNM4Exxgl for <txauth@ietfa.amsl.com>; Thu, 25 Mar 2021 14:50:29 -0700 (PDT)
Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831AC3A0AB2 for <txauth@ietf.org>; Thu, 25 Mar 2021 14:50:29 -0700 (PDT)
Received: by mail-vs1-f41.google.com with SMTP id h4so40493vsl.11 for <txauth@ietf.org>; Thu, 25 Mar 2021 14:50:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bwsg1v/vYOyil9soInWPtSPSXUKwbWHWoQC8bzRREBo=; b=aRXQ+lb0inKhTOy/Nx1bwyySFZQzuH6KIE3BlhrMyeBavmXIixV9rDQbyQo5wKVvHq f7QCtxur3HkU7DqYeulmrPGt+SmFPag4Sz+nRk5lvelsgwknDUn/KhkatPwuNhQ8YmVQ N1xI8VMEr4yxc5qFL9sxacvJ3apareB8DTNcQwfaNxITEAWS6f0poM+x3efPzk2LvXTs wOa1smJP3Zhn+X/BxP/z0ip+ZotF+t0LvHck9phAlfiL5VdYnoOZgCXbc8KcqxAWldf7 112wMcIM9k8HCKEMVFFnRVMlDwwmj/Ek7ye8f+4+wbyHdHbln6dTL2H3eRUrHmi2ws7W vZfQ==
X-Gm-Message-State: AOAM533YZ5OUsRxsxbt2b+R3aGVrgW0WkGFFa1yxYGwpvE6znHKzPDWA 4TC/Yq3NVsGmR7+qGoDQPwFm5EMEO39cYjZ26J4TQ7MtkmYjPQ==
X-Google-Smtp-Source: ABdhPJwT5zNe2bP0ys9ap76xokG66s8zRxpA0z2L0jYd3jpK6Q/ZIXMe5IYyF8urutZdKvs5608QjfsyiP5HAE0z9T4=
X-Received: by 2002:a67:cb87:: with SMTP id h7mr6812514vsl.33.1616709028064; Thu, 25 Mar 2021 14:50:28 -0700 (PDT)
MIME-Version: 1.0
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <CANYRo8gMQYJXcb0FU2VCVcdbBLsopZ5Wfyo3hd1Pd5tmOSs0SA@mail.gmail.com> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <CANYRo8iPeeM3rLP9BYid2B71NzU7fR6J9Ra4=PSODTFE7i75Zg@mail.gmail.com> <CEECEE23-24D0-4C0C-B39E-9FDFF9E1E13D@mit.edu> <CANpA1Z2S8Y3+U+jOa-ZbTzsZ9hkybCnGfzx0kP8VF=Z=Se4uew@mail.gmail.com> <CAM8feuTaYEZY8BNtp5j8dAxZjBLnM-0CZQUO9UgGAAx=-qQyJA@mail.gmail.com> <CANpA1Z2Zt0ksRZqu7f6kGc5CXvWjRvuBMyDn4-EeiVE7Ndj3yw@mail.gmail.com> <CAM8feuRk6bB6ry1dy9W-9OKSgckYqicVtQ7jsrxseA2iJQdPKQ@mail.gmail.com> <CANpA1Z2__Y2UiQ-x_Fz4Q05guFhi-rOygJ+pHkNjbRUdh2Y97Q@mail.gmail.com> <CAM8feuT9pG6sNDpR5SUfKzX2YsX8H6VK9jmNdJLXy_g7EnPMNQ@mail.gmail.com> <CANYRo8jnmkG-LXSKsZZyHDqO7yZH3LAVzhW2qKPCvxpPnJvYnw@mail.gmail.com> <CANpA1Z2xAdG=Hu09wWb6a0Qc7DPPA5rU24oaGb4GMZfjjQbn-Q@mail.gmail.com> <CANYRo8j8ig9gzfJmNOCk=6nOPa=nQmCQahpyuJTPGViA3wj1Cw@mail.gmail.com> <CAM8feuSGR58Y1a0ta5EQThwDeRJfXNLehYe_zhBqvhu+8tDzPg@mail.gmail.com> <CANYRo8gbTuDYHDHaR=y4cWOimYWqptEOYD6UbsbCpdd0Rh6QHQ@mail.gmail.com> <CAM8feuTLG5n+=GFb_Mdb1_fD3YAvSHsJiUrFCp7O+-tP-xzbfQ@mail.gmail.com> <CAM8feuSxttFqra9JpXXSKMqfmGUhz30+3eDQRtDpKPF-4pVmbQ@mail.gmail.com> <CANYRo8iJfpF2nt4se3KNhe14B5c_+ndmwjFFAhw7ybnJa_Cq2A@mail.gmail.com> <CAM8feuS0YOWC-wpz=0GP1x-7EV6fdx0puimkS6AXJP=ZtYM8aA@mail.gmail.com> <CANYRo8hQjcEWrwK=scpopVSnzYQ6AiObk2RoLSS+U=V1jxo1EQ@mail.gmail.com> <CAM8feuT+noLdtUYaUGfzhezTea+Uy6+9xWfb814TOg4w0u_tOA@mail.gmail.com> <CANYRo8hHUqSoDHjGRpm6qZLSm=3rd8E5OEFjreDvDyMvjHOdUw@mail.gmail.com> <CAM8feuTJawB+msiSrYUeen15eHLDcOzD4diy6++DNoYYcHqMug@mail.gmail.com> <CAM8feuTqMXF4b+ZaEJpkfeTJeBsuf227VNC3p1sDGJByFUn8jA@mail.gmail.com> <85AAABFB-2448-452C-BD6D-D5E84FA2438A@mit.edu> <CANpA1Z3x2vZXsvtcKfvFMyrWKv0XxXVWaJ=B3eaTStmbFc+gXA@mail.gmail.com> <E1008110-FBE9-42F2-8649-6ECCF0459D7D@mit.edu> <CANpA1Z2kRZPLPY6qgAJ6KjxbwGTR6B4ZUq=JGsR-6g_STBrqNg@mail.gmail.com>
In-Reply-To: <CANpA1Z2kRZPLPY6qgAJ6KjxbwGTR6B4ZUq=JGsR-6g_STBrqNg@mail.gmail.com>
From: Adrian Gropper <agropper@healthurl.com>
Date: Thu, 25 Mar 2021 17:50:15 -0400
Message-ID: <CANYRo8gXtwAi8f6iHmNfgoY7E1ism+mWJYJriccugHfus+EDmg@mail.gmail.com>
To: Alan Karp <alanhkarp@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, GNAP Mailing List <txauth@ietf.org>, Fabien Imbault <fabien.imbault@gmail.com>, Mark Miller <erights@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
Content-Type: multipart/alternative; boundary="00000000000052b56f05be63678e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nWo05_QWzBLreSXAEe5Lqo6PIDM>
Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture?
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 21:50:35 -0000

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> wrote:

> Justin Richer <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.
> 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> 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> 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> 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>
>>> 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>
>>> 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>
>>>> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Adrian Gropper <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> 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
>>>>>>>>>>>>>>>> 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> 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> 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> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Alan and Adrian,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've created issue AS-RO policy delegation (
>>>>>>>>>>>>>>>>>>> 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> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Fabien Imbault <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> 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> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Justin Richer <jricher@mit.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is
>>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are, and how those can be
>>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS’s that can accept them. I think
>>>>>>>>>>>>>>>>>>>>>>> there’s a lot of room for innovation and flexibility here that doesn’t
>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an AS-RS set that won’t
>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, then I can decide not to
>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question than saying the RS
>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS — and we can’t keep conflating these two
>>>>>>>>>>>>>>>>>>>>>>> models.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I agree.  The point of having an AS-RO is to allow
>>>>>>>>>>>>>>>>>>>>>> RO to specify a policy for which of RO's access tokens should be delegated
>>>>>>>>>>>>>>>>>>>>>> under what conditions.  AS-RS should not need to understand those
>>>>>>>>>>>>>>>>>>>>>> policies.  The flow would be
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    - RO contacts AS-RS and gets one or more access
>>>>>>>>>>>>>>>>>>>>>>    tokens.
>>>>>>>>>>>>>>>>>>>>>>    - RO delegates one or more of those tokens,
>>>>>>>>>>>>>>>>>>>>>>    potentially sub-scoped, to AS-RO.
>>>>>>>>>>>>>>>>>>>>>>    - A different user contacts AS-RO to get a
>>>>>>>>>>>>>>>>>>>>>>    potentially sub-scoped access token from AS-RO.
>>>>>>>>>>>>>>>>>>>>>>    - That user presents the access token delegated
>>>>>>>>>>>>>>>>>>>>>>    by AS-RO when invoking the resource.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> AS-RS only needs to verify that the delegation chain
>>>>>>>>>>>>>>>>>>>>>> is legitimate, e.g., no increase in scope, and that it grants permission
>>>>>>>>>>>>>>>>>>>>>> for the request being made.  AS-RS does not need to understand the policy
>>>>>>>>>>>>>>>>>>>>>> behind granting the delegation by AS-RO.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --------------
>>>>>>>>>>>>>>>>>>>>>> Alan Karp
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <
>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Adrian,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I think this shows the problem with the terminology
>>>>>>>>>>>>>>>>>>>>>>> as it’s been applied in this conversation, which I’ve tried to shine light
>>>>>>>>>>>>>>>>>>>>>>> on before. What you and others are calling the “RS” is really the “AS and
>>>>>>>>>>>>>>>>>>>>>>> RS working together” — everything to the right of the line. When Denis had
>>>>>>>>>>>>>>>>>>>>>>> brought up “eliminating the AS” in another thread, what he’d really done is
>>>>>>>>>>>>>>>>>>>>>>> labeled everything to the right of the line as the “RS”. Of course, the
>>>>>>>>>>>>>>>>>>>>>>> irony here is that everything to the right of the line used all be called
>>>>>>>>>>>>>>>>>>>>>>> the “AS” or simply “server” in the OAuth 1 days. As you say below, I don’t
>>>>>>>>>>>>>>>>>>>>>>> want the client to have visibility on what happens on that side.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Note well: The Google+ logo labeled “IdP” in the
>>>>>>>>>>>>>>>>>>>>>>> diagram is not the AS, as far as GNAP is concerned. It does not issue an
>>>>>>>>>>>>>>>>>>>>>>> access token that the RS will accept. The elements to the left of the line
>>>>>>>>>>>>>>>>>>>>>>> could be a lot of things, but they are NOT the AS — by definition. The
>>>>>>>>>>>>>>>>>>>>>>> client lives over on the left, but so do any external inputs to the AS.
>>>>>>>>>>>>>>>>>>>>>>> These could be policy inputs on behalf of the RO, they could be
>>>>>>>>>>>>>>>>>>>>>>> presentation artifacts, they could be federated logins, they could be the
>>>>>>>>>>>>>>>>>>>>>>> output of policy decisions. How the AS comes to trust those things is up to
>>>>>>>>>>>>>>>>>>>>>>> the AS’s implementation. It’s something we can talk about, but ultimately
>>>>>>>>>>>>>>>>>>>>>>> GNAP won’t be in any position to dictate because in practice some AS’s are
>>>>>>>>>>>>>>>>>>>>>>> simply going to internalize all policies and we will never successfully
>>>>>>>>>>>>>>>>>>>>>>> force those open.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But with all that in mind, I think the key here is
>>>>>>>>>>>>>>>>>>>>>>> going to be looking at what the inputs to the AS are, and how those can be
>>>>>>>>>>>>>>>>>>>>>>> defined in an interoperable way for AS’s that can accept them. I think
>>>>>>>>>>>>>>>>>>>>>>> there’s a lot of room for innovation and flexibility here that doesn’t
>>>>>>>>>>>>>>>>>>>>>>> break the trust model or core use cases. If I have an AS-RS set that won’t
>>>>>>>>>>>>>>>>>>>>>>> accept my favorite flavor of policy engine inputs, then I can decide not to
>>>>>>>>>>>>>>>>>>>>>>> use that one. But this is a very different question than saying the RS
>>>>>>>>>>>>>>>>>>>>>>> itself needs to accept my own AS — and we can’t keep conflating these two
>>>>>>>>>>>>>>>>>>>>>>> models.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So to me, GNAP can support a Zero Trust Architecture
>>>>>>>>>>>>>>>>>>>>>>> by LEVERAGING the AS, not by subsuming or eliminating it. It is in fact the
>>>>>>>>>>>>>>>>>>>>>>> AS, not the client and not the RS, that will request and consume the
>>>>>>>>>>>>>>>>>>>>>>> results of a privacy-preserving zero-trust policy query thing. Anything
>>>>>>>>>>>>>>>>>>>>>>> that happens downstream from that is of little concern to the zero-trust
>>>>>>>>>>>>>>>>>>>>>>> components because, as you point out, it’s on the “other side” of the line.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty
>>>>>>>>>>>>>>>>>>>>>>> right in OAuth: the AS and RS and client working together. Where OAuth
>>>>>>>>>>>>>>>>>>>>>>> misses the mark is the assumption that the user has to log in to the AS
>>>>>>>>>>>>>>>>>>>>>>> through a webpage and interact directly, thereby proving they’re the RO.
>>>>>>>>>>>>>>>>>>>>>>> It’s this latter space where I think we can both push innovation and also
>>>>>>>>>>>>>>>>>>>>>>> address the important and compelling use cases like the ones you’re
>>>>>>>>>>>>>>>>>>>>>>> bringing.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>  — Justin
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper <
>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I'm sorry, Justin. As a Resource Owner, I look at
>>>>>>>>>>>>>>>>>>>>>>> the RS trust boundary (the dotted line in the diagram) as being the RS. I
>>>>>>>>>>>>>>>>>>>>>>> don't expect any visibility into what's going on on the right.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> My problem with the framing you propose is that
>>>>>>>>>>>>>>>>>>>>>>> requests are going to the RS (or the AS-RS) and I don't want to share my
>>>>>>>>>>>>>>>>>>>>>>> policies with the AS-RS. I want to keep the RS and AS-RS as ignorant as
>>>>>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Adrian
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <
>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Adrian,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> What you’re discussing below, in terms of logging
>>>>>>>>>>>>>>>>>>>>>>>> in to a site, is not approaching the RS. You are in fact approaching the
>>>>>>>>>>>>>>>>>>>>>>>> client, and identifying both the AS and RS to the client. The client is a
>>>>>>>>>>>>>>>>>>>>>>>> client *of your identity* in this model, and the
>>>>>>>>>>>>>>>>>>>>>>>> RS is part of the identity provider. It’s really important that we don’t
>>>>>>>>>>>>>>>>>>>>>>>> conflate the RS and client in this way as it leads to a lot of confusion
>>>>>>>>>>>>>>>>>>>>>>>> downstream and a lot of broken trust boundaries.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> With that model in mind, approaching the “RS" and
>>>>>>>>>>>>>>>>>>>>>>>> providing it your identity is really just a case of the “federated login to
>>>>>>>>>>>>>>>>>>>>>>>> AS” pattern that we discussed on the WG call. The user here approaches an
>>>>>>>>>>>>>>>>>>>>>>>> RS, which has its own AS. To share things from this RS, the RO has to
>>>>>>>>>>>>>>>>>>>>>>>> authenticate to the RS’s AS. This particular AS allows the RO to do so
>>>>>>>>>>>>>>>>>>>>>>>> using an external identity — in which case, the AS is now a “client” of a
>>>>>>>>>>>>>>>>>>>>>>>> separate, disconnected (but layered) delegation. The ultimate client that
>>>>>>>>>>>>>>>>>>>>>>>> eventually calls the RS down the way may or may not know about these
>>>>>>>>>>>>>>>>>>>>>>>> layers.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> <PastedGraphic-1.png>
>>>>>>>>>>>>>>>>>>>>>>>> This same AS, which is closely tied to the RS and
>>>>>>>>>>>>>>>>>>>>>>>> trusted by the RS, might also take in FIDO credentials, or DIDs, or any
>>>>>>>>>>>>>>>>>>>>>>>> number of other proof mechanisms. The output of this is an access token the
>>>>>>>>>>>>>>>>>>>>>>>> RS trusts, but the input is up to the AS. The RS is not what you’re logging
>>>>>>>>>>>>>>>>>>>>>>>> in to.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  — Justin
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper <
>>>>>>>>>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation and
>>>>>>>>>>>>>>>>>>>>>>>> correlation. Right now, when I approach a service provider (RS) for the
>>>>>>>>>>>>>>>>>>>>>>>> first time, I'm offered the opportunity to identify my persona as: email,
>>>>>>>>>>>>>>>>>>>>>>>> sign-in with Google, Facebook, or Apple. I know there are people who try to
>>>>>>>>>>>>>>>>>>>>>>>> create one-off email addresses but that is mostly a waste of time.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue.
>>>>>>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS relationship
>>>>>>>>>>>>>>>>>>>>>>>> pseudonymously.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> When I want my resource to be discovered or shared
>>>>>>>>>>>>>>>>>>>>>>>> I will post that RS URL including my pseudonym. If I then want to introduce
>>>>>>>>>>>>>>>>>>>>>>>> a mediator in front of my AS or messaging service endpoint, I have that
>>>>>>>>>>>>>>>>>>>>>>>> option. If I want to keep requests away from the mediator, I would publish
>>>>>>>>>>>>>>>>>>>>>>>> an encryption key along with my pseudonym.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - Adrian
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <
>>>>>>>>>>>>>>>>>>>>>>>> jricher@mit.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <
>>>>>>>>>>>>>>>>>>>>>>>>> kaduk@mit.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian
>>>>>>>>>>>>>>>>>>>>>>>>> Gropper wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp <alanhkarp@gmail.com> shared a talk
>>>>>>>>>>>>>>>>>>>>>>>>> about the Principle Of Least
>>>>>>>>>>>>>>>>>>>>>>>>> >> Authority (POLA) in a recent comment
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
>>>>>>>>>>>>>>>>>>>>>>>>> >> I recommend it.
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with authorization
>>>>>>>>>>>>>>>>>>>>>>>>> in the title to use authority
>>>>>>>>>>>>>>>>>>>>>>>>> >> as a core principle. I advocate for a GNAP
>>>>>>>>>>>>>>>>>>>>>>>>> design that maximizes the power
>>>>>>>>>>>>>>>>>>>>>>>>> >> of the RO, to be seen as a human rights issue
>>>>>>>>>>>>>>>>>>>>>>>>> when the RO is a human. This
>>>>>>>>>>>>>>>>>>>>>>>>> >> causes me to ask how to combine better security
>>>>>>>>>>>>>>>>>>>>>>>>> with better human rights in
>>>>>>>>>>>>>>>>>>>>>>>>> >> GNAP.
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> Who should have the least authority in the GNAP
>>>>>>>>>>>>>>>>>>>>>>>>> design?
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> The AS derives authority as a delegate of the
>>>>>>>>>>>>>>>>>>>>>>>>> RO. If we ask the RO to
>>>>>>>>>>>>>>>>>>>>>>>>> >> partition limited authority across dozens of
>>>>>>>>>>>>>>>>>>>>>>>>> different ASs by domain and
>>>>>>>>>>>>>>>>>>>>>>>>> >> function, then we are not using technology to
>>>>>>>>>>>>>>>>>>>>>>>>> empower the individual.
>>>>>>>>>>>>>>>>>>>>>>>>> >> Probably the opposite, as we introduce consent
>>>>>>>>>>>>>>>>>>>>>>>>> fatigue and burden normal
>>>>>>>>>>>>>>>>>>>>>>>>> >> people to partition their lives into
>>>>>>>>>>>>>>>>>>>>>>>>> non-overlapping domains.
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> My experience says we should aim for one AS per
>>>>>>>>>>>>>>>>>>>>>>>>> persona because that maps
>>>>>>>>>>>>>>>>>>>>>>>>> >> into the way we manage our public and private
>>>>>>>>>>>>>>>>>>>>>>>>> identities. POLA would then
>>>>>>>>>>>>>>>>>>>>>>>>> >> teach care in keeping ASs and RSs related to
>>>>>>>>>>>>>>>>>>>>>>>>> work / public separate from
>>>>>>>>>>>>>>>>>>>>>>>>> >> ASs and RSs related to private life so that a
>>>>>>>>>>>>>>>>>>>>>>>>> policy vulnerability in our
>>>>>>>>>>>>>>>>>>>>>>>>> >> delegation to an AS would have the least
>>>>>>>>>>>>>>>>>>>>>>>>> likelihood of harm.
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > Thinking about how least authority/least
>>>>>>>>>>>>>>>>>>>>>>>>> privilege would apply to GNAP
>>>>>>>>>>>>>>>>>>>>>>>>> > seems like a useful exercise.  I do want to
>>>>>>>>>>>>>>>>>>>>>>>>> point out some potential
>>>>>>>>>>>>>>>>>>>>>>>>> > pitfalls with one-AS-per-persona that we can
>>>>>>>>>>>>>>>>>>>>>>>>> also be aware of.  If
>>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes one-persona-per-AS as
>>>>>>>>>>>>>>>>>>>>>>>>> well, then the AS's
>>>>>>>>>>>>>>>>>>>>>>>>> > identity in effect also serves as a persona
>>>>>>>>>>>>>>>>>>>>>>>>> identity and there are privacy
>>>>>>>>>>>>>>>>>>>>>>>>> > considerations to that.  If, on the other hand,
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> > multiple-personas-per-AS (presumably
>>>>>>>>>>>>>>>>>>>>>>>>> corresponding to multiple humans)
>>>>>>>>>>>>>>>>>>>>>>>>> > route is taken, we should consider whether that
>>>>>>>>>>>>>>>>>>>>>>>>> would lead to various
>>>>>>>>>>>>>>>>>>>>>>>>> > (e.g., market) forces driving consolidation to
>>>>>>>>>>>>>>>>>>>>>>>>> just a handful of
>>>>>>>>>>>>>>>>>>>>>>>>> > super-popular AS services.  That topic is a
>>>>>>>>>>>>>>>>>>>>>>>>> current matter of concern to
>>>>>>>>>>>>>>>>>>>>>>>>> > some IETF participants.
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ben, big +1 to this. This is something that we
>>>>>>>>>>>>>>>>>>>>>>>>> discussed ages ago in the UMA working group, and it’s one of the biggest
>>>>>>>>>>>>>>>>>>>>>>>>> problems with the personal AS (and personal data store) model. This kind of
>>>>>>>>>>>>>>>>>>>>>>>>> thing makes RS-first trust models really difficult in practice.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> As a strawman, let’s say that I’ve got software
>>>>>>>>>>>>>>>>>>>>>>>>> that wants to access my medical information. It calls an RS and requests
>>>>>>>>>>>>>>>>>>>>>>>>> access, but it hasn’t been granted anything yet. Now I as the RO have set
>>>>>>>>>>>>>>>>>>>>>>>>> up the RS so that it talks to my personal AS, that only I use. In addition
>>>>>>>>>>>>>>>>>>>>>>>>> to the RS having to be able to figure out which medical records are being
>>>>>>>>>>>>>>>>>>>>>>>>> requested from the context of the unauthenticated request (which means it
>>>>>>>>>>>>>>>>>>>>>>>>> needs identifiers in the URL or something similar for the RS to be able to
>>>>>>>>>>>>>>>>>>>>>>>>> tell, assuming that it protects data for more than one person). So this
>>>>>>>>>>>>>>>>>>>>>>>>> client software doesn’t know who I am and doesn’t know my medical record
>>>>>>>>>>>>>>>>>>>>>>>>> information, makes a completely unauthorized request to the RS, and the RS
>>>>>>>>>>>>>>>>>>>>>>>>> says “Go to Justin’s personal AS to get a token”. The client can now make a
>>>>>>>>>>>>>>>>>>>>>>>>> direct correlation between the data that’s being protected at the RS and
>>>>>>>>>>>>>>>>>>>>>>>>> the person running the AS that protects it. Importantly, this client makes
>>>>>>>>>>>>>>>>>>>>>>>>> this call with no prior relationship to the RS and no really auditable way
>>>>>>>>>>>>>>>>>>>>>>>>> to track it down after the fact. This is a design feature in the good case,
>>>>>>>>>>>>>>>>>>>>>>>>> and terrifying in the bad case.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says “welcome to Medicine Doctor
>>>>>>>>>>>>>>>>>>>>>>>>> RS, please talk to the Medicine Doctor AS to get access”, we haven’t
>>>>>>>>>>>>>>>>>>>>>>>>> exposed anything at all. And from the perspective of both the patient and
>>>>>>>>>>>>>>>>>>>>>>>>> the RS, this is more privacy-preserving, and it’s really the least
>>>>>>>>>>>>>>>>>>>>>>>>> surprising option. Once the client gets to the AS, it can start a
>>>>>>>>>>>>>>>>>>>>>>>>> negotiation of figuring out who the RO is for the information being
>>>>>>>>>>>>>>>>>>>>>>>>> accessed.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On top of this, the usability expectations of
>>>>>>>>>>>>>>>>>>>>>>>>> people managing their own AS, or set of AS’s for multiple personas to keep
>>>>>>>>>>>>>>>>>>>>>>>>> things separate, is a huge burden. Even in the tech community, I know
>>>>>>>>>>>>>>>>>>>>>>>>> people who can’t reliably manage more than one email address for different
>>>>>>>>>>>>>>>>>>>>>>>>> purposes. I wouldn’t expect my partner to do that — they have trouble
>>>>>>>>>>>>>>>>>>>>>>>>> enough balancing all the logins and sessions required for different kids
>>>>>>>>>>>>>>>>>>>>>>>>> remote schooling, I couldn’t imagine them having to understand all the
>>>>>>>>>>>>>>>>>>>>>>>>> requirements for managing multiple authorization servers and associated
>>>>>>>>>>>>>>>>>>>>>>>>> policies. I also don’t expect any person to “manage keys” — I’ve been on
>>>>>>>>>>>>>>>>>>>>>>>>> the internet for decades and I can barely keep tabs on my GPG keys, and
>>>>>>>>>>>>>>>>>>>>>>>>> only use them when I am forced to. This is exactly the kind of “market
>>>>>>>>>>>>>>>>>>>>>>>>> pressure” that I think Ben mentions above, people will just want to
>>>>>>>>>>>>>>>>>>>>>>>>> outsource that to someone else, and the reality will be a few popular
>>>>>>>>>>>>>>>>>>>>>>>>> providers.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> In which case, we could end up doing a ton of work
>>>>>>>>>>>>>>>>>>>>>>>>> to allow an RS choice only to end up with a world where the RS ends up
>>>>>>>>>>>>>>>>>>>>>>>>> making a limited choice anyway. We see how that plays out with OpenID
>>>>>>>>>>>>>>>>>>>>>>>>> Connect — RP’s could allow arbitrary IdPs but they choose Google because it
>>>>>>>>>>>>>>>>>>>>>>>>> works and that’s where the users are. (And that’s not to say anything of
>>>>>>>>>>>>>>>>>>>>>>>>> the proprietary OIDC-like protocols, but that’s another discussion).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend
>>>>>>>>>>>>>>>>>>>>>>>>> both “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So what does this have to do with GNAP? I think we
>>>>>>>>>>>>>>>>>>>>>>>>> can be clear-eyed on what kinds of expectations we have for the
>>>>>>>>>>>>>>>>>>>>>>>>> participants. If we expect users (RO’s) to have to set up the AS-RS
>>>>>>>>>>>>>>>>>>>>>>>>> relationship, or expect them to carry their AS, or manage their personal
>>>>>>>>>>>>>>>>>>>>>>>>> keys — I think we’ve lost the battle for relevance.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  — Justin
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> TXAuth mailing list
>>>>>>>>>>>>>>>>>>>>>> TXAuth@ietf.org
>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> TXAuth mailing list
>>>>>>>>>>>>>>>>> TXAuth@ietf.org
>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> TXAuth mailing list
>>>>>>>>>>>>>>> TXAuth@ietf.org
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>
>> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>