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

[Fabien Imbault <[e-mail]>]

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
>