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

[[e-mail]]

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.

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

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