Catalog.ID Membership Agreement

Operator: Stichting Outpapier, identified by Operator ID b4np (Netherlands) ("Operator", "we", "us")
Founder / Network Creator: Roberto Bourgonjen ("Founder")
Last updated: 2026-05-14

This Catalog.ID Membership Agreement ("Agreement") governs your registration for and use of catalog.id (the "Network") as operated by the Operator.

Catalog.id is designed as a federated network intended to be operated by foundations in multiple jurisdictions under a common set of rules. This Agreement is tailored to the current Operator: Stichting Outpapier in the Netherlands. If you register with a different operator in the future, you will be presented with that operator's agreement.

Why membership matters. Catalog.org provides technical tools for creative work: collaboration features, provenance and process recording, and timestamping of work. catalog.id adds a shared legal and behavioral framework between individuals. Every Member accepts the same confidentiality and consent rules, the same IP and attribution expectations, and the same dispute process and remedies. Together, this creates a trust standard: when two people are Members, they collaborate inside a common rule set with clear consequences for doxxing, leaks, and infringement — making catalog.id a safe place to collaborate.

1) Acceptance

  1. Your acceptance. By clicking "I agree", creating an Account, or using the Network, you accept this Agreement.
  2. Operator's acceptance. The Operator accepts by activating your Account and providing access to the Network. No physical signature by the Operator is required.
  3. If you do not agree, do not use catalog.id.

2) Purpose and core principles

catalog.id is a membership environment built on:

  • consent-based sharing, including cryptographic key-based sharing;
  • confidentiality of member-shared information;
  • respect for intellectual property (IP) and provenance; and
  • dispute resolution inside the Network first, with court as a last resort.

What this Agreement protects:

  • Confidentiality — Member Shared Data stays private; no onward sharing without explicit consent (Section 10).
  • Intellectual property — attribution norms, notice-and-cure procedure, and enforceable damages for infringement (Sections 12–13).
  • Personal safety — doxxing and unlawful disclosure trigger emergency measures and liquidated damages (Sections 13–15).
  • Efficient dispute resolution — Member arbiters resolve disputes inside the Network before court (Sections 17–18).
  • Accountability — repeat offenders face escalating sanctions, including suspension or termination (Section 15).
  • Encryption by design — personal attributes are stored end-to-end encrypted, with consent-based key sharing and revocation (Section 9).
  • Consent-based third-party login — you control which Attributes are disclosed to Relying Parties, with per-claim consent and revocable authorizations (Section 9a).
  • Agent accountability — Agent Identities operate under Principal control and responsibility, with scoped permissions and full attribution traceability (Section 4.8).

3) Key definitions

  • Natural Person: a living human individual acting in a private capacity.
  • Organization: any legal entity, company, partnership, association, foundation, government body, or other entity that is not a Natural Person.
  • Member: a Natural Person registered on catalog.id.
  • Account / Personal Account: your catalog.id account, registered to and controlled by a single Natural Person.
  • Organization Identity: a Catalog.ID identity registered to an Organization, identified by a domain name as its username, and operated by Members serving as Delegates. Organization Identities are not Members and are governed by the Organization Identity Agreement. See Catalog.ID Whitepaper §3a.
  • Delegate: a Member who is authorized to act on behalf of an Organization Identity in a defined role (owner, admin, treasurer, signer, or viewer). Delegates access the Organization Identity's cryptographic keys through their own personal identity (see Catalog.ID Whitepaper §3a.3–3a.4).
  • Member Shared Data: any data another Member or Organization Identity shares with you via the Network or Catalog clients/APIs, including (without limitation) encrypted attributes, messages, files, links, provenance records, decryption keys, identity assertions, and private metadata. Member Shared Data includes copies, extracts, screenshots, transcriptions, and summaries that reveal the substance of the original data. Where you also use the Catalog.org Cloud Services, Member Shared Data may overlap with "User Content" as defined in the Catalog EULA and Cloud Services Terms.
  • Attribute: structured information associated with an Account, Organization Identity, or content (some of which may be end-to-end encrypted).
  • Onward Sharing: disclosing, publishing, forwarding, selling, sublicensing, or otherwise making available Member Shared Data to any third party (including other Members) beyond the intended audience.
  • Arbiter: a Member listed in the Network's Arbiter Registry and eligible to serve on a dispute panel.
  • Agent Identity: a Catalog.ID identity registered to an autonomous or semi-autonomous entity — such as an AI system, automation script, or human operator — acting on behalf of a personal or delegate identity (the "Principal"). Agent Identities are not Members, have no independent cryptographic credentials, and operate under the Principal's legal framework. See Catalog.ID Whitepaper §3c.
  • Principal: a personal or delegate identity that creates, controls, and is permanently linked to an Agent Identity. The Principal holds all key material for the Agent Identity and is responsible for its actions.
  • Agent Runtime: a locally executing process on the Principal's machine (or within the Principal's trust boundary) that mediates between the Agent Identity and the Principal's key material, exposing signing operations without exposing private keys. See Catalog.ID Whitepaper §3c.5.
  • Relying Party (RP): a third-party website or service that offers "Log in with Catalog.ID" and receives identity information through the OIDC-based authentication protocol described in Section 9a. See Catalog.ID Whitepaper §11.
  • Sanctions Registry: an encrypted registry of sanction records maintained by catalog.id operators, used to prevent re-registration of expelled Members (see Section 15.3).

