Video summary
The session focuses on the third installment of the PDP-Connect working group discussions, specifically detailing the architecture and mechanics of "grants" within the Personal Data Portal protocol. A grant is defined as an immutable historical record that captures a user's specific permission for a client to access a particular subset of their data from a designated source. Unlike mutable tokens that might bypass real-time checks, grants are designed to be static records that explicitly state the scope of access, including timeframes, specific data fields, and retention policies agreed upon by the user. This immutability ensures a clear audit trail for lawful enforcement while allowing users to narrow permissions over time; however, expanding access to new data types or fields requires issuing a new grant, as the system does not automatically assume permission for newly added data sources.
To ensure that these immutable grants remain effective even as client applications evolve, the protocol employs an introspection mechanism rather than relying solely on self-contained signed tokens like JWTs. When a client requests data, the server must actively verify the validity of the grant against its current state, which allows for immediate revocation of access within a short window, typically sixty seconds. The query language supporting these grants is intentionally narrow in this initial version, prioritizing efficient synchronization and filtering over complex relationship expansions or arbitrary sorting. While the current spec limits clients to requesting specific streams they have been granted access to, rather than browsing all available user data, the design allows for future evolution where metadata queries might be added. The system also handles continuous access patterns using cursors to fetch new records incrementally and utilizes "tombstone" records to notify clients when data has been deleted by the server or the user.
The discussion also addressed several open questions regarding policy enforcement and future standardization, particularly concerning sub-grants and automated approval processes. The working group acknowledged that while the current specification discourages or prohibits passing grants to third parties without explicit user action, there is demand for features allowing trusted applications to propagate access under specific conditions. Furthermore, the protocol remains flexible enough to support emerging use cases such as delegating grant approvals to AI agents, provided the underlying authorization logic can be refactored to accommodate non-human decision-makers. The team also noted overlaps with existing standards like IETF RA and WebDAV sync tokens but emphasized that PDP aims to provide a unified framework for personal data portability that addresses gaps where users currently lack control over terms of service, potentially drawing inspiration from emerging standards like ISO's "My Terms."
In conclusion, the working group identified key areas for future development, including refining policy definitions beyond simple one-time or continuous access models and improving mechanisms for discovering available user data. The team plans to expand the protocol's capabilities to support richer queries and relationship expansions in later versions, potentially through enhanced manifests provided by data source authors. As preparation continues for the public announcement of version 0.1 at GDC, the focus remains on building conformance test suites and creating tools that allow developers to build connectors compatible with self-hosted personal servers. The next session will shift toward governance and policy discussions led by a representative from the Bonnet Foundation, aiming to further define how users can attach specific terms to their data and how those terms might be enforced across different platforms and legal structures.
Read the full video transcript
M.
Hi, Lisa.
>> Hi, J. Lisa.
>> Maybe we can just wait another minute
and get started.
Right,
I'll just jump in. Um, we'll have some
time maybe after I go through these
slides where we can chat a little bit
about the material or whatever else
comes to mind. Um, let me just throw my
screen up here.
You guys see that? Okay.
Awesome. Okay. Um, so this is our third
session going over PPP and kind of
introducing the initial version. This is
in advance of GDC where we'll announce
um, V0.1.
and we're happy to have you guys here
and um share some notes and get some
feedback. Today we're talking about
um grants basically how is consent to
data stored and and used and then how is
the data served. In the first session,
we went over the architecture and
overall introduction of PDP.
And last week, we talked about how does
a client request access to data and how
is data modeled. And those sessions are
recorded and documented in the PDP
GitHub repo if you want to find that.
Next week we will talk about um
governance and I think Art will be
leading that session from the Bonnet
Foundation and we'll talk about some of
the key open questions for the current
state of PPP.
Okay. So last week basically the gist of
the material was
um a client
would request access to data with a
selection request. That selection
request basically would be interpreted
by the server containing the user's data
and authorizing it and then render a
consent screen. So think of like ooth um
such and such application wants to
access
this application your account with this
application but there would be
additional details about accessing the
user's data. And some of the key points
there were that um data could either be
modeled as being mutable or immutable.
Um emails in your inbox that are really
old. They're probably not changing over
time. And so we can buy some
optimizations that way.
We don't have any canonical data models.
So unlike some other standards, we
basically try to meet the data where it
is in the form that it exists, which
comes with a benefit of being able to
express the data in sort of its full
form and some trade-offs around um
aggregating data across different data
sources may require a little bit of
additional effort to make them uniform.
And
we also took a pretty opinionated stance
that
we want the UIs that are showing consent
to have semantics for not just what the
protocol can guarantee, but any sort of
terms of service that the user wants to
provide um to clients accessing their
data so that those commitments can be
attributed.
Um, okay. So, today we're talking about
really grants as like the key artifact
of the entire PDP standard. A grant is
fairly simple conceptually. It's just a
record of at this time this subject um a
user gave permission um for a client to
access this particular piece of their
data. And specifically grants are scoped
to a specific data source. So if you
want to serve both email data and music
listening data, you would need, you
know, two different grants. Um, but that
can be handled by the server. So the
grant is meant to be fairly narrow and
it records why was access granted.
um the terms of access. Is it one-time
access? Is it continuous access? Is
there a time frame for the access? And
then
there's detail about specifically what
data can be accessed. And that's based
on the data model streams and the fields
within those streams. And within
streams, we can also apply time
constraints. So it could be something
like this is a grant for access to bank
statements over the year 2025.
Um
and this grant is versioned so that we
can always refer back to
um like which version of the protocol
and which version of the data source uh
declaration the grant applies to.
So over time, maybe the client changes
its brand and the logo changes. That's
metadata that's stored in the grant. Um
the grant is meant to be immutable. It's
a historical record. And um so maybe
there's some drift with how things
change in the future, but we we really
want the grant to be immutable and also
capture
anything that's anything that's dynamic.
for example, a view that says um I want
to access the user's basic profile
information. Um if that dynamic
basic profile definition changes over
time, actually when the grant is
created, it needs to be resolved into
specific fields. And so if the
definition of basic profile changes in a
future version, the grant uh still
states exactly which fields it applied
to. Um the grant can actually change
in the sense that the user can narrow
permissions. Um
so we could say we're going to stop
granting access to
um specific fields in the grant can
still be used to access the other fields
without having to reissue a new grant.
But it can't go the other direction. We
can't say um this data source has some
new features with new data and we're
just going to assume that access should
be granted to those new fields. Um
maybe maybe some new profile fields were
added. Uh that would require a new grant
when grants are revoked. So a user can
revoke a grant. Obviously, we can't go
out into the clients and say, "Give us
the data back or prove that you've
deleted the data." Um, so revoking
access really just cuts off future
access. However, grants do contain some
policies like what is the data retention
policy um that the client is committing
to. And this is similar to how OOTH
token revocation works. And I think the
goal here is basically to just provide
the scaffolding with which um sort of
lawful enforcement can be applied if
needed later on.
Um this is maybe just a little bit of a
lesson in um OOTH and a specific choice
that we're making in relation to
revoking access to data. But I think
it's worth mentioning that um instead of
using JWTs where
um a token is signed and can be
inspected and the server could verify
like okay yes I granted um like I signed
this in the past and it proves that
access has been granted. Therefore I
don't need to go look at anything in my
database. I don't need to make another
round trip. I'm just going to continue
giving access. We chose not to do that
because then the user can't revoke
access and have that re revocation
um go into force immediately. So
introspection is required when a client
requests access to data with their token
with their access token. That access
token gets checked to see if it's still
valid. Uh we allow a 60-second cache but
no more than that. So um if you revoke
access you have a guarantee that within
60 seconds clients will not be permitted
to fetch new data.
Um, so now we can talk a little bit
about
the query language like how does a
client actually ask for data that it's
been granted access to and the full
detail of all this is in the stand is in
the spec, but it's basically
um listing what streams the user has
that you've been granted access to,
getting metadata about those streams,
listing records records within a stream
or grabbing an individual record or if a
record has some kind of blob um defined
like an image or a video at some other
URL, a way to go grab that as well. So
that could be like an attachment from an
email hosted on another server um or on
the same server. And it's important to
note that
um everything that the client sees when
they query for things like tell me what
streams are available for the user,
those are always filtered down through
what the grant allows. And
we actually don't have a way at this
time for clients to just go look up what
is all the data um that a user has that
they could potentially grant me access
to. We may add some features in the
future where users can sort of permit
additional metadata queries. Um
but at the moment
basically the only thing a client can do
is ask the user please give me access to
your data and the user will indicate
which access should be granted and at
that point the client can learn what
data is available.
Um within these endpoints we have a few
I would say key parameters that show up
a lot. Um because the
whole data model and the API is sort of
tailored towards syncing. Um, think like
data that is continuously
fetched in the server or generated in
the server and some client that wants to
on a regular basis get the newest
information or the newest data or the
newest records um because that's how the
data is sort of modeled. Things like
cursors are really important in how
clients talk to the server. And I'll
show some examples here in a second.
So
we're making a choice that at least for
this version of PDP
the spec is fairly narrow in terms of
the query API that we're supporting. So
you can imagine um in an ideal world if
you have access to some data you can do
like really rich queries you can query
for
um expansions through records into their
relationships like I want to find all of
the friends of this person's friends and
maybe another layer of friends and just
expanding down or you can imagine really
um
tight control over how records are
sorted. I want this I want to look up
all of these contacts sorted by zip code
or even like the last four digits of the
zip code. Um we're just not supporting
sort of arbitrarily rich queries in this
version. Um,
one thing that we think clients can do
fairly effectively is do an initial
query to get some data or sort of sync
um, this the data from the stream that
they have access to and then do
re-ranking or additional filtering or
additional sorting the way that they
need to. Um, I think in the future we
will probably create some new semantics
that make things like expanding
relationships
um possible by sort of expressing more
detail about those relationships within
the manifests that the data source
authors provide. Um, but I think that
maybe is a little bit of a stretch at
the moment.
Um
and and actually that being said,
there's nothing stopping clients from
using
um supporting additional features.
Sorry, nothing stopping servers from
supporting additional features.
So, one maybe key idea to help
understand all of this is when
access to data is fulfilled, when a
client requests access to data,
um the way that the server fulfills that
access is actually to go get the grant
and then look at the data, grab the data
and filter it through that grant. So the
grant is not just sort of metadata. Um
it's not just a historical record. It's
actively used in the process for
returning filtered access to data.
Um
and yeah, there's probably not much more
to say on grants. Um
we can talk about
how continuous access works. So, let's
say once a day or once a week I have
access to a user's um listening history
in their music app or I guess in this
case um conversations.
I can ask for all of the newest
conversations since the last time I
asked. And how do I specify that? I pass
a cursor which was given to me on my
previous request. So this is a way where
clients can efficiently sort of ingest
the next set of records um across the
stream.
And you'll also notice in this example
the the second record that was returned
is a tombstone. It's basically an
indication from the server that a record
was deleted. So in the past maybe as a
client I pulled in a particular
conversation and now I'm seeing the user
maybe deleted that conversation or the
server decided to delete that
conversation for some reason.
Um nothing too complicated here. If you
request access for data that you don't
have a grant for, you will get back a
code basically saying um that's not
allowed.
So I think this is an area in the
standard where things may evolve and we
may come back to some of our decisions.
There are some open questions.
Um actually really tight filters and
relationship expansion that we can't
support for clients we can support if
you own the data. If you are the user
and you're just accessing your own data
with um an owner token, we can support
those things and we do name them in the
core spec. So there's a little bit of a
mismatch between what the owner can do
and what a client can do. Um like I
said, I think in the future we will
expand the sort of power that clients
have for querying data.
Right now we make a distinction between
um oneshot access where a grant can only
be used once versus continuous access.
But we don't define other kinds of
policies about access. And so we may
refactor
this a little bit to support other kinds
of policies or maybe extensions to the
spec can support other kinds of
policies. Um or we may choose that
single use is sort of oversp specified
and
um leave that up to implementers.
When it comes to the process of
discovering what data um an individual
has that can be accessed, we don't have
like strong answers for that. The answer
is really just the user tells them at
the time of consent. Um so I think I
mentioned this earlier, we may add some
machinery to make that process a little
bit smoother
and
um
yeah retention policies
and other kinds of policies which the
user is sort of asking the client to
commit to as their terms. maybe could be
generalized a little bit more and we can
sort of open up the space for other
kinds of rules about how the data can be
used and what should happen with that.
Um, a few key decisions that we talked
about today [clears throat] are that
grants are immutable, meaning that
um, you can always look back in history
and see exactly what permission was
granted and how
um tokens are enforced is that we use
introspection to check sort of at
runtime whether access is still allowed.
And our query API is meant to be fairly
narrow and small um
at least in this version of the spec.
So this is information we've shared in
the past, but if you just drop on our
website at ppp.dev, dev, you'll be able
to find all of the things, the Discord
server, the GitHub. Um, you can build a
data connector and try to plug it into a
personal server that's also hosted on
the website that you can self-host and
run yourself. And yeah, some of the work
still to do is to work out um
conformance and building out test suites
and making it easier for platforms to
conform with the protocol. And then
obviously this month is all about um
sort of dotting our eyes and crossing
our tees as we get ready to announce
this more publicly.
Um, so I think at this point I'll just
stop here and open it up for any
questions or discussion.
Um,
and we can just
we can just hang on as long as uh
there's stuff to talk about. So yeah,
any questions?
>> Yeah, I'll I'll pop in with them.
Thanks. Thanks for this. I'm Carmen with
mosilla.org. Um, I'm curious if there is
a concept of a subgrant in this, like
where whoever received a grant can pass
along a smaller piece of it to someone
else, or does every grant always have to
come straight from an original data
owner?
>> I think that's a great question. Um, I
think as written, the spec basically
um either discourages that or
or prohibits it. Um, I think we need a
better answer for either the enforceable
or uninforcable policies that are
expressed by the protocol. Um, I think
it could be a nice fe, excuse me,
feature if users
want an application to be able to sort
of arbitrarily propagate the access that
they're granted in a way that the us
like if the user trusts some application
um with their data. Yeah, I think that's
a good question. I don't think it's a
fully resolved question. Um, do you have
any opinions about how that should work?
>> It's it's uh I ask you because it's
something that I don't feel super
resolved with. Um, so it's mostly
curious your your take if you've if
you've thought about it at all or um
yeah, I guess heard from folks how they
think about it.
Yeah, I think this is probably something
where we think
there's demand for it or if the use
cases are there, we could I I think put
some time into figuring out how to solve
this. Um,
I think in this version of the spec, it
hasn't really been a focus yet, but I'll
definitely take that as an open question
and and we can try to get some clarity
on what makes the most sense. Yeah, I I
appreciate that. And then maybe um like
some tenants I would consider is like
they're more hunches than anything, but
I imagine like subrants would be
narrower than the parent, right? You
always show the full chain back to
original owner and die the moment the
parent grant dies. Um so you don't have
this like partial survival zombie
subrant out there. Um but yeah, I
appreciate you taking that as an action.
>> Yeah, absolutely. Lisa,
>> hi. Um, I wanted to know if you're aware
of the RA metadata draft that is going
in the along in the IETF right now. Um,
because there seems to be some overlap
and since you already use RA,
I mean RA is a RFC and this is a draft,
but Zahavi is uh well embedded in the
OOTH working group and uh has a lot of
of of collaborators.
Oh, I I haven't seen that. Is there like
a
two second summary of um what
what what about that resonates for you?
>> Um well, I think what what resonates? I
don't know that any of this will be
useful for personal data access.
So, I wouldn't say it resonates with me,
but I just wanted to to offer if it was
useful um some
uh exist some you you um use a lot of
tools that already exist to reduce the
amount of work you have to do in PDP and
this is another piece that would reduce
the amount of work you have to do.
>> That sounds great.
>> Yeah, it's always great. [laughter]
Um,
another one is another um obscure bit of
standard stuff that is an RFC is
WebDAB's report and sync token. This is
a lot like cursor. I mean, basically
it's a cursor and allows for
synchronizing large collections.
>> Nice. Okay, I'll take that too as a
note. I think um yeah there are a bunch
of like cursor based protocols out
there. We actually looked
>> there are a lot. [laughter]
>> I was making a list of them uh the other
day like
>> um starting with with rync soap beep xpp
jingle jmap mcp activity pub bit torrent
graphql atlas atom atom pub solid and
webdav.
>> Wow. Yeah. Yeah. Yeah. Yeah. Yeah. This
has been a this is a class of problem
that has been tackled many times.
[laughter]
Not all of them are are are as relevant
in different situations. Like the sync
and resume is not a as great fit for
activity pub, but depending on what use
case you have, you can make sync work
while using activity pubs publish stuff
if publishing is more the model. But um
we've been trying to get companies with
personal data support to support the
standards that already exist for years
and they prefer to keep it inhouse and
custom. So that's that's my biggest, you
know, I I would love to say lots of this
stuff resonates with me, but uh um I
don't know how to get any of them to
implement a standard for filters and
grant scopes and uh expirations and
all of that pageionation even.
Yeah, I think we we started with this
sort of data connector
deployment option as a way for us to
sort of build out an implementation of
PDP without having to wait for other
platforms. And in some ways it seems a
little bit
like you're cobbling together this
um
this like client around an API that may
not properly support all of the
machinery that the client needs. Yeah,
>> but we I think we've been able to get
pretty far surprisingly
um across a bunch of different
platforms, APIs. And um
I think maybe the eventual answer to
this is
sort of along the lines of MCP, like
maybe the way to get people to implement
something like this is not to change
their existing system, but to ship
something that can sit on top of it. and
maybe it's a little bit clunky. Um, but
if it fulfills the spec or if it can
conform to the the standard, then
even if it doesn't conform 100%, maybe
there's some optional features that um
are just not supported like the basic
get the data out like feature. Um, I
think that's that's where I'm putting
some of my my optimism and hope in that
direction. Like there's some kind of
bridge to what exists today. But yeah, I
would love to hear any other thoughts
you have about um how to get these guys
to move um in this direction.
>> Yeah.
>> Yeah. Yeah. And I think along those
lines, um,
there are a number of different ways
that you can imagine accessing data.
We're talking here about syncing data
periodically. Um, if you look at
something like a PDPA export, like a
Google takeout style, just export
everything. We haven't put a lot of
focus on stuff like that because if all
the data is in the server, an export
shouldn't be that hard to build um
versus a real-time query API. So we
started with the harder thing but there
may be other
access paths or use cases where we can
um
maybe define like
more specifically here's how it works
and here's why here's how it can work
well maybe like additional APIs that we
don't have in the stand in the spec
right now. Um,
yeah.
Any other questions or comments?
>> Yeah.
>> Go ahead. I I've gone.
>> Okay. I've got question. Uh do you do
you think Tim or you thought about like
how much protocol should be opinionated
about uh approving grants and building
features related to grant approvals? I'm
thinking about things like delegating
approval of grants you know for example
to AI agent or something like that right
basically assuming that I will not be
always available to approve a grant. I
would like to have an maybe automation
in a auditable way set up that I can and
maybe a few automations and I would be
you know and maybe set set some policies
about you know what kind of data should
be approved and so on.
>> Yeah. Um great question. I think
a few weeks ago
the way that the spec was written was
more tightly coupled to OOTH as an
authorization protocol.
And we actually realized we could
refactor that a little bit and make it
more flexible. And so in the future we
could potentially support something like
um GNAP, GNAP. Um and I think there's
nothing really about PPP that says you
can't implement an authorization
protocol that makes use of an AI agent
or some other undefined mechanism. Um, I
think it could be a really interesting
avenue to explore and I think with AI
agents getting more sophisticated
and users potentially delegating more
and more and and potentially
establishing a lot of trust es like if
you have maybe some lower stakes data
and you don't want to always have to be
in the loop to approve requests but you
also don't want to just automatically
click a button. maybe some agent can
help mediate that process. Yeah, I think
we want there to be ways for
implementers to support that. Um, given
that
like PDP is really just about the
language of data portability,
we're not intending to
prevent um use cases like that.
>> Cool. Thank you.
Cool.
Any other questions?
>> Yeah, I I was just uh kind of noodling
like from a policy perspective, what
happens if the um whatever the the thing
I've given permission to changes legal
ownership? um you know does does my do I
have to does that uh prompt me to revoke
my access because it's a new
relationship with a new kind of company
or corporate structure um you know
[clears throat] I think it could be
interesting to have uh clients have to
sort of report that type of ownership
like it was a security issue um but just
something to I'm curious you've thought
about at all.
>> Do you think you could give me a
specific example?
>> Yeah, sure. Um,
so you know if I'm giving access or
sorry if I'm um giving permission
uh for something to yeah sorry if I'm
giving read permission to a certain set
of information um or to to a client for
certain set of information I'm probably
making a certain assumption about the
the relationship I have with that
company right so maybe let's just take
Spotify I'm giving Spotify read access
um if Spotify were to like change legal
structures or get absorbed into
something else like I would want the
option to know that to be able to to
revoke um because it would be a
different uh like it's a different
company now. Does that make sense?
>> Yeah.
>> So, it's basically like
>> it's a little bit terms of service or
privacy policy like adjacent. Um but I
guess like within the structure.
>> Yeah. I think I mean I think this is a
really interesting question. It's like
if a user has specific terms that they
want to be attached to their data, how
can those be expressed and to the extent
possible enforced by the protocol?
Obviously, there are some limits there,
but
um
I think I'll have to think some more
about that. right now it wouldn't be
hard to extend the standard to allow for
sort of user specified terms. Um, and
then maybe the authorization server
could have some templates or some
recipes for like these are things that
our users typically
um want to request or maybe that could
just be some other RFC that kind of lays
out um what what those common things
are. Um
yeah, I think that's a good question. I
think there's probably a gap um when it
comes to fully addressing like what all
the different things that the user could
want when it comes to granting access to
their data. So yeah, I'll take a look at
that for sure.
>> Yeah, and I appreciate that being zoomed
out um because it could include also
stuff like the client outsources data
processing to like a third party that
was like previously undisclosed or any
any list of of things. So uh yeah,
thanks.
Yeah, Lisa.
>> Yeah, the um this is mostly in response
to Carmen the the are you aware of the
ISO standard for my terms? Um this would
cover the bulk of user data hosting by
the direct like firstparty rather than
third party access the first party
holding of bulk data which users
currently have no control over the terms
of. So that covers a large surface area.
>> Oh, cool. Well, you say it's called my
terms.
>> It's called my terms. Yep.
>> Okay.
All right. Any other questions?
I think we can wrap up this session. Um,
yeah, just a reminder, Art will be
leading the next one next week. I think
the time will be a little bit later in
the day. He's in Australia. Um, but
he'll definitely have less material on
the technical side. It'll be more on the
governance and policy side, which I
think could be really interesting. So,
hope to see you all there. Um, thank you
for joining. Thanks for all the great
questions and feedback. And I don't know
who's going to be in GC, but if you're
there, we should definitely um, sync up.
And yeah, I'm excited. So thanks
everyone.
>> Thank you Tim. Thank you everyone.