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

Hi Austin

These are all great points, but we are not really trying to address these
in the first version of SRI. The goal in version 1 is only to be able to
check the hashes of scripts and links. That said, I tend to agree with you
that this should be in our radar; do you think the spec, as currently
defined, makes it impossible to address these concerns in future
iterations? For example, the parser is intentionally forgiving of formats
it is not aware of, so as to allow such changes in the future.

cheers
Dev


On Mar 9, 2015 11:26 PM, "Austin William Wright" <aaa@bzfx.net> wrote:

> [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
>
>