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

[Fabien Imbault <[e-mail]>]

Thanks. The general problem statement is clear.

The proposed solution a bit less (to me). I understood that from point 2,
Alan involves 2 ASs. You said : "There’s no obvious reason to have two
types of ASs". Do you see an alternative ?

Regarding the last item, I don't think that naming RQ by end-user created
the problem. It might just highlight the asymmetry, which fundamentally
exists.

Fabien


On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <[e-mail]>
wrote:

> Recap:
> 1 - Justin (I think) introduced the idea of an AS on the RS trust boundary
> side.
> 2 - I said the RO should not have to share policies with the RS.
> 3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds of
> PDPs.
>
> The thing is that step 2 is not symmetrical. The RO has a legitimate
> privacy interest in keeping their policies private and minimizing the
> leakage of information about requests that are posed against those
> policies.
>
> The RS, on the other hand, should be publishing its policies (e.g. what
> it’s selling or what jurisdiction it’s in or what tokens or scopes it
> supports). The RS has no obvious privacy interest in GNAP. It’s just an
> enforcer.
>
> There is one other privacy interest to consider around the RS and that is
> the requesting party (the end-user that is not the RO :-) might prefer to
> share attributes with the RS instead of the RO or something controlled by
> the RO. This case could be an “extension” to GNAP and might result in a
> split AS as a solution. This problem was introduced when the editors
> decided to replace RQ with end-user. Obviously, the RO end-user has no
> privacy interests relative to itself.
>
> Adrian
>
>
>
>
> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <[e-mail]>
> wrote:
>
>> I was referring to "By my definition, this model has two ASs since both
>> are processing requests into tokens". If there's no reason to have 2 types
>> of ASs, that's fine then.
>> But I'm a bit lost in where we stand with the idea.
>>
>> Could you recap?
>>
>> Fabien
>>
>> Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <[e-mail]> a
>> écrit :
>>
>>> There’s no obvious reason to have two types of ASs. Any AS that is
>>> executing the policies of the RS can look to GNAP like the RS itself. Why
>>> would GNAP expose that interface to anyone?
>>>
>>> Adrian
>>>
>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs is
>>>> not that easy to grasp.
>>>>
>>>> Fabien
>>>>
>>>> Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <[e-mail]>
>>>> a écrit :
>>>>
>>>>> The purpose of either handling policies locally or delegating them to
>>>>> the RO agent.
>>>>>
>>>>> Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <[e-mail]>
>>>>> a écrit :
>>>>>
>>>>>> What purpose would be served by GNAP splitting the AS into two
>>>>>> components?
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> 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
>>>>>>>>>
>>>>>>>>