16 Jun
2025
16 Jun
'25
6:09 p.m.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Data Policy
Abstract:
This document specifies metadata on how an entity handles its data
(encryption, data retention, etc).
URL: https://xmpp.org/extensions/inbox/data_policy.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
26 Jun
26 Jun
1:07 p.m.
Dear XMPP fellows,
To give you an idea of what is possible to do with this XEP, I've just posted
2 screenshots there :
https://mastodon.social/@Goffi/114749239855176796
As you can see, the idea is to be able to have a badge with a very simple to
understand score showing how secure is it to use a service or gateway.
Of course the information provided in the specification will evolve with time.
I think that I'll add the algorithm to calculate the score there too, so if
people wants to do the same thing, we can have consistency in the score.
Don't hesitate to give me feedback, notably on data you would like to see
exposed.
Regarding the technical, it's currently using disco extension (XEP-0128), but
this has been discussed during council and it may evolve to another way (with
custom element or whatever). The current options are:
- keep current behaviour
- disco, but on a dedicated node
- using ad-hoc commands
- dedicated IQ with custom elements
- Pubsub/PEP (with the advantage that we can subscribe, and get notified when
something change, e.g., terms of service).
I personally don't care much as long as data are available. Would be nice to
have notification on data change.
If you have well-founded ideas on the way forwards, please shoot.
I would very love to see widespread adoption of those data, so in our clients
we can show how safe is it to use an XMPP server, gateway, or any service.
Would be great to see them in Biboumi and Slidge, and to have plugins in
server so admins can fill their data.
Best,
Goffi
1:14 p.m.
Le jeudi 26 juin 2025, 13:07:54 heure d’été d’Europe centrale Goffi a écrit :
Dear XMPP fellows,
{SNIP]
Best,
Goffi
Also I know that there are some lawyers in the XMPP community. I would very
love to have their input on the best way to show which law apply.
Currently, XEP-0080 is used to indicate the location of the servers (and I've
proposed a change which is in discussion to add ISO 3166-2 `regioncode` so we
can know the administrative region were the data are.
Is this enough to know if, e.g., GDPR apply? Or should we get a field with
other data (which)?
Thanks in advance,
Goffi
1:32 p.m.
)
I'm sorry, I had to add that due to <https://xkcd.com/859/> . Thank you for you
understanding.
Le 26 juin 2025 13:14:40 GMT+02:00, Goffi <goffi(a)goffi.org> a écrit :
Le jeudi 26 juin 2025, 13:07:54 heure d’été d’Europe
centrale Goffi a écrit :
Dear XMPP fellows,
{SNIP]
Best,
Goffi
Also I know that there are some lawyers in the XMPP community. I would very
love to have their input on the best way to show which law apply.
Currently, XEP-0080 is used to indicate the location of the servers (and I've
proposed a change which is in discussion to add ISO 3166-2 `regioncode` so we
can know the administrative region were the data are.
Is this enough to know if, e.g., GDPR apply? Or should we get a field with
other data (which)?
Thanks in advance,
Goffi 
29 Jun
29 Jun
3:27 p.m.
Hello Goffi, thank you for the proposal.
While reviewing the protoXEP, I noticed that it currently does not
include any reference to:
- the legal basis for data processing, as required under Article 6 of
the GDPR (this is a key element for any service operating in or serving
users from the EU);
- the categories of personal data processed by the service;
- metadata processing information;
- explicit consent of the user to data processing.
I would suggest introducing a field, similar to the one described in
§3.6 for the Terms of Service, to link to the Privacy Policy. If the
service provider does not supply this link, the XMPP client SHOULD
explicitly inform the user with a disclaimer, indicating that the
Privacy Policy has not been disclosed by the service. Conversely, if the
link is present, the client SHOULD make it visible to the user by
displaying the corresponding URI in an easily accessible manner.
Moreover, if the Privacy Policy has been declared by the service
provider, there SHOULD be a field that allows the user to explicitly
give consent to data processing, in compliance with applicable data
protection regulations.
Kind regards
Mario
Il 26/06/25 13:14, Goffi ha scritto:
Le jeudi 26 juin 2025, 13:07:54 heure d’été d’Europe
centrale Goffi a écrit :
Dear XMPP fellows,
{SNIP]
Best,
Goffi
Also I know that there are some lawyers in the XMPP community. I would very
love to have their input on the best way to show which law apply.
Currently, XEP-0080 is used to indicate the location of the servers (and I've
proposed a change which is in discussion to add ISO 3166-2 `regioncode` so we
can know the administrative region were the data are.
Is this enough to know if, e.g., GDPR apply? Or should we get a field with
other data (which)?
Thanks in advance,
Goffi
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
2 Jul
2 Jul
2:49 p.m.
Hello Mario,
thank you very much for your feedback.
Le dimanche 29 juin 2025, 15:27:51 heure d’été d’Europe centrale Mario
Sabatino a écrit :
Hello Goffi, thank you for the proposal.
While reviewing the protoXEP, I noticed that it currently does not
include any reference to:
- the legal basis for data processing, as required under Article 6 of
the GDPR (this is a key element for any service operating in or serving
users from the EU);
- the categories of personal data processed by the service;
Is there a standardised way to indicate the category of data processed in a
machine-readable format?
- metadata processing information;
- explicit consent of the user to data processing.
I would suggest introducing a field, similar to the one described in
§3.6 for the Terms of Service, to link to the Privacy Policy. If the
service provider does not supply this link, the XMPP client SHOULD
explicitly inform the user with a disclaimer, indicating that the
Privacy Policy has not been disclosed by the service. Conversely, if the
link is present, the client SHOULD make it visible to the user by
displaying the corresponding URI in an easily accessible manner.
Moreover, if the Privacy Policy has been declared by the service
provider, there SHOULD be a field that allows the user to explicitly
give consent to data processing, in compliance with applicable data
protection regulations.
Shouldn't the consent be given during service subscription? There are 2 main
use cases here: XMPP server, and gateways or similar.
I was envisioning this specification as purely informational, I'm not sure if
it's the right place to ask for consent, and I'm not sure how it should be
requested (also regarding UX).
For servers or gateways if in-band registration is used, this can be a field
used at this moment, and client can show a nicely formatted data policy.
For gateways which work without registration, maybe use should be rejected as
long as consent is not given.
I see how this can quickly become cumbersome and really bad UX, but if it's a
legal requirement, we have so handle it somehow.
You've raised an important point, independently of this data policy
specification: how do we handle consent request with any XMPP service?
Kind regards
Mario
Best,
Goffi
4:38 p.m.
Dear Goffi,
Il 02/07/25 14:49, Goffi ha scritto:
Is there a standardised way to indicate the category
of data processed in a
machine-readable format?
Good and fascinating point.
I've found some standardized ways to indicate the category of data
processed in a machine-readable format. The most relevant include:
1. Data Privacy Vocabulary (DPV) – W3C
The Data Privacy Vocabulary (DPV) is a resource
produced by the W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) to
represent information associated with processing of (personal and non-personal) data and
use of technologies in a machine-readable and interoperable manner.
DPV provides an ontology of concepts that enable expressing information such as data and
technologies involved, their purposes and legal basis, measures used for security,
relevant laws and rights, and associated risks and impacts.
DPV also provides taxonomies for these concepts based on real-world applications so that
the machine-readable representations are consistent and interoperable through the use of
DPV concepts.
https://dpvcg.org/
https://w3c.github.io/dpv/2.1/dpv/
2. Open Digital Rights Language (ODRL) – W3C
The Open Digital Rights Language (ODRL) is a policy
expression language that provides a flexible and interoperable information model,
vocabulary, and encoding mechanisms for representing statements about the usage of content
and services. The ODRL Information Model describes the underlying concepts, entities, and
relationships that form the foundational basis for the semantics of the ODRL policies.
Policies are used to represent permitted and prohibited actions over a certain asset, as
well as the obligations required to be meet by stakeholders. In addition, policies may be
limited by constraints (e.g., temporal or spatial constraints) and duties (e.g. payments)
may be imposed on permissions.
https://www.w3.org/TR/odrl-model/
3. ISO/IEC Standards
ISO/IEC 19944-1:2020: Defines data use categories and data processing
roles, especially in cloud services.
ISO/IEC 29100: Privacy framework that defines data categorization in the
context of PII (Personally Identifiable Information).
4. Special Formats in Industry Frameworks
Defines standardized purposes and data categories used in ad tech.
https://iabeurope.eu/transparency-consent-framework/
------
I do not yet have an idea of how to do it in our case but this may be a
good starting point. The Data Privacy Vocabulary (DPV) – developed by
the W3C – could be extremely useful as a standardised way to indicate
the categories of personal data processed in a machine-readable format.
But more study is needed.
Ciao
Mario
5:04 p.m.
We need to understand if the XEP should define the necessary mechanisms
for XMPP clients and servers (also bridges) to exchange all relevant
information regarding data processing policies — including legal basis,
categories of personal data, metadata handling, and processing purposes
— and also to allow the client application to actively obtain the
explicit consent of the user (data subject) where required by applicable
regulations (e.g. the GDPR), for in-band registration but not limited to
it (e.g. web app like Movim or Conversejs and other client scenarios
where data processing may occur outside traditional registration contexts).
Mario
Il 02/07/25 14:49, Goffi ha scritto:
I was envisioning this specification as purely informational, I'm not sure if
it's the right place to ask for consent, and I'm not sure how it should be
requested (also regarding UX).
For servers or gateways if in-band registration is used, this can be a field
used at this moment, and client can show a nicely formatted data policy.
For gateways which work without registration, maybe use should be rejected as
long as consent is not given.
I see how this can quickly become cumbersome and really bad UX, but if it's a
legal requirement, we have so handle it somehow.
You've raised an important point, independently of this data policy
specification: how do we handle consent request with any XMPP service?
26 Jun
26 Jun
2:11 p.m.
I think this should be adopted. If people use it, that'd be great.
But: I hate that "e2e" means not actually end-to-end. "e2e" etc are
terms
of art with specific meanings, we shouldn't be altering them. There's also
complex cases, like escrow-based cryptography, which aren't captured here
(but do exist and are deployed). Whether something's decrypted (or
re-encrypted) in transmit, or stored in unencrypted form (including
"encryption at rest", which is usually a box ticking exercise) makes a huge
difference in legal terms, though less in security. But e2ee has the
specific meaning of being encrypted from its originator to its final
destination, and that's something we shouldn't change here.
Otherwise, looks good - I might propose changing a few things from booleans
to URLs (like data export), and anyone with PITR is going to hate that "0"
means no backups. (That's Point In Time Recovery, not Pain In The ...
whatever.
Dave.
[ The missing close parenthesis is purely to pay Goffi back for having
mismatched brackets around SNIP ]
On Thu, 26 Jun 2025 at 12:09, Goffi <goffi(a)goffi.org> wrote:
Dear XMPP fellows,
To give you an idea of what is possible to do with this XEP, I've just
posted
2 screenshots there :
https://mastodon.social/@Goffi/114749239855176796
As you can see, the idea is to be able to have a badge with a very simple
to
understand score showing how secure is it to use a service or gateway.
Of course the information provided in the specification will evolve with
time.
I think that I'll add the algorithm to calculate the score there too, so
if
people wants to do the same thing, we can have consistency in the score.
Don't hesitate to give me feedback, notably on data you would like to see
exposed.
Regarding the technical, it's currently using disco extension (XEP-0128),
but
this has been discussed during council and it may evolve to another way
(with
custom element or whatever). The current options are:
- keep current behaviour
- disco, but on a dedicated node
- using ad-hoc commands
- dedicated IQ with custom elements
- Pubsub/PEP (with the advantage that we can subscribe, and get notified
when
something change, e.g., terms of service).
I personally don't care much as long as data are available. Would be nice
to
have notification on data change.
If you have well-founded ideas on the way forwards, please shoot.
I would very love to see widespread adoption of those data, so in our
clients
we can show how safe is it to use an XMPP server, gateway, or any service.
Would be great to see them in Biboumi and Slidge, and to have plugins in
server so admins can fill their data.
Best,
Goffi_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
2:43 p.m.
Hi Dave,
Thanks for your feedback.
To be clear: this is a base to document so everybody get the idea, but I
expect it to be modified, possibly heavily (which is my understanding of the
"experimental" status).
In fact, there are already a few fields that I'd like to change but I'm waiting
for the spec to move forward first: pep. rightfully told me that ToS should
accept multiple URI, so ToS could be linked via HTTP and XMPP (e.g., Pubsub
item).
Also the "government" in access_policy was put because I was thinking of cases
where they can't access (e.g. service which delete logs, encrypt everything).
But technically, more or less all services would give access to government on
request. So I'm not 100% sure if it's pertinent to keep it.
Le jeudi 26 juin 2025, 14:11:51 heure d’été d’Europe centrale Dave Cridland a
écrit :
I think this should be adopted. If people use it,
that'd be great.
I hope to be able to show a badge for any gateway services in not-to-distant
future.
But: I hate that "e2e" means not actually
end-to-end. "e2e" etc are terms
of art with specific meanings, we shouldn't be altering them. There's also
complex cases, like escrow-based cryptography, which aren't captured here
(but do exist and are deployed). Whether something's decrypted (or
re-encrypted) in transmit, or stored in unencrypted form (including
"encryption at rest", which is usually a box ticking exercise) makes a huge
difference in legal terms, though less in security. But e2ee has the
specific meaning of being encrypted from its originator to its final
destination, and that's something we shouldn't change here.
One of the base idea of this specification was actually to detect when a
gateway is decrypting content, while it appears as "e2e" to the client because
OMEMO or whatever is used between client and gateway. But you're right, maybe
it would be better to rename it to "service-to-end" or something like that to
make it more clear.
Also note that I have proposed another protoXEP, which will be resubmitted in
a while due to council discussion and requested changes, to do real end-to-end
encryption with gateways (the "gre" option in this data policy spec).
Otherwise, looks good - I might propose changing a few
things from booleans
to URLs (like data export), and anyone with PITR is going to hate that "0"
means no backups. (That's Point In Time Recovery, not Pain In The ...
whatever.
I'm open to use another value, that's not a problem at all.
Dave.
[ The missing close parenthesis is purely to pay Goffi back for having
mismatched brackets around SNIP ]
Goffi
2 Jul
2 Jul
12:08 p.m.
Le lundi 16 juin 2025, 18:09:24 heure d’été d’Europe centrale Daniel Gultsch a
écrit :
The XMPP Extensions Editor has received a proposal for
a new XEP.
Title: Data Policy
Abstract:
This document specifies metadata on how an entity handles its data
(encryption, data retention, etc).
URL: https://xmpp.org/extensions/inbox/data_policy.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
Hi,
I'm seeing interest in this specification, I've been contacted to talk about
it. I think that this mailing list is a good location for discussions about it
(archived, publicly visible, and the official place to talk about specs), but I
don't want to spam it either for side discussions.
Would people interested in working on this specification prefer to talk about
it here, or on a groupchat (probably a dedicated one)?
We can also organise a call, but I'm really busy and prefer to write
asynchronously.
Regarding changes, as I've said in previous email, and following discussion
during council, I may use something else than disco extension to retrieve the
data. Let me know if you have suggestion.
I notably think that it could be nice to add a way to get customized output:
for instance if I'm using an email gateway (using IMAP or similar), I may
connect to any server, so the data policy for the service can't be fully
specified. But if a user use it to access a known server (GMail, Hotmail,
Protonmail, etc), we can return a data policy corresponding to this service.
Let me know also if you want to see some other data exposed.
Thanks,
Goffi
8:01 p.m.
My opinion only:
On Wed, 2 Jul 2025 at 11:09, Goffi <goffi(a)goffi.org> wrote:
I'm seeing interest in this specification,
I've been contacted to talk
about
it. I think that this mailing list is a good location for discussions
about it
(archived, publicly visible, and the official place to talk about specs),
but I
don't want to spam it either for side discussions.
This mailing list would benefit enormously from "spam" of this quality.
Dave.
52
days inactive
68
days old
11 comments
4 participants
participants (4)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
Mario Sabatino