Intellectual Property concern wrt. SD-JWT examples

[msporny]

@bc-pi wrote (on the VCWG mailing list:

Are there any concerns from the W3C or the Verifiable Credentials Working Group regarding the use of some of the YAML constructs from the OpenWallet Foundation’s SD-JWT Reference Implementation in the 'Securing Verifiable Credentials using JOSE and COSE' publication? Specifically, these constructs appear in two examples* without attribution, explanation or reference. Could this raise issues related to publication process/procedure, intellectual property rights, or document clarity?
* these two examples:
https://www.w3.org/TR/vc-jose-cose/#example-a-simple-example-of-a-verifiable-credential-secured-with-sd-jwt
https://www.w3.org/TR/vc-jose-cose/#example-a-simple-example-of-a-verifiable-presentation-secured-with-sd-jwt

[msporny]

Are there any concerns from the W3C or the Verifiable Credentials Working Group regarding the use of some of the YAML constructs from the OpenWallet Foundation’s SD-JWT Reference Implementation in the 'Securing Verifiable Credentials using JOSE and COSE' publication?

Speaking as an Editor of some of the specifications in the VCWG, yes, I am concerned. The content seemed questionable when I saw it, but assumed the Editors of that specification had cleared all the necessary IP hurdles to include that markup.

Specifically, these constructs appear in two examples* without attribution, explanation or reference. Could this raise issues related to publication process/procedure, intellectual property rights, or document clarity?

I had presumed that these examples were using things that were cleared by the Editors of that document and/or approved by or worked on at IETF. I believe one of the former Editors added that markup to the document w/o much of a discussion in the group and the current Editors took over the document w/o the sort of warning you're providing.

It looks like we need to have a discussion about using markup/content that does not have clear IP protections wrt. SD-JWT examples. At the very least, we need to:

1. Check w/ OWF to ensure that they are going to release the IP associated with that markup language.
2. Check with IETF to understand if they're going to standardize that markup language (or at least, don't see a concern with using it).
3. Determine what the markup language should be for that sort of thing (if the answer to either of the above questions is "No").

[selfissued]

The software in question used to generate the examples - the Open Wallet Foundation Python SD-JWT implementation at https://github.com/openwallet-foundation-labs/sd-jwt-python - uses the Apache 2.0 license. The point of that license is to enable anyone to freely use the software for any purpose - which I believe addresses any intellectual property question.

A separate point is that the purpose of the YAML should be explained, which @bc-pi correctly points out. How about this language, along lines privately proposed by @OR13, as a starting point?

The following SD-JWT examples rely on YAML as described in RFC9512 and use the tag !sd to convey which parts of a JSON object are disclosable. This is an implementation detail and these examples are non normative.

[msporny]

The following SD-JWT examples rely on YAML as described in RFC9512 and use the tag !sd to convey which parts of a JSON object are disclosable.

Why are we using a bespoke domain-specific language to describe these properties in the specification?

[iherman]

I know that YAML is a superset of JSON but, largely, I see YAML as (for many) a more readable alternative to JSON. Isn't it possible to express everything in JSON, to be in line with the rest of the specifications?

[bc-pi]

which I believe addresses any intellectual property question.

IANAL but IMHO the IPR question is not that clean - the Apache 2.0 license requires preservation of copyright and license notices, which clearly hasn't happened here.

[bc-pi]

Why are we using a bespoke domain-specific language to describe these properties in the specification?

That's a good question. That bespoke domain-specific language by @danielfett is quite nice for it's intended purpose but is wholly inappropriate for use in a specification like this.

[danielfett]

I know that YAML is a superset of JSON but, largely, I see YAML as (for many) a more readable alternative to JSON. Isn't it possible to express everything in JSON, to be in line with the rest of the specifications?

Not easily, as here a YAML feature is used that JSON doesn't support (adding a type to a key).