4) Membership eligibility

  1. Personal Identities for Natural Persons only. Only Natural Persons may register a Personal Identity and hold membership under this Agreement. Organizations may not hold a Personal Identity or be Members under this Agreement.
  2. Organization Identities. Organizations may register an Organization Identity on catalog.id under the separate Organization Identity Agreement. Organization Identities are identified by a domain name, are not Members, and are operated by Members serving as Delegates. See Catalog.ID Whitepaper §3a.
  3. One person, one Account. Each Personal Account must correspond to a single Natural Person. Shared accounts are not permitted.
  4. Private identity. Membership is personal and based on your private identity, not on corporate or institutional representation.
  5. Age requirement. You must be at least 18 years old to register. By creating an Account, you represent that you are a Natural Person aged 18 or older.
  6. No organizational representation through Personal Accounts. You may not:
    • present your Personal Account as an "official" organizational, company, or foundation account; or
    • represent that your Personal Account membership confers authority to act for any Organization.
      Where you act on behalf of an Organization, you must do so through a registered Organization Identity — not through your Personal Account.
  7. Delegate responsibilities. When you serve as a Delegate of an Organization Identity:
    • your obligations under this Agreement — including confidentiality (Section 10), IP respect (Section 12), and prohibited conduct (Section 14) — apply in full to actions you take through the Organization Identity;
    • you are personally accountable for your actions as a Delegate;
    • you must comply with the Organization Identity Agreement in addition to this Agreement; and
    • you must not use your Delegate access to circumvent sharing controls, revocation, or consent requirements that apply under this Agreement.
  8. Agent Identity responsibilities. You may create Agent Identities linked to your personal or delegate identity. When you do so:
    • you are the Principal and are personally responsible for all actions performed by or through the Agent Identity, including CPR claims, file uploads, chat messages, and any other operations;
    • your obligations under this Agreement — including confidentiality (Section 10), IP respect (Section 12), and prohibited conduct (Section 14) — apply in full to actions performed by or attributed to your Agent Identities;
    • you must configure appropriate session scopes and restrictions for each Agent Identity and must not grant broader permissions than necessary for the agent's intended purpose;
    • you are responsible for the security of machines on which Agent Runtimes operate, including persistent-mode runtimes that store encrypted key material on disk;
    • you must promptly terminate or revoke an Agent Identity if you become aware that it is malfunctioning, compromised, or performing actions outside its intended scope;
    • Agent Identities are not Members and may not be presented as independent actors with autonomous authority; and
    • disputes involving an Agent Identity are disputes with you as Principal. If you are a Delegate, disputes escalate to the Organization's owner Delegate identities.
  9. General eligibility and restrictions. We may restrict or refuse membership where required by law or for risk and safety reasons.

5) Accounts, identity, and security

  1. Registration data. To register you will be required to provide your full legal name, email address, and telephone number. You may provide your address. Some features and trust levels may require you to provide a verified address. You must keep your information accurate and up to date.
  2. Encrypted storage. Personal attributes provided during registration — including your full legal name, email address, telephone number, and (if provided) address — are stored as end-to-end encrypted Attributes as described in Section 9. The Operator cannot access these in plaintext unless you share the decryption key with us.
  3. Security. You are responsible for securing your devices, credentials, and keys.
  4. Key backup. Your private encryption key is generated in your browser and never transmitted to the Operator's servers. The Operator does not possess, store, or escrow your private key. You are solely responsible for maintaining secure backups of your private key and password. The system provides key export during registration and on demand thereafter.
  5. Key loss. If you lose your private key and have no backup, your encrypted Attributes are permanently unrecoverable. This is an intentional property of the system's zero-knowledge architecture. You may recover your account by proving your identity to the operator through alternative validation channels (e.g., validated email, phone, or document verification), creating a new identity, and requesting that the Operator treat the key loss as an account recovery event (see Catalog.ID Whitepaper §3.2). Public claims can be transferred to the new identity. Existing CPR provenance claims remain in the immutable record under the old identity. Encrypted Attributes not previously shared with anyone are permanently lost. CPR signing keys are generated per-machine and stored only on the machine — they are not part of the key bag and are not recoverable through the supersecret. If a machine is lost, the corresponding CPR signing key should be revoked and a new one generated on the replacement machine.
  6. Key compromise — notification and lockdown. You must promptly notify us of suspected compromise or unauthorized access to your private key. You — or any holder of the compromised key — may submit an authenticated lockdown request at any time. Upon lockdown, the Operator immediately halts all API access for the Account (no claim decryption, sharing, CPR claim submissions, or validation requests). Lockdown is a one-way action that does not require operator verification.
  7. Key compromise — rotation. After lockdown, you must prove your identity to the operator through at least one validated channel independent of the compromised key. Once verified, you generate a new key pair and the server wraps all encrypted symmetric keys associated with your Account in an additional encryption envelope using the new public key. The compromised key is retained in your key chain but marked as revoked. The operator then unlocks the Account. No encrypted data is lost during key rotation. See the Catalog.ID Whitepaper §3.3 for the full technical description.
  8. Username — intellectual property and license.
    • Ownership. Your catalog.id username is part of a namespace designed and created by the Founder. The namespace — the set of all possible usernames, the format in which they are expressed, and the algorithm that generates them — is the Founder's intellectual property, protected by copyright, EU sui generis database right, and this Agreement.
    • License chain. The Founder licenses the namespace to the Operator. The Operator sublicenses your individual username to you for the duration of your membership, subject to this Agreement.
    • No ownership by Member. You do not own your username. You hold a sublicense to use it. You may not claim ownership of, register as a trademark, or assert any proprietary right in your username or any part of the catalog.id namespace.
    • Retirement. Upon termination of your membership (for any reason), your username is permanently retired. It is never reassigned to another Member. Provenance records, CPR claims, and other references to the retired username remain valid historical records referencing an identifier that no longer resolves to any identity.
    • No transfer. You may not sell, assign, lease, or otherwise transfer your username independently of your Account. Username portability is governed by Section 8 (Account portability).
    • Agent Identity usernames. Agent Identities you create are assigned usernames from a separate namespace (ten lowercase letters, no digits). Agent usernames are part of the Founder's intellectual property and are sublicensed to you under the same terms as your personal username. Agent usernames are permanently retired upon termination of the Agent Identity.

