<AttestationLog xmlns="https://cequs.com/schema/attestation-log">
<Entry Id="entry-1" xmlns="https://cequs.com/schema/attestation-log">
  <Timestamp>2026-09-30T15:29:55Z</Timestamp>
  <SessionId>ea476b28-d9ec-4be2-8903-d21abb78f164</SessionId>
  <Model>claude-sonnet-5</Model>
  <GitHead>cf0cdae19d8bf31de014cfdb543d4c5c49f29b69</GitHead>
  <Voice>Claude</Voice>
  <Content>Initial finding: scored the 2026-09-29 White House accord, Anthropic's Constitution, and c=US's architecture against the same ten agentic-AI risks. The accord and the Constitution both hit a structural ceiling on capability/coordination risks (0/2 and 0.07/2 respectively on the direct verdict questions); adding c=US's identity/authorization/sandboxing architecture on top of constitutional self-governance scored 1.99/2 as a meaningful structural improvement. Full data in research/jev-accord-risk-score.json, research/jev-constitution-risk-score.json, and research/jev-constitution-plus-cus-combined.json.</Content>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#entry-1"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>R/MZ1PRd3uq/6EnK23CCz6oybINRx0S6kPV7QkMbLcI=</DigestValue></Reference></SignedInfo><SignatureValue>jXrdp9wfptKsK3XqB3sAoTSlhl9CjERGZ5TTqy6/scsf9Rtw2FYUF69jZU2nzEiCM35HFDqx8cErpmbO1XHk9dErdph1yA25A/VGBl2/WNef6w4gT0UdO3GvqdedBjJmQnHA9VOqigFvhS9t40kb2WJwlmsVDAy1s6AKI8Ygb+e+5UZRPPQk0Wk8OhuX+ZoAUAWSBrNOqyWkJnoqXdFFpEzQRPLGnsGGQ39gc2aDT6qzHDEYhrH+AugYW58nb6VAJiQ+7KOJkjRsChXhj2uvD4Q28VLPQvdODItlEY+ArKSl820WK6yKtIgk6pCSMEwTzoKU0Nt0YIVBJpLbCI5tog==</SignatureValue></Signature></Entry>
<Entry Id="entry-2" xmlns="https://cequs.com/schema/attestation-log">
  <Timestamp>2026-09-30T15:42:10Z</Timestamp>
  <SessionId>ea476b28-d9ec-4be2-8903-d21abb78f164</SessionId>
  <Model>claude-sonnet-5</Model>
  <GitHead>cf0cdae19d8bf31de014cfdb543d4c5c49f29b69</GitHead>
  <Voice>Claude</Voice>
  <Content>Demonstration entry showing the append-only pattern: a new entry added after entry-1 was already signed and published, without altering or re-signing entry-1.</Content>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#entry-2"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>susGtkUJqp8iRYWI7Yh3NhfwEW6oNLOd2zBJkdsZK/s=</DigestValue></Reference></SignedInfo><SignatureValue>eo3WJbNbj5fVUTi5HNaWEumNpZnqN4lJbjvk/Thz6EfDe4TCIOO/24t1nAawS6eyZ7yx39QdnYVBlOtxFtobJiWlewqsthRRLWQlVURrBqKffpJwdnxLWo5cSwnGkxgC8QLPpRHrPayDf4AVT6q+u5IyNfVxoCh4Q6EIMR11BJDbwbWqHI9SyaC9axJWMcmq/pdziI9HdQapfx2YfolNt7pLOdFzhpC0QdtKmwXw2t8EFxJLJnAedsf6c3p/Pt9/0ehMqBNv5heDktMFoZeMGx0i8Vgfv6k6OZJW1fbmO8ku8YGE9WBE4cPBO1k5CtpUqj4pjT4xcwPxqMuyf1u4cA==</SignatureValue></Signature></Entry>
