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

[Fabien Imbault <[e-mail]>]

Hi Adrian,

Calling to one AS per persona can only be optional, as we have no way, and
no wish, of knowing all the identities used by the RO.

I think this relates to the idea of the RO having its own distinct agent,
but I still don't understand how that would work (even re-reading the
thread in issue 145). Could you elaborate?

Thxs
Fabien


Le sam. 20 mars 2021 à 06:08, Adrian Gropper <[e-mail]> a
écrit :

> @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.
>
> Beyond that fairly obvious principle, we could spread our interactions
> among as many services as possible. We already do this when we spread
> assets across multiple banks, internet services across redundant platforms,
> or we use LinkedIn, Twitter, and Facebook with limited overlap in social
> graphs.
>
> At the next level down, we want to manage resources at each RS using least
> authority in order to make AS policy vulnerabilities easier to spot and
> debug. My AS might get multiple capabilities or access to scopes from an
> RS, each one carefully labeled with its intended uses so that the policy
> engine of my AS could be structured to consider requests relative to only
> one capability or scope family at a time. For example, in issuing health
> record authorizations, I might separate the behavioral health capabilities
> from capabilities to access the physical parts of my record at a given
> hospital's GNAP RS API.
>
> Lastly, at the level of attenuation, I would choose a relationship with
> RSs that issue to me capabilities that can be attenuated not only by my AS
> but also by the requesting parties that receive them as part of an access
> token.
>
> Adrian
>
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>