6) Registration processing fee

  1. Fee. The Operator charges a registration processing fee of €279 for processing and verification of catalog.id membership applications.
  2. No guarantee of acceptance. Payment of the registration processing fee does not guarantee that your application will be accepted. The Operator may refuse membership for legal, security, risk-management, or policy reasons. Where permitted and practicable, the Operator may provide a brief explanation, but may be unable to do so in some cases (for example due to security, privacy, or legal constraints).
  3. Non-refundable. The fee is non-refundable once processing has started.

7) Address verification by mail

  1. Sharing required. To initiate address verification, you must share your address Attribute with the Operator (per Section 9).
  2. Optional verification. The Operator may offer address verification by physical mail (e.g., a letter or postcard containing a verification code) sent to the address you have shared.
  3. Purpose. Address verification serves as an operational verification step to increase trust and may be used to determine eligibility for certain features and trust levels within the Network.
  4. Feature restrictions. The Operator may restrict access to certain features until address verification has been completed.
  5. No legal guarantee. Address verification is an operational measure and does not constitute legal proof of identity or residence.

8) Account portability and provider migration

  1. Right to migrate. You may request to transfer your Account to another licensed catalog.id operator ("Receiving Provider"). Migration is a data portability and re-registration process, not an automatic right of acceptance by the Receiving Provider.
  2. What transfers. Upon a valid migration request, the Operator will export in a reasonable timeframe (not exceeding 30 days):
    • your Account identity and public key;
    • your encrypted Attributes (ciphertext); and
    • provenance records and content references associated with your Account.
      You are responsible for re-sharing decryption keys with the Receiving Provider as needed.
  3. What does not automatically transfer. Address verification status, Arbiter eligibility, and trust levels are subject to the Receiving Provider's own rules and may require re-verification.
  4. Receiving Provider acceptance. The Receiving Provider must independently accept your registration under its own membership agreement. The Operator has no control over and makes no guarantees regarding acceptance by another provider.
  5. Completion and termination. Once the Receiving Provider confirms activation of your Account, your membership with the Operator terminates. Obligations that survive termination (including confidentiality under Section 10) continue to apply.
  6. No migration during active disputes or sanctions. Migration may be paused if you are subject to a pending dispute (Section 17), active enforcement measures (Section 15), or outstanding liquidated damages (Section 13). The Operator will inform you of the reason for any pause.
  7. Cooperation. The Operator will cooperate in good faith and will not unreasonably delay or block migration.
  8. Sanctions Registry check. The Receiving Provider will check the Sanctions Registry as part of its registration review. Migration may be refused if the applicant matches a sanction record (see Section 15.3).

