Re: Hashlink parameterized URL

Thanks Manu, this was very helpful context for me.

Regarding:

> "hl" colliding with an existing parameter is one of the drawbacks of
using it as a query parameter or a fragment identifier. The spec doesn't
say this, but should. Can someone open an issue for that, please?

I opened an issue for it: https://github.com/w3c-ccg/hashlink/issues/11

Thanks,
Kim

On Sun, Apr 26, 2020 at 8:08 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 4/22/20 7:50 PM, Kim Hamilton wrote:
> > what's interesting is that this introduces some tooling on the caller
> > side I hadn't thought about til now. This is presented as a query
> > parameter, yet callers are simply stripping this off before sending* and
> > checking the response hash.
>
> Yeah, and this is the hacky part of it (and always has been).
>
> Remember, using the ?hl=HHHHHH or #hl-HHHHHHHH syntax *is a hack*, it's
> in the spec because people have legacy systems that they want to hack to
> upgrade them to have some sort of content protection. For example,
> JSON-LD Contexts w/ a ?hl=NNNNN value on them would be used by JSON-LD
> Document Loaders, which would send the value to the server, get the
> response back, and then check to make sure the server sent them what
> they asked for.
>
> Again, hacky hack, but useful if you don't want to fully commit to the
> "@context": "hl:HHHHHHHH:MMMMMMM" format, for example. I've been
> pleading with people to use the latter form (the one in this paragraph)
> ever since the spec came into existence, but people have their own ideas
> about why using it as a query parameter or fragment identifier
> absolutely has to be done in their particular use case.
>
> > *for a range of concerns: we don't trust the response, and also what if
> > "hl" collides with an existing parameter or fails because it doesn't
> > recognize.
>
> "hl" colliding with an existing parameter is one of the drawbacks of
> using it as a query parameter or a fragment identifier. The spec doesn't
> say this, but should. Can someone open an issue for that, please?
>
> Also, can someone (Alex?) open an issue for encoding as a fragment
> identifier as another option?
>
> > It's weird that we express it as a query parameter and then not use it
> > that way. Not complaining, just surprised.
>
> Servers should pay attention to all query parameters. If the server
> responds, it's because it processed the query parameters w/o error (yes,
> that might be that the code path doesn't know anything about "?hl", but
> that's the world we live in... and is why the client should always check
> the result. Again, broken record, but -- please don't use "?hl=HHHHH"
> syntax! It is brittle. Please, please, please use "hl:HHHHH:MMMMM"
> syntax if remotely possible... it's the most secure option.
>
> The reason "?hl=HHHHHH" is useful is because the server can actually
> produce different results for different hashes at the same URL. For
> example:
>
> https://w3id.org/security/latest?hl=12345
> https://w3id.org/security/latest?hl=6789
>
> The two base URLs w/o query parameters above are actually two different
> resources... doing the above would be compatible w/ all URL fetching
> libraries today, but it would allow people to choose the bleeding edge
> they're working on w/o causing the URL maintainers to keep upgrading the
> base URL.
>
> Orie, if you're seeing this, doing so would allow us to manage the DID
> Specification Registries JSON-LD Context in a way that would enable
> people to lock into a particular version of the registry while not
> holding up everyone else. Yes, it would mean hundreds of JSON-LD
> Contexts, but that is a natural result of the decision that the DID WG
> made. In any case, we may want to consider this, rather than
> .../did/registries/v1 -> .../did/registries/v83
>
> Kim, Alex, was this helpful?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>