Subject: [GNAP] Distinct role used by End-user to give permissions to client instances.

From: [email-masked]
Date: Fri, 03 Sep 2021 08:55:06 -0500

Hello,

I'm participating in AuthN and AuthZ related work of 
https://solidproject.org/

I will intentionally keep this email short and provide further details 
based on responses.
Given that I'll try to focus on one problem we are trying to address and 
we can start zooming out from there as needed.

In our scenarios different End-user and Resource Owner is very common 
scenario.
We are working on few proposals for handing User Authorization, in that 
case ACME organization (Resource Owner) could authorize Alice (End-user) 
to access specific data.
In the same way ACME authorizes Bob (another End-user) to access some 
specific data. Data that Alice and Bob can access have certain overlap.

Now both Alice and Bob should be able to independently permission / 
authorize various applications (Client instances) they wan to access 
that data owned by ACME.
In fact both Alice and Bob have broader peer networks, including other 
Organizations and Individuals. We are also defining common permission 
model,
which would allow expressing application access to span across data 
owned by any number of owners.

In the scenario above, we consider assumption that given Resource Owner 
owns all the data on given Resource Server.
In that case Authorization Server which issues Access Tokens stays 
associated with RS, so also with specific Resource Owner.
Since each End-user needs some party which would take responsibility for 
them to give consent and permission apps (Client instances) they are 
using.
We look at another role let's just call it EUXS (End-user's X Server), 
similar to OIDC Provider. It stays associated with End-user in similar 
way to rel="http://openid.net/specs/connect/1.0/issuer" links to OP.

 From here it would be really great to see how GNAP would help handing 
following:

End-user's X Server, in a similar way to OIDC Provider, issues at token 
(let's call it a permissions token) to Client instance representing 
permissions applicable to a specific RS.
Once again very often that RS is controlled by Resource Owner other than 
End-user.
Client instance uses that 'permissions' token with AS to get Access 
Token which finally can be used when making requests to RS.
Here I make assumption that AS understands that permissions token and 
later either makes it available to RS or translates it to something that 
RS can enforce.
Oh, also RS would hint their AS with as_uri in WWW-Authenticate, since 
client doesn't have that prior knowledge.

As I mentioned User Authorization is handled separately so AS & RS have 
prior knowledge of what access Resource Owner granted to End-user.
In this email I mostly focus on End-user having another party associated 
with them (EUXS for the sake of this discussion) where they
can further delegate that access their received to apps (Client 
instances) which they want to use to exercise access to data.

I hope description above is sufficient to roughly illustrate the 
scenario. I can fill in more details as needed.

I very much appreciate any hints on how GNAP can handle described 
scenario in elegant way.

Best regards,
elf Pavlik

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 3 Sep 2021 15:50:31 -0400

An interesting use-case. One way to discuss the protocol issues is from a
transparency perspective.

If the RS / RO is presumed to be operating as a (regulated or informal)
fiduciary with no conflict of interest for its own profit, then both Alice
and Bob should have total transparency on what is actually shared with the
other. That transparency and potentially semi-autonomous behavior would be
managed by the respective EUXS agents.

If the RS / RO is truly acting as an RO and owes relatively little to Alice
and Bob, then the protocol would be easier because the EUXS would have less
information to work with. In the limit, Alice’s EUXS would not even be
notified of Bob’s access to the shared RS.

Notification as part of an authorization protocol is, in my experience with
UMA 2, an option. Even when the RO is the subject and separate from the RS,
the RS may override the scope of an access token. This could be due to
security (e.g. DoS attack) or jurisdictional constraints (cross-border
clients). In these cases, transparency demands that the RS notify the RO or
the AS of the exception.

- Adrian

On Fri, Sep 3, 2021 at 9:57 AM <[email-masked]> wrote:

> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 4 Sep 2021 09:35:05 +0200

Hi Elf,

Indeed that's interesting. I'm not entirely sure I get all the ins and outs
of what you're trying to do, but I'll give a first answer based on my
limited understanding.

In GNAP section 4 (of the core spec) theorically allows the case when the
end-user and the RO are different. The details of how that would work in
still quite thin (and the rest of section 4 considers only the case when
they're the same).

Seems to me that your use case is also relatively close to having to manage
several ASs, with one that's associated to the RS (a case entirely made
possible in GNAP) and one handling permissions tokens (to take your
wording). Similar scenarii have been discussed in the past. Currently we
assume in GNAP core that there's only one AS involved, but it's entirely
possible that an extension would really get into the weeds of how more
complex cases would work. That's kind of the spirit behind the RS part of
the spec, and the entire discussion on capabilities. Please see
https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/25 as a
pointer.

Now to answer your question in detail, I guess we'd need to map the flows
and see how that goes.

Cheers
Fabien

Le ven. 3 sept. 2021 à 21:50, Adrian Gropper <[email-masked]> a
écrit :

> If the RS / RO is truly acting as an RO and owes relatively little to
> Alice and Bob, then the protocol would be easier because the EUXS would
> have less information to work with. In the limit, Alice’s EUXS would not
> even be notified of Bob’s access to the shared RS.
>
> Notification as part of an authorization protocol is, in my experience
> with UMA 2, an option. Even when the RO is the subject and separate from
> the RS, the RS may override the scope of an access token. This could be due
> to security (e.g. DoS attack) or jurisdictional constraints (cross-border

---

From: [email-masked]
Date: Sat, 04 Sep 2021 09:43:12 -0500

Hi Adrian, Fabien,

Thank you for your responsens!

> If the RS / RO is truly acting as an RO and owes relatively little
> to Alice and Bob, then the protocol would be easier because the EUXS
> would have less information to work with. In the limit, Alice’s
> EUXS would not even be notified of Bob’s access to the shared RS.

I think I'm discussing this case. Here both End-users Alice and Bob
each one has EUXS they choose to use. Similar to how each Alice and Bob
can choose their OIDC Provider.
When ACME (RO) sets access policy, they grant access to End-users like 
Alice (EU) and Bob (EU)
and let them permission clients independently using their EUXSs.
We work on notification system so that Alice's EUXS would get notified
when ACME shared access with Alice. When ACME shares access with Bob
Alice's EUXS has NO knowledge of that happening, only Bob's EUXS
will get notified.

>> Notification as part of an authorization protocol is, in my
>> experience with UMA 2, an option.

Yes, as I mentioned when RO gives access to some EU, that EUXS of that 
EU gets
notified. To clarify, similar as OIDC Provider, EUXS can be discovered 
for any EU.

> In GNAP section 4 (of the core spec) theorically allows the case when
> the end-user and the RO are different. The details of how that would
> work in still quite thin (and the rest of section 4 considers only the
> case when they're the same).

In the scenarios we work with, different EU and RO is a very common 
case.
Here I'm trying to focus on most common scenario where RO sets access 
policies
only based on identities of EUs (In our case IRIs are used to identify 
EUs).
Later EUs, independently from RO, can permission clients they are using.
In the end RS and AS associated with it, the one that RS hints in
WWW-Authenticate using as_uri, need to take into account policy set by 
RO
which determines access for given EU, as well as permissions given by EU 
to
the Client. Mentioned

> Seems to me that your use case is also relatively close to having to
> manage several ASs, with one that's associated to the RS (a case
> entirely made possible in GNAP) and one handling permissions tokens
> (to take your wording). Similar scenarii have been discussed in the
> past. Currently we assume in GNAP core that there's only one AS
> involved, but it's entirely possible that an extension would really
> get into the weeds of how more complex cases would work. That's kind
> of the spirit behind the RS part of the spec, and the entire
> discussion on capabilities. Please see

I think we would always have specific AS associated with RS. Again RS 
advertises it
via WWW-Authenticate as_uri . It issues Access Token which client is 
using with that RS.

I probably haven't mentioned that in our scenario End-user is using 
client to seamlessly
access resources in any number of Resource Servers, where each RS can be 
controlled by different RO.
Client would keep track of which Access Token should be used with which 
RS.
For that reason we also don't expect client to redirect EU to any of RS 
associated ASs.
EU would only give consent to the client at their EUXS.

Suggested EUXS would be something closer to OIDC Provider. It stays 
associated
with EU, similar to rel="http://openid.net/specs/connect/1.0/issuer".
EUXS keeps track of all the data that any number of ROs shared with the 
EU. Based on that it presents
consent screen to EU where they can decide which of that data they want 
to access using given client.
As I mentioned, EU shouldn't interact with any of RS associated ASs.
Client should be able to get 'permissions token' from EUXS for each 
distinct RS
(each RS can be in control of different RO). Later Client would exchange 
that 'permissions token'
with AS associated with RS that this token was created for. This should 
happen without End-user
interaction.

Probably it can be useful to discuss it in terms of delegation chains.

1. ACME (RO) delegates some access to Alice (EU)
2. Alice (EU) further delegates some of the access, which she received 
from ACME (RO), to a Projectron (Client)

More advanced case, which I intentionally tried not to start with would 
allow longer chains

1. ACME (RO) delegates some access to Omni (EU-ish) - Omni another 
organization
2. Omni (EU-ish) further delegates some access their received from ACME 
(RO) to Alice (EU)
3. Alice (EU) further delegates some access, which she received from 
Omni (EU-ish),
    which they received from ACME (RO), to a Projectron (Client)

Having just one RO associated with any RS probably makes both scenarios 
simpler.

Again I think only RS associated AS should issue Access Token that it's 
used with RS.
EUXS would issue 'permission tokens', similar to OIDC Provider issuing 
ID Tokens.
I imagine those 'permission tokens' later being exchanged with RS 
associated AS
without End-user interaction.

BTW I think this comment in mentioned issue provides a useful hint.

> If an AS receives and processes an access token, it is acting as an RS.
> There are two transactions at the same time and one entity plays 
> different roles in each.
> If an RS requests a token in response to an incoming request, that RS 
> is now a client instance.

> Now to answer your question in detail, I guess we'd need to map the
> flows and see how that goes.

I have some sequence diagrams which I can adjust to illustrate discussed 
scenario better.
I will also try to clarify there which role any given party plays in 
each interaction.
I'll write a followup message once I have them ready.

Thank you for all your feedback!
elf Pavlik

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Sep 2021 16:46:45 -0400

Hi elf, thanks so much for the detailed writeup. I’d like to add some of my thoughts to this discussion, and hopefully I’m following your use case correctly. Please correct me if I’m off at all!

I believe the scenario you’re describing is in line with the more-general descriptions around “user interaction and consent” that are described in section 4 of GNAP’s current draft. While I agree that some sequence diagrams would be helpful, this is what I’m picturing in your scenario, mapped to GNAP’s messages and terms:

Phase 1: Client Instance makes a request to EUXS for an assertion representing the current user. The nature and format of this assertion are out of scope for GNAP itself, but would be in the purview of Solid’s profile of the technologies — for now we’ll call this a Solid Assertion Token (SAT) within this description. A JWT would be a reasonable carrier for such an assertion. What GNAP offers is a standard way for the client instance to request this assertion and have it delivered directly. We’re assuming that the end user interacts with or otherwise associates with the EUXS so that the EUXS knows who the end user is. Or possibly, the EUXS knows that the client in question has already been authorized and can issue the SAT directly. GNAP allows for both scenarios to come out of the same request message, allowing for a clean fallback in different situations.

Phase 2: Client instance talks to the AS that controls access to the RS. The client instance presents the SAT as part of its “user” information field in the request. The AS validates the SAT based on Solid’s rules. The AS contacts the RO to get permission for the client instance on the end user’s behalf. How that happens is up to the AS, but the SAT would likely have some kind of RO identifier within it: namely representing what’s being requested, not who the SAT was issued to. Or it could be based on the RS and permissions the client instance is asking for — so the client instance and end user wouldn’t necessarily know who the RO was at all, just that they want access to the RS and it’s controlled by … someone. Once the RO approves it, the AS issues the access token to the client instance.

Phase 3: Client instance calls the RS with the access token from AS. It may or may not contain any information from the SAT, since the only thing the RS ultimately needs to know is if the token is good for the request being made. Solid can further profile the access token itself (either its format or its introspected data) to convey specific information. GNAP remains agnostic on this decision, but provisions for standardizing these elements are in the GNAP-RS document.

An alternative process inverts some of the phases:

Phase 1 (alt): Client instance talks to the AS to get access and says it can interact with the end user through the EUXS and get an assertion (SAT) as a result. The AS passes whatever information it needs to complete this back to the client instance. The end user interacts at EUXS to get the SAT generated and handed back to the client instance.

Phase 2 (alt): Client instance presents the SAT back to the AS, which then goes on to talk to the RO, wherever they are.

Phase 3 continues as above.

Do either of these processes align with what you had in mind, or am I missing some important subtleties to this use case? We’ve discussed both of these patterns here in the WG before and accommodations for them are built into the GNAP core protocol: both what it defines and what it allows but keeps out of scope of the core protocol definitions. 

 — Justin

> On Sep 4, 2021, at 10:43 AM, [email-masked] wrote:
> 
> Hi Adrian, Fabien,
> 
> When ACME (RO) sets access policy, they grant access to End-users like Alice (EU) and Bob (EU)
> Yes, as I mentioned when RO gives access to some EU, that EUXS of that EU gets
> notified. To clarify, similar as OIDC Provider, EUXS can be discovered for any EU.
> 
> 
> In the scenarios we work with, different EU and RO is a very common case.
> Here I'm trying to focus on most common scenario where RO sets access policies
> only based on identities of EUs (In our case IRIs are used to identify EUs).
> WWW-Authenticate using as_uri, need to take into account policy set by RO
> which determines access for given EU, as well as permissions given by EU to
> the Client. Mentioned
> 
> 
> I think we would always have specific AS associated with RS. Again RS advertises it
> via WWW-Authenticate as_uri . It issues Access Token which client is using with that RS.
> 
> I probably haven't mentioned that in our scenario End-user is using client to seamlessly
> access resources in any number of Resource Servers, where each RS can be controlled by different RO.
> Client would keep track of which Access Token should be used with which RS.
> For that reason we also don't expect client to redirect EU to any of RS associated ASs.
> Suggested EUXS would be something closer to OIDC Provider. It stays associated
> EUXS keeps track of all the data that any number of ROs shared with the EU. Based on that it presents
> consent screen to EU where they can decide which of that data they want to access using given client.
> Client should be able to get 'permissions token' from EUXS for each distinct RS
> (each RS can be in control of different RO). Later Client would exchange that 'permissions token'
> with AS associated with RS that this token was created for. This should happen without End-user
> interaction.
> 
> 2. Alice (EU) further delegates some of the access, which she received from ACME (RO), to a Projectron (Client)
> 
> More advanced case, which I intentionally tried not to start with would allow longer chains
> 
> 1. ACME (RO) delegates some access to Omni (EU-ish) - Omni another organization
> 2. Omni (EU-ish) further delegates some access their received from ACME (RO) to Alice (EU)
> 3. Alice (EU) further delegates some access, which she received from Omni (EU-ish),
> Having just one RO associated with any RS probably makes both scenarios simpler.
> 
> Again I think only RS associated AS should issue Access Token that it's used with RS.
> EUXS would issue 'permission tokens', similar to OIDC Provider issuing ID Tokens.
> I imagine those 'permission tokens' later being exchanged with RS associated AS
>> There are two transactions at the same time and one entity plays different roles in each.
>> If an RS requests a token in response to an incoming request, that RS is now a client instance.
> 
> 
> 
> I have some sequence diagrams which I can adjust to illustrate discussed scenario better.
> I will also try to clarify there which role any given party plays in each interaction.

---

From: [email-masked]
Date: Wed, 15 Sep 2021 22:04:19 -0500

Hi Justin,

Thank you for your in-depth reply!
I'll try to respond in-line.

> Phase 1: Client Instance makes a request to EUXS for an assertion
> representing the current user. The nature and format of this assertion
> are out of scope for GNAP itself, but would be in the purview of
> Solid’s profile of the technologies — for now we’ll call this a Solid
> Assertion Token (SAT) within this description. A JWT would be a
> reasonable carrier for such an assertion. What GNAP offers is a
> standard way for the client instance to request this assertion and
> have it delivered directly. We’re assuming that the end user interacts
> with or otherwise associates with the EUXS so that the EUXS knows who
> the end user is. Or possibly, the EUXS knows that the client in
> question has already been authorized and can issue the SAT directly.
> GNAP allows for both scenarios to come out of the same request
> message, allowing for a clean fallback in different situations.

I haven't mentioned it (trying to start as simple as possible), but we 
consider
possibility of having separate IdP and EUXS.
The IdP would stay in line with OIDC and issue assertion representing 
the current end-user.
Trying to follow your naming we could call it Solid Identity Assertion 
Token (SIAT)
The EUXS would stay responsible for issuing an assertion representing
'permissions' - what access end-user delegates to the given client 
instance.
We could call this one Solid Permissions Assertion Token (SPAT)

While we evaluate defining separate IdP and EUXS, we also want to
support combined IdP+EUXS which could combine user interaction
into a single flow.

So far I think both IdP and EUXS act as AS. Until now also the
End-user acts as RO who controls issurance of both assertion SIAT and 
SPAT.

> 
> Phase 2: Client instance talks to the AS that controls access to the
> RS. The client instance presents the SAT as part of its “user”
> information field in the request. The AS validates the SAT based on
> Solid’s rules. The AS contacts the RO to get permission for the client
> instance on the end user’s behalf. How that happens is up to the AS,
> but the SAT would likely have some kind of RO identifier within it:
> namely representing what’s being requested, not who the SAT was issued
> to. Or it could be based on the RS and permissions the client instance
> is asking for — so the client instance and end user wouldn’t
> necessarily know who the RO was at all, just that they want access to
> the RS and it’s controlled by … someone. Once the RO approves it, the
> AS issues the access token to the client instance.

The SPAT would indeed contain information about what client can access
on a given RS. Actually EUXS would most likely need to issue one SPAT
per RS that End-user wants to access using the client.

Currently we look at approache where RS has only one RO which has
full control over all the Protected Resources on that RS.

At the sime time End-user will be using the client to access resources
across any number of Resource Servers, where each RS can be in control
of different RO.

Having one SPAT per RS should preven any undesired leak of information
across those different Resource Servers.

What I need to emphasis here, RO who controls given RS, doesn't really
get involved in authorizaing client instances (unless they also act as
End-user of that client). RO grants access directly to End-user,
than End-user can authorize/permission clients they use via EUXS,
independently of RO associated with RS.

Here also EUXS is responsible for authenticating the client,
AS associated with RS relies on client identity from SPAT.

When it comes to flow where End-user wants to request access to
resources on RS (RO != End-user). We consider their EUXS would
handle it for them. Once the End-user has access, they can delegate
it to any clients they want to use to excercise it.

> 
> Phase 3: Client instance calls the RS with the access token from AS.
> It may or may not contain any information from the SAT, since the only
> thing the RS ultimately needs to know is if the token is good for the
> request being made. Solid can further profile the access token itself
> (either its format or its introspected data) to convey specific
> information. GNAP remains agnostic on this decision, but provisions
> for standardizing these elements are in the GNAP-RS document.

Yes, I think this part seems straight forward.

> Phase 1 (alt): Client instance talks to the AS to get access and says
> it can interact with the end user through the EUXS and get an
> assertion (SAT) as a result. The AS passes whatever information it
> needs to complete this back to the client instance. The end user
> interacts at EUXS to get the SAT generated and handed back to the
> client instance.

I need to think further about this flow. Currently we focus mostly
on flow where client starts 'following their nose' from End-user
identiy, discovers their IdP and EUXS (this information is public).
Later EUXS provides an entry point which has index of all the data
across all ther RS that End-user wants to access using given client.
Given above client interacts with EUXS before interacting with any
RS and disovering AS that controlls access to it.

> 
> Do either of these processes align with what you had in mind, or am I
> missing some important subtleties to this use case? We’ve discussed
> both of these patterns here in the WG before and accommodations for
> them are built into the GNAP core protocol: both what it defines and
> what it allows but keeps out of scope of the core protocol
> definitions.

Yes I think it's pretty close. I hope I was able to highlight
additional nuances above.

Thank you again for taking your time to patiently disect
scenarios I'm working with.

Best regards,
elf Pavlik