Proposed XMPP Extension: Data Policy
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.
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
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
) 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@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
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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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
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
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?
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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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
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@xmpp.org To unsubscribe send an email to standards-leave@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
My opinion only: On Wed, 2 Jul 2025 at 11:09, Goffi <goffi@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.
participants (4)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
Mario Sabatino