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

[[e-mail]]

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
> https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/25 as a
> pointer.

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