[Diem] draft-steele-diem-architecture-demo

[Orie <[e-mail]>]

Hi all,

I've written up an individual, Informational draft exploring the DIEM
architecture and use cases, together with a running demo that implements it
end-to-end:

- Draft — "An Architecture for DNS-Delivered Digital Emblems
(Demonstration)"
Editor's copy:
https://or13.github.io/emblem.red/draft-steele-diem-architecture-demo.html
- Live demo: https://emblem.red
- Source: https://github.com/OR13/emblem.red

The core idea is to model a digital emblem as a COSE hash envelope: a COSE
single-signer structure whose payload is the hash of an external resource,
and whose protected header carries the hash algorithm, the resource's
content type and location, a minimal set of CWT claims, and a confirmation
(cnf) key for later proof of possession.

The emblem is then delivered over DNS inside the asset's own HTTPS resource
record, in a private-use service parameter. The point of that choice is a
privacy property: the query used to discover an emblem is indistinguishable
from the query an ordinary client already makes to connect to the asset. A
validator can check whether an asset is protected without revealing — to
the infrastructure provider or an on-path observer — any intent to look for
emblems.

The demo lets you exercise the full lifecycle over an FQDN — issue, mark,
verify, unmark — including real COSE/CWT signing (ES256) and, with
credentials configured, real SVCB/HTTPS record writes. It performs genuine
cryptography but ships an insecure, public issuer key by default; it's a
demonstration, not a production service.

To be clear about scope: this is not a standards-track proposal. It's an
attempt to hold the DIEM architecture and requirements up against something
executable, and I'd value the group's feedback on the modeling choices —
the hash-envelope structure, the DNS delivery mechanism, and the
discovery/privacy properties in particular.

Thanks,
Orie

PS: yeah, I used AI to do this stuff.... I'm not asking for agenda time or
any formal consideration, but if you want to chat with me I will be onsite
for IETF 125.