[Integrity] Revisit RFC6920 URIs for benefit of servers and Semantic Web applications

[CCing swig because I know many of you are also using ni: URIs. Let me know
if there's anything to add!]

I understand that the ni: URI was removed in a recent update to the SRI
draft. I would like to ask this be reconsidered.

Using the ni: URI for SRI is important to Semantic Web applications as it
allows us to treat the assertion as a link relation. This distinction might
not be significant to many user-agents (and thus many on this list), but in
Semantic Web applications, especially Web servers, this is of great
significance, allows us to make useful relationships between resources.

It also confers benefits to servers and application designers, as RFC6920
defines a mapping between ni: URIs and a </.well-known/> URL. In a
corporate project under development, we're already using ni: URIs to keep a
content-addressable database of files, making them accessible through this
mapping. I intend to use Subresource Integrity when serving assets from
this store.

It also provides an intuitive abstraction: If we think of the ni: URI as
identifying a resource (the definition of the URI), the integrity=
attribute is performing an assertion: "These two URIs must identify the
same information resource, otherwise abort!"

For additional support for this use case, I'd like to propose making the
"integrity" attribute a a link-extension for RFC5988 Web Linking, suitable
for use on any declaration of a link.

User agents do not need to think of the ni: URI as a URL if they do not
need to, they just follow the ABNF defined in the RFC. There's many cases
where URIs are used as identifiers in Web applications; in namespaces [1],
schemas (e.g. JSON Schema), DTDs, RDFa [2], and in rel= attributes in all
sorts of tags and HTTP headers.

Additionally, RFC6920 defines a registry of hashes [3], to ensure forward
compatibility (e.g. SHA-3, when standardized later this year). I would like
to avoid duplication of effort defining a database of hashes.

In short, (1) signing was an explicit goal of the ni: URI, along with other
features. Not using ni: would mean servers being unable to take advantage
of these other features; and, (2) don't forget about the HTTP Link: header.

Thanks for your consideration,

Austin Wright.

[1] http://www.w3.org/TR/html5/infrastructure.html#xml
[2] http://www.w3.org/TR/html-rdfa/
[3]
http://www.iana.org/assignments/named-information/named-information.xhtml