Trimming CC.
I'm wearing no hats for this rant.
We seemed to have stumbled on one of my favorite topics.
Authenticated hypergraphs.
Imagine a stream of events, each event is an observation, signed by an
observer.
The stream is partially observable to subscribers.
Each subscriber assembles the events into a belief network.
In these systems, it's a nice feature to agree on identifiers for subjects
and objects.
Its also a nice property to be able to match the key material signing or
decrypting events to the subjects or objects.
But how do you handle conflicting information, merging and consistency over
time?
Consider this small fragment of cypher:
MATCH (p:Person)-[r:WORKS_AT {since: 2021}]->(c:Company)
RETURN p.name AS Employee, c.name AS Company, r.role AS Role
For a query like this, you might want to know which events contribute to
the result, who signed them, and for how long should the information be
considered valid.
You can do this with any container format.
You don't need embedded signatures to do this.
Another design consideration is being able to replace a large event with a
unique identifier.
In order to do that, and still have useful and interesting events people
turn to general purpose canonicalization.
Meanwhile, most of the interesting events are still JWTs, PGP, CMS, normal
COSE, etc...
Real data is often not in a canonical form.
People create map keys as they need them, and they like putting "title"
before "description" even though that's not how they sort lexicographically.
Canonicalization eliminates ways that data can exist.
Cryptography preserves data as it exists.
Naively combining them just eliminates sources of useful information.
For those who want to add embedded signatures to any packaging format.
1. Define the parameter name.
2. Write down the rules for creating and validating it (canonicalization)
3. Describe how to embed and extract signatures.
If you want to do chains (ordered counter signatures) you need a way to
signal the order of the signatures, and rules for how to verify.
The rules don't need to be complicated.
If you want to embed the identifiers for the resource and make them hash
based, another layer of application specific rules.
Ohh but we want redaction too, let's add salted hashes to all the
predicates.
{
id: (magic determinsitic id)
subject: { predicate: object }
signature: [ ... ,
{ ..., key_id, valid_from, valid_until }
]
}
You basically end with event sourced progressively disclosable attribute
cert derived labeled property graphs.
As soon as you're done making this system, somebody will want to simply
sign data without making any changes to it, and you'll be back to enveloped
signatures.
OS
On Wed, Apr 16, 2025, 5:31 PM Wolf McNally <[email protected]> wrote:
> Vadim,
>
> > On Apr 16, 2025, at 1:26 PM, Vadim Goncharov <[email protected]>
> wrote:
> >
> > Essentially known-values are just another way to specify a compact
> encoding
> > for long type string, like JSON-LD does for URIs, so a generic
> > (semantic) compaction framework like CBAPT can replace many wheels
> reinvented
> > again and again in protocols, leaving only thin amount for them to
> define.
>
> I think I understand you correctly, so yes.
>
> Many semantic systems use “triples”:
>
> <subject> <predicate> <object>
> “Sam” ‘knows' “John”
>
> Where predicates like ‘knows’ are common, and in some cases universal.
>
> Gordian Envelope is based on the pattern:
>
> <subject> [
> <predicate>: <object>
> <predicate>: <object>
> ...
> ]
>
> (Note the above is “Envelope Notation”, not CBOR diagnostic notation or
> CDDL). Gordian Envelope itself is built on dCBOR.
>
> Where a number of assertions (<predicate>: <object> pairs) are declared on
> a subject, and any of these positions can be a dCBOR object, including
> nested Gordian Envelopes, forming a tree with a unique digest at every node.
>
> Strings (like URLs) can work for predicates, but can take up significant
> space, and where URLs can be specified numerous ways, this can lead to
> breaking determinism. So we created the known-value space #6.40000 which is
> always just a tagged 64-bit integer. The length of a known-value with a 1+1
> integer is only 5 bytes.
>
> So we’re making first-come first-served assignments of code points in the
> known-value space for anyone who would find such a value useful that is
> fixed public, and globally unique, and can provide a URL to a spec claiming
> it, with no reasonable request refused.
>
> I need to emphasize that there is nothing about known-values that tie them
> to dCBOR or Gordian Envelope (other than that they are compatible with any
> kind of CBOR.) You can use them as keys in CBOR maps, or anywhere you want
> an integer value that is unique and has fixed semantics.
>
>
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md
>
> ~ Wolf
> _______________________________________________
> CBOR mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
