Catalog.ID Membership Agreement

Operator: Stichting Outpapier, identified by Operator ID b4np (Netherlands) ("Operator", "we", "us")
Founder / Network Creator: Roberto Bourgonjen ("Founder"; referred to as "the Developer" in the Catalog.ID Whitepaper)
Last updated: 2026-09-23

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 independent licensed operators (foundations or licensed corporations) 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, and 17.3).
  • Efficient dispute resolution — Member arbiters resolve Member-to-Member disputes inside the Network before court (Section 17); disputes with the Operator follow a mandatory informal-resolution and mediation process (Section 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 / Personal Identity: 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 system-assigned username in the 123abcd456 format (with the Organization's domain name held as a validated domain claim), and operated day-to-day through Delegate Identities. Organization Identities are not Members and are governed by the Organization Identity Agreement. See Catalog.ID Whitepaper §3a.
  • Delegate: a natural person who operates a Delegate Identity — a separate identity type (username format ab12cd34fg) created by an Organization for a person acting in that Organization's capacity — in one or more defined roles (owner, admin, treasurer, or viewer). Delegates are not Members and are not parties to this Agreement: they operate under the legal responsibility of their Organization pursuant to the Organization Identity Agreement, and personally accept the Delegate Terms at activation of the Delegate Identity. A Delegate accesses the Organization Identity's keys through wrapped key copies encrypted to the Delegate Identity's own keys (see Catalog.ID Whitepaper §3a.3–3a.4, §3b). A Delegate who separately holds a Personal Account is a Member with respect to that Personal Account only.
  • Organization Identity Agreement: the Catalog.ID Organization Identity Agreement, the separate agreement between the Operator and an Organization governing Organization Identities and their Delegate Identities.
  • Delegate Terms: the Catalog.ID Delegate Terms, the usage rules each Delegate personally accepts at activation of a Delegate Identity.
  • Member Shared Data: any data another Member, Organization Identity, or Delegate 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. "Onward Share" has the corresponding verbal meaning.
  • CPR: the Catalog Provenance Registry, the provenance and claims registry operated alongside catalog.id (see the CPR Whitepaper).
  • Supersecret: the locally generated recovery credential that encrypts your Key Bag for backup and restore. It is never transmitted to or stored by the Operator (see Catalog.ID Whitepaper §3.4.3).
  • Key Bag: the set of your individually encrypted private-key entries stored on the Operator's servers, which the Operator cannot decrypt (see Catalog.ID Whitepaper §3.4).
  • Key Chain: the ordered sequence of your Account's encryption keys across key rotations (Section 9.2).
  • 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 and have no independent key custody: they have their own registered public keys, but all private keys are generated by and held in the Principal's key bag. They operate under the Principal's legal framework. See Catalog.ID Whitepaper §3c.
  • Principal: the 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. For the purposes of this Agreement, a Principal is a Member acting through their Personal Account; Agent Identities whose Principal is a Delegate Identity are governed by the Organization Identity Agreement (see Catalog.ID Whitepaper §3c.10).
  • 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 system-assigned username linked to a validated domain claim, are not Members, and are operated day-to-day through Delegate Identities created by the Organization for its personnel (who need not be Members). See Catalog.ID Whitepaper §3a–3b.
  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, capacity, and sanctions compliance. 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, that you have full legal capacity to enter into this Agreement, and that you are not subject to sanctions or listed on any EU, UN, or other applicable sanctions list that would prohibit the Operator from providing services to you. Your use of the Network must comply with applicable export control and sanctions laws.
  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 Delegate Identity created for you by that Organization (governed by the Organization Identity Agreement and the Delegate Terms) — not through your Personal Account.
  7. Delegate Identities are outside this Agreement. Your membership under this Agreement is independent of any Delegate Identity you operate for an Organization:
    • actions taken through a Delegate Identity are governed by the Organization Identity Agreement (as to the Organization) and by the Delegate Terms you accept at delegate-identity activation (as to you personally) — not by this Agreement;
    • the Organization is the responsible contracting party for the use of its Delegate Identities;
    • actions taken through your Personal Account remain governed by this Agreement, including when you collaborate with Organizations;
    • linking your Personal Account to a Delegate Identity (Catalog.ID Whitepaper §3b.5) is a session convenience and does not merge the two identities or their legal frameworks; and
    • you must not use a Delegate Identity to circumvent sharing controls, revocation, consent requirements, or sanctions that apply to you under this Agreement, and you must not use your Personal Account to evade restrictions that apply to your Delegate Identity.
  8. Agent Identity responsibilities. You may create Agent Identities linked to your Personal Account. 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.
      Agent Identities created through a Delegate Identity are governed by the Organization Identity Agreement, not by this Agreement (see Catalog.ID Whitepaper §3c.10).
  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 must provide a valid email address and telephone number. Both are validated to complete activation. They are not disclosed to the Operator: validation is performed by the Validator Black Box — a physically and logically isolated validation service (see Catalog.ID Whitepaper §6) — which accesses them only for the validation flow, after which they are stored as end-to-end encrypted Attributes (Section 5.2). You may provide additional Attributes, including your full legal name and address. Certain features, trust levels, and public claim validations require you to provide and validate additional Attributes (for example, a verified address under Section 7). You must keep the information you provide accurate and up to date.
  2. Encrypted storage. Personal attributes you provide during registration or later — including your email address, telephone number, and (if provided) full legal name and address — are stored as end-to-end encrypted Attributes as described in Section 9. The Validator Black Box receives a decryption key only for the duration of a validation flow and issues a signed validation certificate; the Operator's core systems never receive these Attributes in plaintext unless you separately share a decryption key with the Operator (Section 9.4). 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 keys are generated in your browser. They are stored on the Operator's servers (and replicated across the federated network) only as individually encrypted Key Bag entries, encrypted with a key derived from your Supersecret. Your plaintext private keys and your Supersecret are never transmitted to any server, so neither the Operator nor any other operator can decrypt, access, recover, or escrow your private keys. You are solely responsible for the safekeeping of your Supersecret and password. The system presents your Supersecret for export during registration, and the export function remains available thereafter (see Catalog.ID Whitepaper §3.4, §10).
  5. Key loss. If you lose your Supersecret and no longer have any device with imported keys, 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 other than completed migration under Section 8, in which case your username continues with your Account under the Receiving Provider), 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 under your Personal Account 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. Usernames of Agent Identities created through a Delegate Identity are licensed under the Organization Identity Agreement.

6) Registration processing fee

  1. Fee. The Operator charges a one-time registration processing fee of €279, inclusive of VAT where applicable, 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). If the Operator refuses your application, any part of the fee attributable to processing and verification not yet performed is refunded within 14 days.
  3. Non-refundable. Subject to Sections 6.4–6.5, the fee is non-refundable once processing and verification have been fully performed.
  4. Right of withdrawal (consumers). If you are a consumer in the EU/EEA, you may withdraw from this Agreement within 14 days of its conclusion without giving reasons, by notice to the Operator (Section 27); a model withdrawal form is available at catalog.id/terms/withdrawal-form/.
  5. Immediate performance. By submitting your application you expressly request that processing and verification begin immediately, before the withdrawal period expires, and you acknowledge that you lose the right of withdrawal once processing and verification have been fully performed. If you withdraw before full performance, you owe only a proportionate part of the fee for the processing already performed; the remainder is refunded within 14 days.