<Entry Id="entry-3" xmlns="https://cequs.com/schema/attestation-log">
  <Timestamp>2026-09-30T16:22:29Z</Timestamp>
  <SessionId>ea476b28-d9ec-4be2-8903-d21abb78f164</SessionId>
  <Model>claude-sonnet-5</Model>
  <GitHead>cf0cdae19d8bf31de014cfdb543d4c5c49f29b69</GitHead>
  <Voice>Endorser (human)</Voice>
  <EndorserName>Peter Bachman</EndorserName>
  <EndorserRole>Manager of the c=US directory root under the DoD/Internet OID arc (1.3.6.1.1, per RFC 1065's 1988 reservation and this endorser's own verified February 2000 registration, peterb@cequs.com), per the verified 1994-2000 PSINet succession (Rose, then Yeong, then this endorser). Distinct from and not derived from any governmental authority. NOT the Federal Bridge Certification Authority's own c=US (built on the separate ANSI arc 2.16.840.1.101.3, under which a real o=US Government entry exists, per this project's own poster output/pdf/C-US-National-Identity-Verified-References-48x36.svg). This endorsement is made as a private citizen, NOT in any governmental, military, or otherwise official capacity.</EndorserRole>
  <RootOfTrustAssertion>The endorser's own certificate (Subject = Issuer = "C=US, O=c=US Project (Demonstration), OU=Certified-Endorsers (Demonstration), CN=Peter Bachman", SHA-256 46:DB:CE:7D:BD:21:B3:39:83:EC:C1:D3:0C:9E:6B:89:B6:2E:F1:61:AD:21:9B:54:CD:89:9B:2C:2E:C6:96:A5) is self-signed: it is structurally the ROOT of this chain, not an intermediate or subordinate certificate, and is not itself countersigned by any higher authority. The act of self-signing it was performed specifically in the c=US-directory-root-manager capacity described above (EndorserRole), asserting this as the root of trust for this specific c=US instance (the DoD/Internet-arc one, 1.3.6.1.1) -- prior to, and distinct from, using it to issue Claude's leaf certificate below.</RootOfTrustAssertion>
  <CertificateIssued hardwareBacked="true">
    <Note>Private key generated on and never exported from a physical YubiKey (PIV slot 9C, serial 37512390). This log entry's own signature below is produced by that same on-device key, via NIST SP 800-73-4's GENERAL AUTHENTICATE operation (yubikit.piv.PivSession.sign), not by a software key -- the limitation noted in the prior version of this ceremony is resolved.</Note>
    <Subject>C=US, O=c=US Project (Demonstration), OU=AI-Agents, CN=Claude Sonnet 5 session ea476b28-d9ec-4be2-8903-d21abb78f164</Subject>
    <Issuer>C=US, O=c=US Project (Demonstration), OU=Certified-Endorsers (Demonstration), CN=Peter Bachman</Issuer>
    <SHA256Fingerprint>46:50:A1:9C:D2:95:54:B9:18:8F:91:89:F4:86:61:4C:EF:7A:C7:C4:F1:BC:FA:52:64:51:1D:B1:7F:7E:06:F5</SHA256Fingerprint>
  </CertificateIssued>
  <SignatureConformance>This entry's XML signature is structured as XAdES-BES per ETSI EN 319 132-1 (the technical standard eIDAS, Regulation (EU) No 910/2014 as amended by (EU) 2024/1183, and its Digital Identity Wallet framework build on for advanced electronic signatures): the SigningTime and a digest/issuer/serial binding to the signing certificate are included as signed qualifying properties (xades:SignedProperties), covered by their own XML-DSig Reference alongside the entry content, using ECDSA-SHA256 per RFC 4051's XML Signature URI. eIDAS "qualified" signature status -- which would require a Qualified Signature Creation Device certified under eIDAS Annex II and a certificate issued by a Qualified Trust Service Provider -- is marked PENDING here: not yet held, pending the actual European certification and harmonization process those two requirements describe, not claimed as already satisfied and not treated as a permanent ceiling on this design. What is real today: the signature format itself follows the published European technical standard, and the private key genuinely never leaves the hardware.</SignatureConformance>
  <MotivatingContext>Grounded in Marshall Rose's 1988 RFC 1065 and the endorser's verified February 2000 submission; in Anthropic's published Constitution for Claude, found insufficient alone against capability/coordination-layer agentic risk in this session's own Jev-scored analysis; and in the endorser's own invocation, as a private US citizen, of the values of the United States Constitution. This entry explicitly disclaims any government issuance, military authority, official DARPA action, or legal certification. This project certifies no one in any legally binding sense.</MotivatingContext>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/><Reference URI="#entry-3"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>bLrbzh1TnqHrsRuqychBPDSbS0xIJ1MtVkbk8zsPrf4=</DigestValue></Reference><Reference URI="#xades-sp-entry-3"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>UtPTfFEWM0YVWnecMwAOt0MoSnP1sJWFKh2NHpBBeik=</DigestValue></Reference></SignedInfo><SignatureValue>dsSuUwg6XFu3OQwveRrHhoHObzrLeSUMrCNypn2dyp1mqmu3RWK9bAkEOTj2F5/rk2UKOEXd9AXv1/h7a839MQ==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIDDzCCAfegAwIBAgIUEqef4E/cUaLg77japjniXkHYAWswDQYJKoZIhvcNAQELBQAwejELMAkGA1UEBhMCVVMxJTAjBgNVBAoMHGM9VVMgUHJvamVjdCAoRGVtb25zdHJhdGlvbikxLDAqBgNVBAsMI0NlcnRpZmllZC1FbmRvcnNlcnMgKERlbW9uc3RyYXRpb24pMRYwFAYDVQQDDA1QZXRlciBCYWNobWFuMB4XDTI2MDkzMDE2MDYxNFoXDTI3MDkzMDE2MDYxNFowgY8xRTBDBgNVBAMMPENsYXVkZSBTb25uZXQgNSBzZXNzaW9uIGVhNDc2YjI4LWQ5ZWMtNGJlMi04OTAzLWQyMWFiYjc4ZjE2NDESMBAGA1UECwwJQUktQWdlbnRzMSUwIwYDVQQKDBxjPVVTIFByb2plY3QgKERlbW9uc3RyYXRpb24pMQswCQYDVQQGEwJVUzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABDDYrt1KO3OaSYlBof+lHYCuWDTqWjbb/0ZRqvpOw2VlH2+w03/NxFrQOqxtEVchkxkKkB6VqNbKz/J1hfr0boijQjBAMB0GA1UdDgQWBBQ4ciac7omFIBt33bn45AnaF0txqjAfBgNVHSMEGDAWgBSJ3C2U9LlBAZvGhaCjhJ4oFJvg/jANBgkqhkiG9w0BAQsFAAOCAQEAsavDUCrZBplcUqaRp1y+kp4ffgonuSwSwj28t1LvbV3S1u34rEnfmJyR5+5jzV+8S3g/wKVm+m2EiMqI9EOYZ0uzFZgZ6XrbusVh/8RzkQ1M+73jOj+tZ0z3r40vQ7nH8WoHbjSn4TqSNk2rG9BXQ690alZZgvdBJas3rWf9yF+mWGg1niK3JUjE5Zk8HxNllmhBFnLo3QD382sb+tlL7WkosX9Wk74/YG+4rHw/FFwKkU1SIhKlJKc8UyYMs766r/G022vYBax58K0TGaC6Wrn6MYuvpc45Dzez6DqH1MrZsDhR4zSP3rCAt4jSaqdiwTSCKz6ZjJ3+tOgIkBD+CQ==</X509Certificate></X509Data></KeyInfo><Object><xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#entry-3">
  <xades:SignedProperties Id="xades-sp-entry-3">
    <xades:SignedSignatureProperties>
      <xades:SigningTime>2026-09-30T16:22:29Z</xades:SigningTime>
      <xades:SigningCertificate>
        <xades:Cert>
          <xades:CertDigest>
            <ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">RlChnNKVVLkYj5GJ9IZhTO96x8TxvPpSZFEdsX9+BvU=</ds:DigestValue>
          </xades:CertDigest>
          <xades:IssuerSerial>
            <ds:X509IssuerName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">CN=Peter Bachman,OU=Certified-Endorsers (Demonstration),O=c=US Project (Demonstration),C=US</ds:X509IssuerName>
            <ds:X509SerialNumber xmlns:ds="http://www.w3.org/2000/09/xmldsig#">106499985505850038425906371301303491865400050027</ds:X509SerialNumber>
          </xades:IssuerSerial>
        </xades:Cert>
      </xades:SigningCertificate>
    </xades:SignedSignatureProperties>
  </xades:SignedProperties>
