Hashlinks (was Re: The new charter is now in place)

Sorry – Ivan – good catch.

I meant query parameter (?hl).   (was thinking about another URL extension that I am working with that uses fragments)

It has been pointed out to me that RFC7320 (BCP 190) prohibits the use of a specific query parameter for this purpose (there is even an example of using a `sig` query parameter).  Additionally, there seems to be a huge amount of animosity towards creating new schemes (eg. `hl`) as well.

As I am currently using hashlink in a standard I am building (https://contentauthenticity.org/) – I have a *HUGE* amount of interest in getting this resolved (or coming up with a new solution that will fly)

Leonard

From: Ivan Herman <ivan@w3.org>
Date: Sunday, August 23, 2020 at 11:47 AM
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Gregg Kellogg <gregg@greggkellogg.net>, Manu Sporny <msporny@digitalbazaar.com>, W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
Subject: Re: The new charter is now in place




On 23 Aug 2020, at 12:59, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

And all of which also depends on Manu and I figuring out how to get hashlinks through the standards process.   There are definitely going to be problems at the IETF, as there are those who feel strongly that the current proposal isn't compatible with the underlying URL specification and how fragments are supposed to work.


Can you explain this? The IETF proposal[1] doesn't seem to use fragment ids...

[1] https://tools.ietf.org/html/draft-sporny-hashlink-05<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-sporny-hashlink-05&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341190117&sdata=YvN0O8l3xr9JDEEDzjT40rct6QdvtxiCI014AAIp6lA%3D&reserved=0>


I wonder if we could do it via W3C - but are we going to cause more of a rift between the two by doing so...(we know how they felt about the HTML folks taking over the URL spec....)

Yep, I think getting this through W3C would have very little chance. This is IETF land…

Ivan



Leonard

On 8/21/20, 4:52 PM, "Gregg Kellogg" <gregg@greggkellogg.net<mailto:gregg@greggkellogg.net>> wrote:


On Aug 21, 2020, at 8:35 AM, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:

On 8/20/20 4:58 PM, Gregg Kellogg wrote:

Perhaps we can describe mechanism for creating
versioned/cached/optimized contexts, with a default managed by the
group, along with a way to validate and update context versions. It
should allow others to create their own context set, and how to achieve
and measure the resulting compaction.

This mechanism exists in the current CBOR-LD implementation:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdigitalbazaar%2Fcborld%2Fblob%2Fmain%2Flib%2Fcodecs%2FContextCodec.js%23L9-L11&amp;data=02%7C01%7Clrosenth%40adobe.com%7C9cc5fd2e76b848c1bef208d846142d4b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637336399759466031&amp;sdata=5CgueW292h%2BtoqZqD9Nr0TeGgMSYpLzACeHKn1pNo5k%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdigitalbazaar%2Fcborld%2Fblob%2Fmain%2Flib%2Fcodecs%2FContextCodec.js%23L9-L11&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341190117&sdata=g5kwMZjD%2FheV2a0Dv8EcAHQVI9C9wKrNijkOlKzqKwA%3D&reserved=0>

The way it works today is that JSON-LD Contexts that are guaranteed to
not change (for some externally known reason, such as they're a part of
a W3C specification that locks the contexts in at particular releases
with a SHA-256 hash, for example). There can be 32,768 of these sorts of
contexts that are managed by the specification registry for "contexts
that won't change and are thus safe to use with CBOR-LD".

   I’m not sure what contexts would be guaranteed not to change. Several have been changed, where those changes are deemed to have not invalidated anything that was there before (e.g., prefix definitions).

   Previously, these issues were stalled because of the lack of a good mechanism to guarantee the context integrity. Hashlink seemed like the best solution to me, so maybe if such a spec were limited to contexts served up via hashlink, or similar.

   Some specs have decided to create versioned contexts to guarantee that a given version remains unchanged, but this is often (usually?) not the case.


There is also another namespace consisting of 32,768 entries that are
application-defined. If an organization doesn't want to register their
frozen context globally, then they can just publish an
application-specific specification that specifies values from
32,769-65,535. There can be 32,768 of these sorts of contexts for
"application-specified contexts that won't change and are thus safe to
use with CBOR-LD".

   Sounds like another managed registry of immutable data, which might be reasonable, but groups would need an incentive to  use this as well as to mandate the use of specific versioned context URIs.


What we don't do today for CBOR-LD is throw an error if one of these
types of contexts are NOT used. We can put that into the
specification... but remember, we don't throw in this case for JSON-LD
today either... so it would be a strange requirement to put on CBOR-LD
since we don't do that today for JSON-LD.

Contexts can change... that's been known for a very long time with
JSON-LD, and there are a variety of mitigations against that that are
deployed today (ship with frozen contexts and only use those, use
hashlinks or some other form of content-addressed identifier, use known
frozen URLs, etc.)

   Yes, as I suggested above. It seems like a W3C-wide mandate, though, which is a high barrier to achieve.

   Gregg


-- manu

--
Manu Sporny - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7C9cc5fd2e76b848c1bef208d846142d4b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637336399759476024&amp;sdata=AdwslSAoI0PNK6TEJr4Hw4G6w1WAsynh8DzlzKbV9TE%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341200113&sdata=WamhtZH8DQR%2BQdHVhNg0Rli1xujwgyYP0JH642WN9NE%3D&reserved=0>
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&amp;data=02%7C01%7Clrosenth%40adobe.com%7C9cc5fd2e76b848c1bef208d846142d4b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637336399759476024&amp;sdata=dXzhb1HIbT4CVzu%2B2UHxbSFh1%2F1gBzFJZhL%2F0ealmZA%3D&amp;reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341200113&sdata=siItCzd97s7LFgUsbvY47LuZ1VF6P1T5PiVWf0rQAsc%3D&reserved=0>


----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FPeople%2FIvan%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341210105&sdata=EsX%2B8svLAOurumwZh%2B%2BDXBq8WGLCULMQ8TbNIP2flws%3D&reserved=0>
mobile: +33 6 52 46 00 43
ORCID ID: https://orcid.org/0000-0003-0782-2704<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0003-0782-2704&data=02%7C01%7Clrosenth%40adobe.com%7Cea1f54c231c24ee3a74a08d8477bcd46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637337944341210105&sdata=iS7%2F0GUl9Oq%2BubfprEA5bLmNFE7ceGz%2Bg8Gz5d2yOmA%3D&reserved=0>