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

From: Adrian Gropper <[email-masked]>
Date: Sat, 20 Mar 2021 01:07:42 -0400

@Alan Karp <[email-masked]> 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.

Beyond that fairly obvious principle, we could spread our interactions
among as many services as possible. We already do this when we spread
assets across multiple banks, internet services across redundant platforms,
or we use LinkedIn, Twitter, and Facebook with limited overlap in social
graphs.

At the next level down, we want to manage resources at each RS using least
authority in order to make AS policy vulnerabilities easier to spot and
debug. My AS might get multiple capabilities or access to scopes from an
RS, each one carefully labeled with its intended uses so that the policy
engine of my AS could be structured to consider requests relative to only
one capability or scope family at a time. For example, in issuing health
record authorizations, I might separate the behavioral health capabilities
from capabilities to access the physical parts of my record at a given
hospital's GNAP RS API.

Lastly, at the level of attenuation, I would choose a relationship with RSs
that issue to me capabilities that can be attenuated not only by my AS but
also by the requesting parties that receive them as part of an access token.

Adrian

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 20 Mar 2021 09:23:14 +0100

Hi Adrian,

Calling to one AS per persona can only be optional, as we have no way, and
no wish, of knowing all the identities used by the RO.

I think this relates to the idea of the RO having its own distinct agent,
but I still don't understand how that would work (even re-reading the
thread in issue 145). Could you elaborate?

Thxs
Fabien

Le sam. 20 mars 2021 à 06:08, Adrian Gropper <[email-masked]> a
écrit :

> @Alan Karp <[email-masked]> shared a talk about the Principle Of
> Least Authority (POLA) in a recent comment
> 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.
>
> Lastly, at the level of attenuation, I would choose a relationship with
> RSs that issue to me capabilities that can be attenuated not only by my AS
> but also by the requesting parties that receive them as part of an access
> token.
>
> Adrian
>
>
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Adrian Gropper <[email-masked]>
Date: Sat, 20 Mar 2021 05:49:25 -0400

Hi Fabien,

Yes, it’s optional and adding meaningful options is one way to consider the
ethical imperative http://www.cybsoc.org/heinz.htm

If I understand Alan’s teachings, the RS has the option to either issue one
or more capabilities to the RO or to store some identity-related
information about the RO such as the DID of the RO and, by reference, the
AS service endpoint controlled by that DID.

Given some capabilities, the RO can either deal with them manually or hand
them to an AS. Either way, the RS has no idea of the RO’s choice until it
receives a token from some end user. This seems to be what the Letters of
Transit in Casablanca were all about.

If, on the other hand, the RO chooses to give 5e RS a DID, a self-sovereign
identifier, instead of taking some capabilities, then the RS has the
expectation  to trust tokens signed by that DID.

It’s my hope that GNAP can allow an ethical RS to offer both choices to the
RO.

Adrian

On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault <[email-masked]>
wrote:

>> At the next level down, we want to manage resources at each RS using
>> least authority in order to make AS policy vulnerabilities easier to spot
>> and debug. My AS might get multiple capabilities or access to scopes from
>> an RS, each one carefully labeled with its intended uses so that the policy

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 20 Mar 2021 11:52:40 +0100

Thanks for the description.

Trying to summarize what a capability  flow would look like following those
ideas:

1) RS issues a capability for the RO. For instance "view and download
photo".

2) RO can delegate that capability (or an attenuated version) to the AS.
Say "view photo", possibly with some ambient conditions.
If the RO further wants to choose between a list of possible ASs, the RO
would have to signal its choice to the RS, which would then have to signal
it to the client (what we had called RS preflight in some discussions). So
the AS-RS relationship would be mediated via the RO (or more precisely its
agent).

3) a core GNAP negociation takes place with the AS (traditional photo
example).

Is that correct? Do not hesitate to correct me if I didn't accurately
capture what you said.
(I volontarily put DID aside for now)

Steps occurring before 3 are optional (for reasons discussed before and
also because we can't assume all RSs would be able to support that).

Fabien

Le sam. 20 mars 2021 à 10:49, Adrian Gropper <[email-masked]> a
écrit :

> Hi Fabien,
>
> Yes, it’s optional and adding meaningful options is one way to consider
> the ethical imperative http://www.cybsoc.org/heinz.htm
>
> If I understand Alan’s teachings, the RS has the option to either issue
> one or more capabilities to the RO or to store some identity-related
> If, on the other hand, the RO chooses to give 5e RS a DID, a
> self-sovereign identifier, instead of taking some capabilities, then the RS
> has the expectation  to trust tokens signed by that DID.
>
> It’s my hope that GNAP can allow an ethical RS to offer both choices to
> the RO.
>
> Adrian
>
>
>> Calling to one AS per persona can only be optional, as we have no way,
>> and no wish, of knowing all the identities used by the RO.
>>
>>> 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.
>>>

---

From: Adrian Gropper <[email-masked]>
Date: Sat, 20 Mar 2021 08:03:10 -0400

Fabien, that is not the way I think of capabilities working. I would prefer
to leave the explanation to experts that have tried to teach me over the
years. That’s, in part, why I recommended Alan’s 40 minute talk at the
beginning of this thread.

To hold us over until one of them responds, I think of capabilities as a
token that is signed by the issuer so no trust is involved. If the RS
issues a capability to the RO signed by the RS, then it’s a pure bearer
token and any client that appears at the RS API with that capability will
access the resource. That’s option 1.

Option 2 is not based on capabilities. The RS stores a public key and
trusts any token signed to that public key. The public key represents the
identity of the RO or the AS that the RO delegated to. That’s opaque to the
RS.

So the difference between the two options is in who signed the access
token. The RS can offer both options to the RO if they’re nice.

Adrian

On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbault <[email-masked]>
wrote:

> Trying to summarize what a capability  flow would look like following
> those ideas:
>
>> Given some capabilities, the RO can either deal with them manually or
>> hand them to an AS. Either way, the RS has no idea of the RO’s choice until
>> it receives a token from some end user. This seems to be what the Letters
>> of Transit in Casablanca were all about.
>>
>>> I think this relates to the idea of the RO having its own distinct
>>> agent, but I still don't understand how that would work (even re-reading
>>> the thread in issue 145). Could you elaborate?
>>>
>>> Thxs
>>> Fabien
>>>
>>>

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 20 Mar 2021 13:41:46 +0100

Indeed I was asking because it's easy to get it wrong, so the feedback of
higher authorities (Mark or Alan) is most welcome!

In the flow I was indeed expecting bearer tokens.

Fabien

Le sam. 20 mars 2021 à 13:03, Adrian Gropper <[email-masked]> a
écrit :

> Fabien, that is not the way I think of capabilities working. I would
> prefer to leave the explanation to experts that have tried to teach me over
> the years. That’s, in part, why I recommended Alan’s 40 minute talk at the
>>>> Le sam. 20 mars 2021 à 06:08, Adrian Gropper <[email-masked]>
>>>> a écrit :
>>>>
>>>>> Lastly, at the level of attenuation, I would choose a relationship
>>>>> with RSs that issue to me capabilities that can be attenuated not only by
>>>>> my AS but also by the requesting parties that receive them as part of an
>>>>> access token.
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>> --
>>>>> TXAuth mailing list
>>>>> [email-masked]

---

From: Adrian Gropper <[email-masked]>
Date: Sat, 20 Mar 2021 09:55:33 -0400

While we wait, I might add this other perspective: If the RS trusts an
access token, then honor it. If the RS doesn’t trust the access token,
contact an AS with adequate authority. If it knows no AS with adequate
authority, deny the request, with malice.

Adrian

On Sat, Mar 20, 2021 at 8:42 AM Fabien Imbault <[email-masked]>
wrote:

>>>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hi Adrian,
>>>>>
>>>>>> @Alan Karp <[email-masked]> shared a talk about the Principle
>>>>>> Of Least Authority (POLA) in a recent comment
>>>>>> Beyond that fairly obvious principle, we could spread our
>>>>>> interactions among as many services as possible. We already do this when we
>>>>>> spread assets across multiple banks, internet services across redundant
>>>>>> platforms, or we use LinkedIn, Twitter, and Facebook with limited overlap
>>>>>> in social graphs.
>>>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Sat, 20 Mar 2021 10:13:09 -0400

While we still wait, here’s yet another framing: When an RS gets a request
that it thinks it has adequate policies to evaluate, do it. If it does not
have adequate policies, refer the request to someone that might have
adequate policies and don’t worry about it, you might hear back or not.

Adrian

On Sat, Mar 20, 2021 at 9:55 AM Adrian Gropper <[email-masked]>
wrote:

>>>> 2) RO can delegate that capability (or an attenuated version) to the
>>>> AS. Say "view photo", possibly with some ambient conditions.
>>>> If the RO further wants to choose between a list of possible ASs, the
>>>> RO would have to signal its choice to the RS, which would then have to
>>>> signal it to the client (what we had called RS preflight in some
>>>> discussions). So the AS-RS relationship would be mediated via the RO
>>>> (or more precisely its agent).
>>>>
>>>> Le sam. 20 mars 2021 à 10:49, Adrian Gropper <[email-masked]>
>>>> a écrit :
>>>>
>>>>> Hi Fabien,
>>>>>
>>>>> Yes, it’s optional and adding meaningful options is one way to
>>>>> consider the ethical imperative http://www.cybsoc.org/heinz.htm
>>>>>
>>>>> If I understand Alan’s teachings, the RS has the option to either
>>>>> issue one or more capabilities to the RO or to store some identity-related
>>>>> It’s my hope that GNAP can allow an ethical RS to offer both choices
>>>>> to the RO.
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>>> Calling to one AS per persona can only be optional, as we have no
>>>>>> way, and no wish, of knowing all the identities used by the RO.
>>>>>>
>>>>>>> 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

---

From: Alan Karp <[email-masked]>
Date: Sat, 20 Mar 2021 10:57:51 -0700

You are close on the flow.  The only change is that the RO does not need to
inform the RS that the RO is using an AS.

The flow is described in our Zebra Copy tech report,
https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the
way, uses non-opaque tokens.  (Don't worry about the length.  The last 60
pages are a walkthrough of the reference implementation.)  I believe that
example is closer to the GNAP use cases than the one in the talk Adrian
mentioned.  Also, I hope the different terminology isn't too confusing.

   1. The owner of RS delegates a set of rights to the administrator of the
   service, AS-RS.
   2. RO contacts AS-RS and gets back a capability authorizing a specific
   set of methods at RS.
   3. RO can use that capability to invoke RS with any of the authorized
   permissions.
   4. RO can delegate a subset of those rights to a client, who can then
   invoke the RS with any of the authorized permissions.
   5. RO can delegate a subset of those rights to an AS-RO.
   6. AS-RO can delegate a subset of those rights to a client based on a
   policy specified by RO.
   7. That client can invoke RO with any of the authorized permissions.

Note that AS-RS doesn't need to know anything about the various
delegatees.  It just needs to verify that the delegations are valid.

Responsibility tracking follows those steps.  AS-RS will hold RO
responsible for all uses of any token delegated from the one AS-RS gave
RO.  Each delegator is responsible for knowing who to hold responsible for
each of its delegations.  Say there's a $100 penalty for misuse, and the
client in step 6 does something bad.  AS-RS will collect $100 from RO.
It's up to RO to collect $100 from AS-RO and up to AS-RO to collect from
the client.

This approach is the only thing that makes sense.  What would RS or AS-RS
do with the information that RO delegated to AS-RO?  AS-RS has no way of
collecting from AS-RO; only RO does.

--------------
Alan Karp

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 20 Mar 2021 19:22:21 +0100

Hi Alan,

Thanks a lot. This looks good. I'll have a detailed look at zebra copy.

Actually I was suggesting a feedback to the RS only for the worst case
scenario: if the RO has the choice of AS and is different from the
end-user, then the client wouldn't be able to know which AS is to be
called.

Fabien

Le sam. 20 mars 2021 à 18:58, Alan Karp <[email-masked]> a écrit :

> You are close on the flow.  The only change is that the RO does not need
> to inform the RS that the RO is using an AS.
>
>    1. The owner of RS delegates a set of rights to the administrator of
>    the service, AS-RS.

---

From: Adrian Gropper <[email-masked]>
Date: Sat, 20 Mar 2021 16:20:11 -0400

To be clear, I'm suggesting that GNAP standardize two separate flows if
necessary and give the RS the option of supporting one or both of them.
- Option 1 is capabilities and exactly as Alan just outlined where the RO
does not need to inform the RS that it is using an AS.
- Option 2 is an RO-controlled AS as might be linked to a DID service
endpoint.

Adrian

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 20 Mar 2021 21:58:11 +0100

OK fine then.

I just remembered that you suggested a choice between several AS-RSs by the
RO. If that's not the case, there's no problem.

Fabien

Le sam. 20 mars 2021 à 21:20, Adrian Gropper <[email-masked]> a
écrit :

>>    2. RO contacts AS-RS and gets back a capability authorizing a
>>    specific set of methods at RS.

---

From: Adrian Gropper <[email-masked]>
Date: Sat, 20 Mar 2021 17:06:38 -0400

You remember accurately, Fabien. It was one of the ways I was trying to
explain my suggestion. Sorry to mislead. I hope the case I'm making with
Alan's help is clearer now.

Adrian

On Sat, Mar 20, 2021 at 4:58 PM Fabien Imbault <[email-masked]>
wrote:

> OK fine then.
>
> I just remembered that you suggested a choice between several AS-RSs by
> the RO. If that's not the case, there's no problem.
>
> Fabien
>
>>>    3. RO can use that capability to invoke RS with any of the
>>>    authorized permissions.
>>>    4. RO can delegate a subset of those rights to a client, who can
>>>    then invoke the RS with any of the authorized permissions.
>>>    6. AS-RO can delegate a subset of those rights to a client based on
>>>    a policy specified by RO.
>>> This approach is the only thing that makes sense.  What would RS or
>>> AS-RS do with the information that RO delegated to AS-RO?  AS-RS has no way
>>> of collecting from AS-RO; only RO does.
>>>
>>> --------------
>>> Alan Karp
>>>
>>>

---

From: Alan Karp <[email-masked]>
Date: Sat, 20 Mar 2021 19:33:05 -0700

> but also by the requesting parties that receive them as part of an access

The ability to attenuate at each delegation is key to enforcing least
privilege.

--------------
Alan Karp

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 21 Mar 2021 10:18:00 -0700

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

Thanks,

Ben

---

From: Fabien Imbault <[email-masked]>
Date: Sun, 21 Mar 2021 19:34:35 +0100

Hi Ben

Very good question.

The core protocol probably will be able to elude providing an answer,
focusing on singular requests.

Any extension covering AS-RS relationships will have to handle its socio
technical impact.

Fabien

Le dim. 21 mars 2021 à 18:18, Benjamin Kaduk <[email-masked]> a écrit :

> authority

---

From: Adrian Gropper <[email-masked]>
Date: Sun, 21 Mar 2021 15:38:39 -0400

In the SSI community, we have had more than a year of discussion, often
intense, over the relationship between DIDs (decentralized identifiers),
service endpoints (and their protocols) in DIDs (how many and what do they
point to) and concepts like "herd privacy" that are essential to avoiding
unwanted correlation and traffic analysis. With the recent ascension of DID
core to Candidate Recommendation
https://www.w3.org/TR/2021/CR-did-core-20210318/ We consider some of these
issues settled. Along the way we've created various privacy analyses and
had review by W3C. Section 10 is a great place to start as we consider the
privacy of protocols like GNAP CR-did-core-20210318
<https://www.w3.org/TR/2021/CR-did-core-20210318/#privacy-considerations>.

tl:dr My personal perspective after all of this work, is that mediator
roles are a useful option at the intersection between a data model like DID
and a protocol like GNAP. There were two classes of DID service endpoint
protocols that stood out: messaging and authorization. Either one might be
enhanced by the DID controller introducing a mediator but it doesn't change
the core aspects of the messaging or authorization protocol itself. YMMV

Adrian

On Sun, Mar 21, 2021 at 2:34 PM Fabien Imbault <[email-masked]>
wrote:

>> maps

---

From: Justin Richer <[email-masked]>
Date: Mon, 22 Mar 2021 09:55:29 -0400

> super-popular AS services.  That topic is a current matter of concern to

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

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 22 Mar 2021 13:28:42 -0400

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 <[email-masked]> wrote:

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 22 Mar 2021 13:48:48 -0400

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. 

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >> @Alan Karp <[email-masked] <mailto:[email-masked]>> shared a talk about the Principle Of Least
> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693>
> >> I recommend it.
> >>

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 22 Mar 2021 14:14:24 -0400

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 <[email-masked]> 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.
>
> 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
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 22 Mar 2021 14:40:17 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Adrian,
> 
>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 22 Mar 2021 16:13:07 -0400

Justin,

Indeed, we do have a problem with the way terminology is being used in this
conversation. To help with that, you asked me to provide a use-case rather
than arguing over terminology. I did that with the HIPAA API Task Force
use-case in the thread you started that has gone silent since I tried to
summarize the discussion here: FPIrji3uAQDLkGtqVvC-PreMWbI
<https://mailarchive.ietf.org/arch/msg/txauth/FPIrji3uAQDLkGtqVvC-PreMWbI/>

In another approach, Alan Karp has tried to find a consensus around using
AS-RS and AS-RO terminology. That seems to have gone quiet as well.

As far as I can tell, Justin, you are insisting that the RO share
authorization policies with an RS (or AS-RS) that the RO does not control
in the sense that you expect requesting parties to present their claims and
purposes to the AS-RS and then have some expectation that the AS-RS can
convey the request to a separate policy decision point that is controlled
by the RO. I would call that PDP the AS-RO but other names are certainly
possible.

Please, how do I as an RO keep the RS (or AS-RS) as ignorant as possible of
the request content and my RO policies?

Adrian

On Mon, Mar 22, 2021 at 2:40 PM Justin Richer <[email-masked]> 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
>
>> 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
>> 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
>>
>>
>>
>>> 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

---

From: Alan Karp <[email-masked]>
Date: Mon, 22 Mar 2021 13:25:41 -0700

Justin Richer <[email-masked]> wrote:

> 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

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 23 Mar 2021 12:12:23 +0100

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 <[email-masked]> wrote:

>    - A different user contacts AS-RO to get a potentially sub-scoped
>    access token from AS-RO.
>> 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
>> 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
>>>> 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).
>>>>

---

From: Alan Karp <[email-masked]>
Date: Tue, 23 Mar 2021 08:15:17 -0700

> only secure if the tokens issued by AS-RS are cryptographically attenuable

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 <[email-masked]>
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
>>> 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 delegates one or more of those tokens, potentially sub-scoped,
>>    to AS-RO.
>>    - That user presents the access token delegated by AS-RO when
>>    invoking the resource.
>>
>>> 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
>>> 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
>>>
>>>>> to
>>>>> 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
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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
>> [email-masked]

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 24 Mar 2021 17:36:34 +0100

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 <[email-masked]> wrote:

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

---

From: Alan Karp <[email-masked]>
Date: Wed, 24 Mar 2021 12:17:27 -0700

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 <[email-masked]>
wrote:

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

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 24 Mar 2021 22:20:29 +0100

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 <[email-masked]> a écrit :

>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to
>> capture your input.
>>>> 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.
>>>>
>>>
>>>> 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
>>>>
>>>>>> 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.
>>>>>>
>>>>>    - RO delegates one or more of those tokens, potentially
>>>>>    sub-scoped, to AS-RO.
>>>>>> 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
>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory,
>>>>>>> I have a way to start out my RS relationship pseudonymously.
>>>>>>>
>>>>>>>> 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
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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
>>>>> [email-masked]

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 24 Mar 2021 22:41:02 -0400

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 <[email-masked]>
wrote:

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

---

From: Alan Karp <[email-masked]>
Date: Wed, 24 Mar 2021 20:22:00 -0700

Adrian Gropper <[email-masked]> 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 <[email-masked]>
wrote:

>>> AS-RO is an AS that RO trusts to delegate RO's access tokens according
>>> to RO's policies.
>>>
>>> --------------
>>> Alan Karp
>>>
>>>
>>>>>>>    - A different user contacts AS-RO to get a potentially
>>>>>>>    sub-scoped access token from AS-RO.
>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 24 Mar 2021 23:26:43 -0400

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 <[email-masked]> wrote:

> 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 9:36 AM Fabien Imbault <
>>>>>>> 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
>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>>> 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
>>>>>>>>>>> For further reading on these topics, I recommend both “Why
>>>>>>>>>>> Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.
>>>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 25 Mar 2021 07:59:09 +0100

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 <[email-masked]> a
écrit :

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

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 25 Mar 2021 03:04:28 -0400

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 <[email-masked]>
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
>
>> 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
>>
>>>> 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
>>>> On Wed, Mar 24, 2021 at 5:21 PM Fabien Imbault <
>>>>> Isn't that what the AS is supposed to be, only with the caveat that
>>>>> the policy is defined locally?
>>>>>
>>>>> Fabien
>>>>>
>>>>>
>>>>>> AS-RO is an AS that RO trusts to delegate RO's access tokens
>>>>>> according to RO's policies.
>>>>>>
>>>>>> --------------
>>>>>> Alan Karp
>>>>>>
>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 25 Mar 2021 08:07:43 +0100

The purpose of either handling policies locally or delegating them to the
RO agent.

Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <[email-masked]> a
écrit :

>>>> 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
>>>>
>>>>
>>>>> Thank you for creating the issue. My definition of AS is independent
>>>>> of AS-RO or AS-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.
>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>    - That user presents the access token delegated by AS-RO
>>>>>>>>>>>    when invoking the resource.
>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 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).
>>>>>>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 25 Mar 2021 08:10:46 +0100

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 <[email-masked]> a
écrit :

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

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 25 Mar 2021 03:16:36 -0400

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 <[email-masked]>
wrote:

>>>> Le jeu. 25 mars 2021 à 04:26, Adrian Gropper <[email-masked]>
>>>> a écrit :
>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> On Wed, Mar 24, 2021 at 7:41 PM Adrian Gropper <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223)
>>>>>>>>>> to capture your input.
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 25 Mar 2021 08:24:08 +0100

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 <[email-masked]> a
écrit :

>> Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <[email-masked]>
>> a écrit :
>>
>>> The purpose of either handling policies locally or delegating them to
>>> the RO agent.
>>>
>>>> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <
>>>>>> 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
>>>>>>
>>>>>>>> Thank you for creating the issue. My definition of AS is
>>>>>>>> independent of AS-RO or AS-RS.
>>>>>>>> The only other possibility is that the request is packaged by the
>>>>>>>> AS and sent elsewhere (an agent) for evaluation against policy and a
>>>>>>>>> Isn't that what the AS is supposed to be, only with the caveat
>>>>>>>>> that the policy is defined locally?
>>>>>>>>>
>>>>>>>>> Fabien
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 25 Mar 2021 03:48:22 -0400

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 <[email-masked]>
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.
>>>> Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <[email-masked]>
>>>> a écrit :
>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue. Now,
>>>>>>>>>>>>>>>>> in theory, I have a way to start out my RS relationship pseudonymously.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>> For further reading on these topics, I recommend both
>>>>>>>>>>>>>>>>>> “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.
>>>>>>>>>>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 25 Mar 2021 09:15:01 +0100

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 <[email-masked]>
wrote:

>>>> Note : I'm not sure that's a good idea, but having 2 types of ASs is
>>>> not that easy to grasp.
>>>>
>>>> Fabien
>>>>
>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    - That user presents the access token delegated by
>>>>>>>>>>>>>>>>    AS-RO when invoking the resource.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> 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 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
>>>>>>>>>>>>>>>> [email-masked]

---

From: Denis <[email-masked]>
Date: Thu, 25 Mar 2021 09:19:20 +0100

I am full  lost in where we stand with all these ideas which look like a 
Brownian motion.

Which entity is trusting which other entity and for which purpose(s) ?

Denis

> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Recap:
>     1 - Justin (I think) introduced the idea of an AS on the RS trust
>     boundary side.
>     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
>     <[email-masked] <mailto:[email-masked]>> 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.
>         Le jeu. 25 mars 2021 à 08:16, Adrian Gropper
>         <[email-masked] <mailto:[email-masked]>> 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
>             <[email-masked]
>             <mailto:[email-masked]>> 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
>                 <[email-masked]
>                 <mailto:[email-masked]>> 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
>                     <[email-masked]
>                     <mailto:[email-masked]>> a écrit :
>
>                         On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault
>                         <[email-masked]
>                         <mailto:[email-masked]>> 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 <[email-masked]
>                             <mailto:[email-masked]>> a écrit :
>
>                                 On Wed, Mar 24, 2021 at 11:22 PM Alan
>                                 Karp <[email-masked]
>                                 <mailto:[email-masked]>> wrote:
>
>                                     Adrian Gropper
>                                     <[email-masked]
>                                     <mailto:[email-masked]>>
>                                     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.
>
>
>                                     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
>                                     <[email-masked]
>                                     <mailto:[email-masked]>>
>                                     wrote:
>
>                                         <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
>                                         <[email-masked]
>                                         <mailto:[email-masked]>>
>                                         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
>                                             <[email-masked]
>                                             <mailto:[email-masked]>>
>                                             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
>                                                 <[email-masked]
>                                                 <mailto:[email-masked]>>
>                                                 wrote:
>
>                                                     Hi Alan and Adrian,
>
>                                                     I've created issue
>                                                     AS-RO policy
>                                                     delegation
>                                                     (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223
>                                                     <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
>                                                     <[email-masked]
>                                                     <mailto:[email-masked]>>
>                                                     wrote:
>
>                                                         Fabien Imbault
>                                                         <[email-masked]
>                                                         <mailto:[email-masked]>>
>                                                         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
>                                                         <[email-masked]
>                                                         <mailto:[email-masked]>>
>                                                         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
>                                                             <[email-masked]
>                                                             <mailto:[email-masked]>>
>                                                             wrote:
>
>                                                                 Justin
>                                                                 Richer
>                                                                 <[email-masked]
>                                                                 <mailto:[email-masked]>>
>                                                                 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
>                                                                 <[email-masked]
>                                                                 <mailto:[email-masked]>>
>                                                                 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
>>                                                                     <[email-masked]
>>                                                                     <mailto:[email-masked]>>
>>                                                                     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
>>                                                                     <[email-masked]
>>                                                                     <mailto:[email-masked]>>
>>                                                                     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.
>>
>>
>>                                                                         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
>>>                                                                         <[email-masked]
>>>                                                                         <mailto:[email-masked]>>
>>>                                                                         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
>>>                                                                         <[email-masked]
>>>                                                                         <mailto:[email-masked]>>
>>>                                                                         wrote:
>>>
>>>                                                                             On
>>>                                                                             Mar
>>>                                                                             21,
>>>                                                                             2021,
>>>                                                                             at
>>>                                                                             1:18
>>>                                                                             PM,
>>>                                                                             Benjamin
>>>                                                                             Kaduk
>>>                                                                             <[email-masked]
>>>                                                                             <mailto:[email-masked]>>
>>>                                                                             wrote:
>>>                                                                             >
>>>
>>>                                                                             >
>>>                                                                             On
>>>                                                                             Sat,
>>>                                                                             Mar
>>>                                                                             20,
>>>                                                                             2021
>>>                                                                             at
>>>                                                                             01:07:42AM
>>>                                                                             -0400,
>>>                                                                             Adrian
>>>                                                                             Gropper
>>>                                                                             wrote:
>>>                                                                             >>
>>>                                                                             @Alan
>>>                                                                             Karp
>>>                                                                             <[email-masked]
>>>                                                                             <mailto:[email-masked]>>
>>>                                                                             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
>                                                                 [email-masked]
>                                                                 <mailto:[email-masked]>
>                                                                 <https://www.ietf.org/mailman/listinfo/txauth>
>
>                                             -- 
>                                             TXAuth mailing list
>                                             [email-masked]
>                                             <mailto:[email-masked]>
>                                             <https://www.ietf.org/mailman/listinfo/txauth>
>
>                                     -- 
>                                     TXAuth mailing list
>                                     [email-masked]
>                                     <mailto:[email-masked]>
>                                     <https://www.ietf.org/mailman/listinfo/txauth>
>
>

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 25 Mar 2021 04:26:09 -0400

I believe there are alternatives to having two kinds of ASs. The problem
may be a side-effect of deciding to switch away form treating the RO as
different from the RQ. That leads to downstream privacy issues. Our desire
for architectural simplicity is admirable but that may have been a step too
far.

There may also be solutions based on different types of tokens, as in
different capabilities (tokens signed by the RS) vs. tokens signed by the
AS. I’m not sure about that but Alan might have more to say.

Adrian

On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <[email-masked]>
wrote:

>>>> On Thu, Mar 25, 2021 at 3:11 AM Fabien Imbault <
>>>>>>>> Le jeu. 25 mars 2021 à 04:26, Adrian Gropper <
>>>>>>>> [email-masked]> a écrit :
>>>>>>>>
>>>>>>>>>>> The only other possibility is that the request is packaged by
>>>>>>>>>>> the AS and sent elsewhere (an agent) for evaluation against policy and a
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    - RO delegates one or more of those tokens,
>>>>>>>>>>>>>>>>>    potentially sub-scoped, to AS-RO.
>>>>>>>>>>>>>>>>>>> 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,
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 25 Mar 2021 09:44:38 +0100

Ok so I get you correctly:
- what matters is the RQ (could be a RO or a end-user or both : we don't
really care at a high-level, they're all treated as entities that make a
request)
- the policy is able to handle those different cases, based on its own
internal delegation protocol
- currently that requires AS-RS and AS-RO, but maybe it can be simplified

To answer to Denis, here's what I understood:
- RO trusts AS-RS (and then handles its own policies within AS-RO)
- end-user trusts AS-RO (through its client)

Could probably work but that's a fairly different model compared to OAuth2
(and of today's GNAP), with different frontiers between the AS and the RS.

Please do not hesitate to correct me if I'm wrong.

Fabien

On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <[email-masked]>
wrote:

>>> 3 - Alan invented the concept of AS-RO and AS-RS to separate two kinds
>>> of PDPs.
>>>
>>> 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
>>>> 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.
>>>> Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <[email-masked]>
>>>> a écrit :
>>>>
>>>>>> Le jeu. 25 mars 2021 à 08:07, Fabien Imbault <
>>>>>> [email-masked]> a écrit :
>>>>>>
>>>>>>> The purpose of either handling policies locally or delegating them
>>>>>>> to the RO agent.
>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>    - A different user contacts AS-RO to get a
>>>>>>>>>>>>>>>>>>    potentially sub-scoped access token from AS-RO.
>>>>>>>>>>>>>>>>>>> I think we got this basic component model pretty right
>>>>>>>>>>>>>>>>>>> in OAuth: the AS and RS and client working together. Where OAuth misses the
>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the rescue.
>>>>>>>>>>>>>>>>>>>> Now, in theory, I have a way to start out my RS relationship
>>>>>>>>>>>>>>>>>>>> pseudonymously.
>>>>>>>>>>>>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 25 Mar 2021 11:40:52 +0100

To reframe it closer to GNAP:
- AS = AS-RO, that's where you find the RO policies. The AS issues access
tokens to the client.
- the RO policies could be a) defined locally or b) in relationship with
the RS

There have been several ideas related to the AS-RS relationship b:
b1) the RS issues capabilities (which can be further attenuated by the RO)
b2) Adrian also discussed a DID based solution
b3) there was also an alternative ACL proposal from Denis (+ preflight)

Fabien

On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <[email-masked]>
wrote:

>>>> On Thu, Mar 25, 2021 at 3:24 AM Fabien Imbault <
>>>>>>>> Le jeu. 25 mars 2021 à 08:04, Adrian Gropper <
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with the
>>>>>>>>>>>>>> caveat that the policy is defined locally?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Fabien
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Mar 2021 08:45:55 -0400

The way I’m thinking about Adrian’s use case is that what we’re calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not exactly. This is the agent that the RO can use to set policies and manage consent on their behalf, and I’ve been arguing that it fits better into this vaguely-defined “interaction component” aspect of the current AS definition, and it’s not currently separated from the AS definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the RS trusts to issue tokens. In traditional OAuth the AS-RO and AS-RS are always the same thing, from a functional protocol perspective. An important point here is that from a client’s perspective, they’re only talking to the AS-RS since that’s where the client gets its tokens, because at the end of the day the client just wants to call the API at the RS and doesn’t care how that happens (from a protocol standpoint). 

Note well: Even thought I don’t believe that “AS-RO” is an authorization server at all, I’m going to keep using that term below for consistency with previous discussion.

So we have these fundamental relationships around getting the client to access the RS:

1. RS trusts AS-RS to issue tokens that RS will accept, validate, and process for requests from client
2. Client trusts AS-RS to issue tokens that client can use at RS
3. RO trusts RS to protect RO’s api through delegated access

On top of that, we’ve got some additional aspects that we’re discussing:

4. RO trusts AS-RO to manage RO’s policies at runtime
5. AS-RS trusts AS-RO to assert RO’s policies for access to RS
6. Client trusts whatever AS-RS sends client to deal with, including possibly RO-AS at runtime, because of (2)

What I have been saying is that 4/5/6 are optional details of how RS-AS runs things, and I think this also maps with Adrian’s view of choice, since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be motivated to pick a different RS who’s AS-RS lets me do just that. The same way I’d pick a different RS if their surrounding services didn’t accept my preferred federation login and I didn’t want to make another account. Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that. 

What we can do is make it possible for AS-RS to talk to AS-RO, both in philosophy of the protocol design and in concrete hooks to support (6) above. 

Separately, we can approach the issue of making 1/2 above more dynamic. This was UMA2’s “federated authorization” approach, and is behind a lot of the “bring your own AS” models out there. The problem with these is that we know from many years of experience that most RS’s aren’t interested in doing anything of the sort.

So with GNAP we can instead allow 4/5/6 to vary in a predictable and consistent way, letting the RS keep control over 1/2, thereby enabling choice in (3). We don’t have to be the ones who define the all of the details of every permutation of (5) to enable this, though. Some of this is going to be configuration out of band, some of it’s going to be communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech can come in and help out. I don’t think we need to put all the details for using these into core, nor do I think we’ll pull of The Great And Ultimate Abstraction for using these and other approaches. But we can at least start talking about “AS-RS” in such a way that it no longer assumes it’s always the same party dealing with the RO directly.

 — Justin

> On Mar 25, 2021, at 6:40 AM, Fabien Imbault <[email-masked]> wrote:
> 
> - AS = AS-RO, that's where you find the RO policies. The AS issues access tokens to the client.
> - the RO policies could be a) defined locally or b) in relationship with the RS
> 
> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> - what matters is the RQ (could be a RO or a end-user or both : we don't really care at a high-level, they're all treated as entities that make a request)
> - the policy is able to handle those different cases, based on its own internal delegation protocol
> Could probably work but that's a fairly different model compared to OAuth2 (and of today's GNAP), with different frontiers between the AS and the RS. 
> 
> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
> I believe there are alternatives to having two kinds of ASs. The problem may be a side-effect of deciding to switch away form treating the RO as different from the RQ. That leads to downstream privacy issues. Our desire for architectural simplicity is admirable but that may have been a step too far.
> 
> There may also be solutions based on different types of tokens, as in different capabilities (tokens signed by the RS) vs. tokens signed by the AS. I’m not sure about that but Alan might have more to say.
> 
> Adrian
> 
> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Recap:
> 1 - Justin (I think) introduced the idea of an AS on the RS trust boundary side.
> 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 <[email-masked] <mailto:[email-masked]>> 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. 
> Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> a écrit :
> On Thu, Mar 25, 2021 at 2:59 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Adrian Gropper <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Alan and Adrian,
> 
> I've created issue AS-RO policy delegation (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223>) to capture your input. 
> On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <[email-masked] <mailto:[email-masked]>> wrote:
> Fabien Imbault <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Adrian,
> 
>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 25 Mar 2021 14:13:26 +0100

Great analysis Justin.
I also don't think we need (and most probably don't want and anyway can't
take into account) all those variations in the core. We "just" need to make
sure it is possible to extend.

We'd have to see how such a thing as an "AS-RO" or "RO agent" fits in the
interaction component model, as it currently remains fairly abstract.

Fabien

On Thu, Mar 25, 2021 at 1:45 PM Justin Richer <[email-masked]> wrote:

> The way I’m thinking about Adrian’s use case is that what we’re calling
> the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at least not
> exactly. This is the agent that the RO can use to set policies and manage
> consent on their behalf, and I’ve been arguing that it fits better into
> this vaguely-defined “interaction component” aspect of the current AS
> definition, and it’s not currently separated from the AS definition. The
> “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP traditionally, it’s
> what the RS trusts to issue tokens. In traditional OAuth the AS-RO and
> AS-RS are always the same thing, from a functional protocol perspective. An
> important point here is that from a client’s perspective, they’re only
> talking to the AS-RS since that’s where the client gets its tokens, because
> at the end of the day the client just wants to call the API at the RS and
> doesn’t care how that happens (from a protocol standpoint).
>
> Note well: Even thought I don’t believe that “AS-RO” is an authorization
> server at all, I’m going to keep using that term below for consistency with
> previous discussion.
>
> 6. Client trusts whatever AS-RS sends client to deal with, including
> possibly RO-AS at runtime, because of (2)
>
> What I have been saying is that 4/5/6 are optional details of how RS-AS
> runs things, and I think this also maps with Adrian’s view of choice, since
> if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I would be
> motivated to pick a different RS who’s AS-RS lets me do just that. The same
> way I’d pick a different RS if their surrounding services didn’t accept my
> preferred federation login and I didn’t want to make another account. Of
> course, market forces being as they are, I might not have much of an
> actionable choice in RS, but GNAP can’t change that.
>
> What we can do is make it possible for AS-RS to talk to AS-RO, both in
> philosophy of the protocol design and in concrete hooks to support (6)
> above.
>
> Separately, we can approach the issue of making 1/2 above more dynamic.
> This was UMA2’s “federated authorization” approach, and is behind a lot of
> the “bring your own AS” models out there. The problem with these is that we
> know from many years of experience that most RS’s aren’t interested in
> doing anything of the sort.
>
> So with GNAP we can instead allow 4/5/6 to vary in a predictable and
> consistent way, letting the RS keep control over 1/2, thereby enabling
> choice in (3). We don’t have to be the ones who define the all of the
> details of every permutation of (5) to enable this, though. Some of this is
> going to be configuration out of band, some of it’s going to be
> communication at runtime. This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO,
> and a whole swath of other tech can come in and help out. I don’t think we
> need to put all the details for using these into core, nor do I think we’ll
> pull of The Great And Ultimate Abstraction for using these and other
> approaches. But we can at least start talking about “AS-RS” in such a way
> that it no longer assumes it’s always the same party dealing with the RO
> directly.
>
>  — Justin
>
>> Could probably work but that's a fairly different model compared to
>> OAuth2 (and of today's GNAP), with different frontiers between the AS and
>> the RS.
>>
>>>>> what it’s selling or what jurisdiction it’s in or what tokens or scopes it
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>> 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”.
>>>>>>>>>>>>>>>>>>>>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 25 Mar 2021 09:23:09 -0400

Thanks for the summary Justin. You very clearly articulated what I would
call the "regulatory capture" aspects of the problem. The RS will do
everything they can to avoid ceding power to the RO. By avoiding standards
that shift power to the RO, the platforms, IdP's, and most other service
providers delay regulation that would promote agent-based delegated access
to an API as a human right.

It's only recently, with GDPR, that lawmakers have started to consider
human rights outside of healthcare and are now introducing concepts such as
the separation of controller from processor in order to enable a new
generation of regulation. My perspective on GNAP is not arbitrary. It is
honed by years of experience in healthcare as everyone struggles with OAuth
and OpenID Connect, HEART, and now UDAP, to avoid doing in standards what
seems obvious from a human rights perspective.

What's interesting is that the "regulatory capture" standards game is now
playing out in a new arena. The recent transition of DID to W3C Candidate
Recommendation, together with Verifiable Credentials before that, means
that every regulator (e.g. US Health and Human Services, Scotland, EU...)
and some legislatures (e.g. Wyoming) are having to deal with the concept of
Self-Sovereign Identity. It's not fun for the community that has worked so
hard on SSI to now have to dance-around the actual impact of the SSI
standards.

With VC and DID, W3C seems to have broken through a "regulatory capture"
barrier and that community is moving on to standardize protocols like
DIDcomm and Encrypted Data Vaults that may avoid delegated authorization as
a human right. In my opinion, GNAP, and IETF, is facing the same
"regulatory capture" barrier.

Justin says: "Of course, market forces being as they are, I might not have
much of an actionable choice in RS, but GNAP can’t change that." What GNAP
makes core can change the choices the market offers by making GNAP an
interoperability badge that stands for Human-Centered Protocol. If GNAP
moves the human-centered part to an extension, then we're no better than
another "profile" on top of OAuth.

Adrian

---

From: Denis <[email-masked]>
Date: Thu, 25 Mar 2021 16:34:29 +0100

Since there is still no definition to explain what mean the acronyms 
AS-RO and AS-RS,
I have created my own terminology */RO-AS/* and */RO-RS/* and wrote a 
full story including
the definitions of a RO-AS and RO-RS. See the issue #223

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223

Denis

> Thanks for the summary Justin. You very clearly articulated what I 
> would call the "regulatory capture" aspects of the problem. The RS 
> will do everything they can to avoid ceding power to the RO. By 
> avoiding standards that shift power to the RO, the platforms, IdP's, 
> and most other service providers delay regulation that would promote 
> agent-based delegated access to an API as a human right.
>
> human rights outside of healthcare and are now introducing concepts 
> such as the separation of controller from processor in order to enable 
> a new generation of regulation. My perspective on GNAP is not 
> arbitrary. It is honed by years of experience in healthcare as 
> everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, 
> to avoid doing in standards what seems obvious from a human rights 
> perspective.
>
> What's interesting is that the "regulatory capture" standards game is 
> now playing out in a new arena. The recent transition of DID to W3C 
> Candidate Recommendation, together with Verifiable Credentials before 
> that, means that every regulator (e.g. US Health and Human Services, 
> Scotland, EU...) and some legislatures (e.g. Wyoming) are having to 
> deal with the concept of Self-Sovereign Identity. It's not fun for the 
> community that has worked so hard on SSI to now have to dance-around 
> the actual impact of the SSI standards.
>
> With VC and DID, W3C seems to have broken through a "regulatory 
> capture" barrier and that community is moving on to standardize 
> protocols like DIDcomm and Encrypted Data Vaults that may avoid 
> delegated authorization as a human right. In my opinion, GNAP, and 
> IETF, is facing the same "regulatory capture" barrier.
>
> Justin says: "Of course, market forces being as they are, I might not 
> have much of an actionable choice in RS, but GNAP can’t change that." 
> What GNAP makes core can change the choices the market offers by 
> making GNAP an interoperability badge that stands for Human-Centered 
> Protocol. If GNAP moves the human-centered part to an extension, then 
> we're no better than another "profile" on top of OAuth.
>
> Adrian
>
> On Thu, Mar 25, 2021 at 8:46 AM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The way I’m thinking about Adrian’s use case is that what we’re
>     calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP
>     sense, at least not exactly. This is the agent that the RO can use
>     to set policies and manage consent on their behalf, and I’ve been
>     arguing that it fits better into this vaguely-defined “interaction
>     component” aspect of the current AS definition, and it’s not
>     currently separated from the AS definition. The “AS-RS” maps to
>     what we’d call the “AS” in OAuth/GNAP traditionally, it’s what the
>     RS trusts to issue tokens. In traditional OAuth the AS-RO and
>     AS-RS are always the same thing, from a functional protocol
>     perspective. An important point here is that from a client’s
>     perspective, they’re only talking to the AS-RS since that’s where
>     the client gets its tokens, because at the end of the day the
>     client just wants to call the API at the RS and doesn’t care how
>     that happens (from a protocol standpoint).
>
>     Note well: Even thought I don’t believe that “AS-RO” is an
>     authorization server at all, I’m going to keep using that term
>     below for consistency with previous discussion.
>
>     6. Client trusts whatever AS-RS sends client to deal with,
>     including possibly RO-AS at runtime, because of (2)
>
>     What I have been saying is that 4/5/6 are optional details of how
>     RS-AS runs things, and I think this also maps with Adrian’s view
>     of choice, since if my RS’s AS-RS doesn’t allow me to plug in my
>     own AS-RO then I would be motivated to pick a different RS who’s
>     AS-RS lets me do just that. The same way I’d pick a different RS
>     if their surrounding services didn’t accept my preferred
>     federation login and I didn’t want to make another account. Of
>     course, market forces being as they are, I might not have much of
>     an actionable choice in RS, but GNAP can’t change that.
>
>     What we can do is make it possible for AS-RS to talk to AS-RO,
>     both in philosophy of the protocol design and in concrete hooks to
>     support (6) above.
>
>     Separately, we can approach the issue of making 1/2 above more
>     dynamic. This was UMA2’s “federated authorization” approach, and
>     is behind a lot of the “bring your own AS” models out there. The
>     problem with these is that we know from many years of experience
>     that most RS’s aren’t interested in doing anything of the sort.
>
>     So with GNAP we can instead allow 4/5/6 to vary in a predictable
>     and consistent way, letting the RS keep control over 1/2, thereby
>     enabling choice in (3). We don’t have to be the ones who define
>     the all of the details of every permutation of (5) to enable this,
>     though. Some of this is going to be configuration out of band,
>     some of it’s going to be communication at runtime. This is where
>     VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of other tech
>     can come in and help out. I don’t think we need to put all the
>     details for using these into core, nor do I think we’ll pull of
>     The Great And Ultimate Abstraction for using these and other
>     approaches. But we can at least start talking about “AS-RS” in
>     such a way that it no longer assumes it’s always the same party
>     dealing with the RO directly.
>
>      — Justin
>
>>     On Mar 25, 2021, at 6:40 AM, Fabien Imbault
>>     On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault
>>         - what matters is the RQ (could be a RO or a end-user or both
>>         : we don't really care at a high-level, they're all treated
>>         as entities that make a request)
>>         Could probably work but that's a fairly different model
>>         compared to OAuth2 (and of today's GNAP), with different
>>         frontiers between the AS and the RS.
>>
>>         On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>             I believe there are alternatives to having two kinds of
>>             ASs. The problem may be a side-effect of deciding to
>>             switch away form treating the RO as different from the
>>             RQ. That leads to downstream privacy issues. Our desire
>>             for architectural simplicity is admirable but that may
>>             have been a step too far.
>>
>>             There may also be solutions based on different types of
>>             tokens, as in different capabilities (tokens signed by
>>             the RS) vs. tokens signed by the AS. I’m not sure about
>>             that but Alan might have more to say.
>>
>>             Adrian
>>
>>             On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault
>>                 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
>>                 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
>>
>>
>>                     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
>>                         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.
>>                             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 <[email-masked]
>>                                 Le jeu. 25 mars 2021 à 08:07, Fabien
>>                                 Imbault <[email-masked]
>>                                     The purpose of either handling
>>                                     policies locally or delegating
>>                                     them to the RO agent.
>>
>>                                         What purpose would be served
>>                                         by GNAP splitting the AS into
>>                                         two components?
>>
>>                                         Adrian
>>
>>                                             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
>>                                             Le jeu. 25 mars 2021 à
>>                                             04:26, Adrian Gropper
>>                                                 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.
>>                                                 at 11:22 PM Alan Karp
>>                                                         In this
>>                                                         design, the
>>                                                         AS is the
>>                                                         AS-RO. By my
>>                                                         definition,
>>                                                         this model
>>                                                         has two ASs
>>                                                         since both
>>                                                         processing
>>                                                         requests into
>>                                                         tokens. The
>>                                                         problem with
>>                                                         this is
>>                                                         complexity
>>                                                         and privacy.
>>                                                         The RO may
>>                                                         not want to
>>                                                         share the
>>                                                         with the AS-RS.
>>                                                     More precisely,
>>                                                     RO has no choice
>>                                                     but to present
>>                                                     the required
>>                                                     That's why RO
>>                                                         Thank you for
>>                                                         creating the
>>                                                         issue. My
>>                                                         definition of
>>                                                         AS is
>>                                                         independent
>>                                                         of AS-RO or
>>                                                         I also agree
>>                                                         with Alan's
>>                                                         definition
>>                                                         based on
>>                                                         An AS-RS
>>                                                         would be a
>>                                                         delegate of
>>                                                         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
>>                                                         The only
>>                                                         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-RO. By my
>>                                                         definition,
>>                                                         this model
>>                                                         has two ASs
>>                                                         since both
>>                                                         processing
>>                                                         requests into
>>                                                         tokens. The
>>                                                         problem with
>>                                                         this is
>>                                                         complexity
>>                                                         and privacy.
>>                                                         The RO may
>>                                                         not want to
>>                                                         share the
>>                                                         with the AS-RS.
>>                                                         On Wed, Mar
>>                                                         24, 2021 at
>>                                                         5:21 PM
>>                                                             Isn't
>>                                                             that what
>>                                                             the AS is
>>                                                             supposed
>>                                                             to be,
>>                                                             only with
>>                                                             caveat
>>                                                             that the
>>                                                             policy is
>>                                                             locally?
>>                                                             Le mer.
>>                                                             24 mars
>>                                                             2021 à
>>                                                             20:17,
>>                                                                 is an
>>                                                                 trusts
>>                                                                 according
>>                                                                 Wed,
>>                                                                 24,
>>                                                                 9:36
>>                                                                     Alan
>>                                                                     I've
>>                                                                     created
>>                                                                     capture
>>                                                                     A
>>                                                                     arises:
>>                                                                     give
>>                                                                     definition
>>                                                                     AS-RO?
>>                                                                     Tue,
>>                                                                     23,
>>                                                                     4:15
>>                                                                     Alan
>>                                                                             Alan,
>>                                                                             Yes,
>>                                                                             flow,
>>                                                                             secure
>>                                                                             if
>>                                                                             issued
>>                                                                             place.
>>                                                                         requirement,
>>                                                                         doesn't
>>                                                                         Token
>>                                                                         exchange
>>                                                                         fine. 
>>                                                                         SPKI
>>                                                                         zcap-ld
>>                                                                         examples
>>                                                                         crypto
>>                                                                         approach,
>>                                                                         exchange
>>                                                                         system
>>                                                                         HP.
>>                                                                         Alan
>>                                                                         Tue,
>>                                                                         23,
>>                                                                         4:12
>>                                                                             Alan,
>>                                                                             Yes,
>>                                                                             flow,
>>                                                                             secure
>>                                                                             if
>>                                                                             issued
>>                                                                             place.
>>                                                                             9:26
>>                                                                             Alan
>>                                                                                 Alan
>>                                                             mailing list

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Mar 2021 11:45:44 -0400

Denis,

These terms have been explained and defined several times in the thread below, including in more specific detail in the first paragraph of my message, quoted below. Much of the purpose of this thread has been teasing out these very definitions. 

 — Justin

> On Mar 25, 2021, at 11:34 AM, Denis <[email-masked]> wrote:
> 
> Since there is still no definition to explain what mean the acronyms AS-RO and AS-RS,
> I have created my own terminology RO-AS and RO-RS and wrote a full story including
> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223>
> 
> Denis
> 
>> Thanks for the summary Justin. You very clearly articulated what I would call the "regulatory capture" aspects of the problem. The RS will do everything they can to avoid ceding power to the RO. By avoiding standards that shift power to the RO, the platforms, IdP's, and most other service providers delay regulation that would promote agent-based delegated access to an API as a human right. 
>> 
>> It's only recently, with GDPR, that lawmakers have started to consider human rights outside of healthcare and are now introducing concepts such as the separation of controller from processor in order to enable a new generation of regulation. My perspective on GNAP is not arbitrary. It is honed by years of experience in healthcare as everyone struggles with OAuth and OpenID Connect, HEART, and now UDAP, to avoid doing in standards what seems obvious from a human rights perspective.
>> 
>> What's interesting is that the "regulatory capture" standards game is now playing out in a new arena. The recent transition of DID to W3C Candidate Recommendation, together with Verifiable Credentials before that, means that every regulator (e.g. US Health and Human Services, Scotland, EU...) and some legislatures (e.g. Wyoming) are having to deal with the concept of Self-Sovereign Identity. It's not fun for the community that has worked so hard on SSI to now have to dance-around the actual impact of the SSI standards.
>> 
>> With VC and DID, W3C seems to have broken through a "regulatory capture" barrier and that community is moving on to standardize protocols like DIDcomm and Encrypted Data Vaults that may avoid delegated authorization as a human right. In my opinion, GNAP, and IETF, is facing the same "regulatory capture" barrier. 
>> 
>> Justin says: "Of course, market forces being as they are, I might not have much of an actionable choice in RS, but GNAP can’t change that." What GNAP makes core can change the choices the market offers by making GNAP an interoperability badge that stands for Human-Centered Protocol. If GNAP moves the human-centered part to an extension, then we're no better than another "profile" on top of OAuth.
>> 
>> Adrian
>> 
>> On Thu, Mar 25, 2021 at 8:46 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Mar 25, 2021, at 6:40 AM, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Mar 2021 12:05:03 -0400

Adrian,

I think it’s dangerous to overestimate the power and sway that a standards document will have, even once finalized. There needs to be a compelling reason for the RS to talk to an AS, and “there’s a standard” simply isn’t enough. As we’ve both said for years, the business, legal, and technical (BLT) sandwich needs to all come into play. GNAP is all about the technical level, but always influencing what’s possible in the other two with the decisions and assumptions we make here. That’s why it’s best to have clear and specific delineations between components. 

What’s even more dangerous is paying lip service to a standard, or being just compliant enough to get by but still having lock in. That’s a huge problem in the SSI world with the DID and VC specs — each silo can continue to exist separate from the rest of the world and still truthfully claim compliance with the standards. SSI technology will not push user-centered control on its own. There is absolutely nothing stopping someone from restricting to their own proprietary DID method and accepting only their own DID documents and signatures. 

At the end of the day, a standard is only a standard if it gets used, and short of regulations forcing people to use GNAP — and use it in a particular profile or deployment pattern — we can’t expect specific outcomes. Our best hope is to enable them with clear paths, so that the human-centered pieces slot into the overall architecture in a meaningful way. The technical protocol will never be able to fully define this behavior, since if we tried to, GNAP would either be avoided, ignored, or wrapped around by RS providers. We see this with how UMA has been deployed in practice today — it’s used for single-domain trust delegation, not “Bring your own AS” delegation even though it allows that. It’s the other layers of the sandwich that will push what’s done, we can only enable what’s possible.

 — Justin

> On Mar 25, 2021, at 9:23 AM, Adrian Gropper <[email-masked]> wrote:
>

---

From: Alan Karp <[email-masked]>
Date: Thu, 25 Mar 2021 09:36:04 -0700

There seems to be some confusion about how AS-RO comes into the picture,
probably because of the "AS" part.  I'm going to try to clear up that
confusion by more carefully explaining what I mean.

I'm assuming that RO is a computational agent representing the person who
is the resource owner, something called the "user agent" in operating
systems lingo.  I'm also assuming that it's possible to do delegation,
either locally or by token exchange with AS-RS.  All delegations are
potentially sub-scoped, but you may also want to delegate with full scope
to have a separately revocable access token.

  Here's an example of how things work in a capability oriented system.

   1. Someone, the service owner, creates a service.
   2. The service owner contracts with an policy agent (AS-RS) to create
   and manage access tokens for that service (RS).
   3. A person wishing to create a resource at RS uses their user agent
   (RO) to contact the service owner's policy agent (AS-RS) and gets back an
   access token for that resource.
   4. That user agent (RO) can
      1. use that access token to invoke the resource, or
      2. delegate an access token to a client of the user agent's (RO)
      choice, or
      3. contract with a policy agent (AS-RO) to manage those delegations
      on behalf of the user agent (RO), or
      4. specify a policy with the service's policy agent (AS-RS).
   5. A client can contact any holder of the access token (the user agent
   (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to
   get a delegated access token.
   6. That client can delegate that token to another client.
   7. Another user agent (RO') can contact any holder of the access token
   or the service's policy agent (AS-RS) to get a delegated access token.
   8. The other user agent (RO') can
      1. use that access token to invoke the resource, or
      2. delegate it to a client of its choice, or
      3. contract with a policy agent (AS-RO') of its choosing to manage
      those delegations on its behalf, or
      4. specify a policy with the service's policy agent (AS-RS).
   9. and so on

When any of these computational agents, user agents (ROs) or clients acting
on their behalf, invokes the resource, AS-RS verifies that the access token
is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and
that it authorizes the request being made before telling the service (RS)
to honor the request.  At no point does the service's policy agent (AS-RS)
know which computational agent did any particular delegation.  (Token
exchange can be done as anonymously as possible.)  In particular, the
policy agents (AS-RO) need not be the same, or even compatible with, the
service's policy agent (AS-RS).  GNAP specifies the protocol between
requesters, invokers, delegators (for token exchange) of tokens and AS-RS.
That protocol need not be used between user agents (RO), clients, or other
policy agents (AS-RO), but it is likely to be.

 -------------
Alan Karp

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Mar 2021 12:53:43 -0400

Hi Alan,

In all of my discussion, and in the spec itself, the RO is the :entity: in charge of approving rights. They’re probably a person. It might be software that makes a policy decision in some way, or a corporate entity, or something like that. But it’s not assumed to be a computational agent in the terms of the protocol itself. Would that recast what you’re saying below?

 — Justin

> On Mar 25, 2021, at 12:36 PM, Alan Karp <[email-masked]> wrote:
> 
> There seems to be some confusion about how AS-RO comes into the picture, probably because of the "AS" part.  I'm going to try to clear up that confusion by more carefully explaining what I mean.
> 
> I'm assuming that RO is a computational agent representing the person who is the resource owner, something called the "user agent" in operating systems lingo.  I'm also assuming that it's possible to do delegation, either locally or by token exchange with AS-RS.  All delegations are potentially sub-scoped, but you may also want to delegate with full scope to have a separately revocable access token.
> 
> Someone, the service owner, creates a service.
> The service owner contracts with an policy agent (AS-RS) to create and manage access tokens for that service (RS).
> A person wishing to create a resource at RS uses their user agent (RO) to contact the service owner's policy agent (AS-RS) and gets back an access token for that resource.
> That user agent (RO) can 
> use that access token to invoke the resource, or
> delegate an access token to a client of the user agent's (RO) choice, or
> contract with a policy agent (AS-RO) to manage those delegations on behalf of the user agent (RO), or
> specify a policy with the service's policy agent (AS-RS).
> A client can contact any holder of the access token (the user agent (RO) or its policy agent (AS-RO)) or the service's policy agent (AS-RS) to get a delegated access token.
> That client can delegate that token to another client.
> Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token.
> The other user agent (RO') can 
> use that access token to invoke the resource, or
> delegate it to a client of its choice, or
> contract with a policy agent (AS-RO') of its choosing to manage those delegations on its behalf, or
> specify a policy with the service's policy agent (AS-RS).
> and so on
> When any of these computational agents, user agents (ROs) or clients acting on their behalf, invokes the resource, AS-RS verifies that the access token is a valid delegation, i.e., proper sub-scoping, hasn't been revoked, and that it authorizes the request being made before telling the service (RS) to honor the request.  At no point does the service's policy agent (AS-RS) know which computational agent did any particular delegation.  (Token exchange can be done as anonymously as possible.)  In particular, the policy agents (AS-RO) need not be the same, or even compatible with, the service's policy agent (AS-RS).  GNAP specifies the protocol between requesters, invokers, delegators (for token exchange) of tokens and AS-RS.  That protocol need not be used between user agents (RO), clients, or other policy agents (AS-RO), but it is likely to be.
> 
>  -------------
> Alan Karp
> 
> 
> On Thu, Mar 25, 2021 at 5:45 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Denis <[email-masked]>
Date: Thu, 25 Mar 2021 18:18:21 +0100

Justin,

Instead of replying this way, it would be much better that you cut and 
paste these two definitions (if ever they exist).

Denis

> Denis,
>
> These terms have been explained and defined several times in the 
> thread below, including in more specific detail in the first paragraph 
> of my message, quoted below. Much of the purpose of this thread has 
> been teasing out these very definitions.
>
>  — Justin
>
>> On Mar 25, 2021, at 11:34 AM, Denis <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> It's only recently, with GDPR, that lawmakers have started to 
>>> consider human rights outside of healthcare and are now introducing 
>>> concepts such as the separation of controller from processor in 
>>> order to enable a new generation of regulation. My perspective on 
>>> GNAP is not arbitrary. It is honed by years of experience in 
>>> healthcare as everyone struggles with OAuth and OpenID Connect, 
>>> HEART, and now UDAP, to avoid doing in standards what seems obvious 
>>> from a human rights perspective.
>>>
>>> What's interesting is that the "regulatory capture" standards game 
>>> is now playing out in a new arena. The recent transition of DID to 
>>> W3C Candidate Recommendation, together with Verifiable Credentials 
>>> before that, means that every regulator (e.g. US Health and Human 
>>> Services, Scotland, EU...) and some legislatures (e.g. Wyoming) are 
>>> having to deal with the concept of Self-Sovereign Identity. It's not 
>>> fun for the community that has worked so hard on SSI to now have to 
>>> dance-around the actual impact of the SSI standards.
>>>
>>> Justin says: "Of course, market forces being as they are, I might 
>>> not have much of an actionable choice in RS, but GNAP can’t change 
>>> that." What GNAP makes core can change the choices the market offers 
>>> by making GNAP an interoperability badge that stands for 
>>> Human-Centered Protocol. If GNAP moves the human-centered part to an 
>>> extension, then we're no better than another "profile" on top of OAuth.
>>>
>>> Adrian
>>>
>>>     sense, at least not exactly. This is the agent that the RO can
>>>     use to set policies and manage consent on their behalf, and I’ve
>>>     been arguing that it fits better into this vaguely-defined
>>>     “interaction component” aspect of the current AS definition, and
>>>     it’s not currently separated from the AS definition. The “AS-RS”
>>>     maps to what we’d call the “AS” in OAuth/GNAP traditionally,
>>>     it’s what the RS trusts to issue tokens. In traditional OAuth
>>>     the AS-RO and AS-RS are always the same thing, from a functional
>>>     protocol perspective. An important point here is that from a
>>>     client’s perspective, they’re only talking to the AS-RS since
>>>     that’s where the client gets its tokens, because at the end of
>>>     the day the client just wants to call the API at the RS and
>>>     1. RS trusts AS-RS to issue tokens that RS will accept,
>>>     validate, and process for requests from client
>>>     What I have been saying is that 4/5/6 are optional details of
>>>     how RS-AS runs things, and I think this also maps with Adrian’s
>>>     view of choice, since if my RS’s AS-RS doesn’t allow me to plug
>>>     in my own AS-RO then I would be motivated to pick a different RS
>>>     who’s AS-RS lets me do just that. The same way I’d pick a
>>>     different RS if their surrounding services didn’t accept my
>>>     preferred federation login and I didn’t want to make another
>>>     account. Of course, market forces being as they are, I might not
>>>     have much of an actionable choice in RS, but GNAP can’t change
>>>     that.
>>>
>>>     both in philosophy of the protocol design and in concrete hooks
>>>     to support (6) above.
>>>
>>>     and consistent way, letting the RS keep control over 1/2,
>>>     thereby enabling choice in (3). We don’t have to be the ones who
>>>     define the all of the details of every permutation of (5) to
>>>     enable this, though. Some of this is going to be configuration
>>>     out of band, some of it’s going to be communication at runtime.
>>>     This is where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a whole
>>>     swath of other tech can come in and help out. I don’t think we
>>>     need to put all the details for using these into core, nor do I
>>>     think we’ll pull of The Great And Ultimate Abstraction for using
>>>     these and other approaches. But we can at least start talking
>>>     about “AS-RS” in such a way that it no longer assumes it’s
>>>     always the same party dealing with the RO directly.
>>>
>>>      — Justin
>>>
>>>>         - what matters is the RQ (could be a RO or a end-user or
>>>>         both : we don't really care at a high-level, they're all
>>>>         treated as entities that make a request)
>>>>                 Regarding the last item, I don't think that naming
>>>>                 RQ by end-user created the problem. It might just
>>>>                     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.
>>>>
>>>>                     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.
>>>>
>>>>                     (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
>>>>
>>>>
>>>>
>>>>
>>>>                         Le jeu. 25 mars 2021 à 08:16, Adrian
>>>>                             like the RS itself. Why would GNAP
>>>>                             expose that interface to anyone?
>>>>
>>>>                             Adrian
>>>>
>>>>                                         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
>>>>                                             component of the AS?
>>>>                                                 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.
>>>>                                                 On Wed, Mar 24,
>>>>                                                 2021 at 11:22 PM
>>>>                                                         the agent
>>>>                                                         is the
>>>>                                                         AS-RO. By
>>>>                                                         with this
>>>>                                                         privacy.
>>>>                                                     RO has no
>>>>                                                     choice but to
>>>>                                                     present the
>>>>                                                     information to
>>>>                                                     AS-RS if RO
>>>>                                                     wants an access
>>>>                                                     token. However,
>>>>                                                     RO does not
>>>>                                                     want AS-RS to
>>>>                                                     know the policy
>>>>                                                     by which RO
>>>>                                                     tokens. That's
>>>>                                                     why RO uses
>>>>                                                     AS-RO for those
>>>>                                                         Thank you
>>>>                                                         creating
>>>>                                                         the issue.
>>>>                                                         of AS is
>>>>                                                         I also
>>>>                                                         agree with
>>>>                                                         Alan's
>>>>                                                         locally?)
>>>>                                                         in order
>>>>                                                         for it to
>>>>                                                         be run as
>>>>                                                         the code
>>>>                                                         that turns
>>>>                                                         a request
>>>>                                                         into an
>>>>                                                         elsewhere
>>>>                                                         (an agent)
>>>>                                                         policy and
>>>>                                                         returned.
>>>>                                                         In that
>>>>                                                         case the AS
>>>>                                                         is acting
>>>>                                                         elsewhere.
>>>>                                                         I can
>>>>                                                         that an
>>>>                                                         AS-RS would
>>>>                                                         behave this
>>>>                                                         way so that
>>>>                                                         token by
>>>>                                                         the AS-RS.
>>>>                                                         Isn't this
>>>>                                                         what Justin
>>>>                                                         proposing?
>>>>                                                         the agent
>>>>                                                         is the
>>>>                                                         AS-RO. By
>>>>                                                         with this
>>>>                                                         privacy.
>>>>                                                             the AS

---

From: Alan Karp <[email-masked]>
Date: Thu, 25 Mar 2021 10:21:52 -0700

Justin Richer <[email-masked]> wrote:

> Hi Alan,
>
> In all of my discussion, and in the spec itself, the RO is the :entity: in
> charge of approving rights. They’re probably a person. It might be software
> that makes a policy decision in some way, or a corporate entity, or
> something like that. But it’s not assumed to be a computational agent in
> the terms of the protocol itself. Would that recast what you’re saying
> below?
>

Hmmm.  I guess not.  It's just that the person would be using some UI to
express their decisions to what I called the user agent.  That model fits
in very nicely with what we did with Polaris, our virus safe computing
environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033.
The person would click on the icon for a Word file, and an instance of Word
would open with only the permission needed to edit that one file.  Same
thing here.  The client could ask for permission to use the resource, or
permission could be granted implicitly when the user selects a resource
associated with a specific client.

--------------
Alan Karp

On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <[email-masked]> wrote:

> Hi Alan,
>
> In all of my discussion, and in the spec itself, the RO is the :entity: in
> charge of approving rights. They’re probably a person. It might be software
> that makes a policy decision in some way, or a corporate entity, or
> something like that. But it’s not assumed to be a computational agent in
> the terms of the protocol itself. Would that recast what you’re saying
> below?
>
>  — Justin
>
> When any of these computational agents, user agents (ROs) or clients
> acting on their behalf, invokes the resource, AS-RS verifies that the
> access token is a valid delegation, i.e., proper sub-scoping, hasn't been
> revoked, and that it authorizes the request being made before telling the
> service (RS) to honor the request.  At no point does the service's policy
> agent (AS-RS) know which computational agent did any particular
> delegation.  (Token exchange can be done as anonymously as possible.)  In
> particular, the policy agents (AS-RO) need not be the same, or even
> compatible with, the service's policy agent (AS-RS).  GNAP specifies the
> protocol between requesters, invokers, delegators (for token exchange) of
> tokens and AS-RS.  That protocol need not be used between user agents (RO),
> clients, or other policy agents (AS-RO), but it is likely to be.
>
>  -------------
> Alan Karp
>
>
>>>> I believe there are alternatives to having two kinds of ASs. The
>>>> problem may be a side-effect of deciding to switch away form treating the
>>>> RO as different from the RQ. That leads to downstream privacy issues. Our
>>>> desire for architectural simplicity is admirable but that may have been a
>>>> step too far.
>>>>
>>>> On Thu, Mar 25, 2021 at 4:15 AM Fabien Imbault <
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only other possibility is that the request is packaged
>>>>>>>>>>>>>>> by the AS and sent elsewhere (an agent) for evaluation against policy and a
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 25 Mar 2021 17:50:15 -0400

My issue is with Alan's:

"7. Another user agent (RO') can contact any holder of the access token or
the service's policy agent (AS-RS) to get a delegated access token."

I would prefer "7A. Another user agent (RO') can contact any holder of the
access token." by default so that the AS-RS does not see the requests. In
other words, the RS and AS-RS only see access tokens. The requests (from
RO') that resulted in an access token are none of their business.

The reality is that RO' can discover a resource RS and can share whatever
information with RS-AS they want and the RO may not even know about it
unless the RS decides to let them know somehow. This seems to be a drawback
of the capabilities approach.

In terms of privacy and control, I, as the RO, want a contract with the RS
that says that I or my agent (AS-RO) must sign an access token. This is a
fundamental audit requirement. Without it, a rogue RS and AS-RS can do all
sorts of things and the RO would never know. I understand that a rogue RS
might not support an honest contemporaneous log of access tokens presented
so there's a trust issue here that I seems unavoidable unless I specify in
my RO-RS contract that they use a separate contemporaneous log such as
AS-RO for every access token presented and risk being sued if they process
an access token without also updating the separate log.

- Adrian

On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <[email-masked]> wrote:

>> In all of my discussion, and in the spec itself, the RO is the :entity:
>> in charge of approving rights. They’re probably a person. It might be
>> software that makes a policy decision in some way, or a corporate entity,
>> or something like that. But it’s not assumed to be a computational agent in
>> In all of my discussion, and in the spec itself, the RO is the :entity:
>> in charge of approving rights. They’re probably a person. It might be
>> software that makes a policy decision in some way, or a corporate entity,
>> or something like that. But it’s not assumed to be a computational agent in
>>       3. contract with a policy agent (AS-RO) to manage those
>>       delegations on behalf of the user agent (RO), or
>>    5. A client can contact any holder of the access token (the user
>>    agent (RO) or its policy agent (AS-RO)) or the service's policy agent
>>    (AS-RS) to get a delegated access token.
>>    7. Another user agent (RO') can contact any holder of the access
>>    token or the service's policy agent (AS-RS) to get a delegated access token.
>>>> - what matters is the RQ (could be a RO or a end-user or both : we
>>>> don't really care at a high-level, they're all treated as entities that
>>>> make a request)
>>>>>> 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 ?
>>>>>>
>>>>>> On Thu, Mar 25, 2021 at 8:48 AM Adrian Gropper <
>>>>>>>> Le jeu. 25 mars 2021 à 08:16, Adrian Gropper <
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>    - That user presents the access token delegated
>>>>>>>>>>>>>>>>>>>>>>    by AS-RO when invoking the resource.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 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 *of your identity* in this model, and the
>>>>>>>>>>>>>>>>>>>>>>>> RS is part of the identity provider. It’s really important that we don’t
>>>>>>>>>>>>>>>>>>>>>>>> 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

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Mar 2021 07:15:30 -0400

I have a big problem with this line:

> the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.

In the trust model we’ve been discussing, the requests that result in access tokens are solely the business of AS-RS, since AS-RS is the only entity that’s allowed, and trusted by the RS, to create access tokens for the RS. That is its entire job, the entire reason it exists in the system. By definition the party generating tokens for use at the RS is the AS for that RS, I don’t care how you deploy it. If RO wants to give access to someone else (who isn’t an “RO" anymore, they’re another end-user), then that end user’s client software will need to talk to AS-RS to get its own access token.

Now here’s the trick: when the end user’s client instance talks to AS-RS, that does NOT mean that AS-RS needs to know all the details and policy reasons that it should give an access token to that client instance. It doesn’t even need to know the existence of another end user. It doesn’t need identity, it doesn’t need policy. Sure, it COULD handle all of that internally, and many will, but the protocol doesn’t demand it. 

This means that the first client instance, the one that gets the access token, can also be given something alongside the access token that it can then hand to another piece of software (or to a person to hand eo their piece of software). This artifact is not an access token. This artifact could be something structured that the client understands, and can make derivatives of, and present back to the AS-RS for getting new access tokens. There could be multiple different flavors of this kind of artifact for different kinds of environments and groups. But what they all have in common is that they can potentially be used to request more access tokens within some context at the AS-RS.

 — Justin

> On Mar 25, 2021, at 5:50 PM, Adrian Gropper <[email-masked]> wrote:
> 
> My issue is with Alan's:
> "7. Another user agent (RO') can contact any holder of the access token or the service's policy agent (AS-RS) to get a delegated access token."
> 
> I would prefer "7A. Another user agent (RO') can contact any holder of the access token." by default so that the AS-RS does not see the requests. In other words, the RS and AS-RS only see access tokens. The requests (from RO') that resulted in an access token are none of their business.
> 
> The reality is that RO' can discover a resource RS and can share whatever information with RS-AS they want and the RO may not even know about it unless the RS decides to let them know somehow. This seems to be a drawback of the capabilities approach. 
> 
> In terms of privacy and control, I, as the RO, want a contract with the RS that says that I or my agent (AS-RO) must sign an access token. This is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do all sorts of things and the RO would never know. I understand that a rogue RS might not support an honest contemporaneous log of access tokens presented so there's a trust issue here that I seems unavoidable unless I specify in my RO-RS contract that they use a separate contemporaneous log such as AS-RO for every access token presented and risk being sued if they process an access token without also updating the separate log.
> 
> - Adrian
> 
> 
> On Thu, Mar 25, 2021 at 1:22 PM Alan Karp <[email-masked] <mailto:[email-masked]>> wrote:
> Hmmm.  I guess not.  It's just that the person would be using some UI to express their decisions to what I called the user agent.  That model fits in very nicely with what we did with Polaris, our virus safe computing environment for Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033 <https://dl.acm.org/doi/10.1145/1151030.1151033>.  The person would click on the icon for a Word file, and an instance of Word would open with only the permission needed to edit that one file.  Same thing here.  The client could ask for permission to use the resource, or permission could be granted implicitly when the user selects a resource associated with a specific client.
> 
> --------------
> Alan Karp
> 
> 
> On Thu, Mar 25, 2021 at 9:53 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Alan,
> 
>> On Mar 25, 2021, at 12:36 PM, Alan Karp <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 26 Mar 2021 08:30:59 -0400

@Justin, there’s no separation of concerns here. No partition between
processor and controller. No data minimization. And, I see no obvious
reason to make this the core of GNAP.

The one thing we can probably all agree on is that there’s only one RS and
one RO.

The core of GNAP, in my opinion, can be built and explained around this
simple design. The RS is a processor. The RO is a controller. The RS bears
only security responsibility. The RS bears no privacy responsibility. The
RO delegates this to the RS but this is not authorization as the A in GNAP.

The RO retains all rights to delegate within the scope of things that the
RS is willing to support using various token formats and endpoint options.
Some of these options may do all sorts of things for all sorts of clients
and user-agents  but these are options.

For example, if a request comes to the RS that is not in the form of an
access token, then it either gets sent to the RO or their agent, or it gets
logged and dumped. One such option, common in healthcare, is “Break the
Glass” where the RS is acting as an authorization server because the
user-agent is making a request instead of presenting an access token. GNAP
can offer this as an option but it is not our core.

Adrian

On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <[email-masked]> wrote:

> > the RS and AS-RS only see access tokens. The requests (from RO') that
> resulted in an access token are none of their business.
>
> In the trust model we’ve been discussing, the requests that result in
> access tokens are *solely the business of AS-RS*, since AS-RS is the only
> entity that’s allowed, and trusted by the RS, to create access tokens for
> the RS. That is its entire job, the entire reason it exists in the system.
> By definition the party generating tokens for use at the RS is the AS for
> that RS, I don’t care how you deploy it. If RO wants to give access to
> someone else (who isn’t an “RO" anymore, they’re another end-user), then
> that end user’s client software will need to talk to AS-RS to get its own
> access token.
>
> Now here’s the trick: when the end user’s client instance talks to AS-RS,
> that does NOT mean that AS-RS needs to know all the details and policy
> reasons that it should give an access token to that client instance. It
> doesn’t even need to know the existence of another end user. It doesn’t
> need identity, it doesn’t need policy. Sure, it COULD handle all of that
> internally, and many will, but the protocol doesn’t demand it.
>
> This means that the first client instance, the one that gets the access
> token, can also be given something alongside the access token that it can
> then hand to another piece of software (or to a person to hand eo their
> piece of software). This artifact is not an access token. This artifact
> could be something structured that the client understands, and can make
> derivatives of, and present back to the AS-RS for getting new access
> tokens. There could be multiple different flavors of this kind of artifact
> for different kinds of environments and groups. But what they all have in
> common is that they can potentially be used to request more access tokens
> within some context at the AS-RS.
>
>  — Justin
>
>
>
> I would prefer "7A. Another user agent (RO') can contact any holder of
> the access token." by default so that the AS-RS does not see the requests.
> In other words, the RS and AS-RS only see access tokens. The requests (from
>> environment for Windows XP,
>> https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would click
>> on the icon for a Word file, and an instance of Word would open with only
>> the permission needed to edit that one file.  Same thing here.  The client
>> could ask for permission to use the resource, or permission could be
>> granted implicitly when the user selects a resource associated with a
>> specific client.
>>
>> --------------
>> Alan Karp
>>
>>
>>> I'm assuming that RO is a computational agent representing the person
>>> who is the resource owner, something called the "user agent" in operating
>>>    2. The service owner contracts with an policy agent (AS-RS) to
>>>    create and manage access tokens for that service (RS).
>>>       3. contract with a policy agent (AS-RO') of its choosing to
>>>       manage those delegations on its behalf, or
>>>> authorization server at all, I’m going to keep using that term below for
>>>> consistency with previous discussion.
>>>>
>>>> On Thu, Mar 25, 2021 at 9:44 AM Fabien Imbault <
>>>>>>>> minimizing the leakage of information about requests that are posed against
>>>>>>>> those policies.
>>>>>>>>
>>>>>>>>> since both are processing requests into tokens". If there's no reason to
>>>>>>>>> have 2 types of ASs, that's fine then.
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So, along come FIDO2 and DID wallets to the
>>>>>>>>>>>>>>>>>>>>>>>>> rescue. Now, in theory, I have a way to start out my RS relationship
>>>>>>>>>>>>>>>>>>>>>>>>> pseudonymously.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If the RS instead says “welcome to Medicine
>>>>>>>>>>>>>>>>>>>>>>>>>> Doctor RS, please talk to the Medicine Doctor AS to get access”, we haven’t
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>> 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

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Mar 2021 09:30:31 -0400

Adrian,

I disagree, I believe that what I have laid out is exactly separating the concerns into working components. 

Like OAuth before it, GNAP is a protocol negotiate access for a client instance to an RS, using an AS as the facilitator of that delegated negotiation. (Unlike OAuth, it’s importantly also for negotiating user information to the client directly from the AS with no RS involved, but that’s an aside for the purposes of our conversation here).

If a particular GNAP RS also allows other kinds of processes to enable access to it, that is completely fine, but outside of GNAP. If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else. If an RS accepts structured access tokens signed by trusted keys that don’t come from an AS through a negotiated request — again, that’s fine, but GNAP is silent about the RS doing that. If the RS acts as “its own AS” then it’s really just an RS and an AS living in the same box. Again, that’s fine, and super common with OAuth today. 

GNAP is solving the problem of connecting the client to the RS through means of an AS. Other solutions are possible and many of them can be deployed right alongside, but that’s not the corner of the world that GNAP is solving. GNAP should be concerned about how these other technologies can be used alongside it. I think there’s a lot of room for the things that you’re talking about, and more importantly for solving the use cases that you’re bringing. But GNAP should be more than a single-point solution, and so we need to balance these concerns. The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.

 — Justin

> On Mar 26, 2021, at 8:30 AM, Adrian Gropper <[email-masked]> wrote:
> 
> @Justin, there’s no separation of concerns here. No partition between processor and controller. No data minimization. And, I see no obvious reason to make this the core of GNAP. 
> 
> The one thing we can probably all agree on is that there’s only one RS and one RO. 
> 
> The core of GNAP, in my opinion, can be built and explained around this simple design. The RS is a processor. The RO is a controller. The RS bears only security responsibility. The RS bears no privacy responsibility. The RO delegates this to the RS but this is not authorization as the A in GNAP.
> 
> The RO retains all rights to delegate within the scope of things that the RS is willing to support using various token formats and endpoint options. Some of these options may do all sorts of things for all sorts of clients and user-agents  but these are options. 
> 
> For example, if a request comes to the RS that is not in the form of an access token, then it either gets sent to the RO or their agent, or it gets logged and dumped. One such option, common in healthcare, is “Break the Glass” where the RS is acting as an authorization server because the user-agent is making a request instead of presenting an access token. GNAP can offer this as an option but it is not our core.
> 
> Adrian
> 
> 
> 
> On Fri, Mar 26, 2021 at 7:15 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 25, 2021, at 5:50 PM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> My issue is with Alan's:

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 26 Mar 2021 10:04:34 -0400

Justin,

Big YES to “ The conceptual framework of an AS that takes in lots of
different information and spits out access tokens is exactly the
abstraction layer that is necessary for making these use cases
interoperable.” and probably everything else you just said.

I seem to not understand the delegation design between RS and AS. In my
view, that delegation always goes through the RO, although the RO may be
forced to choose from a list provided by the RS.

In my view, GNAP, can acknowledge this and design to be agnostic to whether
the AS is specified by he RO or picked from a list of 1 or more choices
provided by the RS.

- Adrian

On Fri, Mar 26, 2021 at 9:30 AM Justin Richer <[email-masked]> wrote:

> Like OAuth before it, GNAP is a protocol negotiate access for a client
> instance to an RS, using an AS as the facilitator of that delegated
> negotiation. (Unlike OAuth, it’s importantly also for negotiating user
> information to the client directly from the AS with no RS involved, but
> that’s an aside for the purposes of our conversation here).
>
> If a particular GNAP RS also allows other kinds of processes to enable
> access to it, that is completely fine, but outside of GNAP. If an RS allows
> a username/password HTTP Basic auth in addition to accepting access tokens,
> it can do so, but GNAP doesn’t have anything to say about the Basic auth
> use, or even its relation to any access tokens or RO’s or anything else. If
> an RS accepts structured access tokens signed by trusted keys that don’t
> come from an AS through a negotiated request — again, that’s fine, but GNAP
> is silent about the RS doing that. If the RS acts as “its own AS” then it’s
> really just an RS and an AS living in the same box. Again, that’s fine, and
> super common with OAuth today.
>
> GNAP is solving the problem of connecting the client to the RS through
> means of an AS. Other solutions are possible and many of them can be
> deployed right alongside, but that’s not the corner of the world that GNAP
> is solving. GNAP should be concerned about how these other technologies can
> be used alongside it. I think there’s a lot of room for the things that
> you’re talking about, and more importantly for solving the use cases that
> you’re bringing. But GNAP should be more than a single-point solution, and
> so we need to balance these concerns. The conceptual framework of an AS
> that takes in lots of different information and spits out access tokens is
> exactly the abstraction layer that is necessary for making these use cases
> interoperable.
>
>  — Justin
>
>> access tokens are *solely the business of AS-RS*, since AS-RS is the
>> only entity that’s allowed, and trusted by the RS, to create access tokens
>> for the RS. That is its entire job, the entire reason it exists in the
>> system. By definition the party generating tokens for use at the RS is the
>> AS for that RS, I don’t care how you deploy it. If RO wants to give access
>> to someone else (who isn’t an “RO" anymore, they’re another end-user), then
>> "7. Another user agent (RO') can contact any holder of the access token
>> or the service's policy agent (AS-RS) to get a delegated access token."
>>
>>
>> In terms of privacy and control, I, as the RO, want a contract with the
>> RS that says that I or my agent (AS-RO) must sign an access token. This is
>> a fundamental audit requirement. Without it, a rogue RS and AS-RS can do
>> all sorts of things and the RO would never know. I understand that a rogue
>> RS might not support an honest contemporaneous log of access tokens
>> presented so there's a trust issue here that I seems unavoidable unless I
>> specify in my RO-RS contract that they use a separate contemporaneous log
>> such as AS-RO for every access token presented and risk being sued if they
>> process an access token without also updating the separate log.
>>
>> - Adrian
>>
>>
>>>> There seems to be some confusion about how AS-RO comes into the
>>>> picture, probably because of the "AS" part.  I'm going to try to clear up
>>>> that confusion by more carefully explaining what I mean.
>>>>
>>>>    3. A person wishing to create a resource at RS uses their user
>>>>    agent (RO) to contact the service owner's policy agent (AS-RS) and gets
>>>>    back an access token for that resource.
>>>>> calling the “AS-RO” isn’t an “AS” in the traditional OAuth/GNAP sense, at
>>>>> least not exactly. This is the agent that the RO can use to set policies
>>>>> and manage consent on their behalf, and I’ve been arguing that it fits
>>>>> better into this vaguely-defined “interaction component” aspect of the
>>>>> current AS definition, and it’s not currently separated from the AS
>>>>> definition. The “AS-RS” maps to what we’d call the “AS” in OAuth/GNAP
>>>>> traditionally, it’s what the RS trusts to issue tokens. In traditional
>>>>> OAuth the AS-RO and AS-RS are always the same thing, from a functional
>>>>> protocol perspective. An important point here is that from a client’s
>>>>> perspective, they’re only talking to the AS-RS since that’s where the
>>>>> client gets its tokens, because at the end of the day the client just wants
>>>>> to call the API at the RS and doesn’t care how that happens (from a
>>>>> protocol standpoint).
>>>>>
>>>>> RS-AS runs things, and I think this also maps with Adrian’s view of choice,
>>>>> since if my RS’s AS-RS doesn’t allow me to plug in my own AS-RO then I
>>>>> would be motivated to pick a different RS who’s AS-RS lets me do just that.
>>>>> The same way I’d pick a different RS if their surrounding services didn’t
>>>>> accept my preferred federation login and I didn’t want to make another
>>>>> account. Of course, market forces being as they are, I might not have much
>>>>> of an actionable choice in RS, but GNAP can’t change that.
>>>>>
>>>>> dynamic. This was UMA2’s “federated authorization” approach, and is behind
>>>>> a lot of the “bring your own AS” models out there. The problem with these
>>>>> is that we know from many years of experience that most RS’s aren’t
>>>>> interested in doing anything of the sort.
>>>>>
>>>>>> On Thu, Mar 25, 2021 at 9:26 AM Adrian Gropper <
>>>>>>> There may also be solutions based on different types of tokens, as
>>>>>>> in different capabilities (tokens signed by the RS) vs. tokens signed by
>>>>>>> the AS. I’m not sure about that but Alan might have more to say.
>>>>>>>
>>>>>>> Adrian
>>>>>>>
>>>>>>>> point 2, Alan involves 2 ASs. You said : "There’s no obvious
>>>>>>>> reason to have two types of ASs". Do you see an alternative ?
>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Mar 2021 10:38:33 -0400

Adrian,

Yes, the RO is the party/entity which holds the rights for delegation, and they perform that delegation to a piece of software (the client) through the AS. The RS is what they’re delegating the access of, for API-access use cases (again, user/subject information is similar but different). 

There isn’t a delegation between the RS and AS, then. You can perhaps view them as externalizing functions that they might otherwise hold close, but not delegating in the same way the client gets delegated to. You can frame it one of two ways:

 - The RS externalizes its security, policy, authorization, and delegation functions to the AS and looks for access tokens from the AS as proof of that happening (this is the most in line with the model you’ve been presenting)
 - The AS externalizes its data-API functions to into the RS and produces access tokens for the RS to consume/validate (this is actually the model that OAuth 2 started with, in extracting the RS as a separate entity as opposed to OAuth 1)

They tell different views of the same reality. In OAuth, it’s assumed that the RO interacts with the AS directly to perform the delegation to the client. In GNAP, we’ve got an opportunity to expand that, which has been (to me) one of the biggest outcomes of this discussion.

 — Justin

> On Mar 26, 2021, at 10:04 AM, Adrian Gropper <[email-masked]> wrote:
> 
> Justin, 
> 
> Big YES to “ The conceptual framework of an AS that takes in lots of different information and spits out access tokens is exactly the abstraction layer that is necessary for making these use cases interoperable.” and probably everything else you just said. 
> 
> I seem to not understand the delegation design between RS and AS. In my view, that delegation always goes through the RO, although the RO may be forced to choose from a list provided by the RS.
> 
> In my view, GNAP, can acknowledge this and design to be agnostic to whether the AS is specified by he RO or picked from a list of 1 or more choices provided by the RS.
> 
> - Adrian
> 
> On Fri, Mar 26, 2021 at 9:30 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Adrian,
> 
>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Alan Karp <[email-masked]>
Date: Fri, 26 Mar 2021 08:23:20 -0700

> RO') that resulted in an access token are none of their business.

It is common in enterprise systems for employees not to know the access
policies.  For example, employee RO might not know if contractor RO' is
entitled to use the resource.  In this case, RO would designate the
resource to RO' who would have to get an access token from the agent
managing the enterprise policy, which in this case could be AS-RS.  In a
personal setting, RO' won't have the credentials required to get an access
token from AS-RS and will only be able to get an access token from RO or
AS-RO.

> of the capabilities approach.

If RO' can reach AS-RS or RS, then RO' can share any information it has
about RO.  That's an irreducible problem that occurs no matter what access
control model you use.  RO should disclose to RO' only information RO'
needs to act on behalf of RO.  Any violation of the privacy agreement by
RO' is between RO and RO'; AS-RS has no knowledge of it.  It's up to RO to
decide if the risk of potential exposure of the disclosed information is
worth the benefit of delegating to RO'.  (You can replace RO' with
client.)  That's the way I like to think of trust.  Not, "Do I trust this
guy?", but "In what ways am I vulnerable to this guy's bad behavior?"

> an access token without also updating the separate log.

Whether or not access tokens and/or the requests made with them must be
signed is up to the provider of the service.  Some low-value services may
not want the overhead of verifying signatures.  High-value services almost
always will.  As far as a rogue service goes, signing alone doesn't help
you.  The rogue service could create a key pair and claim you provided the
public key.  You'll need additional mechanisms to get that guarantee.

You've got more problems than non-repudiation if the service is malicious.
Our philosophy with HP's E-speak product was, "Fool me once, shame on you.
Fool me twice, shame on me."  You can rely on reputation or bootstrap
trust, as was shown in the Digital Silk Road project from the 1990s,
https://www.semanticscholar.org/paper/The-Digital-Silk-Road-Hardy-Tribble/4cf20dc626013d112f434022c50a1f18848077e1
.

Signing access tokens and requests using them is the standard pattern in
certificate-based capability systems, e.g., SPKI, zcap-ld.  A nice feature
of these systems is that each token can be issued to a public key created
solely for that token, making correlation difficult.  Those other systems
use non-opaque tokens, but there is no reason the tokens can't be opaque.

--------------
Alan Karp

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 26 Mar 2021 11:26:00 -0400

Good. I agree with the externalizing framing you use. To me, they are a
pair. They represent the separation of concerns I’m focused on. The AS has
policies, gets requests from clients, and returns access tokens.

So what are we disagreeing about?

- Adrian

On Fri, Mar 26, 2021 at 10:38 AM Justin Richer <[email-masked]> wrote:

> Adrian,
>
> Yes, the RO is the party/entity which holds the rights for delegation, and
> they perform that delegation to a piece of software (the client) through
> the AS. The RS is what they’re delegating the access of, for API-access use
> cases (again, user/subject information is similar but different).
>
> There isn’t a delegation between the RS and AS, then. You can perhaps view
> them as externalizing functions that they might otherwise hold close, but
> not delegating in the same way the client gets delegated to. You can frame
> it one of two ways:
>
>  - The RS externalizes its security, policy, authorization, and delegation
> functions to the AS and looks for access tokens from the AS as proof of
> that happening (this is the most in line with the model you’ve been
> presenting)
>  - The AS externalizes its data-API functions to into the RS and produces
> access tokens for the RS to consume/validate (this is actually the model
> that OAuth 2 started with, in extracting the RS as a separate entity as
> opposed to OAuth 1)
>
> They tell different views of the same reality. In OAuth, it’s assumed that
> the RO interacts with the AS directly to perform the delegation to the
> client. In GNAP, we’ve got an opportunity to expand that, which has been
> (to me) one of the biggest outcomes of this discussion.
>
>  — Justin
>
> In my view, GNAP, can acknowledge this and design to be agnostic to
> whether the AS is specified by he RO or picked from a list of 1 or more
> choices provided by the RS.
>
> - Adrian
>
>>> Now here’s the trick: when the end user’s client instance talks to
>>> AS-RS, that does NOT mean that AS-RS needs to know all the details and
>>> policy reasons that it should give an access token to that client instance.
>>> It doesn’t even need to know the existence of another end user. It doesn’t
>>> The reality is that RO' can discover a resource RS and can share
>>> whatever information with RS-AS they want and the RO may not even know
>>> about it unless the RS decides to let them know somehow. This seems to be a
>>> drawback of the capabilities approach.
>>>
>>>>> In all of my discussion, and in the spec itself, the RO is the
>>>>> :entity: in charge of approving rights. They’re probably a person. It might
>>>>> be software that makes a policy decision in some way, or a corporate
>>>>> entity, or something like that. But it’s not assumed to be a computational
>>>>> agent in the terms of the protocol itself. Would that recast what you’re
>>>>> saying below?
>>>>>
>>>>
>>>> Hmmm.  I guess not.  It's just that the person would be using some UI
>>>> to express their decisions to what I called the user agent.  That model
>>>> fits in very nicely with what we did with Polaris, our virus safe computing
>>>> https://dl.acm.org/doi/10.1145/1151030.1151033.  The person would
>>>> click on the icon for a Word file, and an instance of Word would open with
>>>> only the permission needed to edit that one file.  Same thing here.  The
>>>> client could ask for permission to use the resource, or permission could be
>>>>> In all of my discussion, and in the spec itself, the RO is the
>>>>> :entity: in charge of approving rights. They’re probably a person. It might
>>>>> be software that makes a policy decision in some way, or a corporate
>>>>> entity, or something like that. But it’s not assumed to be a computational
>>>>> agent in the terms of the protocol itself. Would that recast what you’re
>>>>> saying below?
>>>>>
>>>>>  — Justin
>>>>>
>>>>>       2. delegate an access token to a client of the user agent's
>>>>>       (RO) choice, or
>>>>>> What we can do is make it possible for AS-RS to talk to AS-RO, both
>>>>>> in philosophy of the protocol design and in concrete hooks to support (6)
>>>>>> above.
>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>    - That user presents the access token
>>>>>>>>>>>>>>>>>>>>>>>>>    delegated by AS-RO when invoking the resource.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> We might expect a protocol with
>>>>>>>>>>>>>>>>>>>>>>>>>>>> authorization in the title to use authority
>>>>>>>>>>>>>>>>>>>>>>>>>>>> For further reading on these topics, I
>>>>>>>>>>>>>>>>>>>>>>>>>>>> recommend both “Why Johnny Can’t Encrypt” and “Why CSCW Systems Fail”.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>

---

From: Alan Karp <[email-masked]>
Date: Fri, 26 Mar 2021 08:35:29 -0700

> policies, gets requests from clients, and returns access tokens.

I thought you also want RO to be able to delegate to a client without AS-RS
knowing what policy was used for that delegation.  That's the function of
AS-RO.  The client asks AS-RO for some permissions.  AS-RO either does a
token exchange with AS-RS or gives the client something to present to AS-RS
to get a new access token.  Introducing AS-RO also allows RO to express
policies that AS-RS may not support, such as break glass.

--------------
Alan Karp

On Fri, Mar 26, 2021 at 8:26 AM Adrian Gropper <[email-masked]>
wrote:

>> Yes, the RO is the party/entity which holds the rights for delegation,
>> and they perform that delegation to a piece of software (the client)
>> through the AS. The RS is what they’re delegating the access of, for
>> API-access use cases (again, user/subject information is similar but
>> different).
>>
>> There isn’t a delegation between the RS and AS, then. You can perhaps
>> view them as externalizing functions that they might otherwise hold close,
>> but not delegating in the same way the client gets delegated to. You can
>> frame it one of two ways:
>>
>>  - The RS externalizes its security, policy, authorization, and
>> delegation functions to the AS and looks for access tokens from the AS as
>> proof of that happening (this is the most in line with the model you’ve
>> been presenting)
>> They tell different views of the same reality. In OAuth, it’s assumed
>> that the RO interacts with the AS directly to perform the delegation to the
>>> The RO retains all rights to delegate within the scope of things that
>>> the RS is willing to support using various token formats and endpoint
>>> options. Some of these options may do all sorts of things for all sorts of
>>> clients and user-agents  but these are options.
>>>
>>>> > the RS and AS-RS only see access tokens. The requests (from RO')
>>>> that resulted in an access token are none of their business.
>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> Thank you for creating the issue. My definition of AS
>>>>>>>>>>>>>>>>>>>> is independent of AS-RO or AS-RS.
>>>>>>>>>>>>>>>>>>>>> Isn't that what the AS is supposed to be, only with
>>>>>>>>>>>>>>>>>>>>> the caveat that the policy is defined locally?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Fabien
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > one-AS-per-persona becomes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one-persona-per-AS as well, then the AS's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 26 Mar 2021 11:55:29 -0400

@Alan - The recent conversation between Justin and I does not use the AS-RS
/ AS-RO framing. For now, we're trying to figure out what is core to GNAP
and what is optional.

- Adrian

On Fri, Mar 26, 2021 at 11:35 AM Alan Karp <[email-masked]> wrote:

> I thought you also want RO to be able to delegate to a client without
> AS-RS knowing what policy was used for that delegation.  That's the
> function of AS-RO.  The client asks AS-RO for some permissions.  AS-RO
> either does a token exchange with AS-RS or gives the client something to
> present to AS-RS to get a new access token.  Introducing AS-RO also allows
> RO to express policies that AS-RS may not support, such as break glass.
>
> --------------
> Alan Karp
>
>
>>>  - The AS externalizes its data-API functions to into the RS and
>>> produces access tokens for the RS to consume/validate (this is actually the
>>> model that OAuth 2 started with, in extracting the RS as a separate entity
>>> as opposed to OAuth 1)
>>>
>>>>> This means that the first client instance, the one that gets the
>>>>> access token, can also be given something alongside the access token that
>>>>> it can then hand to another piece of software (or to a person to hand eo
>>>>> their piece of software). This artifact is not an access token. This
>>>>> artifact could be something structured that the client understands, and can
>>>>> make derivatives of, and present back to the AS-RS for getting new access
>>>>> "7. Another user agent (RO') can contact any holder of the access
>>>>> token or the service's policy agent (AS-RS) to get a delegated access
>>>>> token."
>>>>>
>>>>>
>>>>> I would prefer "7A. Another user agent (RO') can contact any holder
>>>>> of the access token." by default so that the AS-RS does not see the
>>>>> requests. In other words, the RS and AS-RS only see access tokens. The
>>>>> requests (from RO') that resulted in an access token are none of their
>>>>> business.
>>>>>
>>>>> In terms of privacy and control, I, as the RO, want a contract with
>>>>> the RS that says that I or my agent (AS-RO) must sign an access token. This
>>>>> is a fundamental audit requirement. Without it, a rogue RS and AS-RS can do
>>>>>>> I'm assuming that RO is a computational agent representing the
>>>>>>> person who is the resource owner, something called the "user agent" in
>>>>>>> operating systems lingo.  I'm also assuming that it's possible to do
>>>>>>> delegation, either locally or by token exchange with AS-RS.  All
>>>>>>> delegations are potentially sub-scoped, but you may also want to delegate
>>>>>>> with full scope to have a separately revocable access token.
>>>>>>>
>>>>>>>> and consistent way, letting the RS keep control over 1/2, thereby enabling
>>>>>>>>> Could probably work but that's a fairly different model compared
>>>>>>>>> to OAuth2 (and of today's GNAP), with different frontiers between the AS
>>>>>>>>> and the RS.
>>>>>>>>>
>>>>>>>>>> There may also be solutions based on different types of tokens,
>>>>>>>>>> as in different capabilities (tokens signed by the RS) vs. tokens signed by
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> AS-RO is an AS that RO trusts to delegate RO's
>>>>>>>>>>>>>>>>>>>>>>> access tokens according to RO's policies.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --------------
>>>>>>>>>>>>>>>>>>>>>>> Alan Karp
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I too am in favor of avoiding consolidation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and correlation. Right now, when I approach a service provider (RS) for the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

---

From: Denis <[email-masked]>
Date: Fri, 26 Mar 2021 18:06:43 +0100

Hi everybody,

The content of this thread has nothing to do any more with its original 
title which was: "Will GNAP support Zero Trust Architecture?"
Since I am going to use some sentences of this thread to open a new 
topic, I changed the title of this thread into :
"Relationship between Authentication and Authorization ?"

At the moment, I got the impression that nobody agrees any more about 
*what GNAP is or is not, what it should address and what it should not 
address*.
The components of the model are becoming more numerous and hazy. A new 
terminology is sometimes being used, but is not yet present in the last 
published draft.

I still can't understand any of the new terms that are being used 
(*AS-RS* and *AS-RO*), _which are still left undefined_.

The last exchanges look more as conversations between workers during the 
construction of the Babel tower.

Last year, my first remark was to mention that a section or an Annex 
explaining the common points and the differences with OAuth 2.0
would be useful. Such section or Annex still does not exist.

Justin wrote:

    /If an RS allows a username/password HTTP Basic auth in addition to
    accepting access tokens, it can do so, but //
    //GNAP doesn’t have anything to say about the Basic auth use, or
    even its relation to any access tokens or RO’s or anything else./

Let us split the end of this sentence into two parts:

"/GNAP doesn’t have anything //to say about the Basic auth use/":  If an 
authentication exchange  is necessary, the draft document should 
describe, for completeness,
the HTTP error code that will be returned.

"/or even its relation to any access tokens or RO’s or anything else/". 
Let us suppose that a RS supports FIDO as an authentication mechanism to 
authenticate its end-users.
FIDO provides the major advantage that, for every RS, a different 
identifier is used by every end-user. This prevents end-users accounts 
correlations between RSs by using
such identifiers. In practice, a FIDO identifier is a pseudonym.

At this very moment, the RS is able to identify and authenticate its 
end-users using FIDO pseudonyms. Now, let us raise the following question:

How will a RS be bootstrapped for working with a GNAP "sub" claim or a 
"sub_id" claim, whereas FIDO is already being used ?

Denis

> information to the client directly from the AS with no RS involved, 
> but that’s an aside for the purposes of our conversation here).
>
> access to it, that is completely fine, but outside of GNAP. If an RS 
> allows a username/password HTTP Basic auth in addition to accepting 
> access tokens, it can do so, but GNAP doesn’t have anything to say 
> about the Basic auth use, or even its relation to any access tokens or 
> RO’s or anything else. If an RS accepts structured access tokens 
> signed by trusted keys that don’t come from an AS through a negotiated 
> request — again, that’s fine, but GNAP is silent about the RS doing 
> that. If the RS acts as “its own AS” then it’s really just an RS and 
> an AS living in the same box. Again, that’s fine, and super common 
> with OAuth today.
>
> deployed right alongside, but that’s not the corner of the world that 
> GNAP is solving. GNAP should be concerned about how these other 
> technologies can be used alongside it. I think there’s a lot of room 
> for the things that you’re talking about, and more importantly for 
> solving the use cases that you’re bringing. But GNAP should be more 
> than a single-point solution, and so we need to balance these 
> concerns. The conceptual framework of an AS that takes in lots of 
>> The core of GNAP, in my opinion, can be built and explained around 
>> this simple design. The RS is a processor. The RO is a controller. 
>> The RS bears only security responsibility. The RS bears no privacy 
>> responsibility. The RO delegates this to the RS but this is not 
>> authorization as the A in GNAP.
>>
>> options. Some of these options may do all sorts of things for all 
>> sorts of clients and user-agents  but these are options.
>>
>> For example, if a request comes to the RS that is not in the form of 
>> an access token, then it either gets sent to the RO or their agent, 
>> or it gets logged and dumped. One such option, common in healthcare, 
>> is “Break the Glass” where the RS is acting as an authorization 
>> server because the user-agent is making a request instead of 
>> presenting an access token. GNAP can offer this as an option but it 
>> is not our core.
>>
>> Adrian
>>
>>
>>
>>     > the RS and AS-RS only see access tokens. The requests (from
>>     In the trust model we’ve been discussing, the requests that
>>     result in access tokens are *solely the business of AS-RS*, since
>>     AS-RS is the only entity that’s allowed, and trusted by the RS,
>>     to create access tokens for the RS. That is its entire job, the
>>     entire reason it exists in the system. By definition the party
>>     generating tokens for use at the RS is the AS for that RS, I
>>     don’t care how you deploy it. If RO wants to give access to
>>     someone else (who isn’t an “RO" anymore, they’re another
>>     end-user), then that end user’s client software will need to talk
>>     to AS-RS to get its own access token.
>>
>>     Now here’s the trick: when the end user’s client instance talks
>>     to AS-RS, that does NOT mean that AS-RS needs to know all the
>>     details and policy reasons that it should give an access token to
>>     that client instance. It doesn’t even need to know the existence
>>     of another end user. It doesn’t need identity, it doesn’t need
>>     policy. Sure, it COULD handle all of that internally, and many
>>     will, but the protocol doesn’t demand it.
>>
>>     access token, can also be given something alongside the access
>>     token that it can then hand to another piece of software (or to a
>>     person to hand eo their piece of software). This artifact is not
>>     an access token. This artifact could be something structured that
>>     the client understands, and can make derivatives of, and present
>>     back to the AS-RS for getting new access tokens. There could be
>>     multiple different flavors of this kind of artifact for different
>>     kinds of environments and groups. But what they all have in
>>     common is that they can potentially be used to request more
>>     access tokens within some context at the AS-RS.
>>
>>      — Justin
>>
>>
>>
>>>     On Mar 25, 2021, at 5:50 PM, Adrian Gropper
>>>         "7. Another user agent (RO') can contact any holder of the
>>>         access token or the service's policy agent (AS-RS) to get a
>>>         delegated access token."
>>>
>>>
>>>     I would prefer "7A.Another user agent (RO') can contact any
>>>     holder of the access token." by default so that the AS-RS does
>>>     not see the requests. In other words, the RS and AS-RS only see
>>>     access tokens. The requests (from RO') that resulted in an
>>>     access token are none of their business.
>>>
>>>     whatever information with RS-AS they want and the RO may not
>>>     even know about it unless the RS decides to let them know
>>>     somehow. This seems to be a drawback of the capabilities approach.
>>>
>>>     In terms of privacy and control, I, as the RO, want a
>>>     contract with the RS that says that I or my agent (AS-RO) must
>>>     sign an access token. This is a fundamental audit requirement.
>>>     Without it, a rogue RS and AS-RS can do all sorts of things and
>>>     the RO would never know. I understand that a rogue RS might not
>>>     support an honest contemporaneous log of access tokens presented
>>>     so there's a trust issue here that I seems unavoidable unless I
>>>     specify in my RO-RS contract that they use a separate
>>>     contemporaneous log such as AS-RO for every access token
>>>     presented and risk being sued if they process an access token
>>>     without also updating the separate log.
>>>
>>>     - Adrian
>>>
>>>
>>>             In all of my discussion, and in the spec itself, the RO
>>>             is the :entity: in charge of approving rights. They’re
>>>             probably a person. It might be software that makes a
>>>             policy decision in some way, or a corporate entity, or
>>>             something like that. But it’s not assumed to be a
>>>             computational agent in the terms of the protocol itself.
>>>             Would that recast what you’re saying below?
>>>
>>>
>>>         Hmmm.  I guess not.  It's just that the person would be
>>>         using some UI to express their decisions to what I called
>>>         the user agent.  That model fits in very nicely with what we
>>>         did with Polaris, our virus safe computing environment for
>>>         Windows XP, https://dl.acm.org/doi/10.1145/1151030.1151033
>>>         <https://dl.acm.org/doi/10.1145/1151030.1151033>. The person
>>>         would click on the icon for a Word file, and an instance of
>>>         Word would open with only the permission needed to edit that
>>>         one file.  Same thing here.  The client could ask for
>>>         permission to use the resource, or permission could be
>>>         granted implicitly when the user selects a resource
>>>         On Thu, Mar 25, 2021 at 9:53 AM Justin Richer
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             Hi Alan,
>>>
>>>             In all of my discussion, and in the spec itself, the RO
>>>             is the :entity: in charge of approving rights. They’re
>>>             probably a person. It might be software that makes a
>>>             policy decision in some way, or a corporate entity, or
>>>             something like that. But it’s not assumed to be a
>>>             computational agent in the terms of the protocol itself.
>>>             Would that recast what you’re saying below?
>>>
>>>              — Justin
>>>
>>>>             On Mar 25, 2021, at 12:36 PM, Alan Karp
>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>             There seems to be some confusion about how AS-RO comes
>>>>             into the picture, probably because of the "AS" part.
>>>>             I'm going to try to clear up that confusion by more
>>>>             carefully explaining what I mean.
>>>>
>>>>             I'm assuming that RO is a computational agent
>>>>             representing the person who is the resource owner,
>>>>             something called the "user agent" in operating systems
>>>>             lingo.  I'm also assuming that it's possible to do
>>>>             delegation, either locally or by token exchange with
>>>>             AS-RS.  All delegations are potentially sub-scoped, but
>>>>             you may also want to delegate with full scope to have a
>>>>             separately revocable access token.
>>>>
>>>>              2. The service owner contracts with an policy agent
>>>>                 (AS-RS) to create and manage access tokens for that
>>>>                 service (RS).
>>>>              3. A person wishing to create a resource at RS uses
>>>>                 their user agent (RO) to contact the service
>>>>                 owner's policy agent (AS-RS) and gets back an
>>>>                  2. delegate an access token to a client of the
>>>>                     user agent's (RO) choice, or
>>>>                  3. contract with a policy agent (AS-RO) to manage
>>>>                     those delegations on behalf of the user agent
>>>>                     (RO), or
>>>>              5. A client can contact any holder of the access token
>>>>                 (the user agent (RO) or its policy agent (AS-RO))
>>>>              7. Another user agent (RO') can contact any holder of
>>>>                 the access token or the service's policy agent
>>>>                  3. contract with a policy agent (AS-RO') of its
>>>>                     choosing to manage those delegations on its
>>>>                     behalf, or
>>>>             When any of these computational agents, user agents
>>>>             (ROs) or clients acting on their behalf, invokes the
>>>>             resource, AS-RS verifies that the access token is a
>>>>             valid delegation, i.e., proper sub-scoping, hasn't been
>>>>             revoked, and that it authorizes the request being made
>>>>             before telling the service (RS) to honor the request. 
>>>>             At no point does the service's policy agent (AS-RS)
>>>>             know which computational agent did any particular
>>>>             delegation. (Token exchange can be done as anonymously
>>>>             as possible.)  In particular, the policy agents (AS-RO)
>>>>             need not be the same, or even compatible with, the
>>>>             service's policy agent (AS-RS).  GNAP specifies the
>>>>             protocol between requesters, invokers, delegators (for
>>>>             token exchange) of tokens and AS-RS.  That protocol
>>>>             need not be used between user agents (RO), clients, or
>>>>             other policy agents (AS-RO), but it is likely to be.
>>>>
>>>>              -------------
>>>>             Alan Karp
>>>>
>>>>
>>>>             On Thu, Mar 25, 2021 at 5:45 AM Justin Richer
>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>                 The way I’m thinking about Adrian’s use case is
>>>>                 that what we’re calling the “AS-RO” isn’t an “AS”
>>>>                 in the traditional OAuth/GNAP sense, at least not
>>>>                 exactly. This is the agent that the RO can use to
>>>>                 set policies and manage consent on their behalf,
>>>>                 and I’ve been arguing that it fits better into this
>>>>                 vaguely-defined “interaction component” aspect of
>>>>                 the current AS definition, and it’s not currently
>>>>                 separated from the AS definition. The “AS-RS” maps
>>>>                 to what we’d call the “AS” in OAuth/GNAP
>>>>                 traditionally, it’s what the RS trusts to issue
>>>>                 tokens. In traditional OAuth the AS-RO and AS-RS
>>>>                 are always the same thing, from a functional
>>>>                 protocol perspective. An important point here is
>>>>                 that from a client’s perspective, they’re only
>>>>                 talking to the AS-RS since that’s where the client
>>>>                 gets its tokens, because at the end of the day the
>>>>                 client just wants to call the API at the RS and
>>>>                 Note well: Even thought I don’t believe that
>>>>                 “AS-RO” is an authorization server at all, I’m
>>>>                 going to keep using that term below for consistency
>>>>                 with previous discussion.
>>>>
>>>>                 1. RS trusts AS-RS to issue tokens that RS will
>>>>                 accept, validate, and process for requests from client
>>>>                 6. Client trusts whatever AS-RS sends client to
>>>>                 deal with, including possibly RO-AS at runtime,
>>>>                 because of (2)
>>>>
>>>>                 What I have been saying is that 4/5/6 are optional
>>>>                 details of how RS-AS runs things, and I think this
>>>>                 also maps with Adrian’s view of choice, since if my
>>>>                 RS’s AS-RS doesn’t allow me to plug in my own AS-RO
>>>>                 then I would be motivated to pick a different RS
>>>>                 who’s AS-RS lets me do just that. The same way I’d
>>>>                 pick a different RS if their surrounding services
>>>>                 didn’t accept my preferred federation login and I
>>>>                 didn’t want to make another account. Of course,
>>>>                 market forces being as they are, I might not have
>>>>                 much of an actionable choice in RS, but GNAP can’t
>>>>                 change that.
>>>>
>>>>                 What we can do is make it possible for AS-RS to
>>>>                 talk to AS-RO, both in philosophy of the protocol
>>>>                 design and in concrete hooks to support (6) above.
>>>>
>>>>                 Separately, we can approach the issue of making 1/2
>>>>                 above more dynamic. This was UMA2’s “federated
>>>>                 authorization” approach, and is behind a lot of the
>>>>                 “bring your own AS” models out there. The problem
>>>>                 with these is that we know from many years of
>>>>                 experience that most RS’s aren’t interested in
>>>>                 So with GNAP we can instead allow 4/5/6 to vary in
>>>>                 a predictable and consistent way, letting the RS
>>>>                 keep control over 1/2, thereby enabling choice in
>>>>                 (3). We don’t have to be the ones who define the
>>>>                 all of the details of every permutation of (5) to
>>>>                 enable this, though. Some of this is going to be
>>>>                 configuration out of band, some of it’s going to be
>>>>                 communication at runtime. This is where VC’s,
>>>>                 ZCAPs, CHAPI, DIDComm, FIDO, and a whole swath of
>>>>                 other tech can come in and help out. I don’t think
>>>>                 we need to put all the details for using these into
>>>>                 core, nor do I think we’ll pull of The Great And
>>>>                 Ultimate Abstraction for using these and other
>>>>                 approaches. But we can at least start talking about
>>>>                 “AS-RS” in such a way that it no longer assumes
>>>>                 it’s always the same party dealing with the RO
>>>>                 directly.
>>>>
>>>>                  — Justin
>>>>
>>>>>                 - AS = AS-RO, that's where you find the RO
>>>>>                 policies. The AS issues access tokens to the client.
>>>>>                     - what matters is the RQ (could be a RO or a
>>>>>                     end-user or both : we don't really care at a
>>>>>                     high-level, they're all treated as entities
>>>>>                     that make a request)
>>>>>                     - the policy is able to handle those different
>>>>>                     cases, based on its own internal delegation
>>>>>                     protocol
>>>>>                     Could probably work but that's a fairly
>>>>>                     different model compared to OAuth2 (and of
>>>>>                     today's GNAP), with different frontiers
>>>>>                     between the AS and the RS.
>>>>>
>>>>>                         I believe there are alternatives to having
>>>>>                         two kinds of ASs. The problem may be a
>>>>>                         side-effect of deciding to switch away
>>>>>                         form treating the RO as different from the
>>>>>                         RQ. That leads to downstream privacy
>>>>>                         issues. Our desire for architectural
>>>>>                         simplicity is admirable but that may have
>>>>>                         been a step too far.
>>>>>
>>>>>                         There may also be solutions based on
>>>>>                         different types of tokens, as in different
>>>>>                         capabilities (tokens signed by the RS) vs.
>>>>>                         tokens signed by the AS. I’m not sure
>>>>>                         about that but Alan might have more to say.
>>>>>
>>>>>                         Adrian
>>>>>
>>>>>                         On Thu, Mar 25, 2021 at 4:15 AM Fabien
>>>>>                             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
>>>>>
>>>>>
>>>>>                                 minimizing the leakage of
>>>>>                                 information about requests that
>>>>>                                 what it’s selling or what
>>>>>                                 jurisdiction it’s in or what
>>>>>                                 tokens or scopes it supports). The
>>>>>                                 RS has no obvious privacy interest
>>>>>                                 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
>>>>>                                     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
>>>>>                                         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
>>>>>                                             Note : I'm not sure
>>>>>                                             that's a good idea,
>>>>>                                             but having 2 types of
>>>>>                                             ASs is not that easy
>>>>>                                             to grasp.
>>>>>                                             08:07, Fabien Imbault
>>>>>                                                 policies locally
>>>>>                                                 or delegating them
>>>>>                                                 Le jeu. 25 mars
>>>>>                                                 2021 à 08:04,
>>>>>                                                     What purpose
>>>>>                                                     served by GNAP
>>>>>                                                     splitting the
>>>>>                                                     AS into two
>>>>>                                                     components?
>>>>>                                                     On Thu, Mar
>>>>>                                                     25, 2021 at
>>>>>                                                     2:59 AM Fabien
>>>>>                                                         Isn't the
>>>>>                                                         AS-RO a
>>>>>                                                         of the AS?
>>>>>                                                         Same idea
>>>>>                                                         as the
>>>>>                                                         component,
>>>>>                                                         functionnally
>>>>>                                                         belongs to
>>>>>                                                         role but
>>>>>                                                         deployed
>>>>>                                                         either as
>>>>>                                                         a monolith
>>>>>                                                         or as a
>>>>>                                                         component?
>>>>>                                                         Le jeu. 25
>>>>>                                                         mars 2021
>>>>>                                                         à 04:26,
>>>>>                                                             but I
>>>>>                                                             the RO
>>>>>                                                             the RO
>>>>>                                                             to get
>>>>>                                                             11:22
>>>>>                                                                     design,
>>>>>                                                                     agent
>>>>>                                                                     By
>>>>>                                                                     since
>>>>>                                                                 More
>>>>>                                                                 precisely,
>>>>>                                                                 present
>>>>>                                                                 However,
>>>>>                                                                 That's
>>>>>                                                                 why
>>>>>                                                                 uses
>>>>>                                                                 7:41
>>>>>                                                                     Thank
>>>>>                                                                     issue.
>>>>>                                                                     agree
>>>>>                                                                     based
>>>>>                                                                     An
>>>>>                                                                     Based
>>>>>                                                                     that,
>>>>>                                                                     order
>>>>>                                                                     run
>>>>>                                                                     code
>>>>>                                                                     turns
>>>>>                                                                     packaged
>>>>>                                                                     (an
>>>>>                                                                     agent)
>>>>>                                                                     acting
>>>>>                                                                     proxy
>>>>>                                                                     PDP
>>>>>                                                                     behave
>>>>>                                                                     turned
>>>>>                                                                     design,
>>>>>                                                                     agent
>>>>>                                                                     By
>>>>>                                                                     since
>>>>>                                                                     5:21
>>>>>                                                                         be,
>>>>>                                                                         Le
>>>>>                                                                         mer.
>>>>>                                                                         24
>>>>>                                                                         mars
>>>>>                                                                         à

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Mar 2021 13:19:59 -0400

GNAP doesn’t have anything too say about anybody authenticating directly to the RS. If that happens, it’s out of the view and out of scope of GNAP.

 — Justin

> On Mar 26, 2021, at 1:06 PM, Denis <[email-masked]> wrote:
> 
> Hi everybody,
> 
> The content of this thread has nothing to do any more with its original title which was: "Will GNAP support Zero Trust Architecture?"
> Since I am going to use some sentences of this thread to open a new topic, I changed the title of this thread into :
> At the moment, I got the impression that nobody agrees any more about what GNAP is or is not, what it should address and what it should not address.
> The components of the model are becoming more numerous and hazy. A new terminology is sometimes being used, but is not yet present in the last published draft.
> 
> I still can't understand any of the new terms that are being used (AS-RS and AS-RO), which are still left undefined. 
> 
> The last exchanges look more as conversations between workers during the construction of the Babel tower.
> 
> Last year, my first remark was to mention that a section or an Annex explaining the common points and the differences with OAuth 2.0
> If an RS allows a username/password HTTP Basic auth in addition to accepting access tokens, it can do so, but 
> GNAP doesn’t have anything to say about the Basic auth use, or even its relation to any access tokens or RO’s or anything else.
> "GNAP doesn’t have anything to say about the Basic auth use":  If an authentication exchange  is necessary, the draft document should describe, for completeness,
> "or even its relation to any access tokens or RO’s or anything else". Let us suppose that a RS supports FIDO as an authentication mechanism to authenticate its end-users.
> FIDO provides the major advantage that, for every RS, a different identifier is used by every end-user. This prevents end-users accounts correlations between RSs by using 
> At this very moment, the RS is able to identify and authenticate its end-users using FIDO pseudonyms. Now, let us raise the following question: 
> 
> How will a RS be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim, whereas FIDO is already being used ?
> Denis
> 
> 
> 
>> Adrian,
>>

---

From: Denis <[email-masked]>
Date: Fri, 26 Mar 2021 18:27:01 +0100

Hi Justin,

Let me rephrase the last question: How will a RS or a RO be bootstrapped 
for working with a GNAP "sub" claim or a "sub_id" claim ?

Denis

> GNAP doesn’t have anything too say about anybody authenticating 
> directly to the RS. If that happens, it’s out of the view and out of 
> scope of GNAP.
>
>  — Justin
>
>> On Mar 26, 2021, at 1:06 PM, Denis <[email-masked] 
>> The content of this thread has nothing to do any more with its 
>> original title which was: "Will GNAP support Zero Trust Architecture?"
>> *what GNAP is or is not, what it should address and what it should 
>> not address*.
>> The components of the model are becoming more numerous and hazy. A 
>> new terminology is sometimes being used, but is not yet present in 
>> the last published draft.
>>
>>     /If an RS allows a username/password HTTP Basic auth in addition
>>     to accepting access tokens, it can do so, but //
>> "/GNAP doesn’t have anything //to say about the Basic auth use/":  If 
>> an authentication exchange  is necessary, the draft document should 
>> "/or even its relation to any access tokens or RO’s or anything 
>> else/". Let us suppose that a RS supports FIDO as an authentication 
>> mechanism to authenticate its end-users.
>> identifier is used by every end-user. This prevents end-users 
>> accounts correlations between RSs by using
>> How will a RS be bootstrapped for working with a GNAP "sub" claim or 
>> a "sub_id" claim, whereas FIDO is already being used ?
>>
>> Denis
>>
>>
>>> Adrian,
>>>
>>> I disagree, I believe that what I have laid out is exactly 
>>> separating the concerns into working components.
>>>
>>> Like OAuth before it, GNAP is a protocol negotiate access for a 
>>> client instance to an RS, using an AS as the facilitator of that 
>>> delegated negotiation. (Unlike OAuth, it’s importantly also for 
>>> negotiating user information to the client directly from the AS with 
>>> no RS involved, but that’s an aside for the purposes of our 
>>> conversation here).
>>>
>>> If a particular GNAP RS also allows other kinds of processes to 
>>> enable access to it, that is completely fine, but outside of GNAP. 
>>> If an RS allows a username/password HTTP Basic auth in addition to 
>>> accepting access tokens, it can do so, but GNAP doesn’t have 
>>> anything to say about the Basic auth use, or even its relation to 
>>> any access tokens or RO’s or anything else. If an RS accepts 
>>> structured access tokens signed by trusted keys that don’t come from 
>>> an AS through a negotiated request — again, that’s fine, but GNAP is 
>>> silent about the RS doing that. If the RS acts as “its own AS” then 
>>> it’s really just an RS and an AS living in the same box. Again, 
>>> that’s fine, and super common with OAuth today.
>>>
>>> GNAP is solving the problem of connecting the client to the RS 
>>> through means of an AS. Other solutions are possible and many of 
>>> them can be deployed right alongside, but that’s not the corner of 
>>> the world that GNAP is solving. GNAP should be concerned about how 
>>> these other technologies can be used alongside it. I think there’s a 
>>> lot of room for the things that you’re talking about, and more 
>>> importantly for solving the use cases that you’re bringing. But GNAP 
>>> should be more than a single-point solution, and so we need to 
>>> balance these concerns. The conceptual framework of an AS that takes 
>>> in lots of different information and spits out access tokens is 
>>> exactly the abstraction layer that is necessary for making these use 
>>> cases interoperable.
>>>
>>>  — Justin
>>>
>>>> @Justin, there’s no separation of concerns here. No partition 
>>>> between processor and controller. No data minimization. And, I see 
>>>> no obvious reason to make this the core of GNAP.
>>>>
>>>> The RO retains all rights to delegate within the scope of things 
>>>> that the RS is willing to support using various token formats and 
>>>> endpoint options. Some of these options may do all sorts of things 
>>>> for all sorts of clients and user-agents  but these are options.
>>>>
>>>> For example, if a request comes to the RS that is not in the form 
>>>> of an access token, then it either gets sent to the RO or their 
>>>> agent, or it gets logged and dumped. One such option, common in 
>>>> healthcare, is “Break the Glass” where the RS is acting as an 
>>>> authorization server because the user-agent is making a request 
>>>> instead of presenting an access token. GNAP can offer this as an 
>>>> option but it is not our core.
>>>>
>>>> Adrian
>>>>
>>>>
>>>>
>>>>     result in access tokens are *solely the business of AS-RS*,
>>>>     since AS-RS is the only entity that’s allowed, and trusted by
>>>>     the RS, to create access tokens for the RS. That is its entire
>>>>     job, the entire reason it exists in the system. By definition
>>>>     the party generating tokens for use at the RS is the AS for
>>>>     that RS, I don’t care how you deploy it. If RO wants to give
>>>>     access to someone else (who isn’t an “RO" anymore, they’re
>>>>     another end-user), then that end user’s client software will
>>>>     need to talk to AS-RS to get its own access token.
>>>>
>>>>     details and policy reasons that it should give an access token
>>>>     to that client instance. It doesn’t even need to know the
>>>>     existence of another end user. It doesn’t need identity, it
>>>>     doesn’t need policy. Sure, it COULD handle all of that
>>>>     This means that the first client instance, the one that gets
>>>>     the access token, can also be given something alongside the
>>>>     access token that it can then hand to another piece of software
>>>>     (or to a person to hand eo their piece of software). This
>>>>     artifact is not an access token. This artifact could be
>>>>     something structured that the client understands, and can make
>>>>     derivatives of, and present back to the AS-RS for getting new
>>>>     access tokens. There could be multiple different flavors of
>>>>     this kind of artifact for different kinds of environments and
>>>>     groups. But what they all have in common is that they can
>>>>     potentially be used to request more access tokens within some
>>>>     context at the AS-RS.
>>>>
>>>>      — Justin
>>>>
>>>>
>>>>
>>>>>         access token or the service's policy agent (AS-RS) to get
>>>>>         a delegated access token."
>>>>>
>>>>>
>>>>>     not see the requests. In other words, the RS and AS-RS only
>>>>>     see access tokens. The requests (from RO') that resulted in an
>>>>>     The reality is that RO' can discover a resource RS and can
>>>>>     share whatever information with RS-AS they want and the RO may
>>>>>     not even know about it unless the RS decides to let them know
>>>>>     Without it, a rogue RS and AS-RS can do all sorts of things
>>>>>     and the RO would never know. I understand that a rogue RS
>>>>>     might not support an honest contemporaneous log of access
>>>>>     tokens presented so there's a trust issue here that I seems
>>>>>     unavoidable unless I specify in my RO-RS contract that they
>>>>>     use a separate contemporaneous log such as AS-RO for every
>>>>>     access token presented and risk being sued if they process an
>>>>>     access token without also updating the separate log.
>>>>>
>>>>>     - Adrian
>>>>>
>>>>>
>>>>>             In all of my discussion, and in the spec itself, the
>>>>>             RO is the :entity: in charge of approving rights.
>>>>>             They’re probably a person. It might be software that
>>>>>             makes a policy decision in some way, or a corporate
>>>>>             entity, or something like that. But it’s not assumed
>>>>>             to be a computational agent in the terms of the
>>>>>             protocol itself. Would that recast what you’re saying
>>>>>             below?
>>>>>
>>>>>
>>>>>         the user agent.  That model fits in very nicely with what
>>>>>         we did with Polaris, our virus safe computing environment
>>>>>         for Windows XP,
>>>>>         https://dl.acm.org/doi/10.1145/1151030.1151033
>>>>>         <https://dl.acm.org/doi/10.1145/1151030.1151033>. The
>>>>>         person would click on the icon for a Word file, and an
>>>>>         instance of Word would open with only the permission
>>>>>         needed to edit that one file.  Same thing here. The client
>>>>>         could ask for permission to use the resource, or
>>>>>         permission could be granted implicitly when the user
>>>>>         selects a resource associated with a specific client.
>>>>>
>>>>>         --------------
>>>>>         Alan Karp
>>>>>
>>>>>
>>>>>             In all of my discussion, and in the spec itself, the
>>>>>             RO is the :entity: in charge of approving rights.
>>>>>             They’re probably a person. It might be software that
>>>>>             makes a policy decision in some way, or a corporate
>>>>>             entity, or something like that. But it’s not assumed
>>>>>             to be a computational agent in the terms of the
>>>>>             protocol itself. Would that recast what you’re saying
>>>>>             below?
>>>>>
>>>>>              — Justin
>>>>>
>>>>>>             There seems to be some confusion about how AS-RO
>>>>>>             comes into the picture, probably because of the "AS"
>>>>>>             part. I'm going to try to clear up that confusion by
>>>>>>             more carefully explaining what I mean.
>>>>>>
>>>>>>             something called the "user agent" in operating
>>>>>>             systems lingo.  I'm also assuming that it's possible
>>>>>>             to do delegation, either locally or by token exchange
>>>>>>             with AS-RS.  All delegations are potentially
>>>>>>             sub-scoped, but you may also want to delegate with
>>>>>>             full scope to have a separately revocable access token.
>>>>>>
>>>>>>                 (AS-RS) to create and manage access tokens for
>>>>>>                 that service (RS).
>>>>>>                  3. contract with a policy agent (AS-RO) to
>>>>>>                     manage those delegations on behalf of the
>>>>>>                     user agent (RO), or
>>>>>>              5. A client can contact any holder of the access
>>>>>>                 token (the user agent (RO) or its policy agent
>>>>>>                 (AS-RO)) or the service's policy agent (AS-RS) to
>>>>>>              7. Another user agent (RO') can contact any holder
>>>>>>                 of the access token or the service's policy agent
>>>>>>             valid delegation, i.e., proper sub-scoping, hasn't
>>>>>>             been revoked, and that it authorizes the request
>>>>>>             being made before telling the service (RS) to honor
>>>>>>             the request.  At no point does the service's policy
>>>>>>             agent (AS-RS) know which computational agent did any
>>>>>>             particular delegation. (Token exchange can be done as
>>>>>>             anonymously as possible.)  In particular, the policy
>>>>>>             agents (AS-RO) need not be the same, or even
>>>>>>             compatible with, the service's policy agent (AS-RS). 
>>>>>>             GNAP specifies the protocol between requesters,
>>>>>>             invokers, delegators (for token exchange) of tokens
>>>>>>             and AS-RS.  That protocol need not be used between
>>>>>>             user agents (RO), clients, or other policy agents
>>>>>>             (AS-RO), but it is likely to be.
>>>>>>
>>>>>>              -------------
>>>>>>             Alan Karp
>>>>>>
>>>>>>
>>>>>>                 and I’ve been arguing that it fits better into
>>>>>>                 this vaguely-defined “interaction component”
>>>>>>                 aspect of the current AS definition, and it’s not
>>>>>>                 currently separated from the AS definition. The
>>>>>>                 “AS-RS” maps to what we’d call the “AS” in
>>>>>>                 OAuth/GNAP traditionally, it’s what the RS trusts
>>>>>>                 to issue tokens. In traditional OAuth the AS-RO
>>>>>>                 and AS-RS are always the same thing, from a
>>>>>>                 functional protocol perspective. An important
>>>>>>                 point here is that from a client’s perspective,
>>>>>>                 they’re only talking to the AS-RS since that’s
>>>>>>                 where the client gets its tokens, because at the
>>>>>>                 end of the day the client just wants to call the
>>>>>>                 API at the RS and doesn’t care how that happens
>>>>>>                 (from a protocol standpoint).
>>>>>>
>>>>>>                 going to keep using that term below for
>>>>>>                 What I have been saying is that 4/5/6 are
>>>>>>                 optional details of how RS-AS runs things, and I
>>>>>>                 think this also maps with Adrian’s view of
>>>>>>                 choice, since if my RS’s AS-RS doesn’t allow me
>>>>>>                 to plug in my own AS-RO then I would be motivated
>>>>>>                 to pick a different RS who’s AS-RS lets me do
>>>>>>                 just that. The same way I’d pick a different RS
>>>>>>                 if their surrounding services didn’t accept my
>>>>>>                 preferred federation login and I didn’t want to
>>>>>>                 make another account. Of course, market forces
>>>>>>                 being as they are, I might not have much of an
>>>>>>                 Separately, we can approach the issue of making
>>>>>>                 1/2 above more dynamic. This was UMA2’s
>>>>>>                 “federated authorization” approach, and is behind
>>>>>>                 a lot of the “bring your own AS” models out
>>>>>>                 there. The problem with these is that we know
>>>>>>                 from many years of experience that most RS’s
>>>>>>                 aren’t interested in doing anything of the sort.
>>>>>>
>>>>>>                 So with GNAP we can instead allow 4/5/6 to vary
>>>>>>                 in a predictable and consistent way, letting the
>>>>>>                 RS keep control over 1/2, thereby enabling choice
>>>>>>                 in (3). We don’t have to be the ones who define
>>>>>>                 the all of the details of every permutation of
>>>>>>                 (5) to enable this, though. Some of this is going
>>>>>>                 to be configuration out of band, some of it’s
>>>>>>                 going to be communication at runtime. This is
>>>>>>                 where VC’s, ZCAPs, CHAPI, DIDComm, FIDO, and a
>>>>>>                 whole swath of other tech can come in and help
>>>>>>                 out. I don’t think we need to put all the details
>>>>>>                 for using these into core, nor do I think we’ll
>>>>>>                 pull of The Great And Ultimate Abstraction for
>>>>>>                 using these and other approaches. But we can at
>>>>>>                 least start talking about “AS-RS” in such a way
>>>>>>                 that it no longer assumes it’s always the same
>>>>>>                 party dealing with the RO directly.
>>>>>>
>>>>>>                  — Justin
>>>>>>
>>>>>>>                     - the policy is able to handle those
>>>>>>>                     different cases, based on its own internal
>>>>>>>                     delegation protocol
>>>>>>>                     On Thu, Mar 25, 2021 at 9:26 AM Adrian
>>>>>>>                         I believe there are alternatives to
>>>>>>>                         having two kinds of ASs. The problem may
>>>>>>>                         be a side-effect of deciding to switch
>>>>>>>                         away form treating the RO as different
>>>>>>>                         from the RQ. That leads to downstream
>>>>>>>                         privacy issues. Our desire for
>>>>>>>                         architectural simplicity is admirable
>>>>>>>                         but that may have been a step too far.
>>>>>>>
>>>>>>>                         different types of tokens, as in
>>>>>>>                         different capabilities (tokens signed by
>>>>>>>                         the RS) vs. tokens signed by the AS. I’m
>>>>>>>                         not sure about that but Alan might have
>>>>>>>                         more to say.
>>>>>>>
>>>>>>>                         Adrian
>>>>>>>
>>>>>>>                             Alan involves 2 ASs. You said :
>>>>>>>                             "There’s no obvious reason to have
>>>>>>>                             On Thu, Mar 25, 2021 at 8:48 AM
>>>>>>>                             Adrian Gropper
>>>>>>>                             <[email-masked]
>>>>>>>                                 1 - Justin (I think) introduced
>>>>>>>                                 the idea of an AS on the RS
>>>>>>>                                 trust boundary side.
>>>>>>>                                 legitimate privacy interest in
>>>>>>>                                 keeping their policies private
>>>>>>>                                 and minimizing the leakage of
>>>>>>>                                 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
>>>>>>>                                 end-user. Obviously, the RO
>>>>>>>                                 end-user has no privacy
>>>>>>>                                 interests relative to itself.
>>>>>>>
>>>>>>>                                 Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                     definition, this model has
>>>>>>>                                     two ASs since both are
>>>>>>>                                     processing requests into
>>>>>>>                                     tokens". If there's no
>>>>>>>                                     08:16, Adrian Gropper
>>>>>>>                                         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.
>>>>>>>                                             but having 2 types
>>>>>>>                                             of ASs is not that
>>>>>>>                                             easy to grasp.
>>>>>>>                                                 or delegating
>>>>>>>                                                 them to the RO
>>>>>>>                                                 agent.
>>>>>>>                                                     served by
>>>>>>>                                                     splitting
>>>>>>>                                                     2:59 AM
>>>>>>>                                                         of the
>>>>>>>                                                         AS? Same
>>>>>>>                                                         idea as
>>>>>>>                                                         belongs
>>>>>>>                                                         to the
>>>>>>>                                                         AS role
>>>>>>>                                                         either
>>>>>>>                                                         as a
>>>>>>>                                                         monolith
>>>>>>>                                                         Le jeu.
>>>>>>>                                                         25 mars
>>>>>>>                                                         04:26,

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Mar 2021 15:57:40 -0400

The subject identifier is whatever identifier the AS knows the subject as. If they log in using only a FIDO token and the AS asserts that key value as the identifier, then that’s what it will be. If they sign up with an email address or make a username or get assigned a random number, that’s what it will be. Or they could sign up using any number of those and the AS still assigns them a random value, because it’s always the AS that determines which value to assign the number. 

The RS is not involved in any subject information. Identity APIs, like OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP.

If there is a subject identifier either included in or referenced by the access token, that is up to any agreements between the AS and RS that lead to the ability of the AS to create the tokens the RS can trust. All of this is outside the scope of the core GNAP protocol and invisible to the client. 

 — Justin

> On Mar 26, 2021, at 1:27 PM, Denis <[email-masked]> wrote:
> 
> Hi Justin,
> 
> Let me rephrase the last question: How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?
> 
> Denis
> 
>>> On Mar 26, 2021, at 1:06 PM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi everybody,
>>>

---

From: Denis <[email-masked]>
Date: Mon, 29 Mar 2021 12:38:50 +0200

Hi  Justin,

Since your response only deals with the AS, but not the RS nor the RO, 
it is not a response to my question which was:

    How will a RS or a RO be bootstrapped for working with a GNAP "sub"
    claim or a "sub_id" claim ?

> The subject identifier is whatever identifier the AS knows the subject 
> as. If they log in using only a FIDO token and the AS asserts that key 
> value as the identifier, then that’s what it will be. If they sign up 
> with an email address or make a username or get assigned a random 
> number, that’s what it will be. Or they could sign up using any number 
> of those and the AS still assigns them a random value, because it’s 
> always the AS that determines which value to assign the number.

When looking at Section 3.2 (Access Tokens), the client (and hence the 
end-user) has currently /no practical way/ to indicate which of its 
attributes should be placed into an access token,
The only reference within Section 3.2 is pointing to the empty Section 
12. Among the many examples, there is not a single example that 
addresses the case of attributes being placed into an access token.

Nevertheless, it seems that in your opinion, only the AS, but NOT the 
client (and hence the end-user), SHALL have control at all of what kind 
of /subject identifier/ claim will be placed inside the access token.

Then after, invoking the postulate "the access token SHALL remain opaque 
to the client (and hence the end-user)", it seems that in your opinion, 
the end-user SHALL have no way to verify
whether its privacy has been respected. If this is not an architecture 
built along "spy by design" principles, I don't know what else it might be.

It is important to re-read two of the current definitions:

    *Privilege*: right *or attribute* associated with a subject.

    *Access Toke*n: data artifact representing a set of rights *a**nd/or
    attributes*.

In the current draft, the case of rights is indeed addressed while *the 
case of attributes is fully ignored*.

> The RS is not involved in any subject information. Identity APIs, like 
> OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP.

Really ? Do you mean that an access token should not contain a "sub" 
claim nor a "sub_id" claim  and if it does, the RS SHALL ignore such 
claims ?

In the "OAuth Access Token JWT Profile", there is the following sentence 
in Section 6 (Privacy Considerations) :

        This profile mandates the presence of the "sub" claim in every JWT
        access token, making it possible for resource servers to rely on
    that
        information for performing tasks such as correlating incoming
        requests with /data stored locally for the authenticated
    principal/.

This sentence clearly makes a relationship between the value present in 
the "sub" claim and "/data stored locally for the //*authenticated 
*//principal/".

However, note that the "OAuth Access Token JWT Profile" fails to allow 
the client (and hence the end-user) to control his privacy, since the 
client
cannot choose which value will be placed in the "sub" claim and also 
because access tokens are considered to be opaque for the clients in OAuth.
> If there is a subject identifier either included in or referenced by 
> the access token, that is /up to any agreements between the AS and RS/
> that lead to the ability of the AS to create the tokens the RS can 
> trust. All of this is outside the scope of the core GNAP protocol and 
> invisible to the client.

You are using the following words "/up to any agreements between the AS 
and RS/". This mandates prior agreements between ASs and RSs
and in such a case the architecture will be non-scalable over the 
Internet. The trust relationship between a RS and an AS is unilateral:
The RS trusts the AS to issue appropriate access tokens corresponding to 
the requests of its clients.

 From an end-user point of view, if there cannot be *transparency* 
because of the access token opacity,**then there cannot be *confidence 
*about GNAP .

Denis

>  — Justin
>
>> On Mar 26, 2021, at 1:27 PM, Denis <[email-masked] 
>> Let me rephrase the last question: How will a RS or a RO be 
>> bootstrapped for working with a GNAP "sub" claim or a "sub_id" claim ?
>>
>> Denis
>>
>>>> At the moment, I got the impression that nobody agrees any more 
>>>> about *what GNAP is or is not, what it should address and what it 
>>>> should not address*.
>>>> The last exchanges look more as conversations between workers 
>>>> during the construction of the Babel tower.
>>>>
>>>> Last year, my first remark was to mention that a section or an 
>>>> Annex explaining the common points and the differences with OAuth 2.0
>>>>     /If an RS allows a username/password HTTP Basic auth in
>>>>     addition to accepting access tokens, it can do so, but //
>>>>     //GNAP doesn’t have anything to say about the Basic auth use,
>>>>     or even its relation to any access tokens or RO’s or anything
>>>>     else./
>>>>
>>>> "/GNAP doesn’t have anything //to say about the Basic auth use/":  
>>>> If an authentication exchange  is necessary, the draft document 
>>>> should describe, for completeness,
>>>> At this very moment, the RS is able to identify and authenticate 
>>>> its end-users using FIDO pseudonyms. Now, let us raise the 
>>>> following question:
>>>>
>>>> How will a RS be bootstrapped for working with a GNAP "sub" claim 
>>>> or a "sub_id" claim, whereas FIDO is already being used ?
>>>>
>>>> Denis
>>>>
>>>>
>>>>> Adrian,
>>>>>
>>>>> negotiating user information to the client directly from the AS 
>>>>> with no RS involved, but that’s an aside for the purposes of our 
>>>>> conversation here).
>>>>>
>>>>> structured access tokens signed by trusted keys that don’t come 
>>>>> from an AS through a negotiated request — again, that’s fine, but 
>>>>> GNAP is silent about the RS doing that. If the RS acts as “its own 
>>>>> AS” then it’s really just an RS and an AS living in the same box. 
>>>>> Again, that’s fine, and super common with OAuth today.
>>>>>
>>>>> these other technologies can be used alongside it. I think there’s 
>>>>> a lot of room for the things that you’re talking about, and more 
>>>>> importantly for solving the use cases that you’re bringing. But 
>>>>> GNAP should be more than a single-point solution, and so we need 
>>>>> to balance these concerns. The conceptual framework of an AS that 
>>>>> takes in lots of different information and spits out access tokens 
>>>>> is exactly the abstraction layer that is necessary for making 
>>>>> these use cases interoperable.
>>>>>
>>>>>  — Justin
>>>>>
>>>>>> On Mar 26, 2021, at 8:30 AM, Adrian Gropper 
>>>>>> between processor and controller. No data minimization. And, I 
>>>>>> see no obvious reason to make this the core of GNAP.
>>>>>>
>>>>>> The core of GNAP, in my opinion, can be built and explained 
>>>>>> around this simple design. The RS is a processor. The RO is a 
>>>>>> controller. The RS bears only security responsibility. The RS 
>>>>>> bears no privacy responsibility. The RO delegates this to the RS 
>>>>>> but this is not authorization as the A in GNAP.
>>>>>>
>>>>>> endpoint options. Some of these options may do all sorts of 
>>>>>> things for all sorts of clients and user-agents  but these are 
>>>>>> options.
>>>>>>
>>>>>>     the RS, to create access tokens for the RS. That is its
>>>>>>     entire job, the entire reason it exists in the system. By
>>>>>>     definition the party generating tokens for use at the RS is
>>>>>>     the AS for that RS, I don’t care how you deploy it. If RO
>>>>>>     wants to give access to someone else (who isn’t an “RO"
>>>>>>     anymore, they’re another end-user), then that end user’s
>>>>>>     client software will need to talk to AS-RS to get its own
>>>>>>     access token.
>>>>>>
>>>>>>     Now here’s the trick: when the end user’s client instance
>>>>>>     talks to AS-RS, that does NOT mean that AS-RS needs to know
>>>>>>     all the details and policy reasons that it should give an
>>>>>>     access token to that client instance. It doesn’t even need to
>>>>>>     know the existence of another end user. It doesn’t need
>>>>>>     identity, it doesn’t need policy. Sure, it COULD handle all
>>>>>>     of that internally, and many will, but the protocol doesn’t
>>>>>>     demand it.
>>>>>>
>>>>>>     access token that it can then hand to another piece of
>>>>>>     software (or to a person to hand eo their piece of software).
>>>>>>     This artifact is not an access token. This artifact could be
>>>>>>     something structured that the client understands, and can
>>>>>>     make derivatives of, and present back to the AS-RS for
>>>>>>     getting new access tokens. There could be multiple different
>>>>>>     flavors of this kind of artifact for different kinds of
>>>>>>     environments and groups. But what they all have in common is
>>>>>>     that they can potentially be used to request more access
>>>>>>     tokens within some context at the AS-RS.
>>>>>>
>>>>>>      — Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>>>         "7. Another user agent (RO') can contact any holder of
>>>>>>>         the access token or the service's policy agent (AS-RS)
>>>>>>>         to get a delegated access token."
>>>>>>>
>>>>>>>
>>>>>>>     holder of the access token." by default so that the AS-RS
>>>>>>>     does not see the requests. In other words, the RS and AS-RS
>>>>>>>     only see access tokens. The requests (from RO') that
>>>>>>>     share whatever information with RS-AS they want and the RO
>>>>>>>     may not even know about it unless the RS decides to let them
>>>>>>>     know somehow. This seems to be a drawback of the
>>>>>>>     capabilities approach.
>>>>>>>
>>>>>>>     contract with the RS that says that I or my agent (AS-RO)
>>>>>>>     must sign an access token. This is a fundamental audit
>>>>>>>     requirement. Without it, a rogue RS and AS-RS can do all
>>>>>>>     sorts of things and the RO would never know. I understand
>>>>>>>     that a rogue RS might not support an honest contemporaneous
>>>>>>>     log of access tokens presented so there's a trust issue here
>>>>>>>     that I seems unavoidable unless I specify in my RO-RS
>>>>>>>     contract that they use a separate contemporaneous log such
>>>>>>>     as AS-RO for every access token presented and risk being
>>>>>>>     sued if they process an access token without also updating
>>>>>>>     the separate log.
>>>>>>>
>>>>>>>     - Adrian
>>>>>>>
>>>>>>>
>>>>>>>     On Thu, Mar 25, 2021 at 1:22 PM Alan Karp
>>>>>>>             protocol itself. Would that recast what you’re
>>>>>>>             saying below?
>>>>>>>
>>>>>>>
>>>>>>>         using some UI to express their decisions to what I
>>>>>>>         called the user agent.  That model fits in very nicely
>>>>>>>         with what we did with Polaris, our virus safe computing
>>>>>>>         needed to edit that one file.  Same thing here. The
>>>>>>>         client could ask for permission to use the resource, or
>>>>>>>             protocol itself. Would that recast what you’re
>>>>>>>             saying below?
>>>>>>>
>>>>>>>              — Justin
>>>>>>>
>>>>>>>>             comes into the picture, probably because of the
>>>>>>>>             "AS" part. I'm going to try to clear up that
>>>>>>>>             systems lingo.  I'm also assuming that it's
>>>>>>>>             possible to do delegation, either locally or by
>>>>>>>>             token exchange with AS-RS.  All delegations are
>>>>>>>>             potentially sub-scoped, but you may also want to
>>>>>>>>             delegate with full scope to have a separately
>>>>>>>>             revocable access token.
>>>>>>>>
>>>>>>>>              2. The service owner contracts with an policy
>>>>>>>>                 agent (AS-RS) to create and manage access
>>>>>>>>                 tokens for that service (RS).
>>>>>>>>              3. A person wishing to create a resource at RS
>>>>>>>>                 uses their user agent (RO) to contact the
>>>>>>>>                 service owner's policy agent (AS-RS) and gets
>>>>>>>>                 (AS-RO)) or the service's policy agent (AS-RS)
>>>>>>>>                 to get a delegated access token.
>>>>>>>>                 of the access token or the service's policy
>>>>>>>>                 agent (AS-RS) to get a delegated access token.
>>>>>>>>                  3. contract with a policy agent (AS-RO') of
>>>>>>>>                     its choosing to manage those delegations on
>>>>>>>>                     its behalf, or
>>>>>>>>             (ROs) or clients acting on their behalf, invokes
>>>>>>>>             the resource, AS-RS verifies that the access token
>>>>>>>>             is a valid delegation, i.e., proper sub-scoping,
>>>>>>>>             hasn't been revoked, and that it authorizes the
>>>>>>>>             request being made before telling the service (RS)
>>>>>>>>             to honor the request.  At no point does the
>>>>>>>>             service's policy agent (AS-RS) know which
>>>>>>>>             computational agent did any particular delegation.
>>>>>>>>             (Token exchange can be done as anonymously as
>>>>>>>>             possible.)  In particular, the policy agents
>>>>>>>>             (AS-RO) need not be the same, or even compatible
>>>>>>>>             with, the service's policy agent (AS-RS).  GNAP
>>>>>>>>             specifies the protocol between requesters,
>>>>>>>>                 that what we’re calling the “AS-RO” isn’t an
>>>>>>>>                 “AS” in the traditional OAuth/GNAP sense, at
>>>>>>>>                 least not exactly. This is the agent that the
>>>>>>>>                 RO can use to set policies and manage consent
>>>>>>>>                 on their behalf, and I’ve been arguing that it
>>>>>>>>                 fits better into this vaguely-defined
>>>>>>>>                 “interaction component” aspect of the current
>>>>>>>>                 AS definition, and it’s not currently separated
>>>>>>>>                 from the AS definition. The “AS-RS” maps to
>>>>>>>>                 what we’d call the “AS” in OAuth/GNAP
>>>>>>>>                 tokens. In traditional OAuth the AS-RO and
>>>>>>>>                 AS-RS are always the same thing, from a
>>>>>>>>                 where the client gets its tokens, because at
>>>>>>>>                 the end of the day the client just wants to
>>>>>>>>                 call the API at the RS and doesn’t care how
>>>>>>>>                 So we have these fundamental relationships
>>>>>>>>                 around getting the client to access the RS:
>>>>>>>>
>>>>>>>>                 optional details of how RS-AS runs things, and
>>>>>>>>                 I think this also maps with Adrian’s view of
>>>>>>>>                 to plug in my own AS-RO then I would be
>>>>>>>>                 motivated to pick a different RS who’s AS-RS
>>>>>>>>                 lets me do just that. The same way I’d pick a
>>>>>>>>                 different RS if their surrounding services
>>>>>>>>                 didn’t accept my preferred federation login and
>>>>>>>>                 I didn’t want to make another account. Of
>>>>>>>>                 course, market forces being as they are, I
>>>>>>>>                 might not have much of an actionable choice in
>>>>>>>>                 RS, but GNAP can’t change that.
>>>>>>>>
>>>>>>>>                 talk to AS-RO, both in philosophy of the
>>>>>>>>                 protocol design and in concrete hooks to
>>>>>>>>                 support (6) above.
>>>>>>>>
>>>>>>>>                 “federated authorization” approach, and is
>>>>>>>>                 behind a lot of the “bring your own AS” models
>>>>>>>>                 out there. The problem with these is that we
>>>>>>>>                 know from many years of experience that most
>>>>>>>>                 RS’s aren’t interested in doing anything of the
>>>>>>>>                 sort.
>>>>>>>>
>>>>>>>>                 in a predictable and consistent way, letting
>>>>>>>>                 the RS keep control over 1/2, thereby enabling
>>>>>>>>                 choice in (3). We don’t have to be the ones who
>>>>>>>>                 define the all of the details of every
>>>>>>>>                 permutation of (5) to enable this, though. Some
>>>>>>>>                 of this is going to be configuration out of
>>>>>>>>                 band, some of it’s going to be communication at
>>>>>>>>                 runtime. This is where VC’s, ZCAPs, CHAPI,
>>>>>>>>                 DIDComm, FIDO, and a whole swath of other tech
>>>>>>>>                 can come in and help out. I don’t think we need
>>>>>>>>                 to put all the details for using these into
>>>>>>>>                 core, nor do I think we’ll pull of The Great
>>>>>>>>                 And Ultimate Abstraction for using these and
>>>>>>>>                 other approaches. But we can at least start
>>>>>>>>                 talking about “AS-RS” in such a way that it no
>>>>>>>>                 longer assumes it’s always the same party
>>>>>>>>>                     - what matters is the RQ (could be a RO or
>>>>>>>>>                     a end-user or both : we don't really care
>>>>>>>>>                     at a high-level, they're all treated as
>>>>>>>>>                     entities that make a request)
>>>>>>>>>                         having two kinds of ASs. The problem
>>>>>>>>>                         for architectural simplicity is
>>>>>>>>>                         admirable but that may have been a
>>>>>>>>>                         step too far.
>>>>>>>>>
>>>>>>>>>                                 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.
>>>>>>>>>
>>>>>>>>>                                 information about requests
>>>>>>>>>                                 that are posed against those
>>>>>>>>>                                 policies.
>>>>>>>>>
>>>>>>>>>                                 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 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
>>>>>>>>>                                         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?
>>>>>>>>>                                             Note : I'm not
>>>>>>>>>                                             sure that's a good
>>>>>>>>>                                             idea, but having 2
>>>>>>>>>                                             types of ASs is
>>>>>>>>>                                             not that easy to
>>>>>>>>>                                             grasp.
>>>>>>>>>                                             2021 à 08:07,
>>>>>>>>>                                                 The purpose of
>>>>>>>>>                                                 handling
>>>>>>>>>                                                 locally or
>>>>>>>>>                                                 delegating
>>>>>>>>>                                                 mars 2021 à
>>>>>>>>>                                                 08:04, Adrian
>>>>>>>>>                                                     purpose
>>>>>>>>>                                                     into two
>>>>>>>>>                                                     On Thu,
>>>>>>>>>                                                     Mar 25,
>>>>>>>>>                                                         AS?
>>>>>>>>>                                                         Same
>>>>>>>>>                                                         idea
>>>>>>>>>                                                         role
>>>>>>>>>                                                         or as
>>>>>>>>>                                                         jeu.
>>>>>>>>>                                                         25

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 29 Mar 2021 08:48:50 -0400

Hi Denis,

I don’t understand your privacy issue, and I would like to try.

Let Alice be the RO and subject of a resource. at a RS. Let Bob be a party,
not Alice, that seeks authorization to access the resource using an access
token.

Bob has discovered the resource somehow that is out of band for GNAP.
(Maybe Alice sent Bob a pointer to the resource in an email).

Bob makes a request for the resource at some AS. The request includes the
pointer that Bob discovered to the resource, some attributes or claims
about Bob, and maybe a reason for the request.

How Bob discovered the AS to make the request to is unclear to me for the
time being. Maybe Bob discovered the AS along with the resource. (e.g The
resource is a DID and the AS is a service endpoint or mediator to an AS in
that DID.)

Given the scenario above, who’s privacy interest are you primarily
concerned about? Alice or Bob?

Adrian

On Mon, Mar 29, 2021 at 6:39 AM Denis <[email-masked]> wrote:

> Hi  Justin,
>
> Since your response only deals with the AS, but not the RS nor the RO, it
> is not a response to my question which was:
>
> How will a RS or a RO be bootstrapped for working with a GNAP "sub" claim
> or a "sub_id" claim ?
>
> The subject identifier is whatever identifier the AS knows the subject as.
> If they log in using only a FIDO token and the AS asserts that key value as
> the identifier, then that’s what it will be. If they sign up with an email
> address or make a username or get assigned a random number, that’s what it
> will be. Or they could sign up using any number of those and the AS still
> assigns them a random value, because it’s always the AS that determines
> which value to assign the number.
>
> end-user) has currently *no practical way* to indicate which of its
> The only reference within Section 3.2 is pointing to the empty Section 12.
> Among the many examples, there is not a single example that addresses the
> case of attributes being placed into an access token.
>
> client (and hence the end-user), SHALL have control at all of what kind of *subject
> identifier* claim will be placed inside the access token.
>
> to the client (and hence the end-user)", it seems that in your opinion, the
> end-user SHALL have no way to verify
> Really ? Do you mean that an access token should not contain a "sub" claim
> nor a "sub_id" claim  and if it does, the RS SHALL ignore such claims ?
>
>    access token, making it possible for resource servers to rely on that
>    requests with *data stored locally for the authenticated principal*.
>
> the "sub" claim and "*data stored locally for the **authenticated *
> *principal*".
>
> However, note that the "OAuth Access Token JWT Profile" fails to allow the
> client (and hence the end-user) to control his privacy, since the client
> If there is a subject identifier either included in or referenced by the
> access token, that is *up to any agreements between the AS and RS*
> that lead to the ability of the AS to create the tokens the RS can trust.
> All of this is outside the scope of the core GNAP protocol and invisible to
> the client.
>
> You are using the following words "*up to any agreements between the AS
> and RS*". This mandates prior agreements between ASs and RSs
> From an end-user point of view, if there cannot be *transparency* because
> of the access token opacity, then there cannot be *confidence *about GNAP
> .
>
> Denis
>
>  — Justin
>
> GNAP doesn’t have anything too say about anybody authenticating directly
> to the RS. If that happens, it’s out of the view and out of scope of GNAP.
>
>  — Justin
>
> Since I am going to use some sentences of this thread to open a new topic,
> I changed the title of this thread into :
> At the moment, I got the impression that nobody agrees any more about *what
> GNAP is or is not, what it should address and what it should not address*.
> I still can't understand any of the new terms that are being used (*AS-RS*
> and *AS-RO*), *which are still left undefined*.
>
> *If an RS allows a username/password HTTP Basic auth in addition to
> accepting access tokens, it can do so, but *
> *GNAP doesn’t have anything to say about the Basic auth use, or even its
> relation to any access tokens or RO’s or anything else.*
>
> "*GNAP doesn’t have anything **to say about the Basic auth use*":  If an
> authentication exchange  is necessary, the draft document should describe,
> for completeness,
> "*or even its relation to any access tokens or RO’s or anything else*".