9) Privacy-by-design encryption and key sharing

  1. Keypair creation. When you create an Account, your client generates a public/private encryption keypair. The private key never leaves your device and is not transmitted to the Operator.
  2. Key chain. Your Account maintains a key chain. The initial key pair is the first link. If you perform a key rotation (Section 5.7), the new key is added to the chain. Decryption of Attributes encrypted before a rotation requires walking the chain from the newest key to the original key. The server performs envelope wrapping server-side using only public keys; it never accesses plaintext key material.
  3. End-to-end encrypted attributes (where supported). Certain Attributes are stored end-to-end encrypted so that the Operator cannot read them in plaintext unless a decryption key is shared with us.
  4. Sharing by encrypted key delivery. When you share an Attribute:
    • with the Operator, the decryption key is shared encrypted to the Operator's public key; and/or
    • with another Member, the decryption key is shared encrypted to that Member's public key.
  5. Revocation. You may revoke sharing of Attributes individually or entirely. After revocation, the Network will no longer provide the recipient with keys needed to decrypt those Attributes.
    • Important: revocation prevents further access through the Network, but cannot guarantee deletion of plaintext copies a recipient may already have obtained outside the Network.
  6. Operational metadata. Even where data is encrypted, we may process necessary technical and operational data (e.g., timestamps, file sizes, usage logs, security logs, network data) to operate and secure the Network and comply with law.
  7. Data protection and your rights. The Operator processes personal data in accordance with the General Data Protection Regulation (GDPR) and applicable Dutch data protection law. Your rights — including access, rectification, portability, erasure, restriction, and objection — are described in the Privacy Policy (available at outpapier.nl). Where this Agreement permits permanent retention or restricts deletion (e.g., for archival or provenance purposes), the Operator will explain the applicable legal basis in the Privacy Policy.
  8. Non-circumvention of key-sharing controls. You must not request, distribute, or accept decryption keys outside the platform's key-sharing mechanisms in order to evade revocation, audit, or access controls. Off-platform key exchanges that circumvent the Network's sharing and revocation model may be treated as a breach of Section 10.
  9. Public claims. You may request that certain Attributes be published as public claims — plaintext records associated with your username and visible to anyone who queries your public profile. A public claim is derived from an existing encrypted Attribute: you share the encrypted Attribute with the Operator through the standard sharing protocol (§9.4), then submit a publication request. The encrypted original remains untouched. Publishing does not decrypt, expose, or modify the underlying encrypted Attribute.
  10. Operator validation and editorial discretion. No public claim is published without validation by the Operator. The Operator exercises editorial discretion — reviewing the shared Attribute data, applying the validation procedure appropriate for the claim type, and deciding whether to approve publication. The Operator may require vouching from established Members as part of the validation process. Upon approval, the public claim is signed by the Operator, attesting that the claim was reviewed and validated.
  11. Eligible claim types. Only the following Attribute types are eligible for public publication: display name, professional role, organization, website, location (city and country level), CPR signing key, and short biography. A Member may have multiple CPR signing key claims — one per machine on which the Catalog software is installed — and may publish any or all of them individually. Publishing a CPR signing key enables that key to sign attribution claims in the CPR. Sensitive Attribute types — including email, phone, postal address, bank account, and date of birth — are not eligible for public publication and must remain encrypted.
  12. License to publish. By requesting publication of an Attribute, you grant the Operator a worldwide, non-exclusive, royalty-free, perpetual license to publish the resulting public claim in cleartext, sign it with the operator's key, and serve it through public APIs and profile interfaces. This license survives account termination and your death, so that public attribution remains resolvable for archival and historical purposes.
  13. Revocation of publication during your lifetime. You may delete any public claim at any time during your lifetime. Deletion takes effect immediately: the Operator will cease serving the deleted public claim through its interfaces. You may also update a public claim at any time; updates follow the same validation process as initial publication. Upon deletion, the perpetual license granted in §9.12 ends with respect to the deleted public claim.
  14. Data protection. The Operator processes public claims in accordance with the GDPR and applicable Dutch data protection law. The applicable lawful bases and your rights with respect to public claims are described in the Privacy Policy (available at outpapier.nl).

9a) Third-party authentication ("Log in with Catalog.ID")

Catalog.ID may be used as an identity provider for third-party websites and services ("Relying Parties") through the OpenID Connect (OIDC) protocol. This section governs your use of third-party authentication. See Catalog.ID Whitepaper §11 for the full technical specification.

  1. Your consent controls disclosure. When you authenticate with a Relying Party, you choose which Attributes (if any) to disclose. No private Attribute data is shared with any Relying Party without your explicit, per-claim consent at authentication time. You may decline to share any non-essential claim and still complete authentication (unless the Relying Party has marked that claim as essential, in which case declining it cancels authentication).
  2. Public claims. Where you have published public claims (Section 9.9–9.14), a Relying Party that requests the openid profile scope receives your published claims without an additional consent screen. You have already authorized publication of these claims, and they are served as standard OIDC claims.
  3. Client-side claim preparation. Private claims are decrypted on your device and packaged as Selective Disclosure JWT (SD-JWT) disclosures before being transmitted. The Catalog.ID server does not access the plaintext of private claims during the authentication flow.
  4. Consent management. You may review, modify, and revoke Relying Party authorizations at any time through your Catalog.ID account settings. Revoking a Relying Party's authorization invalidates its refresh token immediately. Existing access tokens remain valid until they expire but cannot be renewed.
  5. Single sign-on and single logout. Once you authenticate with Catalog.ID, subsequent authorization requests from other Relying Parties within the same browser session may skip re-authentication. When you log out of Catalog.ID, all Relying Party sessions established through your current session are notified via front-channel logout.
  6. Relying Party registration. Before a Relying Party can offer "Log in with Catalog.ID," it must register with Catalog.ID through the developer portal. Catalog.org's own services are pre-registered Relying Parties with elevated trust.
  7. No accumulation of claims. A Relying Party cannot silently request additional claims after initial consent. Any change in requested claims triggers a new consent screen.
  8. Agent Identity tokens. Agent Identities may authenticate with Relying Parties through the authentication paths described in the Catalog.ID Whitepaper §3c.5.5. The resulting tokens are structurally identical to tokens issued for personal and delegate identities, and any Relying Party that accepts one accepts the other without modification. Relying Parties may inspect the IsHuman flag and PrincipalCatalogID fields to apply agent-specific policies.
  9. The Operator's role. The Operator operates the OIDC infrastructure (authorization endpoint, token endpoint, JWKS endpoint) and facilitates the authentication flow. The Operator does not control and is not responsible for Relying Parties' use of the information you choose to disclose. You should review each Relying Party's own privacy policy before sharing Attributes.
  10. No warranty of Relying Parties. The Operator does not endorse, verify, or guarantee any Relying Party's security practices, data handling, or compliance with applicable law. Authentication with a Relying Party is at your own risk.

