- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Thu, 23 Apr 2020 11:41:13 +1200
- To: Kim Hamilton <kimdhamilton@gmail.com>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
On 23/04/2020 11:24, Kim Hamilton wrote: > yes, that totally makes sense, but, isn't the expectation of this > caller behavior quite unique as far as URLs go? > > It's easier for me thinking about hashlinks as an abstraction for > immutable, content-addressable storage, where the response with simply > be: you get the data or you don't. But that is not the model that the majority of web servers use, and if even if they did, the untrustworthy ones would not. So you cannot place any expectations on an untrustworthy web server. > > This opens up many implementation questions. > > On Wed, Apr 22, 2020 at 4:14 PM David Chadwick > <D.W.Chadwick@kent.ac.uk <mailto:D.W.Chadwick@kent.ac.uk>> wrote: > > > On 23/04/2020 10:57, Kim Hamilton wrote: > > This has caused a series of questions, but then I realized the > > behavior around hashlink requests/responses may be out of scope > of the > > spec (I don't see this on a scan). > > > > Nevertheless, here are some naive questions I'm curious for your > > reaction to. > > - What is the expected behavior from the server if the hashlink > > doesn't match? Is it valid for a server to have indexed past > versions > > by their content integrity hash, and serve that up? Or is a > mismatch a > > failure > > - 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? > The caller must be the entity that performs the hash and confirms the > content. Otherwise an untrustworthy server can serve any old > content and > says that it matches the hash. Not good! > > > > > > > > > > On Wed, Apr 22, 2020 at 7:42 AM Manu Sporny > <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> > > <mailto:msporny@digitalbazaar.com > <mailto:msporny@digitalbazaar.com>>> wrote: > > > > On 4/22/20 1:19 AM, alex thompson wrote: > > > Regarding parameterized URLs > > > > https://tools.ietf.org/html/draft-sporny-hashlink-04#section-3.2 > > > > > > Can we generalize that for URL segments instead of just > query string > > > similar to https://tools.ietf.org/html/rfc6920#section-5 > > > > > > Examples: ./hl;zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e > > > ./hw.txt#hl;zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e > > > > > > I think there are clear use cases for having it in the path > > (avoiding > > > conflicts with windows filesystems not allowing "?") and > fragment > > > (doing client side only validation) > > > > Hmm... that's an interesting thought. The Parameterized URL > stuff was > > meant to be a hack to enable the use of hashlinks in legacy URL > > formats. > > > > Allowing them to be embedded in paths and fragments seems like > > even more > > of a hack, so the question really is... are we ok with > hashlinks being > > hacked into all these awkward places? > > > > 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?". > > > > ... and then we wait for feedback. If we get no feedback or > negative > > feedback, we take it out of the spec. If we get positive > feedback, we > > keep it in. > > > > Would that work for you, Alex? > > > > -- 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 Wednesday, 22 April 2020 23:41:35 UTC