- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 26 Apr 2020 11:11:53 -0400
- To: Credentials Community Group <public-credentials@w3.org>
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