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

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> a
écrit :

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