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

Re: Hashlink parameterized URL

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 26 Apr 2020 11:11:53 -0400
To: Credentials Community Group <public-credentials@w3.org>
Message-ID: <c084cf93-a9cc-b7cf-ba56-a5dcd45cc465@digitalbazaar.com>
On 4/22/20 7:45 PM, alex thompson wrote:
> 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.

Ok, sounds good, please raise an issue (or a PR if you're feeling good
about exactly what should be written).

I'll need to publish the spec in the next week or two, so would like to
get this in there if possible.

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

Note that this is the use case *for all variations of hashlink*. That
is, it's primarily client-side technology... the client MUST always
check what it gets back to ensure that it is what they asked for. The
client MUST NOT trust the server to do the right thing.

-- 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
Received on Sunday, 26 April 2020 15:12:06 UTC

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