How should we refer to the Securing specifications?

[msporny]

In PR#1086, @OR13 wrote:

Feels like we should either omit [[VC-JWT]] and [[VC-DATA-INTEGRITY]] and just point to the [[VC-SPECS]] registry, or we should omit the registry pointer and just point to them.

[decentralgabe]

I would prefer pointing to both, and add additional as they become normatively referencable.

[OR13]

Seems like it might be better to refer to a registry that has "specification required" instead, otherwise the reference is a form of bias.

[iherman]

The issue was discussed in a meeting on 2023-05-17

• no resolutions were taken

View the transcript

2.4. How should we refer to the Securing specifications? (issue vc-data-model#1105)

See github issue vc-data-model#1105.

Brent Zundel: one more 1105.
… How should we refer to the securing specifications.
… Who is willing to be assigned to move it forward?
… Or should it be marked pending closed?

Manu Sporny: I think we already point to the specs normatively.
… Doesn't that address the issue?

Brent Zundel: sounds like a request to mark pending close. Any objections?

Orie Steele: The original issue was regarding attempting to frame the core data model to be more inclusive of more securing mechanisms.
… pointing to DI seems to favor DI over others.
… If we do both, we're creating a two-tier system. Those that are in the VCDM and those that aren't.
… The original issue is how we frame securing formats. Not just those we work on here.

Brent Zundel: It doesn't bother me to point to our own groups specifications.
… but I would not be opposed to adding a link to the VC Specs Directory so that as new mechanisms are added there, they can be found.
… Anyone willing to be assigned?

Ivan Herman: +1 to Brent's.

Kevin Griffin: I'll take a stab at it.

Orie Steele: thanks kevin, this seem like a good one for you.

Brent Zundel: Thank you.
… with that, we didn't quite get through all of them.

[brentzundel]

I'm fine pointing directly to specs we define as examples of a normative means of accomplishing something.
My preference is to close this issue without action.

[OR13]

Needs to address https://github.com/w3c/vc-data-model/pull/1181/files#r1253526700

[iherman]

The issue was discussed in a meeting on 2023-07-05

• no resolutions were taken

View the transcript

2.8. How should we refer to the Securing specifications? (issue vc-data-model#1105)

See github issue vc-data-model#1105.

Kevin Griffin: The queue is for issue #1105.
… I think the language that was merged in PR #1086 is fine. I agree with Brent.

Manu Sporny: +1 to what brent said, no further action needed, close it.

Orie Steele: -1.

Kristina Yasuda: You're agreeing with Brent's comment to close with no action, right?

Orie Steele: +1 to closing.

Kristina Yasuda: Manu agrees.
… I'm closing it.

Orie Steele: Brent mentions that proof can be used for things that are not Data Integrity.
… We will still have to describe proof and what to do when you get a different kind of proof.
… We are not citing any securing spec for non Data Integrity uses.
… I'd like that to be made more explicit.

Manu Sporny: It would be good to highlight that.
… proof is not just for Data Integrity.
… The object that's pointed to needs to have a type.

Orie Steele: The vocab defines proof as being specific to JSON-LD... but afaik, its not required to be of type "DataIntegrityProof".

Orie Steele: implementers might need to understand that.

Kristina Yasuda: We want Brent's PR to address this.

Orie Steele: I don't think Brent's PR can address this.
… We need a standalone PR enumerating the two securing specifications.
… We need to say how to use it with the Vocabulary we have.
… Proof is arbitrary JSON-LD.
… You'd better know what you're doing.
… As a security person, this scares me.
… We need to address the challenges of conflating the securing methods with the VCDM.

Brent Zundel: We need a different PR.

Manu Sporny: I can take a shot at this.

Orie Steele: thank you manu!

[msporny]

PR #1212 has been raised to address this issue. Once PR #1212 is merged, this issue will be closed.

[msporny]

PR #1212 has been merged, closing.