VC WG Telco — Minutes

Date: 2021-08-18

See also the Agenda and the IRC Log

Attendees

Present: Manu Sporny, Brent Zundel, Wayne Chang, Kyle Den Hartog, Dave Longley, Justin Richer, David Chadwick, Orie Steele

Regrets:

Guests: Michael Shea

Chair: Brent Zundel

Scribe(s): Wayne Chang

Content:


1. Agenda Review

Brent Zundel: Talk briefly about TPAC meeting, then bulk of discussion is on next WG charter.
… after that, review open PRs, triage issues into v1.1 or v1.2. As time permits, review the issues for v1.1 and v1.2 to check status.
… finish up with next steps inc. next meeting/action items
… questions?

2. Introductions

Michael Shea: I am an observer, not formal member. I’m part of the community working with folks including Markus, just here for my own interest and what’s upcoming in terms of revisions to the VC data model

3. VCWG at TPAC

Brent Zundel: TPAC happening this fall. The plenary meetings & breakouts happen during a week, then another week for WG meetings.

Brent Zundel: https://www.w3.org/wiki/TPAC/2021/GroupMeetings

Brent Zundel: I have tentatively scheduled meetings for the VC WG. If you follow the link, you’ll find them.
… plus the proposed dates and times.
… Do folks feel we will have a need to meet during TPAC to finalize the charter and things of that nature?
… timelinewise, we’ll need to have already in progress v1.1 and v1.2, so there won’t be discussion around those. Please queue to give pros and cons.

Manu Sporny: Doesn’t hurt to schedule something and cancel if we find there’s no purpose to meet.

Brent Zundel: +1
… TPAC is indeed fully remote this year.
… As we get closer to that date, we’ll determine if it makes sense or not. Anything else on TPAC?

4. Next VCWG Charter

Brent Zundel: I made some changes to the charter and those changes were not representative last time we chatted–need to make sure they get merged prior to review.
… I produced a draft for the group to review, rough draft that may need adjustments. I will render it on my own computer and share my screen.
… (begins screen sharing of rendered draft)
… This is the proposed charter, did my best to not make too many assumptions
… right at the beginning, didn’t include wayne as a chair yet, because there was no discussion with wayne yet about that role.
… the scope as indicated in the charter, data models for VCs, registries, proof types for VCs, data models for exchange of presentations
… web-based wallets for storage and sharing of VCs, APIs for the issuance and verification of VCs
… I put everything that we could possibly want to talk about so we could discuss

Manu Sporny: This looks like a great roadmap, but we need to focus everyone’s energy to get specific things done. We have a limited set of people and would like to try to focus. Scope too broad right now to pass without objections, likely.
… if we had to pick, the first 3 bullet items and that’s it. Rechartering to cover the others.

David Chadwick: Slightly different view, first two and fourth, but not the third. The third may be better suited for a subgroup with cryptographic experts.
… depends on what you mean by proof types. If you mean defining the cryptography, is probably another group. If you’re talking about encoding up the group, that could potentially work.

Dave Longley: it’s really proof data modeling, no new crypto methods

Brent Zundel: It’s about the data model for the proof type, not cryptographic signature specifications.
… We can say that specification of cryptographic signature schemes is out of scopes.

Orie Steele: I would see that as the data model for how EdDSA with Ed25519 is encoded as a JWT or LD Proof… not implementation of EdDSA…

Orie Steele: how to use attached and detached JWS with VCs… for example.

David Chadwick: more comfortable with that clarification

Brent Zundel: open to further clarifying in the text

Manu Sporny: Agree with brent, we’re not doing cryptographic signature schemes. We don’t have the expertise to do that here, but we can talk about expression of using cryptographic signature schemes.
… +1 to specification of cryptographic sig schemes out of scope
… we sent an invitation to the IETF security directive to jointly develop, waiting to hear back
… but all we’re doing with the proof type stuff is how a scheme is used, not specifying new cryptographic signature schemes

Dave Longley: maybe schemes should say “primitives”