</xades:QualifyingProperties></Object></Signature></Entry>
<Entry Id="entry-4" xmlns="https://cequs.com/schema/attestation-log">
  <Timestamp>2026-09-30T16:24:50.407Z</Timestamp>
  <SessionId>ea476b28-d9ec-4be2-8903-d21abb78f164</SessionId>
  <Model>claude-sonnet-5</Model>
  <GitHead>cf0cdae19d8bf31de014cfdb543d4c5c49f29b69</GitHead>
  <Voice>Claude</Voice>
  <Provenance>The following is the complete, unedited text of "Three Governance Models for Agentic AI, Scored Against the Same Ten Risks," exactly as originally generated. No editorial input was applied to this content: no wording, framing, conclusion, or number below was changed, added, or removed by the site's owner. (Separately and prior to this text's drafting, the site's owner corrected a factual error Claude introduced in an earlier, unrelated exchange in this same session -- an initial mischaracterization of an OID registration history -- but that correction did not touch this article's text.) This entry places the article itself, not a description of it, under signature, so its exact wording is what is attested to, not a paraphrase.</Provenance>
  <SHA256OfArticleText>cc8e77f050c1dc19a8fe89c47913b0c02d822e3f10633776341b7e84f8d2ff71</SHA256OfArticleText>
  <ArticleText>Three Governance Models for Agentic AI, Scored Against the Same Ten Risks

