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

[Adrian Gropper <[e-mail]>]

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