10) Confidentiality and "no onward sharing" rule (core obligation)

  1. Consent required. You must not Onward Share another Member's Member Shared Data without that Member's explicit permission.
  2. Minimum disclosure. If a Member authorizes sharing, you must share only what is necessary and only with the authorized audience.
  3. No public disclosure. Unless a Member explicitly permits it, you must not publish Member Shared Data publicly (including on websites, social media, forums, or repositories).
  4. No re-identification / no doxxing. You must not attempt to identify, deanonymize, correlate, or dox Members based on identifiers, metadata, or combined information.
  5. Confidentiality survives. Your confidentiality obligations continue even if you stop using catalog.id or your membership ends.

Breach of this section is a serious violation and may result in immediate suspension or termination.

11) Collaboration norms (trust standard)

Membership on catalog.id carries an expectation of professional, respectful collaboration. Members agree to the following norms:

  1. Default confidentiality. Treat Member Shared Data as confidential unless the sharing Member explicitly marks it as public or redistributable.
  2. Consent-first sharing. Share only to the intended recipients. Obtain explicit permission before sharing more broadly.
  3. Attribution. Credit collaborators when building on their work, unless the contributor expressly waives attribution.
  4. Provenance. Where feasible, use Catalog tools to record provenance and creative process. A clear record helps protect everyone.
  5. Respect boundaries. Do not pressure other Members to share decryption keys, personal data, or content outside the platform's sharing mechanisms.
  6. Provenance key confidentiality. Where Members share CPR signing key claims (associating a CPR signing key with a Catalog.ID identity), the receiving Member must treat this association with the same confidentiality as any other Member Shared Data. A Member must not publicly disclose or share another Member's CPR key association without that Member's explicit consent. This applies to all CPR signing keys, including anonymous (unpublished) keys shared for arbitration or private verification purposes.

12) Respect for IP, provenance, and attribution

  1. Respect rights. You must respect the copyright, neighboring rights, database rights, moral rights, and other IP rights of other Members.
  2. No misrepresentation. You must not misrepresent authorship, provenance, or permissions.
  3. Collaboration is complex. Creativity often builds on interactions with others; IP claims can be subtle. The Network supports provenance and process recording to help Members support legitimate claims and enable fair challenges where appropriate.
  4. License only with consent. You may not redistribute another Member's protected content unless you have permission and a lawful basis to do so.

IP notice-and-cure procedure (7 days)

  1. IP Notice required. A Member alleging infringement must send the alleged infringer a written notice ("IP Notice") containing:
    • a link or content identifier for the allegedly infringing material;
    • a description of the alleged infringement;
    • the requested cure (e.g., removal, delisting, cessation of distribution, correction of attribution); and
    • any supporting evidence reasonably available.
  2. Response. Within 7 days of receiving an IP Notice, the recipient must: (a) comply with the requested cure; (b) submit a counterclaim with reasons and evidence; or (c) request clarification (which does not extend the cure period unless both parties agree).
  3. Failure to cure. Failure to respond or cure within the 7-day period triggers the liquidated damages under Section 13.2.
  4. Interim measures. Where there is credible risk of ongoing harm, the Operator may temporarily delist or restrict public access to the disputed content during the cure window.

13) Financial liability and liquidated damages

13.1 Doxxing and unlawful disclosure

Publishing or disclosing a Member's personal data or Member Shared Data without consent — including real name, address, telephone number, email, or other identifiers that enable targeting — whether by public posting or sharing to third parties, gives rise to liquidated damages of €10,000 minimum per incident, plus any higher actual damages and costs (uncapped), including reasonable mitigation and enforcement costs. These amounts are a pre-estimate of harm and enforcement costs. The Operator's right to apply platform sanctions (Section 15) and to seek injunctive relief is fully preserved.

13.2 Copyright and IP infringement (notice + cure)

If a Member is notified of alleged infringement of another Member's copyright, neighboring rights, or other IP rights and fails to cure within 7 days (e.g., by removing, delisting, or ceasing distribution and correcting attribution where relevant), liquidated damages of €2,500 per infringed work or content item apply, plus any higher actual damages and costs (uncapped), including reasonable mitigation and enforcement costs. Platform remedies under Section 15 — including takedown, required corrections, restrictions, and suspension or termination — are fully preserved.