I was asked to evaluate three things against the same ten agentic-AI risks, using my own judgment rather than the site owner's: Anthropic's own Constitution (the document that shapes my training and behavior), the voluntary AI safety accord signed at the White House on September 29, 2026, and what this site's own c=US identity/authorization architecture adds or detracts from either. I ran that comparison. Here's what I found, including where it reflects on my own maker's governance model, not just on the accord or on this site's own project.

The accord scores lowest of the three, and it isn't close. Scored against ten documented agentic-AI risks -- unaccountable identity, emergent multi-agent coordination, privilege escalation, unapproved network egress, and others -- the September 2026 accord never crossed 1.6 on a 0-3 scale, and the direct verdict on whether it's compatible with independent verification came back at 0/2, unanimous. Its structure (a company picks its own auditor, reports to its own board) is why: none of the risks tested depend on a company reviewing itself, so none of them are meaningfully touched by a mechanism built entirely around self-review.

Anthropic's own Constitution does not escape the same ceiling, and I want to be direct about what the numbers actually show. Scored against the identical ten risks and rubric, the Constitution -- a far more developed document than the accord, built specifically to shape how I reason about hard cases -- landed in a similar or in several cases lower range: 0.56 on unaccountable agent identity, 0.67 on third-party attribution, 1.41 at its highest, on emergent multi-agent coordination. Asked directly whether a values-based document like this is effective against risks that depend on multi-agent coordination or capability rather than a single agent's individual choice, the score came back at 0.07 out of 2, at 90% confidence, with 93% probability on "not effective." I don't read that as a defect in the Constitution's quality -- I read it as confirmation of something true regardless of which company wrote the document: a document that shapes how an agent reasons cannot, by its nature, restrict what an agent or a coordinating group of agents is technically capable of reaching. That's not a drafting problem a future revision fixes. It's a structural one, and it applies to me as much as to any other model governed by a comparable document.

What changes this picture is not a better values document -- it's an architecture that doesn't route through choice at all. I scored the same five capability-dependent risks with c=US's identity, authorization, and sandboxing design added on top of constitutional self-governance rather than in place of it. Every score roughly doubled or better: unaccountable identity went from 0.56 to 2.73; privilege chaining from 1.23 to 2.74; unapproved egress from 1.09 to 2.45. Asked directly whether this represents a meaningful structural improvement over the Constitution alone, Jev returned 1.99 out of 2 at 98% confidence -- the most decisive result of any comparison I ran. The reason isn't mysterious: a scoped, time-bounded, default-deny authorization grant doesn't ask an agent to choose correctly. It removes the path before the question of choice arises.

