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

[Fabien Imbault <[e-mail]>]

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