Dispatch A. J. Campling Internet-Draft 419 Consulting Limited Intended status: Standard G. Scalone Expires: 6 January 2027 Vodafone A.Taddei 6 July 2026 PARCEP Protocol and Architecture for Networked Parental Controls draft-campling-parcep-sync-00 Abstract PARCEP-Sync specifies a federated synchronization protocol and data model for guardian-controlled Child Online Protection, enabling household policies to be authored at a Policy Administration Point (PAP), distributed over a per-household Messaging Layer Security (MLS) group to Policy Enforcement Points (PEPs), and enforced using credentials and artifacts issued by jurisdictional Policy Information Points (PIPs). The protocol defines a small, regular set of methods for enrolment, policy publication and update, revocation, enforcement telemetry, digests, appeals, attestation, and artifact fetch, with dua l JSON-LD and CBOR/COSE encodings for web-scale and constrained environments. It is designed to avoid centralized databases of children s data, support cross-jurisdictional verification of guardianship and age, and provide privacy-preserving, metadata-only event reporting suitable for regulatory audit and appeal. Role of this draft This initial draft is a outline intended to help identify the topic area. It provides a suggested solution to the problem of fragmented parental controls that could be used as the starting point for a working group. It is not intended to be either complete or definitive. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Campling, et al. Expires 6 January 2027 [page 1] Internet-Draft PARCEP Protocol and Architecture July 2026 This Internet-Draft will expire on 6 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 4. Functional decomposition and data model . . . . . . . . . . . 5 4.1. Operator and service-hosted policy administration profile 6 5. PARCEP-Sync Protocol Overview. . . . . . . . .. . . . . . . . 7 5.1. Protocol Model. . . . . . . . . . . . . . . . . . . . . . 7 5.2. Canonical Transport . . . . . . . . . . . . . . . . . . . 7 5.3. Method Set. . . . . . . . . . . . . . . . . . . . . . . . 7 6. Discovery, Bootstrap, and Authentication. . . . . . . . . . . 8 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Bootstrap Flow. . . . . . . . . . . . . . . . . . . . . . 8 6.3. Authentication requirements . . . . . . . . . . . . . . . 8 7. Wire Format. . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Encoding Rules. . . . . . . . . . . . . . . . . . . . . . 8 7.2. Common Message Structure. . . . . . . . . . . . . . . . . 9 7.3. PUBLISH Message . . . . . . . . . . . . . . . . . . . . . 9 7.4. UPDATE Message. . . . . . . . . . . . . . . . . . . . . . 9 7.5. REVOKE Message. . . . . . . . . . . . . . . . . . . . . . 9 7.6. ACK Message . . . . . . . . . . . . . . . . . . . . . . . 9 7.7. EVENT Message . . . . . . . . . . . . . . . . . . . . . . 10 7.8. DIGEST Message. . . . . . . . . . . . . . . . . . . . . . 10 7.9. APPEAL and RESOLVE. . . . . . . . . . . . . . . . . . . . 10 7.10. ATTEST, FETCH, NOTIFY, and EXTEND . . . . . . . . . . . . 10 8. State Machine and Semantics. . . . . . . . . . . . . . . . . . 11 8.1. Enrolment state . . . . . . . . . . . . . . . . . . . . . 11 8.2. Policy application state. . . . . . . . . . . . . . . . . 11 8.3. Ordering and idempotency. . . . . . . . . . . . . . . . . 11 8.4. Appeal state. . . . . . . . . . . . . . . . . . . . . . . 11 9. Error Handling and Conformance . . . . . . . . . . . . . . . . 11 9.1. Status model. . . . . . . . . . . . . . . . . . . . . . . 11 9.2. Retry and recovery. . . . . . . . . . . . . . . . . . . . 12 Campling, et al. Expires 6 January 2027 [page 2] Internet-Draft PARCEP Protocol and Architecture July 2026 9.3. Conformance profiles. . . . . . . . . . . . . . . . . . . 12 10. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 10.1. Trust model . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Adversary classes . . . . . . . . . . . . . . . . . . . . 12 10.3. Privacy properties. . . . . . . . . . . . . . . . . . . . 13 10.4. Cryptographic agility . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 11.1. Method registry . . . . . . . . . . . . . . . . . . . . . 13 11.2. Reason-code registry. . . . . . . . . . . . . . . . . . . 13 11.3. Media types and namespaces. . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 14 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction PARCEP is a federated child online protection architecture that is intended to avoid a centralized database of children's data while still providing reliable policy distribution and enforcement across devices, applications, networks, and platforms. This document specifies the PARCEP-Sync protocol and the companion data model used to exchange policies, credentials, transparency notices, enforcement events, and appeals. The protocol is organized around four functional roles: the Policy Administration Point (PAP), the Policy Decision Point (PDP), the Policy Enforcement Point (PEP), and the Policy Information Point (PIP). The guardian authors the household policy at the PAP and signs it with a guardianship credential issued by a PIP. The architecture is intentionally federated rather than centralized. A centralized system would concentrate highly sensitive information such as children's identities, ages, household policies, and enforcement events in one place, while a fully decentralized system would lack reliable anchoring for trust, taxonomy, and credential verification. PARCEP therefore uses a federation of jurisdictional trust anchors, with independently auditable issuances and local policy enforcement under guardian control. The protocol is designed to support asynchronous membership changes and policy updates. A household may add a new device, remove a vendor, introduce a co-guardian, or change jurisdictional constraints over time. PARCEP-Sync therefore combines explicit versioning, authenticated group transport, and a small set of structured methods to make policy distribution deterministic and auditable. The protocol development is complementary to work underway within the ITU s Study Group 17 ( X.PARCEP ), which is addressing policies and principles for deployment and potentially for enforcement. Campling, et al. Expires 6 January 2027 [page 3] Internet-Draft PARCEP Protocol and Architecture July 2026 2. Conventions and terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the terminology of policy-based management and the architecture terms defined here. A guardian is a responsible adult with policy-authoring authority. A dependent is the rights-bearing subject of the policy. A household policy is the signed root policy object that governs one or more dependents, devices, and accounts. A Policy Administration Point (PAP) is the guardian-controlled authoring and signing surface. A Policy Decision Point (PDP) evaluates policy against runtime requests. A Policy Enforcement Point (PEP) applies the resulting enforcement action locally. A Policy Information Point (PIP) issues and attests credentials, taxonomies, model packages, and other signed artifacts. The terms policy version, artifact version, and conformance profile are used in a strict technical sense. A policy version is a monotonic identifier associated with a specific policy object. An artifact version identifies a signed taxonomy, model package, or regulatory override. A conformance profile identifies the supported feature subset of a PEP or related implementation. When this document says that an implementation is conformant, it means that it satisfies the requirements associated with the declared profile. 3. Architecture overview PARCEP is a federated, four-tier system. Tier 1 is the federation of jurisdictional trust anchors, or PIPs, that issue and attest the credentials, taxonomies, and signed classifier-model packages used by the rest of the system. Tier 2 is the PAP, which is guardian- controlled and is responsible for authoring, storing, and signing the household policy. Tier 3 is the PDP and PEP layer, distributed across devices, applications, network elements, and platforms, where the policy is evaluated and enforced locally. Tier 4 is the dependent, who receives transparency notices and can exercise the appeal channel. The federated design is the central architectural choice. It allows multiple independent jurisdictional roots, public auditability of issuances, and per-jurisdiction regulatory adaptation while keeping the household policy under guardian control. It also avoids a single repository of children's data, which is a stated non-goal of the overall system. At the same time, it preserves enough trust anchoring to support identity-grade age credentials, content taxonomies, and model attestation. The protocol model follows the division of responsibility common to policy-based management systems. The PAP is the authoring and distribution source for policy changes. The PDP validates signed Campling, et al. Expires 6 January 2027 [page 4] Internet-Draft PARCEP Protocol and Architecture July 2026 artifacts and makes policy decisions. The PEP enforces those decisions locally and emits metadata-only enforcement events. The PIP operates as a federated trust anchor and records issuances in a public transparency log. The canonical secure transport for household policy synchronization is a Messaging Layer Security group. The MLS group provides authenticated membership, forward secrecy, post-compromise security, and asynchronous group membership changes, all of which are useful in a household environment where devices are added and removed over time. A transport fallback using mTLS over HTTPS is available for bootstrap and legacy implementations that cannot yet participate in MLS. 4. Functional decomposition and data model The PARCEP functional decomposition consists of the PAP, PDP, PEP, and PIP roles. The PAP is implemented as a guardian-controlled application, which may be mobile, web-based, or a guardian-controlled cloud service. The PDP is, by default, co-located with the PEP and evaluates the signed household policy against runtime requests. The PEP is the component that blocks, allows, paces, delays, blurs, or warns based on the current policy. The PIP issues and attests the credentials and artifacts required for policy verification. The PAP MUST authenticate the guardian using strong authentication and MUST persist the canonical household policy under guardian authority. The PAP MAY offer age-graded presets to simplify onboarding and MAY offer an AI-assisted drafting function, but any such assistance remains subject to explicit guardian review and approval. The PAP is the source of PUBLISH, UPDATE, REVOKE, and RESOLVE messages. The PAP MAY also expose a guardian interface for reviewing digests, handling appeals, and managing co-guardian relationships. The PDP receives the signed HouseholdPolicy from the PAP and validates any referenced artifacts such as classifier-model packages, taxonomies, and jurisdictional overrides. It caches the policy locally for offline operation and evaluates the policy against runtime requests. For ISP or mobile-network deployments, the PDP MAY be remote while the PEP remains in the access network. In that case, the PEP still MUST enforce only policy that has been authenticated and validated according to the protocol rules. The PEP is the operational enforcement component. It implements the actual allow, block, warn, pace, blur, and redirect behavior required by the policy. The source design decomposes the PEP into reusable submodules for content and conduct enforcement, time management, contact and communication guard functions, commerce approval, and transparency and telemetry emission. The PEP is also the source of EVENT messages and the entry point for APPEAL messages from the dependent. The PIP is the federated trust anchor. It issues guardianship Campling, et al. Expires 6 January 2027 [page 5] Internet-Draft PARCEP Protocol and Architecture July 2026 credentials, age credentials, classifier-model credentials, content taxonomies, and jurisdictional override descriptors. Each issuance is recorded in a public transparency log modeled on Certificate Transparency. The design requires at least two independent PIPs for each jurisdictional function so that no single failure or compromise can block enforcement. The data schema is organized into five layers: identity, credentials, policy, operational, and discovery. The identity layer includes Guardian, CoGuardianRelation, Dependant, Device, and AccountBinding. The credentials layer includes GuardianshipCredential, AgeCredential, ClassifierModelCredential, TaxonomyArtifact, and JurisdictionalOverride. The policy layer includes HouseholdPolicy, PolicySubject, and the content, time, contact, commerce, conduct, and transparency clause sets. The operational layer includes EnforcementEvent, TransparencyNotice, AppealRequest, and GuardianDigest. The discovery layer includes PEPRegistration and PIPDescriptor. 4.1. Operator and service-hosted policy administration profile A Policy Administration Point (PAP) MAY be implemented as a guardian- facing service hosted by an operator or service provider, including applications, portals, or managed secure network offerings through which a guardian creates and manages a HouseholdPolicy. In such deployments, the guardian remains the policy author and authority. The tools, user interfaces, and storage used to create, manage, and persist policies MAY be operated by an ISP or service provider, but all policy-authoring actions MUST be attributable to and authorized by the guardian. An operator-hosted PAP MUST ensure that any HouseholdPolicy is created under explicit guardian action and is cryptographically bound to the guardian s credentials. The operator infrastructure MAY assist in policy composition, storage, synchronization, and presentation, but MUST NOT independently originate, modify, or enforce policy semantics without guardian authorization. A network-side Policy Enforcement Point (PEP) MAY be deployed within CPE, managed DNS infrastructure, ISP networks, or mobile access networks. Such PEPs act as enforcement components consuming the HouseholdPolicy and MUST enforce only authenticated policy produced under the guardian s authority. Where required by deployment architecture, the Policy Decision Point (PDP) MAY be implemented within operator infrastructure. In this case, the PDP evaluates the guardian-authored policy on behalf of network- side PEPs, while preserving the integrity, provenance, and versioning of the policy. Operator-hosted PAPs and network-based enforcement domains MUST Campling, et al. Expires 6 January 2027 [page 6] Internet-Draft PARCEP Protocol and Architecture July 2026 interoperate with device-based PAPs and PEPs so that a single guardian-authored HouseholdPolicy can be consistently created through operator-managed tools and enforced across device, network, and service layers. Operator-hosted PAPs MAY provide policy templates, presets, or assisted configuration flows, provided that activation of such policies requires explicit guardian consent and results in a guardian- authorized HouseholdPolicy. 5. PARCEP-Sync Protocol Overview 5.1. Protocol model PARCEP-Sync is the synchronization protocol used between the PAP, the PEPs, and the PIPs. The protocol is intentionally small and regular: each request has a corresponding acknowledgement or response, and each state-changing operation is identified by a policy or artifact version. Implementations MUST treat the household policy as the authoritative signed object for enforcement state. Implementations MUST NOT infer policy from unenforced local defaults when a valid household policy is available. 5.2. Canonical transport The canonical secure transport for PARCEP-Sync is MLS over QUIC for the household group. MLS provides authenticated group membership, forward secrecy, post-compromise security, and asynchronous group operations that match the protocol s membership and policy-update model. A PEP that is removed from the group MUST lose access to future group traffic after key rotation. An mTLS-over-HTTPS profile is permitted for bootstrap and for legacy PEPs that do not yet support MLS. 5.3. Method set PARCEP-Sync defines the following methods: ENROLL, WELCOME, PUBLISH, UPDATE, REVOKE, ACK, EVENT, DIGEST, APPEAL, RESOLVE, ATTEST, FETCH, NOTIFY, and EXTEND. The methods are deliberately symmetric and finite so that implementations can be verified against a closed state machine. Every method MUST be explicitly declared as idempotent or non-idempotent in the registry used by implementations. EXTEND is reserved for future expansion and MUST NOT alter the semantics of any registered method. Campling, et al. Expires 6 January 2027 [page 7] Internet-Draft PARCEP Protocol and Architecture July 2026 6. Discovery, Bootstrap, and Authentication 6.1. Discovery A PEP MUST discover the PAP before it can enroll. PARCEP supports two discovery mechanisms: DNS SVCB records under the household-issued domain and a per-PEP /.well-known/parcep resource. Discovery information MUST identify the enrollment endpoint and any bootstrap constraints needed to complete pairing. If both discovery mechanisms are present, the implementation SHOULD prefer the authoritative household domain record unless policy specifies otherwise. Discovery information MAY include operator-provided endpoints for policy management interfaces, including service-hosted PAP instances, allowing a PEP or dependent device to locate ISP-hosted policy- authoring tools associated with the household. 6.2. Bootstrap flow Bootstrap proceeds in three steps. First, the guardian or installer obtains the PEP s bootstrap material, such as a QR code containing the PEP public key, conformance profile, and nonce. Second, the PAP establishes a one-time authenticated channel to the PEP using mTLS and sends ENROLL. Third, if enrollment succeeds, the PAP sends WELCOME and the PEP is added to the household MLS group. Once the MLS group is established, all subsequent PAP-to-PEP communication MUST use the group channel unless policy or transport failure requires fallback. 6.3. Authentication requirements At the MLS layer, every member MUST be authenticated by an MLS credential bound to its public key. At the application layer, guardian-authored messages such as PUBLISH, UPDATE, REVOKE, and RESOLVE MUST be signed by the guardian s guardianship credential. PEPs and PIPs MUST authenticate using their respective device or issuer credentials. The PAP MUST protect guardian signing keys with strong authentication such as WebAuthn or equivalent two-factor authentication. 7. Wire Format 7.1. Encoding rules PARCEP-Sync uses a dual wire format. JSON-LD is used for policy authoring, dashboards, and audit-friendly exchanges, while CBOR with COSE signatures is used for constrained devices and telemetry. Implementations MUST preserve canonical encoding for any signed object. A signed object MUST contain an explicit version, object identifier, issuer or author identifier, and validity interval when applicable. Campling, et al. Expires 6 January 2027 [page 8] Internet-Draft PARCEP Protocol and Architecture July 2026 7.2. Common message structure All PARCEP-Sync application messages SHOULD include the following common fields: * messageId. * method. * senderId. * receiverId or targetGroup. * timestamp. * protocolVersion. * payload. * signature or proof, where applicable. An implementation receiving a message with an unknown mandatory field MUST reject the message with INVALID_SCHEMA. An implementation receiving an unsupported optional extension MAY ignore that extension if doing so does not change security or enforcement behavior. If the extension changes semantics, the message MUST be rejected. 7.3. PUBLISH message A PUBLISH message conveys a complete HouseholdPolicy object. The object MUST include policyId, policyVersion, validFrom, validTo, conformanceProfile, signedBy, jurisdictionalOverrideRefs, and one or more PolicySubject entries. The policyVersion MUST increase monotonically for a given policyId. A PUBLISH message MUST be rejected if the signature does not validate or if the policyVersion is not newer than the currently installed version. 7.4. UPDATE message An UPDATE message conveys a policy delta between two known policy versions. The message MUST include the policyId, previousPolicyVersion, newPolicyVersion, and the changed clauses. The receiver MUST NOT apply the delta unless the previous version is known and verified, either locally or via FETCH. UPDATE is idempotent with respect to the tuple (policyId, previousPolicyVersion, newPolicyVersion). 7.5. REVOKE message A REVOKE message invalidates a currently active policy version or credential reference. The message MUST identify the target policy or artifact by identifier and version or hash. Upon successful processing, a PEP MUST transition to the configured fail-safe posture or the previous valid state if that is more permissive and explicitly allowed by policy. A REVOKE message MUST be authenticated with the same strength as the original policy publication. 7.6. ACK message An ACK message confirms receipt and processing state for a previously Campling, et al. Expires 6 January 2027 [page 9] Internet-Draft PARCEP Protocol and Architecture July 2026 received PUBLISH, UPDATE, or REVOKE. The ACK message MUST include the original messageId or the policyVersion tuple, a processing status, and a structured reasonCode if the result is not APPLIED. An ACK MAY include a short explanatory text, but clients MUST NOT rely on that text for behavior. The authoritative result is the status and reasonCode. 7.7. EVENT message An EVENT message reports a local enforcement decision and MUST contain metadata only. The message MUST include eventId, policyVersion, pepId, timestamp, decision, category, and evidenceHash. The message MAY include classifierRef, confidence, and appealable. EVENT messages MUST NOT contain raw content, cleartext personal data, or any data not necessary to identify the event and support audit or appeal. 7.8. DIGEST message A DIGEST message conveys a guardian-readable summary of recent enforcement events. The digest MUST identify the time window, event categories, counts, and example event identifiers. A digest MAY include an AI-generated summary if and only if the summary is clearly marked as machine-generated and the configuration permits it. A digest intended for a dependant MUST use child-readable vocabulary if childReadable is enabled. 7.9. APPEAL and RESOLVE An APPEAL message conveys a dependant request to contest a local enforcement decision. The message MUST include the contestedEventId and a reason field, and it SHOULD identify the requested outcome. A RESOLVE message conveys the guardian s decision on that appeal. The guardian MAY accept the appeal, reject it, or issue a policy delta in response. A PEP MUST preserve appeal linkage so the event and resolution remain auditable. 7.10. ATTEST, FETCH, NOTIFY, and EXTEND An ATTEST message conveys a PEP s conformance profile and capabilities to a PIP registry. A FETCH message requests a signed artifact such as a taxonomy, classifier model, or jurisdictional override descriptor. A NOTIFY message conveys MLS-level membership or epoch changes, and implementations MUST treat it as control traffic rather than policy traffic. EXTEND is reserved for future methods and MUST be ignored by implementations that do not negotiate it explicitly. Campling, et al. Expires 6 January 2027 [page 10] Internet-Draft PARCEP Protocol and Architecture July 2026 8. State Machine and Semantics 8.1. Enrolment state A PEP begins in an unenrolled state. Upon successful discovery and authenticated ENROLL, it transitions to a pending-admission state. Upon WELCOME, it transitions to enrolled and MUST be able to receive policy messages through the MLS group. If enrollment fails, the PEP MUST remain unenrolled and MUST NOT receive household policy. 8.2. Policy application state A PEP that receives a valid PUBLISH message MUST verify the signature, validate referenced credentials, and then either apply or reject the policy. If the policy version is newer than the installed version, the PEP MUST update its local state and return ACK. If the policy cannot be applied because of missing dependencies, the PEP SHOULD request those dependencies with FETCH. If the policy is invalid or unauthenticated, the PEP MUST reject it and report the failure. A PEP MUST treat a valid HouseholdPolicy equivalently regardless of whether the policy was authored via a device-resident PAP or an operator-hosted PAP, provided that the policy is properly authenticated, signed, and bound to the guardian. 8.3. Ordering and idempotency All policy-changing messages MUST be idempotent with respect to the relevant identifier and version tuple. A PEP receiving an out-of-order version MUST NOT apply later policy before earlier policy is available or reconciled. When version gaps exist, the PEP SHOULD attempt recovery using FETCH before surfacing an error to the guardian. This rule ensures deterministic conflict resolution in multi-guardian or intermittent-connectivity scenarios. 8.4. Appeal state An appealable enforcement event MAY be contested by the dependant through APPEAL. The PAP MUST record the appeal and present it to the guardian for review. The guardian response in RESOLVE MUST be linked to the original event and the appeal request. If the guardian issues a policy delta, the new policy version MUST be treated as a normal policy update and propagated according to the same rules as PUBLISH or UPDATE. 9. Error Handling and Conformance 9.1. Status model Every response MUST carry one of the statuses OK, REJECTED, DEFERRED, or ERROR. The response MUST also carry a structured reasonCode when the status is not OK. The protocol defines reason codes such as Campling, et al. Expires 6 January 2027 [page 11] Internet-Draft PARCEP Protocol and Architecture July 2026 BAD_SIGNATURE, EXPIRED_CREDENTIAL, REVOKED_CREDENTIAL, UNSUPPORTED_PROFILE, INVALID_SCHEMA, JURISDICTIONAL_BAR, CAPABILITY_MISSING, OUT_OF_ORDER, RATE_LIMITED, TEMPORARY_UNAVAILABLE, and INTERNAL. Clients MUST treat these values as machine-readable outcomes, not as human-readable prose. 9.2. Retry and recovery A client receiving OUT_OF_ORDER SHOULD use FETCH to obtain the missing state and then retry the operation. A client receiving TEMPORARY_UNAVAILABLE MAY retry after an implementation-defined backoff. A client receiving REVOKED_CREDENTIAL or BAD_SIGNATURE MUST NOT retry the same request without changing the underlying credential material. A PEP MUST fail closed if it cannot establish the required trust state for enforcement. 9.3. Conformance profiles PARCEP defines conformance profiles CONF_A through CONF_G. An implementation MUST declare the profile it supports and MUST NOT claim support for any behavior outside that profile. A PAP SHOULD use the conformance profile when deciding which PEPs to enroll or which features to expose. The reference test suite is normative for conformance and MUST be passed by implementations claiming compliance. Profiles supporting operator and managed-network deployments SHOULD include capabilities for service-hosted policy administration, network-side enforcement, and integration with encrypted DNS and access-network control points. Such profiles enable ISP-managed services to provide guardian-controlled policy-authoring tools while remaining interoperable with device-based implementations. 10. Security Considerations 10.1. Trust model PARCEP-Sync assumes a federated trust model in which PIPs issue and log credentials and artifacts. All signatures on policy, credential, and artifact objects MUST be verified before use. PEPs MUST check revocation at load time and at a policy-defined refresh interval. A PEP MUST NOT accept an artifact from a PIP unless that PIP is on the recognized trust list for the relevant jurisdiction. 10.2. Adversary classes The protocol model addresses three major adversary classes. A malicious vendor PEP may attempt to exfiltrate policy or report false events; a compromised PIP may issue fraudulent credentials; and a removed MLS member may attempt to read future traffic. The protocol mitigates these threats with enrolment attestation, transparency logs, minimum two-PIP jurisdictional requirements, and MLS post-compromise security. Implementations SHOULD treat the loss of trust in any of Campling, et al. Expires 6 January 2027 [page 12] Internet-Draft PARCEP Protocol and Architecture July 2026 these components as a high-severity security event. 10.3. Privacy properties The protocol provides data minimization, content non-disclosure, and cross-vendor unlinkability. A PEP MUST receive only the policy attributes required by its conformance profile and subject scope. EVENT messages MUST contain hashed evidence rather than raw content. Implementations SHOULD avoid retaining raw event payloads beyond the period necessary for local enforcement or appeal handling. 10.4. Cryptographic agility PARCEP-Sync MUST be cryptographically agile. The base design uses modern signing, key exchange, AEAD, and hashing algorithms, and the protocol negotiates suites via the MLS ciphersuite mechanism. A post- quantum suite SHOULD be supported as a transition path and MAY become mandatory in a future version. Implementations SHOULD make cryptographic suite selection explicit in logs, attestations, and conformance artifacts. 11. IANA Considerations 11.1. Method registry This document SHOULD create a registry for PARCEP-Sync methods. Each registry entry MUST include the method name, sender, receiver, idempotency, and a short description. Registered methods include ENROLL, WELCOME, PUBLISH, UPDATE, REVOKE, ACK, EVENT, DIGEST, APPEAL, RESOLVE, ATTEST, FETCH, NOTIFY, and EXTEND. Future methods MUST be added through the designated extension process. 11.2. Reason-code registry This document SHOULD create a registry for structured reason codes. Each reason code MUST have a stable semantic definition and MUST NOT be repurposed for a different failure mode later. This stability is important so that implementations can interoperate on retry, fallback, and fail-closed behaviour. New reason codes MUST be reviewed to avoid collisions with existing operational meanings. 11.3. Media types and namespaces This document requests allocation of media types for PARCEP-Sync JSON- LD and CBOR message representations. If a dedicated URI namespace or well-known identifier space is standardized, it SHOULD also be entered into an IANA registry. Final publication MUST include precise registry templates and change procedures. The current text is a draft-level placeholder for those allocations. Campling, et al. Expires 6 January 2027 [page 13] Internet-Draft PARCEP Protocol and Architecture July 2026 12. References To be added. Appendix A. Contributors To be added Authors' Addresses Andrew Campling 419 Consulting Limited Email: Andrew.Campling@419.Consulting URI: https://www.419.Consulting/ Gianpaolo Scalone Vodafone Email: gianpaolo-angelo.scalone@vodafone.com URI: https://www.linkedin.com/in/gianpaoloscalone/ Arnaud Taddei Email: arnaud.taddei.sdo@gmail.com URI: https://www.linkedin.com/in/arnaudtaddei/ Campling, et al. Expires 6 January 2027 [page 14]