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

[Alan Karp <[e-mail]>]

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