Verifiable Credentials WG Telco — Minutes

Date: 2022-02-09

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Shigeya Suzuki, joe, David Chadwick, Justin Richer, Kristina Yasuda, Brent Zundel, Manu Sporny, Charles Lehner, Michael Jones, Mahmoud Alkhraishi, Patrick Mandic, Michael Prorock, Ted Thibodeau Jr., Dave Longley, Joe Andrieu

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): David Chadwick, Manu Sporny

Content:

David Chadwick: agenda review.

Ivan Herman: brent, Do we want to add TPAC meeting to the agenda?

Brent Zundel: Yes we do.

1. Introductions and Reintroductions.

David Chadwick: Mahmoud Alkraishi.

David Chadwick: Patrick Mandic.

2. TPAC 2022.

Michael Jones: Get more done in person than virtual. No substitute for it.

Brent Zundel: +1 Mike.

Manu Sporny: If we plan to meet in person in the Fall, it is a long way off and difficult to predict.
… We should not do a hybrid. Either a virtual 4 day, or a one day in person.

Kristina Yasuda: regardless of a time per day, time difference-wise, someone is always disadvantaged…

Kristina Yasuda: +1 justin.

Ted Thibodeau Jr.: Things move faster in person. For myself I might have a limited travel budget so remote attendance is always welcome.

Ivan Herman: Face to face would be in Vancouver. W3C travel team has not yet decided whether remote or not.
… travel team needs to get the feelings of the membership..

Justin Richer: ^– this makes sense for us to follow what TPAC does.

Brent Zundel: we will do a poll of this group.

3. v1.1 feedback.

Brent Zundel: https://github.com/w3c/vc-data-model/labels/V1.1%20feedback.

Brent Zundel: we have addressed the feedback to the best of our ability so far.

Manu Sporny: google are asking us to state that data is expected at the end of these URIs..
… kyle has added this to the feedback.

See github pull request vc-data-model#866.

Brent Zundel: this PR addresses all that we can do non-normatively.

Ivan Herman: we will need a WG resolution to say we will go to final rec at some point in time.
… we need one paragraph to answer google’s concern.
… we need to make sure that no further changes are in the final doc to be published (including the proposed editorials).

Brent Zundel: we will have a further resolution to include the editorials after the final version is published.

Ivan Herman: putting editorials in the final version that address the comments of google (and others) is fine. It is other editorials that should be excluded.

Manu Sporny: respec was updated to do linting on the specification and call out for definitions that are not referred to. So when you reference these 13 terms that are defined in the spec, they should be referenced using the specification.
… one option is to leave things as the are.
… the other option is to remove these 13 definitions.

Brent Zundel: +1 to just publishing, raise an issue to track cleanup, imo..

Ivan Herman: I advise we do not make any further changes..
… in version 2 we are free to do whatever we want, but not in v1.1.

Michael Prorock: +1 ivan.

4. test suite feedback.

4.1. [Tracking Issue - Proposed Corrections Feedback] Test suite improvements are needed (issue vc-test-suite#126)

See github issue vc-test-suite#126.

Charles Lehner: Tallted has commented on this.

Charles Lehner: See Ted’s comments.

See github pull request vc-test-suite#123.

Charles Lehner: when a test has not been evaluated or when feature did not previously exist, I still need to respond to TallTed.

See github pull request vc-test-suite#127.

Brent Zundel: is there anyone on the call that can review these?.

Manu Sporny: you can add me.
… we did not copy 1.0 test suite to a new one. Instead we should add tests to the 1.0 test suite.
… this will not require testers to re-run all their previous tests.
… there will be a proposal to change the way we run tests for v2.0.

5. VCWG Draft Charter.

Ivan Herman: See new charter’s draft.

5.1. ISO Liaison.

Manu Sporny: https://github.com/w3c/vc-wg-charter/pull/66#issuecomment-1033855656.

Manu Sporny: Tony Nadalin noted that ISO is doing work on vc data model in 23220.
… we need to have our WG experts involved in this if this is true.

Michael Prorock: +1 manu.

David Chadwick: There are two people from this group, Kristina and myself, attend the ISO meetings. You already have representation there. I’m not aware of data model work instead of using it… I don’t know if there have any proposals that change the data model. Yes, I’ve seen an appendix that uses the VC Data Model to formulate mDocs, but I’m not aware of any changes at the moment..

Kristina Yasuda: Yes, VC Data Model mapping is in an annex, it’s an example how MSO can be mapped into VC..
… Nothing new is being defined..
… confirmed what DavidC said.

Michael Prorock: Can we have some clarifications – if there is some work in ISO referencing VCs, then the WG should 1) be able to review that material to make sure it’s conformant with current spec and v2.0, and 2) this is part of the reason behind PR 66 – can we have clarification – is there anything touching on how to exchange credentials? We might need to non-normatively discuss that..
… is there work on protocols to transfer VCs?.

Kristina Yasuda: Because there is already a liaison, members of this WG can start joining ISO calls any time, and I think you should have access to the documents as well. I don’t think there is any action needed, maybe we need to reach out to ISO secretariat. When we say ISO Liaison, is that W3C -> ISO, or this WG -> ISO..

Ivan Herman: there are too many ISO groups so we have many liaison officers instead of one for the whole of ISO.
… so liaisons are very specific.

Ivan Herman: See list of ISO liaisons at W3C.

Michael Prorock: @manu - is a liason role something you would consider?.

Kristina Yasuda: there should be a liaison between VCWG and WG4.
… part 1 is the interfaces, part 2 is only data model, part 3 … is part 5 is holder authentication.

