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

[Fabien Imbault <[e-mail]>]

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