[media-types] Hash based media typing

The concept:

earl/<hash-of-description-document>

Draft describing the hash approach, this is a refined version of the
RFC6920 approach.

https://www.ietf.org/archive/id/draft-hallambaker-earl-00.html


Rationale

* No registry of media types can ever be complete and there are many cases
in which the developer of the media type wants to register it.

* Naming the media type by a unique, universal identifier provides the core
function of a media type registration, 'interpret this content according to
this unique identifier'.

* A digest of a JSON or XML schema is one possible identifier.

* The EARL mechanism allows content to link to a specific version of a
schema that can be upgraded in the future.

* The resulting identifiers are human readable and can fit in the same
slots used for IANA media types.

* The IANA registry would not go away, it will simply be a registry of
additional important information.


Discussion

I came across the need for this while passing data between some Web
Servicey type systems. In brief, there is an envelope with a header and
content body and the header has a slot for media type. And that media type
is used to tell the JSON parser what type of object to return after parsing.

So up until now, I have been developing using content types like

application/mesh-deviceprofile.

OK, so lots of problems there, I know what I am doing and I am not likely
to do something bad. But my code generation tools are designed to make it
easy for anyone to do this sort of thing. What if 'anyone' did? We are
going to end up with collisions.

But the ContentType slot is a place where I would normally specify that the
thing inside the envelope is a JPG or whatever. I can easily mint an extra
slot but then I have two places to look for the same data and that leads to
errors.

So what if I could specify the content type as:

earl/eluv-woab-g7ih-onix-ybns-qdxk-rzqs;DeviceProfile

The Media Type is functionally a URN here. The only way that the
application can understand the content type is if either it is programmed
into the app from the start or if there is a mechanism that allows it to
resolve the content type. That mechanism is deliberately left unspecified,
noting the W3C experience of using HTTP to identify schemas.


What this allows me to provide is a seamless path from identifiers used in
development to those used in production.

The EARL construction is a direct descendant of the TAXI assertion
structure used in SAML which is in turn a descendant of PKIX. There is a
metadata slot and a content slot wrapped by an unauthenticated header and
trailer allowing a digital signature to be specified.

So let's say I change the schema, the new schema will of course have a
completely different digest which means that we can specify a specific
version if we like. But inside that envelope there is a signature
authenticating the new assertion under an update key specified in the
original.

And if I pass change control to IETF or W3C or whoever, I can sign an
assertion passing the update key to them.

The security angle might seem a bit over the top, but it is a pretty
effective way of ensuring everyone is clear about their responsibilities,
who currently has change control over what, etc. and of ensuring third
party services don't get confused and act under divergent interpretations
of the circumstances.


The main risk here is that someone mints a content type that later becomes
important and is unable to sign an assertion transferring change control.
But that is OK, it is indistinguishable from refusing to.

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]