Re: Hashlink parameterized URL

A similar proposal from 2015, referred to as "trusty uris". I haven't
sorted through the differences yet, but putting this out there:
https://www.researchgate.net/publication/273945977_Making_Digital_Artifacts_on_the_Web_Verifiable_and_Reliable

Is this the next Newton/Leibniz controversy?*

* no, it's totally not. But check out Leibniz's Soundcloud...

On Wed, Apr 29, 2020 at 5:04 PM alex thompson <pierogitus@hotmail.com>
wrote:

> Manu,
> I agree with trying to encourage the scheme syntax ("hl:"). I'll make a
> pull request that tries not to impede that goal.
>
> One last point, what do you think about not using "=" so you would have a
> query like
> ?key1&key2=v2
>
> key1 would be the entire hashlink not just "hl" which eliminates key
> collisions. It would need another delimiter which I propose as double
> hyphen "--" and you could even use the metadata part as hl--HHHHH--MMMMM
>
> My rationale is that because this is such a hack it should have a more
> distinct syntax than regular url params.
>
> Alex
> ------------------------------
> *From:* Kim Hamilton <kimdhamilton@gmail.com>
> *Sent:* Tuesday, April 28, 2020 6:16 PM
> *To:* Manu Sporny <msporny@digitalbazaar.com>
> *Cc:* alex thompson <pierogitus@hotmail.com>; public-credentials@w3.org <
> public-credentials@w3.org>
> *Subject:* 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
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c-ccg%2Fhashlink%2Fissues%2F11&data=02%7C01%7C%7C6854fb669aaa44cad45608d7ebdaf69a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637237197974813844&sdata=HQ3gzS%2BYNEMXNDDWCCBasJixegqyeSciPvTpMDe33NU%3D&reserved=0>
>
> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3id.org%2Fsecurity%2Flatest%3Fhl%3D12345&data=02%7C01%7C%7C6854fb669aaa44cad45608d7ebdaf69a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637237197974823838&sdata=G%2Bh90JmVkSmHvR5EXvI%2BupJG4sDAmTzfX3kTzqLAh8U%3D&reserved=0>
> https://w3id.org/security/latest?hl=6789
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3id.org%2Fsecurity%2Flatest%3Fhl%3D6789&data=02%7C01%7C%7C6854fb669aaa44cad45608d7ebdaf69a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637237197974823838&sdata=arnt%2FSQ1LnBQ%2FzSNq%2BxYWO8hq3mE2rbsokzkUsv1FQ0%3D&reserved=0>
>
> 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/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7C%7C6854fb669aaa44cad45608d7ebdaf69a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637237197974833836&sdata=jYov8HWS9prwXGBuGbctcH1xYR1WizqCue9kG2yV9Ws%3D&reserved=0>
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7C%7C6854fb669aaa44cad45608d7ebdaf69a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637237197974833836&sdata=XlIUerRpPm%2FEFgKvGyUITYqmG7wyemSuWLM2O14Zyd4%3D&reserved=0>
>
>