Part 4 in a
series on
the link
network.
The web trusts names.
In the DNS system, publisher identity is tied to network location.
The visible trust anchor of the web is the origin name.
Trust decisions are based on the name.
Numerical IP addresses can also be trusted, but it can be impractical for
publishers to hold on to an IP-based identity for long periods
of time,
and difficult for consumers to recognize publishers from long strings of numbers.
Identity in the rel=friend link network is bound to the resource URL,
but this is fragile since it equates identity with a network location
and it creates a dependency on DNS which may not be desirable.
In the link network trust in a source is derived by transitive
propagation of trust from one source that publishes a resource that contains
a rel=friend link to that other source.
When trust in an identity is instead placed in a persistent cryptographic key, that key can replace DNS names and IP addresses for establishing identity, making the network source ephemeral while preserving trust in resource provenance.
What would be the simplest way to cryptographically establish and verify provenance in the link network?
Source-authenticated provenance
The authenticated "source" in this context can be either a resource URL or
an origin URL.
Authenticating the origin URL collapses the entire origin namespace under one identity, while authenticating the resource URL shifts the trust decision from the publisher namespace to individual resources.
Relying on resource provenance is a way to side-step authentication of resource
content and the associated problems of stable canonicalization and deterministic
decoding.
Provenance can instead be used to establish trust in resource content through
application-layer attestation of publishing source and continuity,
in a way similar to the SSH known_hosts mechanism.
The link network builds on accessible and ordinary web primitives so binding a cryptographic
key to a source should be accomplished by embedding or linking provenance information in the resource representation.
Embedding provenance information is preferable because it makes
the resource representation self-describing and verification resilient
to disappearance of linked keys or signatures.
Embedding a public key in a web resource associates the public key with the publishing source.
By embedding a signature of the source and public key fingerprint in the
resource along with the public key, it becomes possible
to verify that the source was controlled by the holder of the private key
corresponding to the embedded public key.
Signing the source is a kind of channel authentication analogous to TLS server identity, where the signature does not prove immutability but that the content was delivered within a trust context controlled by the key-holder.
In the link network, where there are no intermediaries and data is processed and stored by edge nodes, content integrity adds little value and is already provided by the TLS transport.
If the user wishes to rotate keys, then a new key is published along with two signatures: an attestation signature and a rotation signature. The old key signs the source and public key fingerprint, and the new key signs the source, the old key fingerprint and the new key fingerprint.
The attestation signature provides proof of current source control, and the rotation signature provides continuity linkage between the previous and successor keys.
The public key and signatures could for example be encoded using
the JWK and JWS standards, making them easily processable with JavaScript.
This source-authenticated provenance construction is interesting because it enables verification of more than the continuity relationships of the link
network itself.
Verifiable RDF Provenance
If the publisher is trusted, the transport is trusted, the embedding resource
is ephemeral and the trust decision is immediate, then any embedded RDF assertions
inherit trust transitively from the authenticated source context.
When sources are authenticated using cryptographic keys, the provenance of RDF assertions
issued from those sources by extension becomes cryptographically verifiable.
Continuity-based trust evolution makes it possible for publication sources and publisher identities to change without loss of trust, while preserving cryptographically verifiable provenance in a graph of RDF assertions rooted in independently issued trust anchors.
The link network can in this way provide a low-cost, low-complexity distributed trust topology where
arbitrary RDF assertions can be locally verified and remain resilient to infrastructure churn.
Semantic stability and continuity
For this assumption of transitive propagation of trust to hold, decoding of JSON-LD encoded RDF assertions must be predictable by network nodes.
This may not be the case, since expansion of terms requires network resolution
of JSON-LD contexts. But in an environment that restricts term resolution within
preloaded trusted context, this consideration becomes less important.
As with the web certificate system, trust ultimately has to be rooted in something visible to the user, such as an origin name.
The ultimate trust anchor in a system that crawls the web non-interactively and trusts keys on first use could be an after-the-fact inspection of the network provenance path and a visible continuity score based on an unbroken chain of signed key rotations.
Since the link network is opportunistic and asynchronous, delivery is not guaranteed and there is no global ordering. Network nodes may therefore miss key rotation updates.
To reduce the risk of continuity verification breaks caused by update gaps, rotated keys and their associated rotation signatures should remain published alongside successor keys for sufficiently long periods of time.
The following describes one possible implementation of the provenance construction.
Implementation
A simple implementation of the link network source-authenticated provenance system signs two types
of payloads: source assertions and key rotations.
Additionally, a format for serializing RDF assertions for input
into a link network application for verification is specified.
Source attestations
A source attestation signature consists of the percent-encoded source identifier and the
publisher public key fingerprint separated by a line feed character.
Example attestation
https%3A%2F%2Fexample.com
sha256-abc123
Key rotation
A key rotation signature consists of the percent-encoded source identifier,
the previous public key fingerprint and the successor public key fingerprint,
separated by line feed characters.
Example rotation
https%3A%2F%2Fexample.com
sha256-old
sha256-new
Signature payload grammar
attestation-payload =
percent-encoded-source LF
key-fingerprint
rotation-payload =
percent-encoded-source LF
old-key-fingerprint LF
new-key-fingerprint
percent-encoded-source =
encodeURIComponent(source)
key-fingerprint =
algorithm "-" digest
old-key-fingerprint =
key-fingerprint
new-key-fingerprint =
key-fingerprint
algorithm =
"sha256" / "sha384" / "sha512"
digest =
base64-encoded digest
LF =
%x0A
RDF assertions
The assertion syntax is derived from the N-Quads RDF serialization format.
The format is designed to encode singular assertions and
to be easily parseable.
The format is also designed to be easily embeddable in URL parameters for
construction of direct verification links.
As such, the encoded assertions include the graph position to correctly
identify the assertion provenance.
Example assertion
<https://example.com/alice> <https://vocab.example/knows> <https://example.org/bob> <https://example.com/graph>
RDF assertion grammar
assertion =
subject SP
predicate SP
object SP
graph
subject =
iri
predicate =
iri
object =
iri / literal
graph =
iri
iri =
"<" absolute-iri ">"
literal =
DQUOTE *( character ) DQUOTE
absolute-iri =
IRI as defined by RFC 3987
SP =
%x20
DQUOTE =
%x22
So that is the plan.
You can follow the progress by visiting the demo app.