Shifting to a Structured Header-like syntax?

[mikewest]

If we adopt the suggestion in #16 to shift towards RFC9421's Identity-Digest/Signature-Input/Signature headers, we'll be representing the ~same information we need in HTML, but using a different syntax.

I wonder whether it would be helpful for developers to adopt the same syntax in HTML as well (though of course we'd need to support the current syntax ~forever). That is, rather than:

<script src="https://my.cdn/script.js"
        crossorigin="anonymous"
        integrity="sha256-[base64-encoded-hash]
                   sha512-[base64-encoded-hash]
                   ed25519-[base64-encoded-public-key]"></script>

we could recommend:

<script src="https://my.cdn/script.js"
        crossorigin="anonymous"
        integrity="sha-256=:[base64-encoded-hash]:,
                   sha-512=:[base64-encoded-hash]:,
                   ed25519=:[base64-encoded-public-key]:"></script>

This seems worth considering from an aesthetic and consistency perspective, but I'm not sure the churn is actually worth it. 🤷

[LPardue]

Is the proposal for "like" Structured Fields or actually structured fields? Mainly thinking from a generator/parser perspective. Having something similar to Structured Fields but slightly different adds another potential source of interop failure. For example, would you be defining the integrity field as a Dictionary, where items are allowed to have additional parameters?

I'm not sure the consistency of presentation would actually help that much. So long as mapping between the two is well defined (which seems simple to do).

[mikewest]

Same text, same generator would be able to produce both. The spec currently has an option syntax that's unused; we'd replace it with structured field parameters.

I don't think this is important, but it occurred to me this morning as a thing to consider when noticing the difference in spelling of the hash algorithms (sha256 vs sha-256).

[LPardue]

Also, it's potentially confusing since the digest field Dictionary entries are strictly hashing =<base 64 calculated hash>. The ed25519 entry in your example is neither of those things right?

Could probably be wordmithed to avoid confusion but not sure.

[mikewest]

Right. The Ed25519 entry is a base64-encoded public key, not a content hash. But I think we'd also represent it as a byte sequence, and it doesn't seem terribly confusing to me to do so next to hashes (assuming that folks recognize that hashing algorithms and signature algorithms are distinct (which I think they have to in order to engage with this proposal no matter how we spell it)).

[LPardue]

I think the important distinction to make would be that the integrity property is not a structured field dictionary, and does not represent what a single header field would contain.

Instead integrity property is a comma-separated list of key value pairs where the value is a structured fields Byte Sequence Item. That would be fine IMO. We'd probably want some text to say that the key values in the property are related to the values registered by IANA.

[mikewest]

I'm happy to frame it in any way that makes sense.

That said, I'm still not sure it does make sense. :) Let's work everything else out first.

[LPardue]

SGTM I could live with either format.