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

[Adrian Gropper <[e-mail]>]

@Alan - The recent conversation between Justin and I does not use the AS-RS
/ AS-RO framing. For now, we're trying to figure out what is core to GNAP
and what is optional.

- Adrian

On Fri, Mar 26, 2021 at 11:35 AM Alan Karp <[e-mail]> wrote:

>  Adrian Gropper <[e-mail]> wrote:
>
>> Good. I agree with the externalizing framing you use. To me, they are a
>> pair. They represent the separation of concerns I’m focused on. The AS has
>> policies, gets requests from clients, and returns access tokens.
>>
>
> I thought you also want RO to be able to delegate to a client without
> AS-RS knowing what policy was used for that delegation.  That's the
> function of AS-RO.  The client asks AS-RO for some permissions.  AS-RO
> either does a token exchange with AS-RS or gives the client something to
> present to AS-RS to get a new access token.  Introducing AS-RO also allows
> RO to express policies that AS-RS may not support, such as break glass.
>
> --------------
> Alan Karp
>
>
> On Fri, Mar 26, 2021 at 8:26 AM Adrian Gropper <[e-mail]>
> wrote:
>
>> Good. I agree with the externalizing framing you use. To me, they are a
>> pair. They represent the separation of concerns I’m focused on. The AS has
>> policies, gets requests from clients, and returns access tokens.
>>
>> So what are we disagreeing about?
>>
>> - Adrian
>>
>> On Fri, Mar 26, 2021 at 10:38 AM Justin Richer <[e-mail]> wrote:
>>
>>> Adrian,
>>>
>>> Yes, the RO is the party/entity which holds the rights for delegation,
>>> and they perform that delegation to a piece of software (the client)
>>> through the AS. The RS is what they’re delegating the access of, for
>>> API-access use cases (again, user/subject information is similar but
>>> different).
>>>
>>> There isn’t a delegation between the RS and AS, then. You can perhaps
>>> view them as externalizing functions that they might otherwise hold close,
>>> but not delegating in the same way the client gets delegated to. You can
>>> frame it one of two ways:
>>>
>>>  - The RS externalizes its security, policy, authorization, and
>>> delegation functions to the AS and looks for access tokens from the AS as
>>> proof of that happening (this is the most in line with the model you’ve
>>> been presenting)
>>>  - The AS externalizes its data-API functions to into the RS and
>>> produces access tokens for the RS to consume/validate (this is actually the
>>> model that OAuth 2 started with, in extracting the RS as a separate entity
>>> as opposed to OAuth 1)
>>>
>>> They tell different views of the same reality. In OAuth, it’s assumed
>>> that the RO interacts with the AS directly to perform the delegation to the
>>> client. In GNAP, we’ve got an opportunity to expand that, which has been
>>> (to me) one of the biggest outcomes of this discussion.
>>>
>>>  — Justin
>>>
>>> On Mar 26, 2021, at 10:04 AM, Adrian Gropper <[e-mail]>
>>> wrote:
>>>
>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>