---

From: Denis <[email-masked]>
Date: Mon, 29 Mar 2021 15:53:55 +0200

Hi Adrian,

Thank you for the scenario. You certainly know the following sentence:

    "When the only tool you have is a hammer, every problem looks like a
    nail".

Similarly:  "When the only tool you have is an AS, every problem looks 
like an access token issued by an AS".

Let us start with exactly the same sentence that explains the goal:

    Let Alice be the RO and subject of a resource. at a RS. Let Bob be a
    party, not Alice, that seeks authorization to access the resource
    using an access token.

Then Bob asks to Alice to issue for him an authorization to access the 
resource.
Alice, as the RO of the resource, request from the RS an "/access 
token/"  which is an (unsigned) data structure which contains:
a read permission on some Alice's photo directory, associated with a 
large random number /chosen by the RS/.

Note that a validity period will also be associated in practice, but 
this is a minor detail for the demonstration.

Alice sends back to Bob the "/access token/" issued by the RS.

*Bob looks inside the access token* to make sure that it corresponds to 
what he requested to Alice, i.e. a read permission on some Alice's photo 
directory.

If the content is fine, Bob presents to the RS the large random number 
associated together with an API GET for some sub-set of the photos 
contained in Alice's directory.

Since the RS recognizes the large random number and that the GET API is 
valid according to the "access token" memorized by the RS authorization 
set by Alice as a RO,
the access is granted.

