Re: CR Transition - help needed

I created https://github.com/w3c/rdf-canon/pull/180 with some suggested wording, and an arbitrarily picked CR exit date.

Gregg Kellogg
gregg@greggkellogg.net

> On Oct 13, 2023, at 2:39 AM, Phil Archer <phil.archer@gs1.org> wrote:
> 
> Hi all,
> 
> It seems we need to do a little more work before we can achieve Candidate Rec. See https://github.com/w3c/transitions/issues/571#issuecomment-1750709231
> 
> If we can sort this out via email, so much the better. If we need to meet on Tuesday next week (17th) then we can.
> 
> Firstly, and most easily, we need to specify the exit criteria in the status section of the doc. We agreed these at TPAC, see https://www.w3.org/2023/09/11-rch-minutes.html#r03 but didn't write them in.
> 
> @Gregg - can you please make the necessary change to the doc? The VC Data Model at https://www.w3.org/TR/2019/CR-verifiable-claims-data-model-20190328/ provides a template if needed.
> 
> Secondly, we didn't explicitly consider the other liaisons in our charter. With thanks to Pierre-Antoine, here's a breakdown:
> 
> Verifiable Credentials Working Group
>   To synchronize the definition and usage of the RDF Dataset Canonicalization and Hash, both needed for the ability to provide proofs for Verifiable Credentials.
> → ensured by a significant intersection between the two groups
> 
> Dataset Exchange Working Group
>    To synchronize on the needs and requirements of dataset publications and exchange regarding canonicalization.
> → ensures via common team contact; the DCAT-3 references RCH (https://www.w3.org/TR/vocab-dcat-3/#security_and_privacy)
> 
> Web Application Security Working Group
>    To ensure that the canonicalization and hashing mechanisms defined in this group have similar security properties to the rest of the Web, and to take advantage of lessons learned while designing other canonicalization systems.
> → ?
> 
> I would suggest that the privacy and security review we did and the TAG review cover this but did anyone talk to WebAppSec directly?
> 
> 
> 
> Web of Things Working Group
>    To synchronize on the needs and requirements of the WoT community, in particular on the subject of WoT Thing Descriptions, regarding canonicalization.
> → joint session during TPAC 2023
> 
> Credentials Community Group
>    Coordination on other specifications incubated and maintained the Credentials Community Group at W3C.
> → ensured by a significant intersection between the two groups
> 
> RDF-DEV Community Group
>    To synchronize on the further evolution of the RDF Standard, such as canonicalization and hash functions for Generalized or RDF-star Graphs and Datasets.
> → ensured by a significant intersection between the two groups; point to relevant issues on GH
> 
> External Organizations
> 
> Internet Engineering Task Force Crypto Forum Research Group
>    To perform broad horizontal reviews on the output of the Working Group and to ensure that new pairing-based and post-quantum cryptographic algorithms and parameters can be integrated into the RDF Dataset Hash ecosystem.
> Hyperledger Aries
>    To coordinate on broad horizontal reviews and implementations related to the specifications developed by the Working Group.
> Decentralized Identity Foundation Interoperability Working Group
>    To coordinate on broad horizontal review and integration of the specifications developed by the Working Group into the Decentralized Identity Foundation's ecosystem.
> 
> → ?
> 
> I'm not aware of any direct communications here? But I'd suggest that the support for other hash algorithms that we have discussed at length recently cover the Crypto issue?
> 
> DIF? Might be a little more tricky. If we have no evidence of direct communication then can we think about whether the DIF's approach is in line with RDFC in the first place? If not, I'd question the need for the liaison?
> 
> 
> Phil
> 
> 
> 
> ---
> 
> Phil Archer
> Web Solutions Director, GS1
> https://www.gs1.org
> 
> https://philarcher.org
> +44 (0)7887 767755
> https://mastodon.social/@PhilA
> 
> CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are  confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium). 
> If you are not the addressee, or if this has been copied or sent to you in error, you must not use data herein for any purpose, you must delete it, and should inform the sender. 
> GS1 disclaims liability for accuracy or completeness, and opinions expressed are those of the author alone. 
> GS1 may monitor communications. 
> Third party rights acknowledged. 
> (c) 2020.
>