Re: Transforming Queries for Access Control

Hi Adam,

 

I have developed 6 API end-points (2 are skeletons because no system exists that justifies development at this stage) that comply with RFC 9396, authZen (with parameters as JSON) and basic “& separated strings”. Internally, everything is a URI (actually, it is a large knowledge graph), the reality is that everything can be compressed to the “last” bit of the URI (uri…blahblahblah…action) as the triples are not resolved on each execution (they are all resolved at the point of definition or ingestion of the policy). Authorisation, unlike authentication (happens once?), possibly happens on each request to an object (depending on the granularity could be at “object” / “sub-object” or “properties of…”) – you want them short and fast to process as they are orders of magnitude more.

 

According to each standard, the requests have different names for fields, but they all follow the [ actor, action, asset ] triple concept as normative elements.

 

Everything moving forward (in terms of the other standards) will use a JSON, and the “& separated strings” just made sense if there is a use case for having a constrained type of IoT device (perhaps memory, bandwidth or CPU).

 

Regards,

 

___________________________________

Joshua Cornejo

marketdata

smart authorisation management for the AI-era

 

From: Adam Sobieski <adamsobieski@hotmail.com>
Date: Tuesday 4 February 2025 at 16:46
To: "public-solid@w3.org" <public-solid@w3.org>
Subject: Transforming Queries for Access Control
Resent-From: <public-solid@w3.org>
Resent-Date: Tue, 04 Feb 2025 16:45:30 +0000

 

Solid Community Group,

 

Hello. I am pleased to share a recent idea involving the use of text templating for transforming or compressing queries, e.g., SPARQL and SQL queries, into more efficient representations more resembling remote procedure calls or actions [1].

 

In this technique, actions’ “verbs” are URIs, or, more specifically, URLs from which to retrieve those templates with which to decompress the transmitted objects back into query languages. It is possible to process incoming queries using the compressed representations and also to obtain the intended full query-language representations.

 

This technique should allow solutions like ODRL to describe queries, at least for those cases where the resultant “verbs” were well-known to, or recognized by, servers. Additionally, ODRL constraints could be placed on query actions’ arguments.

 

Thank you for any feedback on these ideas.

 

 

Best regards,

Adam Sobieski

http://www.phoster.com

 

[1] https://github.com/WICG/proposals/issues/194