henkbirkholz
commented
1 year ago NEW (during WG discussion):
- Use of DID in the scope of the Internet seems fine at first glance. A SCITT specific URI scheme also seems like a good route (based on comments from Hannes)
- The duty to provide the content at the location the reference points to (maybe after resolving it) is a burden of the issuer, yes?
- A solution specified should take into account historical analog data (that you cannot point at directly via resolved URL), (based on comments from Charlie). In cases of historical data that was previously not online available, there might be an issuer that vouches for having registered the corresponding statement after transforming analog statements into a digital representations and then making them available?
OLD (I really missed the topic here, nvm):
The SCITT architecture highlight in Section 1:
A Statements payload content MAY be encrypted and opaque to the Transparency Services, if so desired: however the metadata MUST be transparent in order to warrant trust for later processing.
Following this language, this type of reference would be a... non-opaque statement. A statement that MUST be transparent and that has a well-known (standardized CBOR) structure, maybe?.
OR13
cabo
SteveLasker
This issue summarizes discussions so far on references between transparent statements---see also slide 22 at the last IETF SCITT session. I am using "reference" below but identifier or URL may be better.
Motivation: We need a standard way to refer to previously-registered statements. In particular, references to transparent statements may be included in new statements (in headers or payloads or receipts) to point, for example, to a policy statement, to some keying information, to a prior statement it replaces on a given stream, or to statements for artifacts it depends on in the supply chain.
Goals:
Syntax: references include both a locator and a commitment. Concretely, we may use DID URLs of the form
did:web:ts.software.org/42&digest=4ce2320130450...where
42is the serial registration index in the log of this TS anddigestis the SHA256 hash of the transparent statement.We may provide a more compact format by making the DID optional for local references within a TS, and making the digest optional when the transparent statement is attached.
We may even just use the raw digest
4ce2320130450as an opaque identifier (since the hash already authenticates the locator) and separately deal with locators.Discoverability The TS, or an auxiliary database of transparent claims, may support transparent-statement lookups given their reference. This auxiliary lookup service is not a requirement (random access is hard to guarantee) and it need not be trusted (since clients can easily verify the receipt of the resulting transparent statement against their reference). Alternatively, a transparent statement may be distributed together with supporting transparent statements it refers to. This facilitates offline verification and auditing but is more verbose. Or it may include auxiliary headers to help retrieve the supporting statements from any other location.
Open issues:
A TS may produce multiple receipts for the same registered statement, hence multiple commitments with different digests. We could simply ignore the problem, and assume the “primary” receipt is the first one produced by the TS. We could also provide flexibility, using something of the form
did:web:ts.software.org/42®istered=SHA256(signed statement)&digest=SHA256(receipt)digest-sha256=...for agility; we also argued about a TS federating multiple logs, in which case we may need more than a serial registration index.