Meeting minutes
Brent Zundel: welcome, everyone on meeting needs to be member of W3C and working group or invited expert
… any introductions?
F2F Meeting
Brent Zundel: couple weeks away, meeting in Brussels, number of people both onsite and remote
<Brent Zundel> https://
Brent Zundel: agenda drafted and possible that things may still shift, content where we want to be
… most of agenda given to task forces, each will have at least one 75 minute slot
… expectation and hope is that Task Force leads will create brief intro on what Task Force is working on, rest of the time spent as they see fit - issue processing and raising PRs, discussing larger issues
… however it wishes to spend time
… please review what slots your Task Force has been assigned, limited ability to move things around, tried to be aware of remote participant needs but don't know all things and may not be able to accommodate all, but will do our best
… questions from Task Force leads or comments on agenda?
Joe Andrieu: did we manage to close loop with when Simone could do threat modeling?
Brent Zundel: yes, Tuesday immediately following lunch - will make sure he knows time and has links
… two 75 minute slots - first with Simone, second with the group
Joe Andrieu: do we know what topically we want to spend time on? Most mature Threat Model or most immature?
Brent Zundel: Simone has exercise he uses with Working Groups, but whether we start with something mature or immature, we'll take feedback. Open to group on how best to proceed
Kayode Ezike: what do you recommend for Task Force leaders who are remote for the day?
Brent Zundel: if you can't attend when you are scheduled to lead, we may be able to swap with someone in person. Either leading remotely or coordinating with someone there is good
Manu Sporny: agenda looks good to me, covers broad swath appropriately, thank you to chairs for putting it together
… threat modeling, would like us to know what we are doing before we show up as it may require a lot of prep
… happy for us to take most far along model
… let's take the most far along one and show people how it works - which one is that? other option is that we have a lot of people together, could we use time to work on least done one? two minds - Joe Andrieu, suggestions?
Joe Andrieu: interested in helping one least far along bootstrap. Not fully certain which one is most far along
… like bootstrap, give them the boost up and all groups would learn
Manu Sporny: I don't know if there are any threat models that are really struggling because we just started
… VCALM feels like good use of time - core issuer holder ecosystem. feels like something everyone would be able to participate in, something we all need to do, benefits other threat model. My vote of what we would focus on. Not super worthwhile to write barcode threat model, pretty niche, number of people who care about core threat model for VC
Data Model would be much higher
Ivan Herman: very different problem, no idea how threat model would look for vocabulary work.
Joe Andrieu: great question, think answer is that there probably shouldn't be one, similar question for registries
… process isn't up to date with answering that, don't know if it makes sense to have one
Ivan Herman: personally agree, but not sure what others would say
Manu Sporny: agree with Ivan Herman and Joe Andrieu, don't think there should be threat models for vocabularies. Used by other systems, we could spend an eternity on just focusing on threat models and need to find right balance
Brent Zundel: remaining questions and concerns, please reach out to chairs
VC and AI
<Brent Zundel> w3c/
Brent Zundel: asked in an Issue by Dom - team is seeking input on impact of AI on working groups
… not asking how we are using AI in meetings or specs, but how is AI impacting VCs and VCs impacting AI
… 20 minutes max
Ivan Herman: I took part in one of the discussions in another working group - kind of discussion - digital publication group
… conceivable in a few years that there will be digital groups that can display content right away or read aloud, EPUB looking at what additional data and metadata should be added to make the feature really good
… what are the features we might have to add or modify in our specs in the future as a result of AI
Patrick St-Louis: just going to share three quick points - reverse effect that VCs can be used to give authorization to AI, also think AI make implementation of - lot more easy to build these implementations, think AI can help understainding credentials and add purpose, and AI will probably drive features we want to add to the ecosystem, capabilities not
previously available
Joe Andrieu: I think AI in any roles becomes interesting, should probably consider how that will change language
… interesting wrinkle - is AI acting on its own or on behalf of legal person.
… how do we respond?
… not sure if there is consensus on how we would deal with it
Manu Sporny: +1 to everything Patrick St-Louis and Joe Andrieu said
… company vouch.id that presented, leveraged VCs and DIDs through whole protocol, example that they are building into protocols, deploying, using VCs for agent representation,
… healthcare industry, seen very similar type thing where agent operating on behalf of individual has had something delegated to it that allows it to interact with patient records - also using W3C VCs and DIDs
… explainability in AI, what reasoning path did AI go through to get to answer, today very probabilistic, seeing problems with that. AI conveying answers that make it seem like they went through a human-based thinking process, no formal mechanism that allows you to step through logic in more formal sense.
… retail sector - agentic commerce - definitely seeing it here
<Dave Longley> this isn't new -- so just adding it in chat here, but of course VCs are also being used "defensively" or to help differentiate between AI (or things AI has produced) and humans/persons and what they have produced.
Phillip Long: two responses - first, starting from perspective that there needs to be a connection between the DID whether it is being told to act or not, provenance needs to be retained and clear
… LLMs are probabilistic by design, may get better, but unless disign changes, no deterministic path to decision making
… notion of structured data formats VCs represent and algorithms used provide good anchor in keeping decision making reference back to some form of deterministic set of values
Joe Andrieu: wanted to highlight biometric template work in confidence method task force
… if you are interacting with someone, can they prove who
… yes, we need something like biometrics to help us figure out if there is a real person involved
Brent Zundel: thank you, good exploration so far. Most of what I've heard was positive, any other thoughts?
Ivan Herman: my question would be in relation to all the various things you all said, are there or should there be additional extensions or changes in our model or specification somewhere to have positively those applications or counter problems
… would any of these influence how our specifications look?
Manu Sporny: great question, also note, we don't have to solve these problems for the world because we aren't the experts here, but Ivan Herman, your point about would there be an extension or anchor that would help, we should look into that more
… between DID and VCWG - delegation part that feels like something we could do that would be useful
… but when you get into provable reasoning, nothing feels like we absolutely have to move on something right now
… just got a decentralized extensibility model, hope people will do work outside of the group
… mcpi and vouch
<Manu Sporny> +1 to start documenting AI use cases as a first step
Brent Zundel: could have an AI related use case. Because VCs are building block and can be used, this would be a demonstration of how they could be used, now how they would be changed
<Joe AndrieuAndrieu> +1 to AI use cases
Manu Sporny: real quick, apologies I was late, one thing I want to highlight with VC Data Model Core
w3c/vc-data-model#1629
<Manu Sporny> w3c/
Manu Sporny: PR to deprecate digest SRI - lots of +1s but also a push back on the issue
… raised a number of things, don't want to merge right now because it feels like he is objecting, would be good for others in group to chime in
… main concern with objections is that they are not technical in nature
… we've got to do something with the PR and issue, other opinions would be helpful in the thread
Brent Zundel: we do not have consensus to merge the PR (chair hat on) - implemented against DigestSRI our changing the spec now or changing in the future is requiring implementations to change, which is a consideration we have to take seriously
… please engage on the issue
… important discussion group needs to have
Controlled Identifiers Maintenance
<Brent Zundel> https://
Brent Zundel: we have a number of open issues in Controlled Identifiers Specification, need to make sure they are triaged appropriately and have a plan to address them because we are chartered to maintain this spec
Manu Sporny: there are a couple of comments. I made a pass over all issues to classify on changes, if ready for PR, lots that are not ready for PR
w3c/cid#168
Manu Sporny: one that is ready that Pierre-Antoine opened trying to qualify what the primary identifier is, one where I would appreciate more reviews on PR before merging. Don't think it harms anything, would also address one or two issues there
Manu Sporny: this PR is about allowing for fragment identifier in DID Document ID
… we are introducing this new term "primary identifier" and the primary identifier in a controlled identifier document, needs to be something without a fragment
… url of document, document ID must not contain a fragment
… primary identifier must be the same as the canonical
… don't put a fragment in document ID, want to make sure other people think algorithms make sense
… think it was confusing in previous working group
<Dave Longley> +1 to Joe Andrieu
Joe AndrieuAndrieu: Manu Sporny, seems like what you said is opposite of this PR
… okay to have fragment
Manu Sporny: think you are right, that would be bad
Ivan Herman: so, I can fully understand where he is coming from, whether we like it or not, using fragment ID has been around and used for last 25 years, very often can even see formal ID of TBL
… presume request came from solid working group (name today?) looking at CID as a tool for themselves, use case community that would like to use fragments. Whether we answer it or not is a different case
Brent Zundel: with the realization we were looking at this backwards, what are comments? We have the Issue, believe Issue links to conversation, I'm not super familiar with conversation in LWS
<Dave Longley> +1 to Joe Andrieu ... i think this just needs careful consideration ... and comparison against what the DID spec does for compatibility, etc.
Joe AndrieuAndrieu: I think this feels a bit off, part of hesitation is simply not having had time to understand if there is something deeply wrong with why it feels off
… confusing if there there a fragment that is not #me, don't know how that even works in a JSON-LD framework
… naive solution would be to take ID and append secondary fragment, now we have two fragments and that fees wrong
Manu Sporny: apologies, totally misrepresented PR, read through it twice
… http range 14 conversation that never dies, reading through with that understanding
… do admit that it is going to be hard to justify not allowing a fragment identifier in the CID document
… Joe Andrieu, agree it feels off, always fall on other side of range 14 conversation
… type of resource tells you what it is point toward
… but group of people that will never agree, fear is that we get pulled into a range 14 discussion
… don' think this breaks anything, but need to be very very careful with this PR
… now three different terms we use in spec to talk about URLs for document itself
… base identifier, primary identifier, canonical URL, and each of those means something a bit different
<Dave Longley> needs a little security analysis for things like how comparing controllers when resolving verification methods changes, etc.
Manu Sporny: just a warning it is HTTPRange 14 territory, keep in mind while reviewing. But to agree with Ivan Herman, that community agrees that there should be hash identifiers on these IDs
… don't know if there is any big problem adding this feature, but ramifications are pretty broad
Benjamin Young: I don't think I'd be quite as HTTP range 14, think it is clarifying something that isn't clarified now
… its permitted now, can put fragment identifiers in all of these URLs
Joe Andrieu: not permitted now
Benjamin Young: in CID spec, fragment identifier can appear?
Manu Sporny: no, specifically banned that
Manu Sporny: long discussion, fragment IDs not allowed
… think that as always range 14 issues seem simple, but not
… allows a different level of attacks, made us not feel great about security attack surface
Manu Sporny: if we are going to allow people to use fragment idenfiers, how does it change ??? could it be used as an attack vector to use key or object mix-ups, all these things come up when we allow this
<Dave Longley> +1 it might end up being ok, but requires more analysis.
Manu Sporny: may be okay, but need to look at Data Integrity spec and se how it it is used
… never really used CID spec directly, they would be the first ones really using the spec
Benjamin Young: I think one of the things triggering the range 14 bits is the section using hash me, but that could be any identifiable thing with a fragment, is a JSON-LD document
… so I think it is maybe okay, but we should dig into whether it is actually before we do the wrong thing
<Ivan Herman> +1, it is also used that way in my own foaf file
Manu Sporny: just to highlight why this seems simple - not always JSON-LD document, people who worked on this spec wanted to be able to use it without JSON-LD, so algorithms are not always straightforward
Brent Zundel: that is PR 168, let's look at our Issues now
… did someone just go through and put a bunch of class II and Class IV from these?
Manu Sporny: yes
w3c/cid#170
Joe Andrieu: not sure which class it should be
Manu Sporny: I vaguely remember using CID and it working, totally agree with Joe Andrieu that this should work, maybe it is CID 1.0, ways to do aliases, need someone who can work with XREF to work with it
Joe Andrieu: part of confusion, I meant to refer to term controlled indentifier, not specification
Ivan Herman: double brackets is for reference to documents
Ivan Herman: think you are looking for a different notation
Joe AndrieuAndrieu: I'll check, may not be an issue
<Manu Sporny> xref: ["CID"]
Manu Sporny: this does work Joe Andrieu, just checked in DID spec - search for document and it is cross-referenced
<Manu Sporny> [=controlled identifier document=]
Joe AndrieuAndreiu: that worked, but that is not CID
Manu Sporny: you want to type in CID, where do you want it to link?
Joe AndrieuAndrieu: the term
Manu Sporny: we need to export the shortened version
Joe AndrieuAndrieu: I think we're on the same page
Brent Zundel: Agreed, Class II change
w3c/cid#169
Brent Zundel: look at 169 to ensure Class IV is appropriate
… opened three weeks ago, would require an addition to the IANA registration for CID
Manu Sporny: I believe so, but forget what we registered. Suggestion is that we don't do this because multiple different profiles lead to non-interoperable implementations
… want to be specific about profiles, think we need the activity pub use case
… better thing would be for community to argue for changes into CID spec, need more info from them. Don't think profile leads to good interop
Patrick St-Louis: just curious about idea that profiles hurt interop
… think profile can give clear pictures of what someone can align to, profiles being prescriptive about specification you want to implement. Don't see why they hurt, don't think they are ultimate solution
… I feel sometimes, some specs more than others there is a lot of optionality, optionality is good, but it can also spend a lot of time. Profile can give a path to a more direct implementation, not sure I totally agree that profiles are bad based on my limited experience
Manu Sporny: profiles are somewhat okay when what you explained ends up happening, but that is not always what happens. With CID spec, you can choose to punt JSON-LD to curb and add lots of features and make that your profile, then you have features that are a superset - you can just add whatever you want to
… typically that is not super great if it is not clear, yes you can do that, but inevitably it will make it so that your community is the only one that can implement
… adding profile allows you to do whatever you want, and sometimes people do things that completely break interop without any discussion with broader community, which is where interop failure comes in
Patrick St-Louis: agree 100%, do not think profiles should extend capabilities, see them as extension of selected
… for me, this doesn't add anything, but agree if profiles want to use on own features that expand spec, can see why this would be dangerous path
Manu Sporny: +1 to that
… complete side note on spec, I'm one of the editors, have very little time to work on spec and it is lower priority, if there are other editors who would like to help out that would be great
Brent Zundel: 17 open issues in CID spec, 10 labeled Class II so we can address them.
… work to be done on this spec, need people to jump in
… look forward to meeting next week, then in Brusels