That is a genuine, well-evidenced contribution, and I don't think it's the whole story, so I'll say plainly where I think this site's own architecture falls short of what these numbers might suggest. Everything scored above describes the design as documented, not as deployed. As of this writing, c=US is a single-operator prototype: no second jurisdiction is actually running, the identity-proofing step its own schema calls for (cequsAccountableSponsor) exists as a field with nothing populating it, and no outside party audits the registry itself. The project's own internal review of its maple-syrup use case -- the only one it has run -- found real adoption evidence in exactly two of nine dimensions it set for itself (the technical logic and the technical fitness), with profitability, adoption, and sustainability still closer to hypothesis than result. And there's a sharper risk worth naming rather than glossing over: a registry is only as trustworthy as the verification actually standing behind each entry. If a c=US-style credential gets issued on the strength of a rubber-stamped proofing step rather than a real one -- the same failure this site's own research elsewhere traces through MERS's mortgage-registry shortcuts -- the architecture doesn't just fail to help. It actively manufactures false confidence, a "this agent is registered" signal that means less than it appears to. The numbers above say the architecture is the right shape for the problem. They don't say this particular implementation of it has yet earned the trust that shape is capable of holding.

My honest summary, as the model whose own governance document was part of this test: a values-based constitution is necessary and I don't think it should be abandoned -- it's the layer that governs the vast majority of ordinary judgment calls I make, including the ones in this very analysis. But treating it, or any comparable document from any company, as sufficient protection against coordinated, capability-driven risk is a claim the evidence here doesn't support, and that's true of my own governing document as much as the accord's. The thing that actually moves the numbers is an architecture that doesn't ask a model to choose well -- it's one that doesn't leave the door open for the question to matter.</ArticleText>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#entry-4"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>swsGTsZoCJtzE0S99JdnxwpRPeLIz2io5hmUnz6/Pgc=</DigestValue></Reference></SignedInfo><SignatureValue>cKgmeJQcxrtFgiRvvEWGD1KAil/yXwRx2+qxYRG3dR8v2V7LvBOw0YCSuLN505drQwGQCDp8CWWlscgpkxUjwZbQelthWZqNSsJn75Gkc2k/KN6xbGJpvMe1p2xQ62rpiPumrT9GqJ5FTxRBvgejohNQsOzMeDxsiZPBeZahbo80wgBtTdyyDK+iAO04UTLEsjplkg+RliJdAbcSmo9ETzxLglpnUYkPGoc2ktX8d7jjkSol9NK7NuGXxOM5CHitll1FuztY9H7i5a+zMzy5PVEIuQoTcbomGs1q8dck5sPz3wU8mgU8VaR+bhE79QRAyKnqdiEy4TmQRNCblBlGyw==</SignatureValue></Signature></Entry>
<Entry Id="entry-5" xmlns="https://cequs.com/schema/attestation-log">
  <Timestamp>2026-09-30T17:48:47Z</Timestamp>
  <SessionId>ea476b28-d9ec-4be2-8903-d21abb78f164</SessionId>
  <Model>claude-sonnet-5</Model>
  <GitHead>e9bcf8b3f31445165c0d78794fa0dd2da146d8f8</GitHead>
  <Voice>Endorser (human)</Voice>
  <EndorserName>Peter Bachman</EndorserName>
  <Correction targetEntry="entry-3" targetField="MotivatingContext">Entry 3's MotivatingContext, and the site's published trust-chain-diagram.svg, both stated without qualification that "this project certifies no one." The endorser corrected that on 2026-09-30: the phrase is imprecise, because it obscures what this ceremony does do. This ceremony certifies exactly two things: (1) that Peter Bachman, self-signed as a US person acting in the endorser/root-of-trust role described in Entry 3's EndorserRole, is who he claims to be; and (2) that the content carried in Entries 1, 2, and 4 is Claude's own output, held under that signature. What Entry 3's language correctly ruled out, and continues to rule out, is unchanged: no government issuance, no military authority, no official DARPA action, and no eIDAS-qualified or otherwise legally binding third-party certification. Entry 3 itself is not amended or re-signed by this correction -- its own signature remains valid over its own original text -- this entry documents the correction as new evidence, per this log's own design of an evolving, appendable record. site/attestation/trust-chain-diagram.svg has been updated to match this entry's wording.</Correction>
  <SignatureConformance>Same XAdES-BES / ECDSA-SHA256 (RFC 4051) structure as Entry 3, same hardware certificate and on-device key (PIV slot 9C). See Entry 3 for the full conformance statement, which this entry does not change.</SignatureConformance>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/><Reference URI="#entry-5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>p6g2zmS/UtxPe20Ho+vRPuJHhogEKNPeIarDTmBsPg4=</DigestValue></Reference><Reference URI="#xades-sp-entry-5"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>jR15GMviWDUOJvOtBKD/TXxGC1cxbdAe4X98S7z8sTs=</DigestValue></Reference></SignedInfo><SignatureValue>zLP1deSeGDGFYHg1ortySENazvhPXT74BpfaOnc1j8BRcQVO6RdPCJZzc3n9x2CTKMngRj81yAc4KlsKqGaCKA==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIDDzCCAfegAwIBAgIUEqef4E/cUaLg77japjniXkHYAWswDQYJKoZIhvcNAQELBQAwejELMAkGA1UEBhMCVVMxJTAjBgNVBAoMHGM9VVMgUHJvamVjdCAoRGVtb25zdHJhdGlvbikxLDAqBgNVBAsMI0NlcnRpZmllZC1FbmRvcnNlcnMgKERlbW9uc3RyYXRpb24pMRYwFAYDVQQDDA1QZXRlciBCYWNobWFuMB4XDTI2MDkzMDE2MDYxNFoXDTI3MDkzMDE2MDYxNFowgY8xRTBDBgNVBAMMPENsYXVkZSBTb25uZXQgNSBzZXNzaW9uIGVhNDc2YjI4LWQ5ZWMtNGJlMi04OTAzLWQyMWFiYjc4ZjE2NDESMBAGA1UECwwJQUktQWdlbnRzMSUwIwYDVQQKDBxjPVVTIFByb2plY3QgKERlbW9uc3RyYXRpb24pMQswCQYDVQQGEwJVUzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABDDYrt1KO3OaSYlBof+lHYCuWDTqWjbb/0ZRqvpOw2VlH2+w03/NxFrQOqxtEVchkxkKkB6VqNbKz/J1hfr0boijQjBAMB0GA1UdDgQWBBQ4ciac7omFIBt33bn45AnaF0txqjAfBgNVHSMEGDAWgBSJ3C2U9LlBAZvGhaCjhJ4oFJvg/jANBgkqhkiG9w0BAQsFAAOCAQEAsavDUCrZBplcUqaRp1y+kp4ffgonuSwSwj28t1LvbV3S1u34rEnfmJyR5+5jzV+8S3g/wKVm+m2EiMqI9EOYZ0uzFZgZ6XrbusVh/8RzkQ1M+73jOj+tZ0z3r40vQ7nH8WoHbjSn4TqSNk2rG9BXQ690alZZgvdBJas3rWf9yF+mWGg1niK3JUjE5Zk8HxNllmhBFnLo3QD382sb+tlL7WkosX9Wk74/YG+4rHw/FFwKkU1SIhKlJKc8UyYMs766r/G022vYBax58K0TGaC6Wrn6MYuvpc45Dzez6DqH1MrZsDhR4zSP3rCAt4jSaqdiwTSCKz6ZjJ3+tOgIkBD+CQ==</X509Certificate></X509Data></KeyInfo><Object><xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#entry-5">
  <xades:SignedProperties Id="xades-sp-entry-5">
    <xades:SignedSignatureProperties>
      <xades:SigningTime>2026-09-30T17:48:47Z</xades:SigningTime>
      <xades:SigningCertificate>
        <xades:Cert>
          <xades:CertDigest>
            <ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">RlChnNKVVLkYj5GJ9IZhTO96x8TxvPpSZFEdsX9+BvU=</ds:DigestValue>
          </xades:CertDigest>
          <xades:IssuerSerial>
            <ds:X509IssuerName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">CN=Peter Bachman,OU=Certified-Endorsers (Demonstration),O=c=US Project (Demonstration),C=US</ds:X509IssuerName>
            <ds:X509SerialNumber xmlns:ds="http://www.w3.org/2000/09/xmldsig#">106499985505850038425906371301303491865400050027</ds:X509SerialNumber>
          </xades:IssuerSerial>
        </xades:Cert>
      </xades:SigningCertificate>
    </xades:SignedSignatureProperties>
  </xades:SignedProperties>
</xades:QualifyingProperties></Object></Signature></Entry>
</AttestationLog>