Michael Prorock: @Kristina - thanks - that is helpful - so transport is defined separate, but may handle transfer of VCs?.

Kristina Yasuda: data objects are in cbor and it is that that is being transferred.

Ted Thibodeau Jr.: joint project between DIF and VCWG requires everyone to enrol in DIF, so it is not a proper joint project.
… so is there something similar for ISO.

Michael Prorock: Ted - thanks for bringing that to my knowledge - which CCG work item is that?.

Ted Thibodeau Jr.: DIF project is “Secure Storage” a/k/a “Identity Hub” at https://lists.identity.foundation/g/sds-wg/wiki/Home and https://github.com/decentralized-identity/identity-hub/.

Manu Sporny: if VC data model is being used then this group needs to be able to see how this is happening.
… because ISO is relatively closed how do we get access to get feedback.

Kristina Yasuda: It’s NOT closed-door.

Kristina Yasuda: establish liaison and you get access to meetings and material.

Manu Sporny: only have one or two reps is not broad enough for all the group is too narrow.

Kristina Yasuda: closed door is not correct.

Michael Prorock: Thanks @TallTed.

Kristina Yasuda: this group defines VC data model we should not need to supervise its use in all other groups.
… if the data model is well specified everyone should be able to use it without our group being present.

Manu Sporny: +1 to getting access for everyone in the group vs. a few of us… just need it for transparency..

Kristina Yasuda: FHIR did the same as ISO - they have their own data model, and after that, they mapped it to a VC..

Manu Sporny: Kristina, yes, and they did it in a way that was not interoperable <– this is the problem..

Kristina Yasuda: if they cannot map it correctly to a vc-data-model by reading the spec, we need to go back to the spec and add improvements, instead of going to every single group and educating them.

Kristina Yasuda: that is not scalable.

Ivan Herman: See ISO Liaisons currently.

Ivan Herman: formally I am already the liaison for some groups, and the formal liaison persons are W3C staff.
… i.e., the formal liaison for these groups for VC would probably me if choose to set up such a liaison.
… I already receive notification of all documents in my other liaisons. So if I see they are relevant then I can forward them to this group.
… the problem is that I get overloaded with too many ISO documents so filtering is very time consuming.

Michael Jones: the fact that other groups are using vc data model is a victory so we should concentrate on PRs.

5.2. Normative specification of APIs or protocols is out of scope (pr vc-wg-charter#70)

See github pull request vc-wg-charter#70.

Justin Richer: I agree with the text as written.

Justin Richer: it does not mean that discussion of protocols and APIs are out of scope, we can talk about whatever we want to.
… it just means that we wont standardise any of them.

Manu Sporny: +1 to what justin is saying.

Ivan Herman: +1 to justin.

Brent Zundel: Justin’s reading matches my interpretation.

Michael Prorock: +1 justin.

Manu Sporny: +1 to @justin_r and this PR text should be included.

Dave Longley: +1 to pulling in this PR and that doing so does not mean that we will not discuss protocols/apis in the group.

Brent Zundel: any objections to pulling in this PR?.
… I hear no objections so I will merge the PR.

5.3. Clarify some non-normative deliverables, as well as explicit not in scope items (pr vc-wg-charter#66)

See github pull request vc-wg-charter#66.

Brent Zundel: this PR adds a similar line to the scope section.
… do we have consensus on this PR today?.

Michael Prorock: this is a minor conflict on the PR now due to a previous merge.

Brent Zundel: addressing things non-normatively in a note does not raise IPR issues.
… scope of non-normative notes is limited by the scope of our charter and time and effort of our group.
… the note itself does not need to reflect the consensus of the group, but is something that someone needs to say.

Justin Richer: there are other protocols coming down the line e.g. gnap, that mesh with VCs by design. So we must not have language in the charter that stops these being discussed.
… we must not stop the WG from doing work that it sees is valuable to the community.
… whether this results in a note in V2.0 or in a document elsewhere is a moot point.
… there was vast knowledge that went into OIDC and JWTs due to discussions in the respective groups even if neither group published this.
… in contradiction to their charters.

Mahmoud Alkhraishi: +1.

Michael Jones: +1 to Justin’s points.

Manu Sporny: we do not want to cut off the ability to cut of discussions of new things that might come up.
… we should talk about things we know people want to work on and leave the door open for discussions about relevant topics.

Ivan Herman: I slightly disagree with manu. The list of topics is huge.
… protocols are out of scope of standardisation but the list of other topics is too huge that we could get pushback when trying to get this charter accepted.
… the work that people would like to do does not have to be listed in the charter.

Manu Sporny: I submit the Web Apps charter as a counter-example to Ivan’s concerns: https://www.w3.org/2019/05/webapps-charter.html.

Michael Prorock: @ivan - we are requesting the explicit ability to discuss certain items in a non normative fashion in the context of a developer guide - and I am more than willing to volunteer to do the work for that dev guide.

Ted Thibodeau Jr.: the reason for a 3 year period is due to a shorter period leading to rushed recommendations with sub-par results.
… 18 months work requires a 2 year charter.

Michael Prorock: +1 TallTed.

Manu Sporny: +1 TallTed.

Justin Richer: +1 to TallTed – this is the weaponizing that I’ve talked about all call.

Ted Thibodeau Jr.: we know these topics are going to come up so we need the ability to write about. This is why they should be in scope.

Michael Prorock: i will hard object to not explicitly including these items.

Mahmoud Alkhraishi: +1 to everything ted just said.

Ted Thibodeau Jr.: because we have had pushback in the past for topics which other said were out of scope.

Manu Sporny: it is not unusual for W3C to approve charters with a long list of items.

Ivan Herman: I can concede on this point.