[Rats] Re: Adoption call for draft-richardson-rats-geographic-results

[Serhii Nikolaichuk <[e-mail]>]

Michael, Camilo,

Rather than answer the encoding question in prose I built the TRIP-shaped
case end to end and put it in PR #6 under examples/trip-synthetic, labelled
synthetic in every file. Camilo's set replaces the evidence file when it
arrives; nothing else changes.

The chain. Sixty-four breadcrumbs, each an H3 resolution-10 cell plus a
timestamp, 15 minutes apart, 15.75 hours end to end, each signed with the
device's Ed25519 key, the shape Camilo described. No coordinate is signed
or seen. Verifier A verifies all 64 signatures, requires each whole cell
to lie inside one country polygon, and emits the Result only when all 64
do. They do: 64/64 verify, 64/64 in NL, Result 25 bytes,
a3 00 62 4e 4c 0d 50 <uuid> 0e 00: jurisdiction-country, claim-uuid,
basis = 0. It validates against the CDDL in the PR. Verifier A then puts
it in an EAR signed with COSE_Sign1 (EdDSA), 228 bytes. Verifier B
consumes that EAR as an Attestation Result and emits its own, 236 bytes:
same country, its own claim-uuid, basis = 2, and a reference to A's
claim-uuid. Then a relying party verifies both signatures against its
trust anchors and applies an appraisal policy for results.

That last step is the answer to "should it care", in a table. Policy
"strict": trusted signer, EU country, basis evidence or endorsement, and
attestation-result only through a reference that bottoms out in one of
those. Policy "lenient": trusted signer and EU country.

R1 from A, basis evidence strict ACCEPT lenient ACCEPT
R2 from B, attestation-result with reference strict ACCEPT lenient ACCEPT
R2 without the reference strict REJECT lenient ACCEPT
forged EAR, kid A, untrusted key strict REJECT lenient REJECT
the SEV-SNP NL result of the 26-artifact run strict REJECT lenient ACCEPT
the Azure NL result, basis endorsement strict ACCEPT lenient ACCEPT

Same four bytes 00 62 4e 4c in every NL row. The only thing the strict
policy reads differently is the basis, and the lenient policy is free to
ignore it. That is the property I have been arguing for: the Result
carries it, the policy decides.

Michael's two questions, on that basis. "Could TRIP generate Evidence that
another Verifier could use?" Yes, and it is the artifact that matters. The
device-signed cells are Evidence; a Verifier that appraises them itself,
as the Criticality Engine does, emits basis = evidence. TRIP's own
certificate, exponents and a trust score, is an Attestation Result; a
Verifier that took it as input would emit basis = attestation-result with
a reference to it, the two-hop case you described on 8 September. Today
that hop cannot carry a country, because the certificate holds nothing
locational, which is Camilo's point and why the example's second hop is a
generic workload Verifier rather than TRIP. "Which claims could a TRIP
verifier set?" In this run, jurisdiction-country only. A resolution-10 cell
has 76 m edges, about 150 m corner to corner, so a country, and a
subdivision where the boundaries are good enough, are derivable; room,
hallway and a GNSS-grade position are not, and the example does not
pretend otherwise.

On "how would you like to encode the basis": as in PR #6, grm.basis at
label 14, a group-to-choice of evidence = 0, endorsement = 1,
attestation-result = 2, and grm.claim-uuid at label 13. One collision to
flag while we are counting: PR #4 also puts provence at 13. I hold no
position on numbers; the example puts provence at 15 so that a Result can
carry both, class and method, and shows that they compose.

Two things the chain needed that #6 does not have, offered as questions
with the text ready rather than as text: a reference to the result this
one rests on (label 16, a uuid), without which basis = attestation-result
is a dead end for an auditor; and, for longitudinal evidence, the interval
the conclusion covers (labels 17 and 18, time), because a trajectory
result is about a period, not an instant. They are in draft PR #7,
stacked on #6 so that it can be dropped as a unit, with the third worked
example in the appendix. With both, R2 is 57 bytes, and the signatures
verify with an independent COSE implementation as well as mine.

Camilo, send the set at the parameters you named and I will run it
through the same script and put the real bytes in place of the synthetic
ones.

Serhii Nikolaichuk
Austin, Texas

On Wed, Sep 09, 2026 09:42 PM, Michael Richardson <[e-mail]>
wrote:

>
> camilo ayerbe <[e-mail]> wrote:
>     > conclusion from Evidence it appraised itself, so this is basis =
> evidence
>     > and not the two-hop endorsement case Michael raised. TRIP is the
> document a
>     > registry entry would point at, once it's stable enough to cite.
>
>     > The caveat: TRIP's Attestation Result today doesn't carry a
>     > jurisdiction.
>
>     > The certificate emits statistical exponents and a trust score,
> deliberately
>     > nothing locational. The design goal is proof of embodied existence,
> that an
>     > identity moved in a way consistent with a living organism, not where
> it
>     > went. So the honest worked example isn't "TRIP outputs NL."
>
> Which claims from geographic result would a TRIP verifier be able to set?
>
>     > It's that a
>     > geographic Verifier working from the same signed H3 evidence could
> emit a
>     > coarse jurisdiction in your format, and that result would carry
> basis =
>     > evidence with TRIP as the method. The jurisdiction is derivable from
> the
>     > quantized cells, it just isn't in TRIP's current certificate.
>
> So, TRIP could generate Evidence that another Verifier could use?
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>