Re: Hashlink parameterized URL

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<mailto: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>