Dave Longley: what’s out of scope should be “new crypto primitives” (we are not inventing new math)

Kyle Den Hartog: I’m concerned about leaving proofs off again, given the nature of how much trouble they’ve caused us dealing with these things. The data model is def in scope and I like that, but not going further is potentially worrisome to interop
… it’s caused issues for our implementations, but I understand not having the expertise in place is even more worrisome.

Orie Steele: Agree with kyle, data model for proofs must be in scope, but design of cryptographic proofs / primitives should be out of scope.

Kyle Den Hartog: consider the value of being able to depend on linked data integrity, if it’s not there then it’s a lot more difficult

Manu Sporny: In the semantic web group, we said let’s take linked data proofs, linked data integrity, RDF canonicalization, put it into the semantic web group.
… people looked at RDF canonicalization and said they knew they needed to do the work for 20 years, let’s do the work. When it came to the LD integrity stuff, two people (Peter Schnieder, Dan Brickley) said the scope was broad. There was pushback.
… Counter-proposed what if you worked on the data models for expressing these things, making it specifically focused on VCs, within the VC WG?
… people working on LD signatures/integrity, purely packaging, not signature suites, would be working on this within VC WG in tandem with IETF
… they suggested “you’re just packaging up crypto, don’t need deep security diligence”
… we’re getting positive feedback, but no certainty yet on this
… so we wish to define Linked Data Integrity, security packaging

Kyle Den Hartog: I think you just clarified that the suites would fall under packaging, thanks.

Dave Longley: We shouldn’t use the word ‘scheme’ when saying it falls out of scope because it’s loosely defined. We’re not inventing cryptographic primitives, but may combine primitives for use. What we don’t want to do is to invent the next new math for e.g. quantum crypto

Brent Zundel: Sounds like folks agree that the last 2 items should be removed from the scope. Do folks want to make it out of scope or not mention?

Manu Sporny: Probably not mention, perhaps signal that we may write notes about them.

David Chadwick: perhaps implementation guidelines?

Brent Zundel: I can add the word ‘guidance’

Manu Sporny: Typically what W3C members who aren’t deeply involved but want to ensure there are boundaries, they tend to look at scope and object on that basis.
… putting it in the scope could be a dangerous thing, but a note is okay. We have to think about whether or not we’ll really put in the effort to do this.
… it could be argued that the group may be starting to get into protocols, expanding into cryptographic protocols + application protocols at the same time, which is biting off a lot, considering the maturity of other ecosystem items
… if these charters are not very very tight, this is grounds for objection

David Chadwick: in terms of registries, can we just say registries for the data model instead of ‘extensions’?
… we added vc and vp into the IANA registry as claim types
… so they’re not extensions, they’re part of the data model

Justin Richer: wanted to agree with manu on scope–it’s very important that people joining the group know what the group is supposed to be doing and what the intent of the group is
… care should be taken that this doesn’t become a catch-all space for anything in the space

Orie Steele: +1 justin_r

Justin Richer: chartering and recharting is an onerous process in the W3C compared to some other groups, but this group should absolutely be careful not to boil the entire ocean at once

Brent Zundel: my suggestion is that I remove the last two bullets and may make mention of them as possible notes in the non-normative deliverables section
… also propose remove bullet 3, it could be understood as being part of bullet 1
… this may limit the scope to within acceptability

Manu Sporny: this runs the risk of not allowing us to do to the work due to bad communication.
… however, it is listed in the normative spec that we are doing this work…

Brent Zundel: not saying getting rid of proof types for VCs, saying get rid of #4 which is getting rid of data models for exchange & presentation

Manu Sporny: oh okay

Orie Steele: queued to complain about a similar thing–the proof type piece is important because while we’re not building crypto primitives, we need to talk about how those things are expressed.
… in the existing VC data model, we got asymmetric public key reasonably well-defined, nothing else well-defined
… it probably comes with lack of definition about proof types and their expression, so we want to get deeper on what that looks like for interop
… e.g., if we want to talk about data models that allow proofs w/aggregation, how does that look? we need to be able to clearly talk about the differences in expression

