Encryption, standards, and compatibility

Parts of the local demonstration use encryption in transit. The mTLS gateway requires TLS 1.3 or newer and an authenticated client certificate; the directory integration uses LDAPS rather than cleartext network LDAP. In a correctly configured deployment, TLS protects the connection between endpoints.

That is not the same as a claim that every record is encrypted everywhere. The demonstration does not define a production database encryption, backup encryption, key-management, or secret-retention architecture. Encryption at rest, storage locations, access controls, and key custody must be designed and verified for the actual deployment.

The code establishes a minimum TLS version of 1.3 for the local mTLS gateway. TLS 1.3+ is the required local-demo baseline, but "how good" cannot be answered from a protocol name alone. It depends on the deployed TLS version and cipher configuration, certificate chain and hostname validation, private-key protection, patching, revocation, logging, endpoint hardening, and whether the system fails safely when a dependency is unavailable.

The demo uses isolated, temporary or demo credentials in several paths. Those are useful for proving a workflow, but they are not a substitute for a production PKI, hardware or managed key custody, certificate lifecycle management, independent testing, or monitoring.

TLS is the protocol family commonly used to protect HTTPS and other network connections. TLS 1.3 is newer than TLS 1.2. It removes support for several older cryptographic choices, simplifies the permitted cipher suites, and reduces the number of round trips needed for a full handshake in common cases. Those design changes can improve both security hygiene and connection setup time.

Neither label alone guarantees a secure deployment. TLS 1.2 can still be safely deployed with carefully selected, current cryptography and operations; TLS 1.3 is generally the preferred baseline for a new deployment when every required client, proxy, directory service, and monitoring tool supports it. The current local C=US mTLS listeners require TLS 1.3 and reject TLS 1.2-only connections.

See the TLS overview and TLS handshake overview for background.

No. In the delegation demonstration, Ed25519 signs decision evidence. A signature supports integrity and origin verification: a verifier can detect an altered signed decision and validate it against a pinned public key. It does not make the signed content secret. Confidentiality needs encryption and suitable access controls in addition to signatures.

The project uses or demonstrates these technical building blocks: X.500/LDAP directory concepts, X.509v3 certificates, TLS mutual authentication, LDAPS, WebAuthn/FIDO2 browser authentication, and Ed25519 signatures for decision evidence. These are standards or well-established standard families; using a building block does not itself establish conformance to every profile, certification program, or policy that refers to it.

For WebAuthn context, see the W3C WebAuthn Recommendation.

X.500 is a family of directory-service standards. It describes a hierarchical directory information model: entries are organized in a directory information tree, identified with distinguished names, and can hold structured attributes such as a person, organization, service, or agent record.

LDAP, the Lightweight Directory Access Protocol, is the widely used network protocol and data model for working with directory services. Applications use LDAP or LDAPS to search, read, authenticate against, and sometimes modify directory entries. LDAP began as a lighter way to access X.500-style directories and remains closely aligned with many X.500 concepts.

In this project, X.500 describes the proposed registry and naming model; LDAP/LDAPS describes a practical interface for local demonstration and integration. Neither term by itself establishes a specific schema, operating authority, interoperability profile, or production deployment.

No jurisdiction-wide compliance claim is made. The EU GDPR, the European Digital Identity framework, Canadian privacy law such as PIPEDA and applicable provincial laws, and China's PIPL plus related data-security rules each turn on the operator, personal-data roles, processing purpose, data locations, retention, transfers, vendor contracts, security measures, and applicable sector rules. A technical demo cannot establish those facts.

Before operating with real people or data, obtain jurisdiction-specific legal and privacy advice, complete a data inventory and transfer assessment, document safeguards, and test production controls. Official starting points include the EU GDPR text, the European Digital Identity framework, Canada's PIPEDA business guidance, and the English text of China's Personal Information Protection Law.

Registration can give a relying organization a consistent way to discover an agent, bind it to an accountable sponsor, review its declared purpose and scope, and record whether its authority remains active. It can also provide a common reference for certificate bindings, revocation or suspension, audit evidence, and cross-organization interoperability.

The benefit is governed trust, not automatic trust. A directory entry should not itself authorize an action, prove that an agent is safe, disclose more personal information than necessary, or imply that a state has endorsed the agent's behavior. A receiver still needs its own policy checks, explicit consent or contractual authority where required, and a current credential and authorization decision.

For a producer or consultant, registration may make it easier to show a customer what an agent is allowed to do and who can suspend it. For a public-sector program, it may support oversight and a common governance record. Participation should remain voluntary unless a lawful program says otherwise, and the operator must define data minimization, access controls, correction processes, retention, and appeal or dispute handling before collecting real records.

Not automatically. A standard name is not enough to determine interoperability. Please specify the standard's full name, version or edition, implementation profile, required optional features, identity and trust model, conformance level, data fields, test suite, and the system that must interoperate. The project can then be evaluated against a written compatibility matrix and tested with representative endpoints.

Absent that analysis and testing, the project makes no promise of compatibility with OIDC, OAuth 2.x, SAML, SCIM, verifiable credentials, EUDI Wallet profiles, FIPS 140-3, ISO 27001, eIDAS qualified trust services, or other named standards and certification schemes.