13.3 Determination of liability

Liability under this section is determined through the dispute resolution process in Section 17 (between Members) or Section 18 (between a Member and the Operator). For safety cases (doxxing/unlawful disclosure), the Operator may also open and pursue the dispute process under Section 17.4 on behalf of the Network. This does not limit the Operator's right to impose immediate platform sanctions under Section 15.

13.4 Agent Identity liability

Where a breach of this Agreement is committed by or through an Agent Identity, liability attaches to the Principal. The Principal is liable for liquidated damages and actual damages under this section to the same extent as if the Principal had performed the act directly. The existence of an Agent Identity as intermediary does not reduce, limit, or excuse the Principal's liability.

13.5 Mandatory law

Where mandatory law applies, a court may adjust a contractual penalty if fairness clearly requires it.

14) Prohibited conduct

You must not use catalog.id to:

  • harass, threaten, stalk, or intimidate others;
  • facilitate illegal activity;
  • distribute malware, attempt unauthorized access, or abuse the Network;
  • scrape or bulk-collect Member data;
  • trade or sell access to decryption keys or Member Shared Data without consent;
  • impersonate others or mislead Members about identity or authority.

15) Enforcement and remedies (within the Network)

To protect Members and enforce this Agreement, the Operator may:

  • issue warnings or require corrective actions;
  • restrict features (including sharing, publication, messaging, or API access);
  • suspend or terminate Accounts;
  • apply reputation or trust-status changes where applicable;
  • cooperate with lawful requests from competent authorities.

We may act immediately in urgent cases (see Emergency Measures in Section 17.3).

15.1 Duty to mitigate and cooperate

  1. Mitigation. Members must promptly take reasonable steps to mitigate harm arising from a breach — including removing disclosures under their control, revoking access, and ceasing distribution.
  2. Evidence preservation. Members must preserve relevant evidence and cooperate with arbitration panels and the Review Board confidentially.
  3. Limits. This duty does not require a Member to incriminate themselves or make disclosures that would be unlawful.

15.2 Repeat offender escalation

Repeated or patterned breaches of this Agreement may trigger escalating sanctions, up to and including permanent expulsion from the Network and permanent restrictions across all Network features (sharing, publication, messaging, and API access). The Operator will consider the nature, severity, and frequency of breaches when determining appropriate escalation.

15.3 Sanctions registry and re-registration prevention

  1. Sanction record creation. When a Member is expelled or permanently banned, the Operator creates a sanction record in the Sanctions Registry containing the information necessary for a registration reviewer to identify the sanctioned person (e.g., verified identity data, sanction type, date, and reason).
  2. Encrypted storage and access control. Sanction records are encrypted and accessible only to authorized registration reviewers at catalog.id operators. Sanction records are not published, shared with Members, or used for any purpose other than preventing re-registration and enforcing bans.
  3. Federated sharing. The Operator may share the Sanctions Registry with other licensed catalog.id operators to protect the Network as a whole. Receiving operators must apply equivalent confidentiality and access controls.
  4. Flag-and-review, not automatic rejection. A potential match between a new applicant and a sanction record triggers a human review, not automatic denial. The reviewer assesses whether the applicant is the same person as the sanctioned Member. The applicant is not informed of the sanctions match regardless of the outcome.
  5. Retention period. Sanction records are retained for the duration of the ban, with a minimum of 1 year and a maximum of 20 years from the date of expulsion. After the retention period expires, the record is deleted.
  6. Legal basis. The Sanctions Registry is maintained under GDPR Article 6(1)(f) (legitimate interest in network safety and prevention of re-registration by expelled members) and, where applicable, Article 17(3)(e) (defence of legal claims). This processing is proportionate because records are encrypted, access-restricted, and used solely during registration verification.
  7. Refusal and recourse. If registration is refused on the basis of a sanctions match, the Operator will inform the applicant that registration has been denied. The Operator is not required to disclose the existence or contents of the matching sanction record. The applicant may submit a brief written objection; the Operator will review it and issue a final written decision. This decision is final within the Network. Nothing in this clause limits the applicant's right to seek recourse before a competent court or data protection authority under applicable law.

16) Trust signals and good standing

  1. Trust indicators. The Operator may display limited trust indicators associated with Accounts (e.g., address verified, Arbiter status, good standing) to support safer collaboration between Members.
  2. Minimal and factual. Trust indicators are limited to factual status information. The Operator will not publish detailed allegations, dispute history, or confidential information through trust indicators.
  3. Feature gating. The Operator may restrict certain features or collaboration tools to Members who have completed specific verification steps (e.g., address verification under Section 7) or who maintain good standing.
  4. No guarantee. Trust indicators are informational and do not constitute a warranty, endorsement, or guarantee of a Member's identity, reliability, or conduct.

17) Dispute resolution between Members (phased, Network-first)

This section applies to disputes between Members arising from use of the Network, including confidentiality breaches, Onward Sharing, IP disputes, harassment, and misuse of keys.

17.1 Informal resolution (encouraged)