7) Address verification by mail

  1. Sharing required. To initiate address verification, you must share your address Attribute with the Validator Black Box (per Section 9). Like email and telephone validation (Section 5.1), address verification is executed by the Validator Black Box; your address is not disclosed to the Operator's core systems in plaintext.
  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 transfers the contractual relationship and your Account's origin-node designation to the Receiving Provider; it is not an automatic right of acceptance by the Receiving Provider. Migration is available once one or more other licensed operators are active in the Network; at the date stated above, the Operator is the sole licensed operator.
  2. How migration works. Because every licensed node already holds a complete replica of all account data — your Account identity, public keys, encrypted Attributes (ciphertext), and provenance references (see Catalog.ID Whitepaper §15.3) — migration requires no data export or transfer by you. Upon a valid migration request and the Receiving Provider's acceptance, the Operator will cooperate to update your Account's origin-node designation within 30 days. No decryption keys are shared with any operator as part of migration.
  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. Key creation. When you create an Account, your client generates a set of public/private key pairs, each serving a distinct purpose (for example Attribute encryption and messaging), collectively managed as your Key Bag. Plaintext private keys never leave your device; they are stored on the server only as Key Bag entries encrypted under your Supersecret, which the Operator cannot decrypt (see Catalog.ID Whitepaper §3.4).
  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, an Organization Identity, a Delegate Identity, or an Agent Identity, the decryption key is shared encrypted to that recipient'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), professional or public contact email, professional or public contact telephone, 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 — 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. This deletion right survives termination of your membership for any reason: as long as you are living, you may request deletion of your public claims at any time, including after your Account has been terminated, and the Operator will cease serving them immediately.
  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 Member Shared Data without the explicit permission of the sharing party. Where the sharer is an Organization Identity or a Delegate Identity acting for its Organization, permission is given by the Organization; where the shared data is a Delegate's own personal data, the consent of the Delegate concerned is also required.
  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 any natural person behind a Catalog.ID identity — including Members, Delegates, and holders of anonymous CPR signing keys — 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.
  6. Obligations toward Organizations. Confidentiality obligations regarding data shared by an Organization Identity or Delegate Identity are owed to the Operator and to the Organization concerned, which may enforce them as a third-party beneficiary of this Agreement.

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 or a Delegate Identity's CPR key association without the explicit consent of that Member or (for Delegate Identities) the Organization and Delegate concerned. 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 the personal data of a Member or of any natural person behind a Catalog.ID identity (including a Delegate) 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. This section applies to Agent Identities whose Principal is a Member acting through their Personal Account; Agent Identities with Delegate Identity principals are governed by the Organization Identity Agreement.

