Linked-Data Permissions Notifications (LDPN) defines a minimal,
append-only notification log for permission changes in Linked Data
ecosystems. Each agent hosts an inbox container that
contains two Turtle documents—sharedWithMe.ttl and sharedWithOthers.ttl—that record access grants and
changes using the Linked Data Platform, ActivityStreams 2.0, and Web Access Control vocabularies.
LDPN makes privacy and permission changes auditable, allowing end-users
to track who has access to which resources and when those permissions
changed.
This is an unofficial proposal.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.
Permission changes in Linked Data systems are often invisible to the people they affect. When access is granted or updated, the recipient typically has no standardized, machine-readable record of that change. LDPN addresses this gap by defining a predictable location and representation for permission change notifications, making privacy changes trackable and manageable by end-users.
This specification is intended for the following audiences:
The goals of this specification are to:
sharedWithMe.ttl and
sharedWithOthers.ttl—contained within an
inbox container that inventory the permissions received
from others and granted to others, respectively.
Readers are expected to be familiar with RDF 1.1, Turtle, and the Linked Data Platform.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.
ldp:Container within an agent's personal data store
that hosts LDPN notification logs as defined by
LDP.
sharedWithMe.ttl document that records permissions
granted to the inbox owner by other agents.
sharedWithOthers.ttl document that records
permissions changes the inbox owner grants to other agents.
Terminology from RFC 3986, RFC 9112, RDF 1.1, and LDP is used as defined in those specifications.
This specification uses RDF 1.1 Turtle documents to represent permissions notifications.
The following prefixes are used throughout the document:
PREFIX as: <https://www.w3.org/ns/activitystreams#>
PREFIX acl: <http://www.w3.org/ns/auth/acl#>
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX ldp: <http://www.w3.org/ns/ldp#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
LDPN defines a pair of append-only logs stored in an agent-controlled
inbox. Each permissions change is recorded as an
ActivityStreams as:Offer entry that
uses the Web Access Control vocabulary to
describe the target resource and access modes.
Each agent MUST host an inbox container that is
an ldp:Container as defined by the
Linked Data Platform.
The inbox MUST contain the two log files defined in this
specification:
sharedWithMe.ttlsharedWithOthers.ttl
Servers SHOULD include ldp:contains statements in
RDF representations of the inbox container.
The inbox location MUST be discoverable from the agent's
profile document using the ldp:inbox predicate. If no
ldp:inbox link is present, clients MUST assume
the inbox is located at {webid-document}/inbox/, where
{webid-document} is the agent WebID URI without a
fragment identifier.
When permissions are changed for a resource, the system applying the change MUST create notification entries in both logs:
sharedWithMe.ttl log.
sharedWithOthers.ttl log, unless the granting
agent and the affected agent are the same.
If permissions are updated multiple times, each change MUST
result in a new entry. This specification defines grant and update
notifications using as:Offer.
A permission revocation MUST be represented using
ActivityStreams as:Undo. The
revocation entry MUST be appended to the same log(s) as a
grant/update notification and MUST include the following:
as:Undo.as:object identifying the prior
as:Offer notification being revoked.
acl:accessTo identifying the
affected resource.
acl:mode values
describing the access modes being revoked.
dct:created as an
xsd:dateTime timestamp.
dct:creator identifying the
agent who initiated the revocation.
In sharedWithOthers.ttl, revocation entries
MUST also include as:target identifying the
affected agent. Implementations SHOULD keep revocations
append-only to preserve audit trails.
<#UndoNStqftOhhw> a <https://www.w3.org/ns/activitystreams#Undo>;
<https://www.w3.org/ns/activitystreams#object> <#NStqftOhhw>;
<http://purl.org/dc/terms/creator> <https://triple.ilabt.imec.be/test/profile/card#me>;
<http://purl.org/dc/terms/created> "2026-02-11T10:15:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>;
<http://www.w3.org/ns/auth/acl#accessTo> <https://triple.ilabt.imec.be/test/querycache/>;
<http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Read>.
sharedWithMe.ttl allows public append, servers should
validate and rate-limit incoming updates to mitigate spam or
denial-of-service risks.
If-Match) to prevent
lost updates during concurrent writes.