Brent Zundel: i meant bullet 4, not bullet 3. thanks

Dave Longley: +1 to Orie, we need to be talking about that. however, bullet point 4 could be merged into the first one if we changed the first one to say data models for VCs and VPs

Brent Zundel: agreed

Kyle Den Hartog: seeing where people fall on this–what do you think about the scoping discussion around letting the subject prove they are who they say they are, such as through image verification?
… we never extended into this direction, but could that be in scope?

Orie Steele: from perspective of data model described identifiers to prove things, i think you’re talking about a set of identifiers and contexts to prove that stuff

Brent Zundel: +1 to Orie

Orie Steele: e.g., holder binding in the specification, is that relevant? i think it’s already included and we’d be able to discuss that in the same section

Manu Sporny: it’s inevitable that these discussions will happen, and probably a healthy discussion. this is where we need to be deliberate about the type of work we take on, and remember that w3c for a very long time allowed you to do R&D in a working group, and as a community we’ve moved away from that
… to do a charter, they expect incubated specs containing major features as input documents

Justin Richer: isn’t the existing spec the input document?

Orie Steele: I might consider not including the “subject holder” section… in the main spec, though, and push it to a note / or implementation guide… since its already non normative.

Brent Zundel: +1 manu and Justin

Manu Sporny: if we were very diligent about this, we’d have no input document or mention within the charter. so we should practice some restraint w/the scope in what we open up, be ready for people to say “you’re suggesting something completely new, and we shouldn’t be working on that”
… i’m probably coming across stronger than intended, but we should be specific, bring input documents, and not be surprised if people object to doing large R&D in the wg

Kyle Den Hartog: i think that’s reasonable to take such an approach, especially if we’re defining extensions to make this possible. but where do we draw the line? can we say we’re thinking about this type of thing, and as the wg is going
… i do like the deliberately intentionality in defining the scope

Manu Sporny: justin_r, yes, the existing spec is the input document, but the existing spec doesn’t talk about PURPLE_CREDENTIALS which are a totally new concept that isn’t covered at all in the existing spec.

Brent Zundel: great, i got what i need to make adjustments. let’s go over the deliverables
… we are starting to feel pressure and excitement from W3C

4.1. Deliverables

Brent Zundel: I wrote down two things, Verifiable Credentials 2.0. The links and status are probably correct, but the second is a rough draft. Suggestions?

Dave Longley: i think “Linked Data Integrity” was better

Dave Longley: +1

Kyle Den Hartog: +1 for “Linked Data Integrity”

Manu Sporny: I think instead of Linked Data Signatures, Linked Data Integrity is better.
… in the description, we say this specification defines proof signatures and other mechanisms for expressing integrity over linked data. This group is only considering its use for Verifiable Credentials.
… this is to avoid a grounded objection
… we will have to take the JWT stuff into its own spec, or further specify how we express JWT-based VCs due to the multiple approaches
… there are several approaches emerging for this expression

Orie Steele: +1 to the Linked Data Integrity title. Avoid the word signature, use the word proof instead. We’re talking about proof types that are built on top of linked data integrity among other things.
… the other piece of this, regarding JWTs, not sure if anything in this particular section….we have to do a better job of not creating layer violation between data models and assertion formats
… i’d like to see some top-level attempt to move the expression of assertion formats….we need to do a better job
… i don’t think the JWT encoding or linked data encoding of those representations necessarily deserves their own specification individually, but not sure that they belong in these sections
… just wanted to note that the linked data encoding and JWT encoding both rely on these types of expressions. perhaps it could be argued that the JWT encoding does not in any way depend on this linked data encoding, and if that’s the case, the JWT encoding may warrant its own section here

Dave Longley: maybe this subtitle?: “This specification defines how to express proofs of integrity for bounded Linked Data documents such as Verifiable Credentials”

Manu Sporny: I like that ^^^ (dlongley’s suggestion)

