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

[Adrian Gropper <[e-mail]>]

Justin,

Big YES to “ 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.” and probably everything else you just said.

I seem to not understand the delegation design between RS and AS. In my
view, that delegation always goes through the RO, although the RO may be
forced to choose from a list provided by the RS.

In my view, GNAP, can acknowledge this and design to be agnostic to whether
the AS is specified by he RO or picked from a list of 1 or more choices
provided by the RS.

- Adrian

On Fri, Mar 26, 2021 at 9:30 AM Justin Richer <[e-mail]> wrote:

> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]> wrote:
>>
>>> Justin Richer <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>>> 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 <
>>>>> [e-mail]> 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 <
>>>>>> [e-mail]> 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 <
>>>>>>> [e-mail]> 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 <
>>>>>>>> [e-mail]> 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 <
>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Adrian Gropper <[e-mail]> 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 <
>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Fabien Imbault <[e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Justin Richer <[e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <
>>>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Adrian Gropper wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> >> @Alan Karp <[e-mail]> 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
>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> TXAuth mailing list
>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> TXAuth mailing list
>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>
>>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>
>