W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

Re: Hashlink parameterized URL

From: Kim Hamilton <kimdhamilton@gmail.com>
Date: Wed, 22 Apr 2020 16:50:11 -0700
Message-ID: <CAFmmOzf=TjTwLwG3JtX3YUufv29tia==C0XXBiPDHFYS7XTNKQ@mail.gmail.com>
To: alex thompson <pierogitus@hotmail.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>
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.

*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.

It's weird that we express it as a query parameter and then not use it that
way. Not complaining, just surprised.

On Wed, Apr 22, 2020 at 4:45 PM alex thompson <pierogitus@hotmail.com>
wrote:

> Manu,
> > I don't have a strong opinion one way or the other, so am happy to add
> > an experimental section stating something to the effect of "Hey, if you
> > want to embed a hashlink in a path or a fragment identifier, here's one
> > way you can do it, and this is experimental and we're looking for
> > feedback on whether or not this is useful to you. Is this the only way
> > you can achieve your use case?".
>
> I think the approach taken in RFC6920 is more appropriate. Basically a
> disclaimer that acknowledges the ambiguity but still gives solid guidance
> that covers all the scenarios. Also since hashlink kind of supersedes
> RFC6920 I think it makes sense to have parity in this area.
>
> Kim,
> > - Could we envision a hashlink as something that's up to the caller to
> > parse and handle? I.e. caller extracts url (doesn't send hl) and then
> > confirms content received matches?
>
> Yes that's the use case for fragment so you can add an integrity value to
> a URL you don't control even if you can't support the hl: scheme
>
>
>
>
>
>
>
>
>
>
Received on Wednesday, 22 April 2020 23:50:34 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC