Meeting minutes
<ivan> Date: 2024-02-21
brent: Welcome to the VCWG call
manu: I responded to a privacy review by Ping
Jennie: I'm Jennie Meyer. I'm here with Digital Contract Design.
PING Review Report
<manu> w3cping/
manu: PING did a review on Bitstring Status List 2 weeks ago
<manu> Response here: w3cping/
manu: including by Martin Thompson of Mozilla
… I responded about an hour ago
… Nothing new came up
… The spec could talk more about correlation and tracking with the identifiers used
… Please look at the response to them
… I've requested that they raise issues for things they want us to address
manu: If they don't raise issues, we may have to read the tea leaves
Work Item Status Updates/PRs
decentralgabe: We've been making excellent progress on jose-cose
… We have 10 remaining issues for Before CR - 4 with PRs
… We hope to get to CR by the end of the month or not much later
brent: PR #239 adds securing with JWS
selfissued: Gabe has done good work so that rendering of examples are consistent.
brent: People are encouraged to review the issues and PRs
<manu> https://
manu: I processed PRs on VCDM. We have another set that appear to be non-controversial.
<manu> Jeffrey has reviewed the algorithm alignment work here: w3c/
brent: Are there other VCDM PRs that could benefit from discussion in the group?
PR Review
ivan: There's also the item on media types we should look at
<decentralgabe> w3c/
w3c/vc-data-model#1441
ivan: I don't want to get into a discussion of the details of the diagram here
… The question is whether we want to keep it
manu:
manu: We should keep it. I've referred to it.
<manu> lifecycle of VC: https://
manu: We should update the diagram and move it to the lifecycle section
decentralgabe: +1 to what Manu said
… I find the diagrams very useful
<manu> +1 to "more pretty pictures please"
decentralgabe: More pretty pictures please
brent: Where in the DM is the diagram currently?
<manu> https://
ivan: Let's keep it
… I propose that I edit the diagram to incorporate comments from David Lehn, etc.
<decentralgabe> we also have https://
ivan: Later we could move it, but I don't want to mix the two issues
… I'm happy to do the required changes
brent: We should probably combine sections
<ivan> For reference, the new version of the diagram is (temporarily) here: https://
manu: We need to figure out what we're doing with these sections
… Let's start by updating the diagram first
… Then later editorially move things around
<ivan> +1 to manu
brent: The PR that modifies the diagram will be merged after Ivan updates it
… I will open a PR proposing combining sections
w3c/vc-data-model#1440
ivan: We had a call on this issue. We decided to change the term "Media Type" to "Encoding Format".
<ivan> w3c/
ivan: Discussions are ongoing
… We shouldn't spend that much time on this
manu: The goal is for activity streams to be able to use this without changes
… We may just be incompatible with the activity streams context
… If changing this one thing doesn't fix it, then we shouldn't make the change, since the problem wouldn't be addressed
… The way activity streams and schema.org define the context are neither right
… We probably don't want to do this
… Maybe we should define IANA media type and have it refer to the IANA registry
… I'm leaning towards that being my preference
… The downside is that we're creating yet another term
ivan: Note that the two things you mentioned are orthogonal to one another
… What term should we use?
… Should we define it ourselves?
<TallTed> ianaMediaType was my idea, fwiw. its domain & range remain vital.
ivan: The definition of a data type for media types can be added
… It's not a huge deal
… I question altogether whether we should do
… This property won't be widely used anyway
<dlongley> another option is to go with `encodingFormat` today and then potentially add `ianaMediaType` or `mediaType` in a future WG
selfissued: It would be strange to change from a term that is well known "media type" to "encoding format", which we'd be entirely making up.
ivan: We are not making it up, schema.org defined it.
selfissued: That's not authoritative for us.
ivan: That's debatable.
<Zakim> manu, you wanted to ask Dmitri if there are plans for another AS context?
manu: Dmitri is on the call and is chairing the Social Web Community Group
dmitri: We're the ones shepherding the activity streams formats
<Zakim> manu, you wanted to propose a concrete path forward.
dmitri: We want to be able to sign activity streams objects
manu: We shouldn't use schema.org
… We shouldn't use activity pub
… We should point to IETF and IANA and get this right once and for all
… It probably shouldn't go in our vocabulary
… It could go in our security vocabulary
… We should call it something that people understand
<ivan> IANA pointer
ivan: I have put this pointer into the minutes
iana: From an RDF point of view, would the pointer be the URL of the property?
… I don't really like that
… Instead we can define a media type for RDF
… This is where the string format is defined
… We define a property in one of our vocabularies
manu: I wouldn't object to that
… But we'd be repeating what the social web and schema.org did and we'd be creating another property
ivan: I don't know exactly how activity streams defined it
… If its compatible with IANA, we could use it
… If Dmitri gives me a pointer to the definition, I could look at it
It's defined here: https://
dmitri: What's the objection to reusing the mediaType definition?
manu: They made it too specific to activity streams
dmitri: That could be changed so it can be applied to any domain
ivan: That would be perfect
selfissued: It's not clear to me, are we taking a dependence on an externally defined vocabulary?
dmitri: We could change that
manu: We already point to a bunch of externally defined vocabularies
… We'd be reusing the URL they use for the definition
… This would be more correct than using the schema.org encoding
… We could actually call this media type
dlehn: ?Question?
… Equivalency checking
agree with Dmitri, I don't think this is an issue to re-use AS as long as it's aligned.
dlehn: How much do people do full RDF processing?
dmitri: Zero
brent: The proposal to raise an issue on the activity streams repository sounds right
… For our PR, the consensus is to not merge that PR
ivan: I'm happy to close it
… Who has the action to raise the PR in the right place?
brent: I'm willing to do it but I'm not sure I could accurately reflect what we want.
ivan: I'm willing to do it
VCDM Issue Processing
<brent> https://
The activity streams repository is https://
w3c/vc-data-model#1254
manu: This text is in the internationalization write-up
… I think it's fine where it is
<ivan> +1 to manu
manu: It doesn't need to be in the Security Considerations
… I think we should mark the issue pending close
brent: Any objections to that?
… No objections
w3c/vc-data-model#1098
brent: This is about setting up a mini registry inside the spec
… What are the next steps?
DavidC: The issue sets it out clearly
… It's a question of semantics
… If something is already defined, what does it mean to more formally define it?
manu: The distinction is between a term being defined, referencing a URL, and writing text about the definition
… For example, we may reserve render method but we won't write normative text about it
DavidC: I can buy that
… We have a table of reserved properties anyway
… We can say that "these terms are reserved" and may be defined later
+1 to that suggestion
w3c/vc-data-model#1197
DavidC: I can create a PR
selfissued: The term "public key" is well known, "verification material" is not, why would we do this?
manu: There are verification methods that don't use public keys.
brent: A response to this issue entails going through the spec and inspecting the places we use the term "public key"
w3c/vc-data-model#995
manu: I am against continuing this discussion
brent: Marking "pending close", per the previous minutes
brent: If we are pretty sure we're not going to get to something, we should close it.
… I don't have confidence that a future group will pick up on leftovers we leave them