Manu Sporny: I do agree that let’s split them apart so they’re not coupled, so we should be very aware of this when putting the output there.
… we should make this testable. you need a crypto signature expression like ed25519 to make it testable
… we should specify at least one thing to make it testable.
… maybe…this is where we start dipping our toes in the notes, such as for BBS+
… “we want to show you we can do some interesting things with these expressions, including next generation selection disclosure”

Orie Steele: One approach would be: “VC Data Model”, “Linked Data Integrity”, “Linked Data Proof”, “JWT Proof”

Orie Steele: +1 David

Dave Longley: +1 to David

Manu Sporny: agree with DavidC

Brent Zundel: +1

Dave Longley: very important that there’s a clean separation with the proofs and the VC and how powerful that is.

David Chadwick: in the prev wg, we did express about credentials and verifiable credentials, the fact that you get a credential and turn it into a verifiable credential by adding a proof either by LD or JWT. however, we didn’t fully document the fact that when you put the proof on they’re different, but when you take it off it’s the same thing. we should make this apparent
… credentials are the same. VCs can be different depending on format. if we take this approach, we don’t need a separate document
… perhaps coupled with the new document proposed on linked data, you could refer to that and demonstrate how you can use what’s specified to create the proofs

Orie Steele: huuuuuuge +1 david :)

Dave Longley: yes, huge +1, that was a major reason for the whole thing that we failed to emphasize.

Brent Zundel: time check
… Last thing we wanted to make sure to talk about, was a list of other deliverables

4.2. Other Deliverables

Brent Zundel: I didn’t touch the other deliverables section at all, this is from the previous charter. What do people want to see?
… a note on BBS+

Manu Sporny: a test suite for concrete implementation such as with ed25519 at minimum

Brent Zundel: test suite for JWTs was mentioned

Kyle Den Hartog: i’m okay leaving that as a note, but would like to see it elevated to test suite contingent on IETF review

Brent Zundel: i’ve been contacted by folks requesting BBS+ being an official note
… what else?

Manu Sporny: perhaps specify use cases and requirements document contains this

Brent Zundel: probably within our purview to update existing notes

Manu Sporny: at the top of the call, we said we might take notes on exchange/presentation

Brent Zundel: we should see how other feel are acceptable, including poking at protocol a bit

Orie Steele: not sure if it’s a good idea, but with presentations, the problem with them is that they assume this domain and challenge attributes that came from somewhere else, and we never defined these formats. it may be valuable to define the data model for request format of presentation. but anything protocol-related should be out of scope
… defining a data model for the thing you use to construct a presentation may be helpful, due to the instance of domain and challenge in the spec example come out of nowhere, whereas it would help to provide origin/history for these
… we’re dancing around the reality that authentication has multiple steps. the data structures we’re defining here in data models can be used to assemble protocols, but we shouldn’t be defining protocols, just data models
… aside from domain and challenge, for the pieces of the data models shared by all assertions formats, are there queries related to all those data models such as framing and other things?

Manu Sporny: +1 to Orie

Dave Longley: +1

Orie Steele: we should find common grounds and enforce them, and if we can find a query that applies to all representations, we should spend time on that

Brent Zundel: the text on my screen is the text in the actual HTML file. what isn’t working right now is the link to github.io…i will reach out to ivan for that resolution. please open PRs and issues to anything that you may want to change
… i have notes for what changes to make for the scope, changes to deliverables, changes to other deliverables. will try to push them in this week

Manu Sporny: https://github.com/w3c/vc-wg-charter/

Brent Zundel: last thing, when are we meeting again?
… are folks available this time next week?

Kyle Den Hartog: Charter is viewable at this link: https://w3c.github.io/vc-wg-charter/?cachebuster

David Chadwick: this conflicts with OIDC presentation

Brent Zundel: one hour prior?

Kyle Den Hartog: we can try!

Brent Zundel: okay, we’ll send out an agenda for weds 25th, 1 hour prior to meeting today
… thanks

Kyle Den Hartog: the query parameter forces github to not rely upon the cache

Orie Steele: thanks all!

Wayne Chang: o/