13.5 Proportionality and mandatory law

The amounts in this section are a genuine pre-estimate of minimum harm and enforcement costs for serious breaches. The arbitration panel, the Review Board, and any competent court shall reduce a liquidated amount where its application would be manifestly disproportionate in the circumstances, taking into account the nature, severity, and duration of the breach, the degree of fault, the harm actually caused or likely, and the breaching Member's conduct after notice (including prompt cure and mitigation). Liquidated damages are credited against any award of actual damages for the same incident. Nothing in this section limits mandatory protections you enjoy as a consumer, including judicial review of penalty clauses.

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 proactively informed that a potential match occurred or that a review took place; if the review results in refusal of registration, the notification and objection process in Section 15.3.7 applies, and the Operator informs the applicant of the denial without confirming or denying the existence of a sanction record. Data subject rights under the GDPR, including the right of access, remain available and are handled in accordance with the Privacy Policy; the Operator may restrict them only where and to the extent a legal ground under GDPR Article 23 (as implemented in Dutch law) applies, such as the establishment or defence of legal claims or the prevention of circumvention of sanctions.
  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. It also applies to safety cases that the Operator opens on behalf of the Network under Section 17.4 (which are not Member–Operator disputes under Section 18) and, mutatis mutandis, to disputes between a Member and an Organization Identity, with the Organization appearing through an owner Delegate Identity or another Delegate Identity authorized in writing, as provided in the Organization Identity Agreement.

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 or in safety cases under Section 17.4, and the Operator may waive it where a face-to-face conversation would be inappropriate (for example, in harassment cases); either party may request such a waiver.

  1. Recording. The conversation is recorded by the platform-provided recording facility as a necessary part of the dispute procedure under this Agreement. Both parties are informed of the recording before it begins; its processing is described in the Privacy Policy.
  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 (Section 17.5.7). 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. Demonstrated inability (as opposed to refusal) to post the deposit does not by itself count against the Respondent on the merits; the Operator may reduce or waive the deposit in cases of demonstrated financial hardship.
  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 at most a nominal fee of €50 as determined under Section 17.4.1, or no fee if the Operator opens the case; the Respondent deposit rules in Section 17.4 apply.
    • The Operator may reduce or waive the filing fee in cases of demonstrated financial hardship.
    • The panel may allocate costs in its decision and shall order reimbursement of the filing fee to a prevailing claimant (and may order reimbursement of deposits 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 within the Network as to platform remedies (Section 17.5.8) 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 as to platform remedies. 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 31.

17.9 Consumer rights preserved

Nothing in Sections 17–18 deprives a Member acting as a consumer of the right to bring or defend a claim before the competent court under mandatory law. Where Stage 1 arbitration is invoked against you as a consumer, you may within one month of that invocation elect in writing to have the dispute decided by the competent court instead (Article 6:236(n) of the Dutch Civil Code). Panel and Review Board decisions bind Members only as to remedies within the Network (Section 17.5.8) as a condition of membership; they constitute an internal complaint and enforcement scheme, not an arbitral award under the Dutch Arbitration Act, and do not bar access to court. The filing fee and deposit rules of this section never limit your right to bring a dispute before the competent court instead.

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, except that where the Member is a consumer, the Operator bears the mediator's fees. Mediation shall conclude within 60 days of referral unless the parties agree to extend. Mediation is without prejudice to a consumer's right to bring the dispute before the competent court at any time (Section 17.9 applies mutatis mutandis).

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 31.

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, disclaimers, and liability

  1. Service standard. The Operator will provide the Network with reasonable skill and care. If you are a consumer in the EU/EEA, the Network must conform to this Agreement and to mandatory conformity requirements for digital services (Directive (EU) 2019/770 as implemented in Dutch law), and your statutory remedies for non-conformity remain unaffected. Subject to the foregoing, the Network is provided as available: we do not guarantee uninterrupted availability, and we do not guarantee that Members will comply with this Agreement, but we provide tools and enforcement mechanisms and will act where appropriate.
  2. Liability cap. Except in cases of intent or deliberate recklessness of the Operator or its managers, or liability for death or personal injury, the Operator's aggregate liability to you under or in connection with this Agreement is limited to the registration processing fee you paid (Section 6.1). The Operator is not liable for loss of encrypted data resulting from the loss of your own Supersecret or keys (Section 5.5), or for the acts of other Members, Organizations, Delegates, or Relying Parties.
  3. Mandatory rights. Some jurisdictions do not allow certain disclaimers or limitations; this section applies only to the extent permitted, and rights that mandatory (consumer) law does not allow to be limited remain unaffected.

20) Indemnification