In this example, the RS will not know who is reading the photo 
directory. So Bob can transmit the "access token" to someone else during 
its validity period, which may be a desirable feature.
Note that it is also possible to allow Bob only to access Alice's 
directory. For simplicity, this alternative is not explained.

In the mean time, I solved the answer of your question which was:" /How 
Bob discovered the AS to make the request to is unclear to me for the 
time being/".
The request to your question is also unclear to me for the time being, 
but since there is no AS involved, Bob does not need to discover any AS. :-)

I am quite sure that someone else will be able to describe one or more 
scenarios "/using an AS as an hammer/", but is is very likely that in 
such a case,
the AS will be able know that Bob is rather likely to access in a short 
time some photos placed in the Alice's directory of photo hosted on that 
RS. /
This may be a privacy concern for Bob/.

Of course, in addition, the AS and the RS must establish some prior 
relationships, etc ...

However, all the discussion above is outside the scope of this initial 
thread which is: Relationship between Authentication and Authorization ?
If you want to continue the discussion on the topic you mentioned, 
that's fine with me, but please change the title of this thread.

Denis

> Let Alice be the RO and subject of a resource. at a RS. Let Bob be a 
> party, not Alice, that seeks authorization to access the resource 
> using an access token.
>
> Bob makes a request for the resource at some AS. The request includes 
> the pointer that Bob discovered to the resource, some attributes or 
> claims about Bob, and maybe a reason for the request.
>
> How Bob discovered the AS to make the request to is unclear to me for 
> the time being. Maybe Bob discovered the AS along with the resource. 
> (e.g The resource is a DID and the AS is a service endpoint or 
> mediator to an AS in that DID.)
>
> On Mon, Mar 29, 2021 at 6:39 AM Denis <[email-masked] 
>     Since your response only deals with the AS, but not the RS nor the
>     RO, it is not a response to my question which was:
>
>         How will a RS or a RO be bootstrapped for working with a GNAP
>         "sub" claim or a "sub_id" claim ?
>
>>     The subject identifier is whatever identifier the AS knows the
>>     subject as. If they log in using only a FIDO token and the AS
>>     asserts that key value as the identifier, then that’s what it
>>     will be. If they sign up with an email address or make a username
>>     or get assigned a random number, that’s what it will be. Or they
>>     could sign up using any number of those and the AS still assigns
>>     them a random value, because it’s always the AS that determines
>     When looking at Section 3.2 (Access Tokens), the client (and hence
>     the end-user) has currently /no practical way/ to indicate which
>     of its attributes should be placed into an access token,
>     The only reference within Section 3.2 is pointing to the empty
>     Section 12. Among the many examples, there is not a single example
>     that addresses the case of attributes being placed into an access
>     token.
>
>     Nevertheless, it seems that in your opinion, only the AS, but NOT
>     the client (and hence the end-user), SHALL have control at all of
>     what kind of /subject identifier/ claim will be placed inside the
>     access token.
>
>     Then after, invoking the postulate "the access token SHALL remain
>     opaque to the client (and hence the end-user)", it seems that in
>     your opinion, the end-user SHALL have no way to verify
>     whether its privacy has been respected. If this is not an
>     architecture built along "spy by design" principles, I don't know
>     what else it might be.
>
>         *Access Toke*n: data artifact representing a set of rights
>         *a**nd/or attributes*.
>
>     In the current draft, the case of rights is indeed addressed while
>     *the case of attributes is fully ignored*.
>
>>     The RS is not involved in any subject information. Identity APIs,
>>     like OpenID Connect’s UserInfo Endpoint, are out of scope for GNAP.
>
>     Really ? Do you mean that an access token should not contain a
>     "sub" claim nor a "sub_id" claim  and if it does, the RS SHALL
>     ignore such claims ?
>
>     In the "OAuth Access Token JWT Profile", there is the following
>     sentence in Section 6 (Privacy Considerations) :
>
>     This sentence clearly makes a relationship between the value
>     present in the "sub" claim and "/data stored locally for the
>     //*authenticated *//principal/".
>
>     However, note that the "OAuth Access Token JWT Profile" fails to
>     allow the client (and hence the end-user) to control his privacy,
>     since the client
>     cannot choose which value will be placed in the "sub" claim and
>     also because access tokens are considered to be opaque for the
>     clients in OAuth.
>>     If there is a subject identifier either included in or referenced
>>     by the access token, that is /up to any agreements between the AS
>>     and RS/
>>     that lead to the ability of the AS to create the tokens the RS
>>     can trust. All of this is outside the scope of the core GNAP
>>     protocol and invisible to the client.
>
>     You are using the following words "/up to any agreements between
>     the AS and RS/". This mandates prior agreements between ASs and RSs
>     The RS trusts the AS to issue appropriate access tokens
>     corresponding to the requests of its clients.
>
>     because of the access token opacity,**then there cannot be
>     *confidence *about GNAP .
>
>     Denis
>
>
>>      — Justin
>>
>>>>     directly to the RS. If that happens, it’s out of the view and
>>>>     out of scope of GNAP.
>>>>
>>>>      — Justin
>>>>
>>>>>     Since I am going to use some sentences of this thread to open
>>>>>     a new topic, I changed the title of this thread into :
>>>>>     At the moment, I got the impression that nobody agrees any
>>>>>     more about *what GNAP is or is not, what it should address and
>>>>>     what it should not address*.
>>>>>     The components of the model are becoming more numerous and
>>>>>     hazy. A new terminology is sometimes being used, but is not
>>>>>     yet present in the last published draft.
>>>>>
>>>>>     I still can't understand any of the new terms that are being
>>>>>     used (*AS-RS* and *AS-RO*), _which are still left undefined_.
>>>>>
>>>>>         //GNAP doesn’t have anything to say about the Basic auth
>>>>>         use, or even its relation to any access tokens or RO’s or
>>>>>         anything else./
>>>>>
>>>>>     "/GNAP doesn’t have anything //to say about the Basic auth
>>>>>     use/": If an authentication exchange is necessary, the draft
>>>>>     document should describe, for completeness,
>>>>>     "/or even its relation to any access tokens or RO’s or
>>>>>     anything else/". Let us suppose that a RS supports FIDO as an
>>>>>     authentication mechanism to authenticate its end-users.
>>>>>     FIDO provides the major advantage that, for every RS, a
>>>>>     different identifier is used by every end-user. This prevents
>>>>>     end-users accounts correlations between RSs by using
>>>>>     At this very moment, the RS is able to identify and
>>>>>     authenticate its end-users using FIDO pseudonyms. Now, let us
>>>>>     raise the following question:
>>>>>
>>>>>     How will a RS be bootstrapped for working with a GNAP "sub"
>>>>>     claim or a "sub_id" claim, whereas FIDO is already being used ?
>>>>>
>>>>>     Denis
>>>>>
>>>>>
>>>>>>     Adrian,
>>>>>>
>>>>>>     Like OAuth before it, GNAP is a protocol negotiate access for
>>>>>>     a client instance to an RS, using an AS as the facilitator of
>>>>>>     that delegated negotiation. (Unlike OAuth, it’s importantly
>>>>>>     also for negotiating user information to the client directly
>>>>>>     from the AS with no RS involved, but that’s an aside for the
>>>>>>     purposes of our conversation here).
>>>>>>
>>>>>>     If a particular GNAP RS also allows other kinds of processes
>>>>>>     to enable access to it, that is completely fine, but outside
>>>>>>     of GNAP. If an RS allows a username/password HTTP Basic auth
>>>>>>     in addition to accepting access tokens, it can do so, but
>>>>>>     GNAP doesn’t have anything to say about the Basic auth use,
>>>>>>     else. If an RS accepts structured access tokens signed by
>>>>>>     trusted keys that don’t come from an AS through a negotiated
>>>>>>     request — again, that’s fine, but GNAP is silent about the RS
>>>>>>     doing that. If the RS acts as “its own AS” then it’s really
>>>>>>     just an RS and an AS living in the same box. Again, that’s
>>>>>>     fine, and super common with OAuth today.
>>>>>>
>>>>>>     GNAP is solving the problem of connecting the client to the
>>>>>>     RS through means of an AS. Other solutions are possible and
>>>>>>     many of them can be deployed right alongside, but that’s not
>>>>>>     the corner of the world that GNAP is solving. GNAP should be
>>>>>>     concerned about how these other technologies can be used
>>>>>>     alongside it. I think there’s a lot of room for the things
>>>>>>     that you’re talking about, and more importantly for solving
>>>>>>     the use cases that you’re bringing. But GNAP should be more
>>>>>>     concerns. The conceptual framework of an AS that takes in
>>>>>>     lots of different information and spits out access tokens is
>>>>>>     exactly the abstraction layer that is necessary for making
>>>>>>>     @Justin, there’s no separation of concerns here. No
>>>>>>>     partition between processor and controller. No data
>>>>>>>     minimization. And, I see no obvious reason to make this the
>>>>>>>     core of GNAP.
>>>>>>>
>>>>>>>     around this simple design. The RS is a processor. The RO is
>>>>>>>     a controller. The RS bears only security responsibility. The
>>>>>>>     RS bears no privacy responsibility. The RO delegates this to
>>>>>>>     the RS but this is not authorization as the A in GNAP.
>>>>>>>
>>>>>>>     The RO retains all rights to delegate within the scope of
>>>>>>>     things that the RS is willing to support using various token
>>>>>>>     formats and endpoint options. Some of these options may do
>>>>>>>     all sorts of things for all sorts of clients and user-agents
>>>>>>>      but these are options.
>>>>>>>
>>>>>>>     For example, if a request comes to the RS that is not in the
>>>>>>>     form of an access token, then it either gets sent to the RO
>>>>>>>     or their agent, or it gets logged and dumped. One such
>>>>>>>     option, common in healthcare, is “Break the Glass” where the
>>>>>>>     RS is acting as an authorization server because the
>>>>>>>     user-agent is making a request instead of presenting an
>>>>>>>     access token. GNAP can offer this as an option but it is not
>>>>>>>     our core.
>>>>>>>
>>>>>>>     Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     On Fri, Mar 26, 2021 at 7:15 AM Justin Richer
>>>>>>>         > the RS and AS-RS only see access tokens. The requests
>>>>>>>         (from RO') that resulted in an access token are none of
>>>>>>>         their business.
>>>>>>>
>>>>>>>         In the trust model we’ve been discussing, the requests
>>>>>>>         that result in access tokens are *solely the business of
>>>>>>>         AS-RS*, since AS-RS is the only entity that’s allowed,
>>>>>>>         and trusted by the RS, to create access tokens for the
>>>>>>>         RS. That is its entire job, the entire reason it exists
>>>>>>>         in the system. By definition the party generating tokens
>>>>>>>         for use at the RS is the AS for that RS, I don’t care
>>>>>>>         how you deploy it. If RO wants to give access to someone
>>>>>>>         else (who isn’t an “RO" anymore, they’re another
>>>>>>>         end-user), then that end user’s client software will
>>>>>>>         Now here’s the trick: when the end user’s client
>>>>>>>         instance talks to AS-RS, that does NOT mean that AS-RS
>>>>>>>         needs to know all the details and policy reasons that it
>>>>>>>         should give an access token to that client instance. It
>>>>>>>         doesn’t even need to know the existence of another end
>>>>>>>         user. It doesn’t need identity, it doesn’t need policy.
>>>>>>>         Sure, it COULD handle all of that internally, and many
>>>>>>>         This means that the first client instance, the one that
>>>>>>>         gets the access token, can also be given something
>>>>>>>         alongside the access token that it can then hand to
>>>>>>>         another piece of software (or to a person to hand eo
>>>>>>>         their piece of software). This artifact is not an access
>>>>>>>         token. This artifact could be something structured that
>>>>>>>         the client understands, and can make derivatives of, and
>>>>>>>         present back to the AS-RS for getting new access tokens.
>>>>>>>         There could be multiple different flavors of this kind
>>>>>>>         of artifact for different kinds of environments and
>>>>>>>         groups. But what they all have in common is that they
>>>>>>>         can potentially be used to request more access tokens
>>>>>>>>             "7. Another user agent (RO') can contact any holder
>>>>>>>>             (AS-RS) to get a delegated access token."
>>>>>>>>
>>>>>>>>
>>>>>>>>         I would prefer "7A.Another user agent (RO') can contact
>>>>>>>>         any holder of the access token." by default so that the
>>>>>>>>         AS-RS does not see the requests. In other words, the RS
>>>>>>>>         and AS-RS only see access tokens. The requests (from
>>>>>>>>         The reality is that RO' can discover a resource RS and
>>>>>>>>         can share whatever information with RS-AS they want and
>>>>>>>>         the RO may not even know about it unless the RS decides
>>>>>>>>         to let them know somehow. This seems to be a drawback
>>>>>>>>         contract with the RS that says that I or my agent
>>>>>>>>         (AS-RO) must sign an access token. This is a
>>>>>>>>         fundamental audit requirement. Without it, a rogue RS
>>>>>>>>         and AS-RS can do all sorts of things and the RO would
>>>>>>>>         never know. I understand that a rogue RS might not
>>>>>>>>         support an honest contemporaneous log of access tokens
>>>>>>>>         presented so there's a trust issue here that I seems
>>>>>>>>         unavoidable unless I specify in my RO-RS contract that
>>>>>>>>         they use a separate contemporaneous log such as AS-RO
>>>>>>>>         for every access token presented and risk being sued if
>>>>>>>>         they process an access token without also updating the
>>>>>>>>         separate log.
>>>>>>>>
>>>>>>>>         - Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>                 In all of my discussion, and in the spec
>>>>>>>>                 itself, the RO is the :entity: in charge of
>>>>>>>>                 approving rights. They’re probably a person. It
>>>>>>>>                 might be software that makes a policy decision
>>>>>>>>                 in some way, or a corporate entity, or
>>>>>>>>                 something like that. But it’s not assumed to be
>>>>>>>>                 a computational agent in the terms of the
>>>>>>>>             Hmmm.  I guess not. It's just that the person would
>>>>>>>>             be using some UI to express their decisions to what
>>>>>>>>             I called the user agent.  That model fits in very
>>>>>>>>             nicely with what we did with Polaris, our virus
>>>>>>>>             safe computing environment for Windows XP,
>>>>>>>>             <https://dl.acm.org/doi/10.1145/1151030.1151033>.
>>>>>>>>             The person would click on the icon for a Word file,
>>>>>>>>             and an instance of Word would open with only the
>>>>>>>>             permission needed to edit that one file.  Same
>>>>>>>>             thing here. The client could ask for permission to
>>>>>>>>             use the resource, or permission could be granted
>>>>>>>>             implicitly when the user selects a resource
>>>>>>>>                 In all of my discussion, and in the spec
>>>>>>>>                 itself, the RO is the :entity: in charge of
>>>>>>>>                 approving rights. They’re probably a person. It
>>>>>>>>                 might be software that makes a policy decision
>>>>>>>>                 in some way, or a corporate entity, or
>>>>>>>>                 something like that. But it’s not assumed to be
>>>>>>>>                 a computational agent in the terms of the
>>>>>>>>>                 There seems to be some confusion about how
>>>>>>>>>                 AS-RO comes into the picture, probably because
>>>>>>>>>                 of the "AS" part. I'm going to try to clear up
>>>>>>>>>                 representing the person who is the resource
>>>>>>>>>                 owner, something called the "user agent" in
>>>>>>>>>                 operating systems lingo.  I'm also assuming
>>>>>>>>>                 that it's possible to do delegation, either
>>>>>>>>>                 locally or by token exchange with AS-RS.  All
>>>>>>>>>                 delegations are potentially sub-scoped, but
>>>>>>>>>                 you may also want to delegate with full scope
>>>>>>>>>                  3. A person wishing to create a resource at
>>>>>>>>>                     RS uses their user agent (RO) to contact
>>>>>>>>>                     the service owner's policy agent (AS-RS)
>>>>>>>>>                     and gets back an access token for that
>>>>>>>>>                     resource.
>>>>>>>>>                      2. delegate an access token to a client
>>>>>>>>>                         of the user agent's (RO) choice, or
>>>>>>>>>                      3. contract with a policy agent (AS-RO)
>>>>>>>>>                         to manage those delegations on behalf
>>>>>>>>>                         of the user agent (RO), or
>>>>>>>>>                  5. A client can contact any holder of the
>>>>>>>>>                     access token (the user agent (RO) or its
>>>>>>>>>                     policy agent (AS-RO)) or the service's
>>>>>>>>>                     policy agent (AS-RS) to get a delegated
>>>>>>>>>                     access token.
>>>>>>>>>                  7. Another user agent (RO') can contact any
>>>>>>>>>                     holder of the access token or the
>>>>>>>>>                     service's policy agent (AS-RS) to get a
>>>>>>>>>                     delegated access token.
>>>>>>>>>                      3. contract with a policy agent (AS-RO')
>>>>>>>>>                         of its choosing to manage those
>>>>>>>>>                         delegations on its behalf, or
>>>>>>>>>                 When any of these computational agents, user
>>>>>>>>>                 agents (ROs) or clients acting on their
>>>>>>>>>                 behalf, invokes the resource, AS-RS verifies
>>>>>>>>>                 that the access token is a valid delegation,
>>>>>>>>>                 i.e., proper sub-scoping, hasn't been revoked,
>>>>>>>>>                 and that it authorizes the request being made
>>>>>>>>>                 before telling the service (RS) to honor the
>>>>>>>>>                 request.  At no point does the service's
>>>>>>>>>                 policy agent (AS-RS) know which computational
>>>>>>>>>                 agent did any particular delegation. (Token
>>>>>>>>>                 exchange can be done as anonymously as
>>>>>>>>>                 (AS-RO) need not be the same, or even
>>>>>>>>>                 compatible with, the service's policy agent
>>>>>>>>>                 (AS-RS).  GNAP specifies the protocol between
>>>>>>>>>                 requesters, invokers, delegators (for token
>>>>>>>>>                 exchange) of tokens and AS-RS.  That protocol
>>>>>>>>>                 need not be used between user agents (RO),
>>>>>>>>>                     The way I’m thinking about Adrian’s use
>>>>>>>>>                     case is that what we’re calling the
>>>>>>>>>                     “AS-RO” isn’t an “AS” in the traditional
>>>>>>>>>                     OAuth/GNAP sense, at least not exactly.
>>>>>>>>>                     This is the agent that the RO can use to
>>>>>>>>>                     set policies and manage consent on their
>>>>>>>>>                     behalf, and I’ve been arguing that it fits
>>>>>>>>>                     definition. The “AS-RS” maps to what we’d
>>>>>>>>>                     call the “AS” in OAuth/GNAP traditionally,
>>>>>>>>>                     it’s what the RS trusts to issue tokens.
>>>>>>>>>                     In traditional OAuth the AS-RO and AS-RS
>>>>>>>>>                     are always the same thing, from a
>>>>>>>>>                     functional protocol perspective. An
>>>>>>>>>                     important point here is that from a
>>>>>>>>>                     client’s perspective, they’re only talking
>>>>>>>>>                     to the AS-RS since that’s where the client
>>>>>>>>>                     gets its tokens, because at the end of the
>>>>>>>>>                     day the client just wants to call the API
>>>>>>>>>                     at the RS and doesn’t care how that
>>>>>>>>>                     happens (from a protocol standpoint).
>>>>>>>>>
>>>>>>>>>                     Note well: Even thought I don’t believe
>>>>>>>>>                     that “AS-RO” is an authorization server at
>>>>>>>>>                     all, I’m going to keep using that term
>>>>>>>>>                     1. RS trusts AS-RS to issue tokens that RS
>>>>>>>>>                     will accept, validate, and process for
>>>>>>>>>                     requests from client
>>>>>>>>>                     6. Client trusts whatever AS-RS sends
>>>>>>>>>                     client to deal with, including possibly
>>>>>>>>>                     RO-AS at runtime, because of (2)
>>>>>>>>>
>>>>>>>>>                     optional details of how RS-AS runs things,
>>>>>>>>>                     and I think this also maps with Adrian’s
>>>>>>>>>                     view of choice, since if my RS’s AS-RS
>>>>>>>>>                     doesn’t allow me to plug in my own AS-RO
>>>>>>>>>                     then I would be motivated to pick a
>>>>>>>>>                     different RS who’s AS-RS lets me do just
>>>>>>>>>                     that. The same way I’d pick a different RS
>>>>>>>>>                     if their surrounding services didn’t
>>>>>>>>>                     accept my preferred federation login and I
>>>>>>>>>                     didn’t want to make another account. Of
>>>>>>>>>                     might not have much of an actionable
>>>>>>>>>                     choice in RS, but GNAP can’t change that.
>>>>>>>>>
>>>>>>>>>                     What we can do is make it possible for
>>>>>>>>>                     AS-RS to talk to AS-RO, both in philosophy
>>>>>>>>>                     of the protocol design and in concrete
>>>>>>>>>                     hooks to support (6) above.
>>>>>>>>>
>>>>>>>>>                     Separately, we can approach the issue of
>>>>>>>>>                     making 1/2 above more dynamic. This was
>>>>>>>>>                     UMA2’s “federated authorization” approach,
>>>>>>>>>                     and is behind a lot of the “bring your own
>>>>>>>>>                     AS” models out there. The problem with
>>>>>>>>>                     these is that we know from many years of
>>>>>>>>>                     experience that most RS’s aren’t
>>>>>>>>>                     So with GNAP we can instead allow 4/5/6 to
>>>>>>>>>                     vary in a predictable and consistent way,
>>>>>>>>>                     letting the RS keep control over 1/2,
>>>>>>>>>                     thereby enabling choice in (3). We don’t
>>>>>>>>>                     have to be the ones who define the all of
>>>>>>>>>                     the details of every permutation of (5) to
>>>>>>>>>                     enable this, though. Some of this is going
>>>>>>>>>                     to be configuration out of band, some of
>>>>>>>>>                     it’s going to be communication at runtime.
>>>>>>>>>                     This is where VC’s, ZCAPs, CHAPI, DIDComm,
>>>>>>>>>                     FIDO, and a whole swath of other tech can
>>>>>>>>>                     come in and help out. I don’t think we
>>>>>>>>>                     need to put all the details for using
>>>>>>>>>                     these into core, nor do I think we’ll pull
>>>>>>>>>                     of The Great And Ultimate Abstraction for
>>>>>>>>>                     using these and other approaches. But we
>>>>>>>>>                     can at least start talking about “AS-RS”
>>>>>>>>>                     in such a way that it no longer assumes
>>>>>>>>>                     it’s always the same party dealing with
>>>>>>>>>                     the RO directly.
>>>>>>>>>
>>>>>>>>>                      — Justin
>>>>>>>>>
>>>>>>>>>>                     On Mar 25, 2021, at 6:40 AM, Fabien
>>>>>>>>>>                     - AS = AS-RO, that's where you find the
>>>>>>>>>>                     RO policies. The AS issues access tokens
>>>>>>>>>>                     to the client.
>>>>>>>>>>                     - the RO policies could be a) defined
>>>>>>>>>>                     locally or b) in relationship with the RS
>>>>>>>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 29 Mar 2021 11:49:26 -0400

This is helpful, Denis.

I will focus on "Then Bob asks to Alice to issue for him an authorization
to access the resource." and avoid using any hammers.

Let's use something in the news and say the RS is a hospital that gave
Alice a J&J COVID vaccine. Alice identified herself to the hospital with a
number N. N could have been randomly chosen by Alice or the hospital or N
could be Alice's driver's license number right next to her face photo. GNAP
should probably deal with both cases.

The hospital creates a digital credential that includes the J&J vaccine
name and lot number, N, a statement about how N was derived, and a date.
The hospital posts this credential at some resource URL, protected by some
access token requirement, and gives Alice the "resource URL" instead of or
along with a paper vaccination card with the same information as the
resource.

When Bob asks Alice for an access token, Bob makes a request to Alice and
she can either:
A - Give Bob the "resource URL" and let him try his luck turning this into
an access token somewhere,
B - Go to the hospital portal and authenticate somehow and grab an access
token that she can return to Bob,
C - Give Bob an access token for the resource URL based on some signature
that is trusted by the hospital.

When Bob gets the resource, it will include N along with the hospital's
statement about how N was derived. Bob can decide what to do next.

Adrian

On Mon, Mar 29, 2021 at 9:54 AM Denis <[email-masked]> wrote:

> "When the only tool you have is a hammer, every problem looks like a nail".
>
> party, not Alice, that seeks authorization to access the resource using an
> access token.
>
> Alice, as the RO of the resource, request from the RS an "*access token*"
> which is an (unsigned) data structure which contains:
> a read permission on some Alice's photo directory, associated with a large
> random number *chosen by the RS*.
>
> Note that a validity period will also be associated in practice, but this
> is a minor detail for the demonstration.
>
> Alice sends back to Bob the "*access token*" issued by the RS.
>
> valid according to the "access token" memorized by the RS authorization set
> by Alice as a RO,
> the access is granted.
>
> In this example, the RS will not know who is reading the photo directory.
> So Bob can transmit the "access token" to someone else during its validity
> period, which may be a desirable feature.
> In the mean time, I solved the answer of your question which was:" *How
> Bob discovered the AS to make the request to is unclear to me for the time
> being*".
> The request to your question is also unclear to me for the time being, but
> since there is no AS involved, Bob does not need to discover any AS. :-)
>
> scenarios "*using an AS as an hammer*", but is is very likely that in
> such a case,
> * This may be a privacy concern for Bob*.
>
> If you want to continue the discussion on the topic you mentioned, that's
> fine with me, but please change the title of this thread.
>
> Denis
>
> Hi Denis,
>
> party, not Alice, that seeks authorization to access the resource using an
> access token.
>
>> value as the identifier, then that’s what it will be. If they sign up with
>> an email address or make a username or get assigned a random number, that’s
>> what it will be. Or they could sign up using any number of those and the AS
>> still assigns them a random value, because it’s always the AS that
>> determines which value to assign the number.
>>
>> 12. Among the many examples, there is not a single example that addresses
>> the case of attributes being placed into an access token.
>>
>> claim nor a "sub_id" claim  and if it does, the RS SHALL ignore such claims
>> ?
>>
>> because of the access token opacity, then there cannot be *confidence *about
>> GNAP .
>>
>> Denis
>>
>>  — Justin
>>
>> I still can't understand any of the new terms that are being used (
>> *AS-RS* and *AS-RO*), *which are still left undefined*.
>>

---

From: Denis <[email-masked]>
Date: Mon, 29 Mar 2021 19:18:52 +0200

Adrian,

I changed the title of this thread since your are addressing a new topic 
that I am unable to understand.
Alice J&J vaccine is Alice's private information. For which reason would 
Bob ask Alice to provide an access token ?

Denis

> This is helpful, Denis.
>
> I will focus on "Then Bob asks to Alice to issue for him an 
> authorization to access the resource." and avoid using any hammers.
>
> Alice a J&J COVID vaccine. Alice identified herself to the hospital 
> with a number N. N could have been randomly chosen by Alice or the 
> hospital or N could be Alice's driver's license number right next to 
> her face photo. GNAP should probably deal with both cases.
>
> The hospital creates a digital credential that includes the J&J 
> vaccine name and lot number, N, a statement about how N was derived, 
> and a date. The hospital posts this credential at some resource URL, 
> protected by some access token requirement, and gives Alice the 
> "resource URL" instead of or along with a paper vaccination card with 
> the same information as the resource.
>
> When Bob asks Alice for an access token, Bob makes a request to Alice 
> and she can either:
> A - Give Bob the "resource URL" and let him try his luck turning this 
> into an access token somewhere,
> B - Go to the hospital portal and authenticate somehow and grab an 
> access token that she can return to Bob,
> C - Give Bob an access token for the resource URL based on some 
> signature that is trusted by the hospital.
>
> When Bob gets the resource, it will include N along with the 
> hospital's statement about how N was derived. Bob can decide what to 
> do next.
>
> Adrian
>
>
> On Mon, Mar 29, 2021 at 9:54 AM Denis <[email-masked] 
>     Similarly:  "When the only tool you have is an AS, every problem
>     looks like an access token issued by an AS".
>
>         Let Alice be the RO and subject of a resource. at a RS. Let
>         Bob be a party, not Alice, that seeks authorization to access
>         the resource using an access token.
>
>     Then Bob asks to Alice to issue for him an authorization to access
>     the resource.
>     a read permission on some Alice's photo directory, associated with
>     a large random number /chosen by the RS/.
>
>     Note that a validity period will also be associated in practice,
>     but this is a minor detail for the demonstration.
>
>     *Bob looks inside the access token* to make sure that it
>     corresponds to what he requested to Alice, i.e. a read permission
>     on some Alice's photo directory.
>
>     If the content is fine, Bob presents to the RS the large random
>     number associated together with an API GET for some sub-set of the
>     photos contained in Alice's directory.
>
>     Since the RS recognizes the large random number and that the GET
>     API is valid according to the "access token" memorized by the RS
>     authorization set by Alice as a RO,
>     the access is granted.
>
>     directory. So Bob can transmit the "access token" to someone else
>     during its validity period, which may be a desirable feature.
>     In the mean time, I solved the answer of your question which was:"
>     /How Bob discovered the AS to make the request to is unclear to me
>     for the time being/".
>     The request to your question is also unclear to me for the time
>     being, but since there is no AS involved, Bob does not need to
>     discover any AS. :-)
>
>     I am quite sure that someone else will be able to describe one or
>     more scenarios "/using an AS as an hammer/", but is is very likely
>     that in such a case,
>     the AS will be able know that Bob is rather likely to access in a
>     short time some photos placed in the Alice's directory of photo
>     hosted on that RS. /
>     Of course, in addition, the AS and the RS must establish some
>     prior relationships, etc ...
>
>     However, all the discussion above is outside the scope of this
>     initial thread which is: Relationship between Authentication and
>     Authorization ?
>>     Let Alice be the RO and subject of a resource. at a RS. Let Bob
>>     be a party, not Alice, that seeks authorization to access the
>>     resource using an access token.
>>
>>     Bob has discovered the resource somehow that is out of band for
>>     GNAP. (Maybe Alice sent Bob a pointer to the resource in an email).
>>
>>     Bob makes a request for the resource at some AS. The request
>>     includes the pointer that Bob discovered to the resource, some
>>     attributes or claims about Bob, and maybe a reason for the request.
>>
>>     How Bob discovered the AS to make the request to is unclear to me
>>     for the time being. Maybe Bob discovered the AS along with the
>>     resource. (e.g The resource is a DID and the AS is a service
>>     endpoint or mediator to an AS in that DID.)
>>
>>     Given the scenario above, who’s privacy interest are you
>>     primarily concerned about? Alice or Bob?
>>
>>     Adrian
>>
>>         Since your response only deals with the AS, but not the RS
>>         nor the RO, it is not a response to my question which was:
>>
>>             How will a RS or a RO be bootstrapped for working with a
>>             GNAP "sub" claim or a "sub_id" claim ?
>>
>>>         The subject identifier is whatever identifier the AS knows
>>>         the subject as. If they log in using only a FIDO token and
>>>         the AS asserts that key value as the identifier, then that’s
>>>         what it will be. If they sign up with an email address or
>>>         make a username or get assigned a random number, that’s what
>>>         it will be. Or they could sign up using any number of those
>>>         and the AS still assigns them a random value, because it’s
>>         When looking at Section 3.2 (Access Tokens), the client (and
>>         hence the end-user) has currently /no practical way/ to
>>         indicate which of its attributes should be placed into an
>>         access token,
>>         The only reference within Section 3.2 is pointing to the
>>         empty Section 12. Among the many examples, there is not a
>>         single example that addresses the case of attributes being
>>         placed into an access token.
>>
>>         Nevertheless, it seems that in your opinion, only the AS, but
>>         NOT the client (and hence the end-user), SHALL have control
>>         at all of what kind of /subject identifier/ claim will be
>>         placed inside the access token.
>>
>>         Then after, invoking the postulate "the access token SHALL
>>         remain opaque to the client (and hence the end-user)", it
>>         seems that in your opinion, the end-user SHALL have no way to
>>         verify
>>         architecture built along "spy by design" principles, I don't
>>         know what else it might be.
>>
>>             *Access Toke*n: data artifact representing a set of
>>             rights *a**nd/or attributes*.
>>
>>         In the current draft, the case of rights is indeed addressed
>>         while *the case of attributes is fully ignored*.
>>
>>>         The RS is not involved in any subject information. Identity
>>>         APIs, like OpenID Connect’s UserInfo Endpoint, are out of
>>>         scope for GNAP.
>>
>>         Really ? Do you mean that an access token should not contain
>>         a "sub" claim nor a "sub_id" claim  and if it does, the RS
>>         SHALL ignore such claims ?
>>
>>         In the "OAuth Access Token JWT Profile", there is the
>>         following sentence in Section 6 (Privacy Considerations) :
>>
>>                requests with /data stored locally for the
>>             authenticated principal/.
>>
>>         However, note that the "OAuth Access Token JWT Profile" fails
>>         to allow the client (and hence the end-user) to control his
>>         privacy, since the client
>>         cannot choose which value will be placed in the "sub" claim
>>         and also because access tokens are considered to be opaque
>>         for the clients in OAuth.
>>>         If there is a subject identifier either included in or
>>>         referenced by the access token, that is /up to any
>>>         agreements between the AS and RS/
>>>         that lead to the ability of the AS to create the tokens the
>>>         RS can trust. All of this is outside the scope of the core
>>>         GNAP protocol and invisible to the client.
>>
>>         You are using the following words "/up to any agreements
>>         between the AS and RS/". This mandates prior agreements
>>         between ASs and RSs
>>         and in such a case the architecture will be non-scalable over
>>         the Internet. The trust relationship between a RS and an AS
>>         is unilateral:
>>         From an end-user point of view, if there cannot be
>>         *transparency* because of the access token opacity,**then
>>         there cannot be *confidence *about GNAP .
>>
>>         Denis
>>
>>
>>>          — Justin
>>>
>>>>>         GNAP doesn’t have anything too say about anybody
>>>>>         authenticating directly to the RS. If that happens, it’s
>>>>>         out of the view and out of scope of GNAP.
>>>>>
>>>>>          — Justin
>>>>>
>>>>>>         The content of this thread has nothing to do any more
>>>>>>         with its original title which was: "Will GNAP support
>>>>>>         Zero Trust Architecture?"
>>>>>>         Since I am going to use some sentences of this thread to
>>>>>>         open a new topic, I changed the title of this thread into :
>>>>>>         At the moment, I got the impression that nobody agrees
>>>>>>         any more about *what GNAP is or is not, what it should
>>>>>>         address and what it should not address*.
>>>>>>         The components of the model are becoming more numerous
>>>>>>         and hazy. A new terminology is sometimes being used, but
>>>>>>         is not yet present in the last published draft.
>>>>>>
>>>>>>         I still can't understand any of the new terms that are
>>>>>>         being used (*AS-RS* and *AS-RO*), _which are still left
>>>>>>         undefined_.
>>>>>>
>>>>>>         The last exchanges look more as conversations between
>>>>>>         workers during the construction of the Babel tower.
>>>>>>
>>>>>>         Last year, my first remark was to mention that a section
>>>>>>         or an Annex explaining the common points and the
>>>>>>         differences with OAuth 2.0
>>>>>>             /If an RS allows a username/password HTTP Basic auth
>>>>>>             in addition to accepting access tokens, it can do so,
>>>>>>             but //
>>>>>>             //GNAP doesn’t have anything to say about the Basic
>>>>>>             auth use, or even its relation to any access tokens
>>>>>>             or RO’s or anything else./
>>>>>>
>>>>>>         "/GNAP doesn’t have anything //to say about the Basic
>>>>>>         auth use/":  If an authentication exchange  is necessary,
>>>>>>         the draft document should describe, for completeness,
>>>>>>         anything else/". Let us suppose that a RS supports FIDO
>>>>>>         as an authentication mechanism to authenticate its end-users.
>>>>>>         different identifier is used by every end-user. This
>>>>>>         prevents end-users accounts correlations between RSs by
>>>>>>         using
>>>>>>         authenticate its end-users using FIDO pseudonyms. Now,
>>>>>>         let us raise the following question:
>>>>>>
>>>>>>         How will a RS be bootstrapped for working with a GNAP
>>>>>>         "sub" claim or a "sub_id" claim, whereas FIDO is already
>>>>>>         being used ?
>>>>>>
>>>>>>         Denis
>>>>>>
>>>>>>
>>>>>>>         Adrian,
>>>>>>>
>>>>>>>         I disagree, I believe that what I have laid out is
>>>>>>>         exactly separating the concerns into working components.
>>>>>>>
>>>>>>>         Like OAuth before it, GNAP is a protocol negotiate
>>>>>>>         access for a client instance to an RS, using an AS as
>>>>>>>         the facilitator of that delegated negotiation. (Unlike
>>>>>>>         OAuth, it’s importantly also for negotiating user
>>>>>>>         information to the client directly from the AS with no
>>>>>>>         RS involved, but that’s an aside for the purposes of our
>>>>>>>         conversation here).
>>>>>>>
>>>>>>>         If a particular GNAP RS also allows other kinds of
>>>>>>>         processes to enable access to it, that is completely
>>>>>>>         fine, but outside of GNAP. If an RS allows a
>>>>>>>         username/password HTTP Basic auth in addition to
>>>>>>>         accepting access tokens, it can do so, but GNAP doesn’t
>>>>>>>         have anything to say about the Basic auth use, or even
>>>>>>>         its relation to any access tokens or RO’s or anything
>>>>>>>         else. If an RS accepts structured access tokens signed
>>>>>>>         by trusted keys that don’t come from an AS through a
>>>>>>>         negotiated request — again, that’s fine, but GNAP is
>>>>>>>         silent about the RS doing that. If the RS acts as “its
>>>>>>>         own AS” then it’s really just an RS and an AS living in
>>>>>>>         the same box. Again, that’s fine, and super common with
>>>>>>>         OAuth today.
>>>>>>>
>>>>>>>         GNAP is solving the problem of connecting the client to
>>>>>>>         the RS through means of an AS. Other solutions are
>>>>>>>         possible and many of them can be deployed right
>>>>>>>         alongside, but that’s not the corner of the world that
>>>>>>>         GNAP is solving. GNAP should be concerned about how
>>>>>>>         these other technologies can be used alongside it. I
>>>>>>>         think there’s a lot of room for the things that you’re
>>>>>>>         talking about, and more importantly for solving the use
>>>>>>>         cases that you’re bringing. But GNAP should be more than
>>>>>>>         a single-point solution, and so we need to balance these
>>>>>>>         concerns. The conceptual framework of an AS that takes
>>>>>>>         in lots of different information and spits out access
>>>>>>>         tokens is exactly the abstraction layer that is
>>>>>>>         necessary for making these use cases interoperable.
>>>>>>>
>>>>>>>          — Justin
>>>>>>>
>>>>>>>>         minimization. And, I see no obvious reason to make this
>>>>>>>>         the core of GNAP.
>>>>>>>>
>>>>>>>>         The core of GNAP, in my opinion, can be built and
>>>>>>>>         explained around this simple design. The RS is a
>>>>>>>>         processor. The RO is a controller. The RS bears only
>>>>>>>>         security responsibility. The RS bears no privacy
>>>>>>>>         responsibility. The RO delegates this to the RS but
>>>>>>>>         this is not authorization as the A in GNAP.
>>>>>>>>
>>>>>>>>         The RO retains all rights to delegate within the scope
>>>>>>>>         of things that the RS is willing to support using
>>>>>>>>         various token formats and endpoint options. Some of
>>>>>>>>         these options may do all sorts of things for all sorts
>>>>>>>>         of clients and user-agents  but these are options.
>>>>>>>>
>>>>>>>>         For example, if a request comes to the RS that is not
>>>>>>>>         in the form of an access token, then it either gets
>>>>>>>>         sent to the RO or their agent, or it gets logged and
>>>>>>>>         dumped. One such option, common in healthcare, is
>>>>>>>>         “Break the Glass” where the RS is acting as an
>>>>>>>>         authorization server because the user-agent is making a
>>>>>>>>         request instead of presenting an access token. GNAP can
>>>>>>>>         offer this as an option but it is not our core.
>>>>>>>>
>>>>>>>>         Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>             > the RS and AS-RS only see access tokens. The
>>>>>>>>             requests (from RO') that resulted in an access
>>>>>>>>             token are none of their business.
>>>>>>>>
>>>>>>>>             In the trust model we’ve been discussing, the
>>>>>>>>             requests that result in access tokens are *solely
>>>>>>>>             the business of AS-RS*, since AS-RS is the only
>>>>>>>>             entity that’s allowed, and trusted by the RS, to
>>>>>>>>             create access tokens for the RS. That is its entire
>>>>>>>>             job, the entire reason it exists in the system. By
>>>>>>>>             definition the party generating tokens for use at
>>>>>>>>             the RS is the AS for that RS, I don’t care how you
>>>>>>>>             deploy it. If RO wants to give access to someone
>>>>>>>>             end-user), then that end user’s client software
>>>>>>>>             will need to talk to AS-RS to get its own access
>>>>>>>>             token.
>>>>>>>>
>>>>>>>>             instance talks to AS-RS, that does NOT mean that
>>>>>>>>             AS-RS needs to know all the details and policy
>>>>>>>>             reasons that it should give an access token to that
>>>>>>>>             client instance. It doesn’t even need to know the
>>>>>>>>             existence of another end user. It doesn’t need
>>>>>>>>             identity, it doesn’t need policy. Sure, it COULD
>>>>>>>>             handle all of that internally, and many will, but
>>>>>>>>             the protocol doesn’t demand it.
>>>>>>>>
>>>>>>>>             This means that the first client instance, the one
>>>>>>>>             that gets the access token, can also be given
>>>>>>>>             something alongside the access token that it can
>>>>>>>>             then hand to another piece of software (or to a
>>>>>>>>             person to hand eo their piece of software). This
>>>>>>>>             artifact is not an access token. This artifact
>>>>>>>>             could be something structured that the client
>>>>>>>>             understands, and can make derivatives of, and
>>>>>>>>             present back to the AS-RS for getting new access
>>>>>>>>             tokens. There could be multiple different flavors
>>>>>>>>             of this kind of artifact for different kinds of
>>>>>>>>             environments and groups. But what they all have in
>>>>>>>>             common is that they can potentially be used to
>>>>>>>>             request more access tokens within some context at
>>>>>>>>             the AS-RS.
>>>>>>>>
>>>>>>>>              — Justin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>                 "7. Another user agent (RO') can contact any
>>>>>>>>>                 holder of the access token or the service's
>>>>>>>>>                 policy agent (AS-RS) to get a delegated access
>>>>>>>>>                 token."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             I would prefer "7A.Another user agent (RO') can
>>>>>>>>>             contact any holder of the access token." by
>>>>>>>>>             default so that the AS-RS does not see the
>>>>>>>>>             requests. In other words, the RS and AS-RS only
>>>>>>>>>             see access tokens. The requests (from RO') that
>>>>>>>>>             The reality is that RO' can discover a resource RS
>>>>>>>>>             and can share whatever information with RS-AS they
>>>>>>>>>             want and the RO may not even know about it unless
>>>>>>>>>             the RS decides to let them know somehow. This
>>>>>>>>>             seems to be a drawback of the capabilities approach.
>>>>>>>>>
>>>>>>>>>             In terms of privacy and control, I, as the RO,
>>>>>>>>>             want a contract with the RS that says that I or my
>>>>>>>>>             agent (AS-RO) must sign an access token. This is a
>>>>>>>>>             fundamental audit requirement. Without it, a rogue
>>>>>>>>>             RS and AS-RS can do all sorts of things and the RO
>>>>>>>>>             would never know. I understand that a rogue RS
>>>>>>>>>             might not support an honest contemporaneous log of
>>>>>>>>>             access tokens presented so there's a trust issue
>>>>>>>>>             here that I seems unavoidable unless I specify in
>>>>>>>>>             my RO-RS contract that they use a separate
>>>>>>>>>             contemporaneous log such as AS-RO for every access
>>>>>>>>>             token presented and risk being sued if they
>>>>>>>>>                     itself, the RO is the :entity: in charge
>>>>>>>>>                     of approving rights. They’re probably a
>>>>>>>>>                     person. It might be software that makes a
>>>>>>>>>                     policy decision in some way, or a
>>>>>>>>>                     corporate entity, or something like that.
>>>>>>>>>                     But it’s not assumed to be a computational
>>>>>>>>>                     agent in the terms of the protocol itself.
>>>>>>>>>                 Hmmm.  I guess not. It's just that the person
>>>>>>>>>                 would be using some UI to express their
>>>>>>>>>                 decisions to what I called the user agent. 
>>>>>>>>>                 That model fits in very nicely with what we
>>>>>>>>>                 did with Polaris, our virus safe computing
>>>>>>>>>                 The person would click on the icon for a Word
>>>>>>>>>                 file, and an instance of Word would open with
>>>>>>>>>                 only the permission needed to edit that one
>>>>>>>>>                 file.  Same thing here. The client could ask
>>>>>>>>>                 for permission to use the resource, or
>>>>>>>>>                 permission could be granted implicitly when
>>>>>>>>>                 the user selects a resource associated with a
>>>>>>>>>                 specific client.
>>>>>>>>>
>>>>>>>>>                 --------------
>>>>>>>>>                 Alan Karp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                     itself, the RO is the :entity: in charge
>>>>>>>>>                     of approving rights. They’re probably a
>>>>>>>>>                     person. It might be software that makes a
>>>>>>>>>                     policy decision in some way, or a
>>>>>>>>>                     corporate entity, or something like that.
>>>>>>>>>                     But it’s not assumed to be a computational
>>>>>>>>>                     agent in the terms of the protocol itself.
>>>>>>>>>>                     probably because of the "AS" part. I'm
>>>>>>>>>>                     going to try to clear up that confusion
>>>>>>>>>>                     by more carefully explaining what I mean.
>>>>>>>>>>
>>>>>>>>>>                     I'm assuming that RO is a computational
>>>>>>>>>>                     agent representing the person who is the
>>>>>>>>>>                     resource owner, something called the
>>>>>>>>>>                     "user agent" in operating systems lingo. 
>>>>>>>>>>                     I'm also assuming that it's possible to
>>>>>>>>>>                     do delegation, either locally or by token
>>>>>>>>>>                     exchange with AS-RS.  All delegations are
>>>>>>>>>>                     potentially sub-scoped, but you may also
>>>>>>>>>>                     want to delegate with full scope to have
>>>>>>>>>>                     a separately revocable access token.
>>>>>>>>>>
>>>>>>>>>>                      2. The service owner contracts with an
>>>>>>>>>>                         policy agent (AS-RS) to create and
>>>>>>>>>>                         manage access tokens for that service
>>>>>>>>>>                         (RS).
>>>>>>>>>>                      3. A person wishing to create a resource
>>>>>>>>>>                         at RS uses their user agent (RO) to
>>>>>>>>>>                         contact the service owner's policy
>>>>>>>>>>                         agent (AS-RS) and gets back an access
>>>>>>>>>>                         token for that resource.
>>>>>>>>>>                      5. A client can contact any holder of
>>>>>>>>>>                         the access token (the user agent (RO)
>>>>>>>>>>                         or its policy agent (AS-RO)) or the
>>>>>>>>>>                         service's policy agent (AS-RS) to get
>>>>>>>>>>                         a delegated access token.
>>>>>>>>>>                      7. Another user agent (RO') can contact
>>>>>>>>>>                         any holder of the access token or the
>>>>>>>>>>                         service's policy agent (AS-RS) to get
>>>>>>>>>>                         a delegated access token.
>>>>>>>>>>                     When any of these computational agents,
>>>>>>>>>>                     user agents (ROs) or clients acting on
>>>>>>>>>>                     their behalf, invokes the resource, AS-RS
>>>>>>>>>>                     verifies that the access token is a valid
>>>>>>>>>>                     delegation, i.e., proper sub-scoping,
>>>>>>>>>>                     hasn't been revoked, and that it
>>>>>>>>>>                     authorizes the request being made before
>>>>>>>>>>                     telling the service (RS) to honor the
>>>>>>>>>>                     policy agent (AS-RS) know which
>>>>>>>>>>                     computational agent did any particular
>>>>>>>>>>                     particular, the policy agents (AS-RO)
>>>>>>>>>>                     need not be the same, or even compatible
>>>>>>>>>>                     with, the service's policy agent
>>>>>>>>>>                     (AS-RS).  GNAP specifies the protocol
>>>>>>>>>>                     between requesters, invokers, delegators
>>>>>>>>>>                     (for token exchange) of tokens and
>>>>>>>>>>                     AS-RS.  That protocol need not be used
>>>>>>>>>>                     between user agents (RO), clients, or
>>>>>>>>>>                     On Thu, Mar 25, 2021 at 5:45 AM Justin
>>>>>>>>>>                     Richer <[email-masked]
>>>>>>>>>>                         the “AS-RO” isn’t an “AS” in the
>>>>>>>>>>                         traditional OAuth/GNAP sense, at
>>>>>>>>>>                         traditionally, it’s what the RS
>>>>>>>>>>                         trusts to issue tokens. In
>>>>>>>>>>                         traditional OAuth the AS-RO and AS-RS
>>>>>>>>>>                         client’s perspective, they’re only
>>>>>>>>>>                         talking to the AS-RS since that’s
>>>>>>>>>>                         where the client gets its tokens,
>>>>>>>>>>                         because at the end of the day the
>>>>>>>>>>                         client just wants to call the API at
>>>>>>>>>>                         the RS and doesn’t care how that
>>>>>>>>>>                         authorization server at all, I’m
>>>>>>>>>>                         going to keep using that term below
>>>>>>>>>>                         for consistency with previous discussion.
>>>>>>>>>>
>>>>>>>>>>                         So we have these fundamental
>>>>>>>>>>                         relationships around getting the
>>>>>>>>>>                         client to access the RS:
>>>>>>>>>>
>>>>>>>>>>                         1. RS trusts AS-RS to issue tokens
>>>>>>>>>>                         that RS will accept, validate, and
>>>>>>>>>>                         process for requests from client
>>>>>>>>>>                         On top of that, we’ve got some
>>>>>>>>>>                         additional aspects that we’re discussing:
>>>>>>>>>>
>>>>>>>>>>                         client to deal with, including
>>>>>>>>>>                         runs things, and I think this also
>>>>>>>>>>                         maps with Adrian’s view of choice,
>>>>>>>>>>                         would be motivated to pick a
>>>>>>>>>>                         different RS who’s AS-RS lets me do
>>>>>>>>>>                         just that. The same way I’d pick a
>>>>>>>>>>                         different RS if their surrounding
>>>>>>>>>>                         services didn’t accept my preferred
>>>>>>>>>>                         federation login and I didn’t want to
>>>>>>>>>>                         make another account. Of course,
>>>>>>>>>>                         market forces being as they are, I
>>>>>>>>>>                         philosophy of the protocol design and
>>>>>>>>>>                         in concrete hooks to support (6) above.
>>>>>>>>>>
>>>>>>>>>>                         This was UMA2’s “federated
>>>>>>>>>>                         authorization” approach, and is
>>>>>>>>>>                         behind a lot of the “bring your own
>>>>>>>>>>                         AS” models out there. The problem
>>>>>>>>>>                         with these is that we know from many
>>>>>>>>>>                         years of experience that most RS’s
>>>>>>>>>>                         details of every permutation of (5)
>>>>>>>>>>                         to enable this, though. Some of this
>>>>>>>>>>                         is going to be configuration out of
>>>>>>>>>>                         band, some of it’s going to be
>>>>>>>>>>                         communication at runtime. This is
>>>>>>>>>>                         where VC’s, ZCAPs, CHAPI, DIDComm,
>>>>>>>>>>                         FIDO, and a whole swath of other tech
>>>>>>>>>>                         can come in and help out. I don’t
>>>>>>>>>>                         think we need to put all the details
>>>>>>>>>>                         for using these into core, nor do I
>>>>>>>>>>                         think we’ll pull of The Great And
>>>>>>>>>>                         Ultimate Abstraction for using these
>>>>>>>>>>                         and other approaches. But we can at
>>>>>>>>>>                         least start talking about “AS-RS” in
>>>>>>>>>>                         such a way that it no longer assumes
>>>>>>>>>>                         it’s always the same party dealing
>>>>>>>>>>                         with the RO directly.
>>>>>>>>>>
>>>>>>>>>>                          — Justin
>>>>>>>>>>
>>>>>>>>>>>                         - AS = AS-RO, that's where you find
>>>>>>>>>>>                         the RO policies. The AS issues
>>>>>>>>>>>                         access tokens to the client.
>>>>>>>>>>>                         - the RO policies could be a)
>>>>>>>>>>>                         defined locally or b) in
>>>>>>>>>>>                         relationship with the RS
>>>>>>>>>>>
>>>>>>>>>>>                         b1) the RS issues capabilities
>>>>>>>>>>>                         (which can be further attenuated by
>>>>>>>>>>>                         the RO)

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 29 Mar 2021 14:37:51 -0400

Here's an example:
https://www.governor.ny.gov/news/governor-cuomo-announces-pilot-program-testing-excelsior-pass-madison-square-garden-and

Bob is manning the gate at Madison Square Garden.

Adrian

On Mon, Mar 29, 2021 at 1:19 PM Denis <[email-masked]> wrote:

>> large random number *chosen by the RS*.
>>
>>> "*GNAP doesn’t have anything **to say about the Basic auth use*":  If