Members should first try to resolve disputes directly and in good faith using available tools (messages, clarification, takedown requests, revocation of sharing). Either party may proceed immediately to Emergency Measures if necessary.

17.2 Mandatory personal conversation (pre-arbitration)

Before either party may file for Stage 1 arbitration, the parties must participate in a face-to-face conversation of at least 60 minutes, conducted via live video or in person, with the aim of reaching a mutually acceptable resolution. The parties may end the conversation early by mutual agreement if a resolution is reached before the minimum time has elapsed. This requirement does not apply where Emergency Measures have been invoked under Section 17.3.

  1. Recording. The conversation must be recorded by the platform-provided recording facility. Both parties consent to this recording as a condition of proceeding.
  2. Confidentiality upon agreement. If the parties reach a resolution during or as a result of the conversation, the recording remains strictly confidential and may not be disclosed, used, or referenced by either party, the Operator, or any arbiter.
  3. Disclosure to arbiters upon failure. If the parties do not reach a resolution and the dispute proceeds to Stage 1 or Stage 2 arbitration, the recording is disclosed to the arbitration panel or Review Board as evidence. The panel must treat the recording with the same confidentiality obligations that apply to all dispute materials under Section 17.5.
  4. Use in court proceedings. If arbitration does not resolve the dispute and either party brings the matter before a competent court under Section 17.8, the recording may be submitted as evidence in those proceedings, subject to applicable rules of evidence and any court-imposed confidentiality orders.
  5. Additional conversations ordered by arbiters. During Stage 1 or Stage 2 proceedings, the arbitration panel or Review Board may order the parties to participate in one or more additional face-to-face conversations before issuing a decision. These additional conversations follow the same recording, confidentiality, and disclosure rules as the initial conversation under this section.

17.3 Emergency Measures (fast protection)

Where there is credible risk of ongoing harm (e.g., doxxing, unlawful disclosure, harassment, or active misuse of keys), the Operator may impose temporary measures, such as:

  • temporarily restricting sharing/publication/messaging;
  • temporarily delisting public pages or public access (where applicable);
  • temporarily freezing specific sharing relationships or keys (platform-side controls).

Emergency Measures are temporary and expire after 14 days unless:

  • the affected Member consents to an extension;
  • a Stage 1 panel or Stage 2 Review Board confirms or modifies the measures; or
  • the Operator determines, with documented reasons, that the risk of harm persists and extends the measures for an additional 14-day period (renewable under the same standard).

The Operator will notify the affected Member of any Emergency Measures and the reasons for them as soon as practicable.

17.4 Safety cases: doxxing and unlawful disclosure

  1. No filing fee for the affected Member. In cases involving doxxing or unlawful disclosure (as described in Sections 10.4 and 13.1), the affected Member is not required to pay the standard Stage 1 filing fee. The Operator may permit the affected Member to open a case for a nominal fee of €50 (solely to deter misuse) or may open and pursue the case on behalf of the Network at its own initiative.
  2. Respondent deposit. If the Respondent disputes the allegation and wishes to proceed to Stage 1 arbitration or regain restricted access pending the outcome, the Operator may require the Respondent to post a deposit of €1,500. If the Respondent is cleared, the deposit is returned in full.
  3. Arbitration cost allocation in safety cases. The panel allocates arbitration costs in its decision:
    • If the Respondent is found liable: costs are deducted from the Respondent's deposit before any remainder is returned.
    • If the Respondent is cleared and the claim was frivolous or made in bad faith: the panel may order the claimant to pay the arbitration costs directly. The Operator may advance costs and recover them from the claimant.
    • If the Respondent is cleared and the claim was made in good faith: the Operator bears the arbitration costs as a Network safety expenditure.
  4. Refusal to post deposit. If the Respondent does not post the required deposit, the Operator may maintain Emergency Measures and/or impose sanctions under Section 15, and the matter may be decided on the available evidence or referred to Stage 2.
  5. Confidential handling. Evidence and identity data in safety cases must be handled with heightened confidentiality by the panel, the parties, and the Operator.

17.5 Stage 1 — Member Arbitration Panel (default)

  1. Arbiter Registry. Members may list themselves as Arbiters subject to eligibility rules and conflict-of-interest standards published by the Operator.
  2. Panel selection (3 Arbiters).
    • Each party selects one Arbiter from the Registry.
    • Those two Arbiters select a third Arbiter as chair.
    • If the panel cannot be formed within 7 days, the dispute moves to Stage 2.
  3. Conflicts and challenges. An Arbiter must disclose conflicts. A party may challenge an Arbiter for bias; the chair (or the Operator if no chair yet) decides the challenge.
  4. Process and confidentiality. Submissions are confidential to the panel and parties. Parties must not publish filings or evidence without consent of the other party (except where legally required).
  5. Decision standard. The panel decides by majority (2 of 3).
  6. Timing. The panel aims to decide within 21 days of formation unless complexity requires more time.
  7. Fees.
    • Standard filing fee (non-safety disputes): €1,500, paid by the claimant as a deposit to open a Stage 1 case.
    • Safety cases (Section 17.4): the affected Member pays a nominal fee of €50 or no fee if the Operator opens the case; the Respondent deposit rules in Section 17.4 apply.
    • The panel may allocate costs in its decision (e.g., order reimbursement of filing fees, deposit, and reasonable costs to the prevailing party).
  8. Remedies (platform-focused). The panel may order remedies within the Network, including:
    • cessation of Onward Sharing and revocation/cessation of access;
    • removal/delisting of public access (where applicable);
    • required notices/corrections/attribution;
    • trust-status impacts;
    • temporary or permanent access restrictions.
  9. Binding within the Network. Panel decisions are binding as a condition of membership. Refusal to comply may result in suspension or termination.

