Verifiable Credentials Working Group Telco — Minutes

Date: 2022-08-17

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Kristina Yasuda, David Chadwick, Manu Sporny, Ted Thibodeau Jr., Orie Steele, Marty Reed, Dave Longley, Michael Jones, Michael Prorock, Joe Andrieu, Mary Dwyer, Logan Porter, Oliver Terbu, Gabe Cohen, Antony Nadalin, Dmitri Zagidulin, Steve Cole, Kaliya Young, Kevin Dean, Samuel Smith, David Waite, Kerri Lemoie

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): David Chadwick, Manu Sporny

Content:

Manu Sporny: DavidC: Are we going to discuss 3 issue, or is there an order?.

David Chadwick: Manu asked if people are working on PoCs please add a slide describing this.

David Chadwick: Manu will add the URL of the slide deck to the mailing list.

1. TPAC.

Brent Zundel: See agenda draft.

Brent Zundel: There is a yellow box in the above doc for people to add topics to it to be discussed at TPAC.
… second tab is for people to say if they are attending in person or virtually.
… also indicate if you want to attend the dinner.
… VC DM scheduled for thurs and friday.
… Wednesday joint meeting for web of things and VCs.
… may be other joint meetings as well.

2. Issue Discussion.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc.

2.1. Implementation Issues and under specification (issue vc-data-model#709)

See github issue vc-data-model#709.

Antony Nadalin: we do not know what type of info is at this URI.

Orie Steele: what is the relationship between the issuer attribute and a DID document. Orie says they should be the same.
… we should cover all cases.

Dave Longley: +1 to Orie to showing examples with DID dereferencing.

Manu Sporny: DavidC: What about a .well-known URL?.

Dmitri Zagidulin: what about putting issuer related fields directly into the issuer object?.
… in JFF we want to store things like name and logo of the issuer.

Antony Nadalin: would like some more time to think about this issue.

Oliver Terbu: https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/.

Antony Nadalin: not sure that discussion so far will help implementors determine what they are likely to get back.

2.2. Schema for VPs (issue vc-data-model#839)

See github issue vc-data-model#839.

David Chadwick: in OIDC, when we stick something into VP, it will have new type into type field – it would be nice if this data model could give some guidance on how different types of VPs are formed and how recipient will know if VP is well formed..

David Chadwick: Are we going to have a presentation schema? That’s the broad issue..

Kristina Yasuda: don’t think we made that decision in Connect WG, David…

David Chadwick: We have schemas for VCs, so looking at schema you can see what they contain… but we don’t have one for VPs. We have talked 19:22:55 <manu> q+.

Brent Zundel: is anyone opposed to having a vp schema.

Manu Sporny: not opposed, but it would be very simple for now.
… however it will be related to protocols as they determine what fields should be there e.g. audience.

Kristina Yasuda: +1 to maybe we do not need a schema.

Dmitri Zagidulin: not opposed but maybe we don’t need a schema if all the fields are optional.

Michael Jones: not opposed but it is work. Takes work to keep schemas in sync.

Orie Steele: context files are not schemas..

Michael Jones: is the effort worth the benefit?.

Orie Steele: very different security considerations.

Michael Prorock: can we leave this until we have more context and examples. Feels like a lot of maintenance work to start now.

Oliver Terbu: the schema is needed for syntactic interoperability. Can we reuse credentialSchema for VPs?.
… whilst number of properties is small now, implementors may add lots of new ones.

Kevin Dean: if we are going to verify a VP then processing schema seems to be fundamental to me.

Orie Steele: See also input validation, as it related to “schemas”… https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html.

Samuel Smith: in ACDC we use compose schema and disclose schema so that once verifier signs it is committed to the rules then the ACDC can be disclosed.

David Waite: if we have normative text describing properties plus a schema then one has to trump the other if they conflict.

Orie Steele: +1 david… normative text trumps… ideally schema implements normative stuff only..

Dave Longley: +1 to David.

Manu Sporny: +1 to dwaite.

David Waite: since we dont want to mandate people to use schemas then they should be informative.

Michael Jones: JSON schema is not used in TLS. Prose are sufficient for interoperable implementations.

Michael Prorock: +1 selfissued - the normative text tells you what to do (hopefully with nice examples and test vectors and other fun bits).

Gabe Cohen: their is value in schemas.

Manu Sporny: there is spec text already so a schema would be simple and not necessary (for now).
… someone who is interested can create a PR with the schema and keep it up to date.

David Chadwick: Yes, trying to write down what Oliver said, got a bit lost when he was talking about subtypes and subschemas..
… As we have with credentials, there can be multiple types of credentials that have the same schema, there was some confusion in DIF – 1-to-1 mapping between schemas and types. Types come into this because we should be creating different types of verifiable presentation when they have different content… but if properties remain the same, type could still change. Schema defining a particular property, but type alters value of particular property, for example..

Manu Sporny: we are still not clear if we are talking about a new VPschema or existing credentialSchema.
… we have conformance tests currently for VPs.
… if the wallet creates a VP with its own properties and adds the schema, but has a bug in this, then the wallet has not followed its own rules.

Brent Zundel: concludes that there is no opposition to this, but not necessarily anyone wanting to do all the work!.

2.3. Include a regex for XML Date Time in the next version of the standard. (issue vc-data-model#846)

See github issue vc-data-model#846.

Orie Steele: found flaws in the v1.0 description of date/times.
… this was fixed in v1.1 DM.
… but need to be clear about which string format is being used.
… so prefer a regex value.

Manu Sporny: we can add this to v2 DM.

Dmitri Zagidulin: +1 to including the RegEx in the spec :) (having had to come up with that same regex for a library…).

Manu Sporny: alternatively we could define an XML schema for date/time and a regex to check if it is correct.

Dmitri Zagidulin: having already implemented this, we will save a lot of time if we add Regex expression to the DMv2.

Gabe Cohen: +1. implementing xsd:dateTime was incredibly painful.

Michael Jones: I added regex to OAuth2 and implementors have found it useful.

Manu Sporny: +1 selfissued, I think that would be fine..

Michael Jones: so I support adding it.

Brent Zundel: we need a volunteer to produce a PR for this? Orie? Dmitry?.

Dmitri Zagidulin: said he would produce the first draft.

2.4. Can a credentialSubject be only a string value? (issue vc-data-model#762)

See github issue vc-data-model#762.

Brent Zundel: credential subject is currently an object or array of objects. Can it be a simple string?.

Manu Sporny: what is the use case for having a subject as a URL.

Oliver Terbu: +1 manu.

David Chadwick: At an earlier time, we discussed this being an email address, possibly… verifier could send PIN code, wallet user could return PIN code, that’s proof of possession… there were alternatives, telephone number, sent secret to phone number..
… It doesn’t have to be a DID..

Manu Sporny: we can allow alternative PoP schemes today through the id in the subject object..
… so do not see any value in altering the text today.

Kerrie Lemoie: prefer to keep it as an object.

Orie Steele: credentialSubject and Issuer and Holder should be aligned. Currently they are not.
… subject can be an array but the others cannot be.

Manu Sporny: hrm, disagree, because each field has a slightly different purpose.

David Waite: agree with Orie that we should make these objects more consistent.

Manu Sporny: like, having an issuer that is a DID is totally fine… whereas doing the same for credentialSubject is problematic..