You will indemnify and hold harmless the Operator against third-party claims, damages, and reasonable costs (including legal fees) to the extent arising from your breach of Sections 10, 12, 13.1, or 14 or your unlawful use of the Network, except to the extent the claim is attributable to the Operator. If you are a consumer, this obligation applies only to the extent permitted by mandatory law and only to breaches attributable to you.

21) Changes to this Agreement

We may update this Agreement. For material changes we will give at least 30 days' advance notice by email and/or in-Network notification, stating the effective date. If you do not accept a material change, you may terminate your membership or migrate under Section 8 before the effective date; continued use after the effective date constitutes acceptance. Changes required by law, court order, or urgent security needs may take effect immediately, with notice as soon as practicable. No change retroactively reduces the encryption and consent guarantees of Section 9 for data already stored.

22) Termination

  1. By you. You may stop using catalog.id and terminate your membership at any time.
  2. By the Operator. We may suspend or terminate your membership for breach, safety, security, legal compliance, or non-payment of amounts due under this Agreement (such as dispute filing fees, deposits, cost allocations, or liquidated damages under Sections 13 and 17).
  3. Effects of termination. Upon termination for any reason other than completed migration under Section 8, your encrypted Attributes, keys, and validation certificates are permanently destroyed, and your username is permanently retired and never reassigned (Section 5.8). Public claims persist under the license in Section 9.12 unless deleted (Section 9.13). CPR provenance records remain in the immutable record. Where your membership ends through completed migration under Section 8, your Account, keys, encrypted Attributes, and username continue under the Receiving Provider's agreement: only your contractual relationship with the Operator ends, and nothing is destroyed or retired.
  4. Survival. The following survive termination for any reason: Section 3 (definitions as used in surviving sections), Section 5.8 (username retirement and license consequences), Sections 9.12–9.14 (publication license and revocation), Section 10 (confidentiality), Sections 12.5–12.8 and 13 (for breaches arising before termination), Section 15.3 (sanction records), Sections 17–18 (for disputes arising from pre-termination facts), and Sections 19, 20, and 24–31.

23) Death of a Member

Upon verified notification of your death (by family, heirs, an executor, or otherwise), the Operator terminates the Account with the effects of Section 22.3. Heirs and estates do not acquire access to the Account or to encrypted Attributes; the Operator holds no decryption keys and cannot provide plaintext (Section 5.4). Public claims persist under the license in Section 9.12 for archival and attribution purposes unless deleted before death. CPR provenance claims remain immutable historical records. No fee refund is due. See Catalog.ID Whitepaper §16.

24) Force majeure

Neither the Operator nor the Member 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).

25) 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.

26) 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.

27) Notices

  1. Legal notices to the Operator must be sent to [email protected] or the Operator's registered office and are effective on receipt.
  2. The Operator gives notices to you via your registered email address and/or in-Network notification; notices are deemed received 48 hours after sending, provided your contact details are current (Section 5.1).
  3. IP Notices under Section 12 and dispute filings under Section 17 must be submitted through the Network's designated dispute interface or, if unavailable, by email.

28) Assignment

  1. The Operator may assign this Agreement, in whole, to a successor foundation or licensed catalog.id operator that assumes the Operator's obligations, including in connection with a transfer of Network stewardship. We will notify you of any assignment; if you object, you may migrate under Section 8 or terminate your membership.
  2. You may not assign or transfer your membership or Account; account portability is governed exclusively by Section 8.

29) Entire agreement and precedence

This Agreement, together with the Privacy Policy and, where you use the Catalog.org Cloud Services, the Catalog EULA and Cloud Services Terms, constitutes the entire agreement regarding your catalog.id membership. In case of conflict concerning membership, identity, or the matters governed by this Agreement, this Agreement prevails. The Catalog.ID Whitepaper is referenced for technical explanation only and creates no contractual obligations. The Organization Identity Agreement and the Delegate Terms govern Organization Identities and Delegate Identities respectively and do not modify this Agreement.

30) Governing law

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

31) 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.

32) Contact

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