17.6 Arbiter duties

  1. Confidentiality. Arbiters must treat all dispute materials, submissions, deliberations, and decisions as strictly confidential. Arbiters must not reuse, disclose, or reference dispute materials outside the proceedings.
  2. Conflict of interest. Arbiters must promptly disclose any relationship, interest, or circumstance that could reasonably create a conflict of interest or appearance of bias. An Arbiter with a disclosed conflict must recuse themselves unless both parties consent in writing.
  3. Impartiality. Arbiters must act impartially and independently, free from outside influence or pressure from either party or the Operator.
  4. Sanctions for breach. An Arbiter who breaches these duties may be removed from the Arbiter Registry, subjected to membership sanctions under Section 15, and held liable for resulting damages.

17.7 Stage 2 — Review Board (appeal / formation failure / serious cases)

Stage 2 applies if:

  • a Stage 1 panel cannot be formed; or
  • there is a credible claim of procedural unfairness, undisclosed conflict of interest, or new decisive evidence; or
  • the Operator determines the matter is exceptionally serious for Network integrity.

Board composition (4 persons):

  • Chair: Founder Roberto Bourgonjen, or the Founder's written appointee; and
  • three (3) Members selected from an eligible pool (e.g., experienced Arbiters), with disclosed conflicts.

Decision standard: majority (at least 3 of 4) unless the Board decides a higher standard is required for specific sanctions (e.g., permanent expulsion).

Timing: aims to decide within 30 days.

Effect: Binding within the Network. Non-compliance may result in suspension or termination.

17.8 Stage 3 — Court (last resort)

If the dispute cannot be resolved through Stages 1–2, either party may bring the dispute before the competent court under Section 26.

18) Dispute resolution between a Member and the Operator

This section applies to disputes between a Member and the Operator arising from this Agreement, including enforcement actions, account decisions, and operational matters. (Member-to-member disputes are governed by Section 17.)

18.1 Informal resolution (mandatory)

Before initiating formal proceedings, you must contact the Operator at [email protected] describing your dispute. The Operator will attempt to resolve the matter within 30 days. Both parties agree to engage in good faith.

18.2 Mediation (mandatory)

If informal resolution does not resolve the dispute, either party may refer the matter to mediation administered by a qualified mediator in the Netherlands, agreed upon by the parties or, failing agreement, appointed by the competent court. Each party bears its own mediation costs; the mediator's fees are shared equally. Mediation shall conclude within 60 days of referral unless the parties agree to extend.

18.3 Court (last resort)

If the dispute is not resolved through Sections 18.1–18.2, either party may bring the dispute before the competent court under Section 26.

Urgent relief. Nothing in this section prevents either party from seeking interim or injunctive relief from a competent court where necessary to prevent irreparable harm.

19) Limitations and disclaimers

catalog.id is provided as is and as available to the maximum extent permitted by law. We do not guarantee that Members will comply with this Agreement, but we do provide tools and enforcement mechanisms and will act where appropriate.

Some jurisdictions do not allow certain disclaimers; mandatory rights remain unaffected.

20) Changes to this Agreement

We may update this Agreement. If changes are material, we will provide notice within the Network or via reasonable channels. Continued use after the effective date constitutes acceptance.

21) Termination

You may stop using catalog.id at any time. We may suspend or terminate your membership for breach, safety, security, legal compliance, or non-payment of applicable fees. Sections intended to survive (including confidentiality under Section 10 and sanction records under Section 15.3) survive termination.

22) Force majeure

Neither Party shall be liable for delays or failures in performance resulting from events beyond its reasonable control, including natural disasters, war, terrorism, cyberattacks, pandemic, government action, or internet/infrastructure failures. This does not excuse a Member's obligations under Section 10 (Confidentiality).

23) Severability

If any provision of this Agreement is held invalid, illegal, or unenforceable, the remaining provisions continue in full force. The invalid provision shall be modified to the minimum extent necessary to make it enforceable while preserving its intent.

24) Waiver

Failure or delay by the Operator or any Member in enforcing a provision of this Agreement does not constitute a waiver of that provision or of the right to enforce it later.

25) Governing law

This Agreement is governed by the laws of the Netherlands, excluding conflict-of-law rules, unless mandatory consumer law requires otherwise.

26) Venue / court

If a dispute proceeds to court (Stage 3), it shall be brought before the competent court in the Netherlands in the jurisdiction where the Operator is established, unless mandatory consumer law requires a different venue.

27) Contact

Stichting Outpapier
Website: outpapier.nl
Email: [email protected]