Re: CBOR-LD stabilization (was: Re: Regarding CBOR-LD Web Transports)

> On Apr 25, 2021, at 8:13 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 4/21/21 9:28 AM, Leonard Rosenthol wrote:
>> However, I am concerned about the status (or lack thereof) on the actual 
>> specification.
> 
> There is the start of a specification here, albeit, it is now out of date and
> light on details:
> 
> https://digitalbazaar.github.io/cbor-ld-spec/
> 
>> Without an actual specification, preferably on an active track(!), it will
>> not be possible for this technology to be used in other standards that
>> would wish to do so.
> 
> While I agree with this statement, we're still in early days with the
> pre-standard... it's not even a CG work item (in any CG, yet). We proposed it
> to the JSON-LD group and the response was tepid interest and confusion.

To clarify, there was certainly interest in the JSON-LD WG for CBOR-LD, and work started on a note [1]. The problem was that it came in late in the process and we didn’t have sufficient expertise among active participants. However, the core specs opened the way for this by separating the core algorithms from the JSON syntax.

IIRC, the group felt that its role would be to define the specific transformations between the core representation and not the content of any context that would be required to get the best encoding to take advantage of CBOR. Manu and Dave’s spec depends on a specific Term Codec Registry, which would be an application of a core spec, and the group didn’t quite figure out how that might work within a standard framework.

I would suggest separating the core normative algorithms for CBOR-LD from the registry ittself so that there is room for alternate registries or updates to a registry over time.

Note the the JSON-LD WG remains open as a Maintenance Group and could publish a document (not sure if it can be TR, though) given participants with interest to work on it.

Gregg

[1] https://w3c.github.io/json-ld-cbor/

> The use case driving this stuff is the vaccination certificate work as well as
> anti-fraud features on government-issued ID cards.
> 
> Until multiple companies engage in experiments (which is starting to happen
> now w/ Mattr and Transmute), do implementations (which there is only one of
> right now), it's an adopted work item (which is a discussion that still needs
> to be had), and more loud industry support... there is only so much 3
> companies can do.
> 
> That this stuff is of interest to Adobe is great news, but as you know, we
> need it to be of interest to 30-50 companies before we can take it standards
> track. While it looks like interest is building rapidly for CBOR-LD... we're
> not quite there yet and I have no idea when we will be there.
> 
> To put it in perspective, it took ~9 years for the interest to build in Linked
> Data Signatures before we were able to get a W3C Charter circulated for it. I
> expect CBOR-LD might move much faster (it's far simpler than JSON-LD, VCs,
> DIDs, or Linked Data Signatures).
> 
>> Also, I would like to see more work done on non-VC/DID uses cases for the
>> technology to demonstrate its flexibility and benefit in other contexts
>> that require optimized binary serializations.
> 
> Agreed, and that would require new participants to join in. This will most
> likely occur via the proposed Linked Data Signatures WG. The current
> participants are buried in work.
> 
>> I am happy to do what I can to further the work on the spec as needed...
> 
> The next step for the specification would be:
> 
> 1. Reading and understanding the current stable
>   implementation:
> 
> https://github.com/digitalbazaar/cborld/tree/main/lib
> 
> 2. Translate the code into algorithms in the
>   specification:
> 
> https://digitalbazaar.github.io/cbor-ld-spec/#get-term-codec-map-algorithm
> 
> PRs welcome. :)
> 
> -- 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, 28 April 2021 16:28:41 UTC