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

[Adrian Gropper <[e-mail]>]

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 <[e-mail]> wrote:

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