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

[Justin Richer <[e-mail]>]

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, [e-mail] wrote:
> 
> 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
> 
> -- 
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth