Privilege Request Protocol is not reusable across Solid; only covers one very specific case

[RubenVerborgh]

No description provided.

[justinwb]

I agree with @RubenVerborgh in that we should look at the different options in our toolset to support this. It would be worthwhile to further document and then compare the merits of this approach against the protocol suggested by @zenomt.

One caveat is that using LDN for this would require mechanisms for verifying the source of the notification message to ensure that submitted privilege requests are coming from verified sources (so someone cannot spoof a privilege access request).

[zenomt]

I do not think its current mechanism is a good fit with the REST architectural style

i disagree with this assessment.

what i'm calling the "privilege request endpoint" is essentially an inbox to which one posts a request. the inbox URI is (or should be) a capability, but is not itself a verb.

the location of this inbox is discovered via hypermedia (in a Link header).

you make a request for additional privilege by POSTing a representation of your request (encoded as media type application/x-www-form-urlencoded instead of an RDF serialization) to this inbox.

in the successful case, you receive a representation of the acceptance (HTTP 204) of your request along with potentially a hypermedia link for a necessarily non-REST user interface.

this is as HATEOAS as it gets. it could be a little more Solid if the permission request and response representations were RDF (maybe Turtle or JSON-LD) instead of application/x-www-form-urlencoded and plain JSON.

[zenomt]

preface: privilege-request-protocol was designed to be a simple and general solution to a general HTTP problem ("i don't seem to have access to this resource... but maybe i could!") and as it stands is general enough to cover the Solid use case without being Solid-specific, while being as simple as possible (but not simpler). i intended it to be able to go the IETF eventually.

changing the order of your bullets a little.

any objections to

• defining RDF representations instead?

for the permission request payload, i would have no objection to defining an RDF representation, except that by not having it be application/x-www-form-urlencoded (or multipart/form-data, or text/plain), the request would require a CORS preflight. since the user of the link would need to know the vocabulary anyway (even with RDF and shapes), its representation in a simple-request-compatible media type doesn't violate REST principles. CORS is the reason i chose application/x-www-form-urlencoded even though it made me a little sad.

for the response payload, i think it's a fine idea for it to be JSON-LD, but minimal/simple (that is, adding a @context key for the vocabulary so that it's self-describing, but making it so a simple client that knows the vocabulary can get to the permission management page's URI with a simple JSON key→string lookup without having to understand JSON-LD).

• reusing the LDN inbox mechanism as-is?

i think this implies different operational semantics than my proposal, and would be a substantially different protocol (or i'm missing something). i think a concrete proposal, that works through use cases and with a representative example, would help me understand exactly what you mean and would aid discussion.

[pmcb55]

I do not think its current mechanism is a good fit with the REST architectural style
i disagree with this assessment.

Oh dear. The classic REST debate again. I'm firmly in the Ruben camp here though, but unfortunately the distinction between /auth/request-permission?r=8374B650-4974-4E14-A7DF-8729041A96D8 being RPC-like or 'properly' RESTful is notoriously subtle (and in my experience, no amount of explaining or justifying ever seems to help - so I'm certainly not going to bother trying).

So basically I'll just say I support Ruben's suggestion of LDN notifications instead here (as I do see query params stuck onto IRI's when trying to explicitly identify resources (in this case 'inboxes') as too limiting when building truly flexible RESTful systems). Likewise, I also support mandating RDF (over 'allowing just JSON'), again for the flexibility and interop benefits it brings. And finally, introducing spec decisions just to avoid CORS inflights seems like premature optimization to me (i.e. as Ruben says, inflights are inconvenient, but certainly not an obstacle).

[zenomt]

@pmcb55

... unfortunately the distinction between /auth/request-permission?r=8374B650-4974-4E14-A7DF-8729041A96D8 being RPC-like or 'properly' RESTful ...

please note that the URI given was from an explanatory example HTTP interaction, and is the (opaque to the client) target URI of the permission request link for this request. the actual target URI is entirely an implementation detail of the server. the example i gave was representative of one way i imagined a server might be implemented.

this URI represents a time-bounded capability for requesting additional privilege related to the denied request. as an implementation detail of the server, this capability WOULD PROBABLY relate relevant context of the original request including the URI and method, the authenticated identity used to make the request, the identity of the application used (for example, the Origin), when the request was made, the reasons why the server denied the request, and so on.

[csarven]

@zenomt, the form urlencoded approach introduces additional components into the system: Sender-Receiver: form urlencoding, Consumer-Receiver: JSON(-LD).

I agree with Ruben that shaping different kinds of request information is already well-aligned with the existing/expected architecture and interactions.

@RubenVerborgh, I think the alternative you suggest for the most part sounds like what we've covered in Resource Access at solid/data-interoperability-panel#13 (comment) , right? Part of the notion of a "request notification" for different use cases.

I'll comment on the PR.

But that would require all clients to support JSON-LD. It should be available as Turtle, as that is a requirement for other resources anyway.

That entails making it LDN-like by either:

0. requiring JSON-LD with optional conneg (LDN)
1. requiring Turtle
2. requiring JSON-LD and Turtle
3. requiring JSON-LD and conneg (towards Turtle)

Are you suggesting option 1?

Aside: this circles back to resolving issue on which RDF syntaxes to require in the system and to what purpose (partly discussed in solid/specification#6 ). If for instance Solid applications are required to be OPTIONS/Accept-* (or whatever) capable, then option 3 above looks attractive.

@justinwb, verification++. Another panel can figure this out ;)

[zenomt]

@csarven urlencoding and JSON are already part of the system: in addition to being nearly universal and foundational, support for these encodings is included in every web browser and most popular languages, and is already needed to talk to OpenID Connect Providers.

[zenomt]

@RubenVerborgh

as simple as possible (but not simpler)

…it is simpler than what we need.

respectfully, i disagree with this assessment. we spent quite a bit of time talking about this point over several panel calls (although i don't believe we reached complete unanimity on this point).

• what specific permissions are requested (read, append, write, control, other)

the client probably won't know how to request what it really needs from a server. especially in the "not Solid-specific" case. the easiest thing is to try. a good server (value-add differentiation opportunity) can guess likely generalizations of privilege to present to the user/controller/admin based on the original request.

• for which apps (origins) those permissions hold

"the one i used to make the request".

• permissions for groups

i think this is out-of-scope for "app authorization", and is a general permission management problem. please revisit the envisioned use cases. in the course of processing a request for additional privilege, an owner/controller/admin might add the requesting user to a group as one way to fulfill a request for access to a (class of) resources.

• time-bound permissions

do you imagine a client would make a request for access to a resource for only during certain periods? otherwise if the client can access a resource now it does; if it's not allowed now it'll be denied and given the opportunity to request additional privilege (the meaning and management of which, as in all cases, is entirely up to the server).

CORS preflight

That's not an obstacle. It's an inconvenience, but not an obstacle.

for a not-LD-specific general purpose method intended for use in web browsers, and without a compelling technical reason for a non-CORS-simple-request content-type, it might be an enormous obstacle to reaching rough consensus in the IETF if standardization is desired.

... user of the link ...

One could provide a hypermedia form that needs to be filled out.

my use of "user" was probably confusing. i meant the client (application), which is using the link. to make use of it, the client (app) needs to know what the TBD link relation is for no matter what. in the simple case (as currently documented) the request body is empty. i have a few ideas for things that might go in the request body, like a webhook for a server-side component or bot to know when a request for additional privilege has been processed, and perhaps a hint that the client can't or won't launch a browser-based permission management interface (which might affect how the server determines to process the request -- for example, the request might be sent to an admin even if the authenticated user has authority to process the request).

... It should be available as Turtle, as that is a requirement for other resources anyway.

in the envisioned "not Solid-specific" general case, Turtle support is not a given, and requiring it will also be an obstacle for standardization in the IETF. for JSON-LD, i was imagining constraining it like i've seen in other standards with a mandatory default vocabulary (i'll look for a reference) so that if the client doesn't know JSON-LD but knows the vocabulary for this activity, it can understand the response (and it would already ignore unrecognized keys, like @context). adding a @context can make an otherwise ordinary JSON be self-describing Linked Data. and again, the original choice of JSON was for a low barrier works-like-the-rest-of-the-web way to accomplish the goal.

Will write one and post it here. [#28]

i look forward to this taking shape. ;)

[zenomt]

the client probably won't know how to request what it really needs from a server.

The client exactly knows what it wants to do. The server does not know that.

these two statements are not mutually exclusive.

solid/specification#20 does.

my reading of that issue is for it to be possible to express in an ACL during what periods an access rule is active. a request by an app for time-bounded access (that is, an app asking for access to a class of resources but only for during some period(s) -- for example, "i want to read and write your chats, but only on wednesdays") is not a use case that we've considered, nor one i think is realistic.

On the other hand, it is insufficiently general, as users can only ask permissions for specific apps.

AppA requesting permission for AppB is not a use case that we've considered, nor one i think is realistic.

a user/controller/admin/owner managing the privileges for different apps and users to resources on a server (including when those privileges might apply) is an orthogonal, but no less important, problem to the one addressed by the privilege request protocol, which is concerned only with requesting additional privilege when denied access because of insufficient privilege.

[zenomt]

I know, that's why I listed them both 🙂

i meant that both "the client probably won't know how to request what it really needs from a server" and "The client exactly knows what it wants to do. The server does not know that." are not mutually exclusive.

That one is definitely not realistic, but it's also not an adequate summary of solid/specification#20.

AppA requesting permission for AppB

It's not the one I'm proposing.

sorry, then for both of these i must not understand what you mean.

There is a case for a user requesting permissions to a resource [...] independent of any apps. [...] And the currently proposed HTTP Privilege Request Protocol does not support that case, as we have established above.

access to resources is always made with or through some app, even if it's data browser views on the resource server (and with the exception of directly viewing raw resources in your web browser, which is already not going to do anything interesting with a 403 other than tell you "Nope"). it's up to the resource server and the controller/owner/admin whether to grant or restrict access to any resource according to any parameters, including whether to care about what app the user is using. note that the "visitor requests access to a resource for which the visitor currently has no permission at all" is one of the envisioned use cases and is handled like (and is externally indistinguishable from) any other "insufficient privilege" situation.

i think it's likely that non-owner/controller users will either end up with "use any app you want" permission or, on really fancy servers, each user will be able to control and limit what apps can access different classes of resources for/as that user.

based on the comments in this Issue so far, i feel that my proposal must not adequately convey its philosophy and scopes of operation and function.

If pursued, it would lead to a proliferation of such specific endpoints.

i am also not in favor of a proliferation of highly specialized endpoints. i look forward to more detail in your #28 proposal.

[bblfish]

@zenomt answered @RubenVerborgh's point on simplicity

…it is simpler than what we need.

respectfully, i disagree with this assessment. we spent quite a bit of time talking about this point over several panel calls (although i don't believe we reached complete unanimity on this point).

In those calls I mentioned a few times that I thought the proposal of having a mechanism to allow an app to request changes to ACL's was clearly a good idea. I also mentioned that it would be useful to think of what general category of client/server interactions it fit into, as that would likely show that we could use an more general mechanism for notification, so as to avoid inventing a new one.

[elf-pavlik]

1. A user requests access to a resource
2. A user requests access to a resource for a specific app

For 'app authorization' I see common scenario where

3. A user has access to a resource, and wants to give app of one's choice access to that resource, possibly by giving it access to broader set of resources that includes that resource as well. (eg. conforms to shape & no restriction on which resource server or even container)

The base use case has always been "give agent A permissions P to resource R".

I don't want to box panels to hard but since above doesn't involve any notion of app I see it possibly out of scope for 'app authorizaion'.

To comment on Privilege Request Protocol in general, I see it as a submission from @zenomt to this panel. I think we should clarify what specific use cases it addresses and stay open to consider various alternative approaches that satisfy those use cases. I can also see that this submission doesn't address use cases I need solid to cover so submitted Privilege Request Protocol doesn't provide a complete solution for app authorizations.

Just during last call I noticed requirement for establishing independent session with resource server to use it with resource server specific UI:

"The privilege management system might (but is not required to) provide a browser-based permission management interface, and in some circumstances it might be appropriate to allow the client's user to access this interface."

Implementations and deployments I want Solid to enable for usage patterns I aim for, need to work with any number of Resource Serves smoothly integrating into workflows. I understand PoP Tokens in WebID-OIDC also come out of such motivation. Establishing separate sessions with all those Resource Servers and requiring person to interact with number of different (RS specific) privilege management interfaces, I see as burden on users that other approaches can prevent.

Given above Privilege Request Protocol currently does seem to me like addressing very specific use cases, which I still need to better understand. Possibly more enterprise environments with stricter requirements on what needs to stay under control of Resource Server operators. Personally it sounds to me comparable to 'one needs to use company provided blackberry' vs. 'one can use one's own Android or iPhone device', it also reminds me of story related to Personal Clouds told by Doc Searls in this keynote: https://www.youtube.com/watch?v=ZaFmSmDdZBA

[zenomt]

@elf-pavlik

I can also see that this submission doesn't address use cases I need solid to cover

unless it's the consensus of the panel to abandon my proposal, please open an issue against it with the use case you feel it doesn't address.

Just during last call I noticed requirement for establishing independent session with resource server to use it with resource server specific UI

there is no requirement for the server to provide its own server-specific UI. however, if one is provided, it'll probably be necessary for the client to present it to the user, as it'll probably be part of the approval process.

i agree it's not an ideal user experience. however, i felt it was necessary in order to address the privacy concerns of #7 and #17 (comment) in a natural way. presumably the number of times the user would need to interact with such an interface on any server will be limited (ideally to "0 to 1 times").

i've considered (and mentioned earlier in this thread #27 (comment)) a possible extension to indicate that the client requesting additional privilege can't or won't launch a browser-based management interface, which could affect how the resource server processes the request. it might be a good idea to invert this, such that the default case is the client can't or won't launch such an interface, but the client can give a hint that it would launch such an interface for the user, if available and appropriate.

the philosophy of the privilege request protocol is: "a client either has sufficient privilege to access a resource(s), or it does not. if it does not and is denied access to one of those resources, it might be able to request 'additional privilege'. what constitutes 'sufficient privilege', and how privilege is managed, represented, and enforced, is solely the purview of the server. oh and sometimes people use web browsers."

[elf-pavlik]

unless it's the consensus of the panel to abandon my proposal, please open an issue against it with the use case you feel it doesn't address.

I don't say we should abandon it, I think it comes as possible solution to specific subset of all use cases but it doesn't address all the use cases. I've responded more to it in #7

presumably the number of times the user would need to interact with such an interface on any server will be limited (ideally to "0 to 1 times").

per application, which also doesn't include changes to authorization and revoking it #24