Meeting minutes
<DavidC> Does anyone have the Zoom link please for this meeting
<DavidC> thanks. I never got a TPAC message even though I registered for remote participation
<manu_> Here's the Zoom link: https://
<DavidC> manu_ thanks for the link. I have now registered at the W3C site but not got the Zoom link for the meeting yet
<mandyv> https://
<DavidC> thankyou manu_
wes-smith: I'm Wes Smith, presenting with Mandy from Digital Bazaar.
<Isaac> https://
wes-smith: let's do a round of introductions
<GregB> Greg Bernstein: Invited expert, co-author cryptosuite specifications, author of test vectors, also working on BBS at IETF.
<rigo> presentation Rigo Wenning: W3C Legal counsel, contact person in Brussels, also doing research and development in the area of Digital Product passports
bigbluehat: Benjamin Young, Digital Bazaar, Inc.
<JennieM> Jennie Meier, Digital Contract Design
<RYKay> Hello all, Kay - Infocomm Media Development Authority of Singapore, Observing
<ericaconnell> Erica Connell with Legendary Requirements
wes-smith: thanks for the intros!
… please remember to be nice and follow the code of conduct.
… we're discussing what might go into the next VCWG charter
… there's a good deal of things being explored currently
… we have 3 main categories: features, protocols, and applications of VCs
… in features, we're looking at renderMethod and others
… in protocols, we'll look at VC API and others
<DavidC> we have lost the voice
wes-smith: and...we're back. over to you, Mandy
Mandy: the screen is delayed for those here in the room--apoloies
… First up, renderMethod
… this allows issuers to provide displays of the credentials
… the community is experimenting with SVG, PDF, and others
… Singapore is exploring OpenAttestation
… there is an SVG render method implementation in the VC Playground
… here's an example of a driver's license
… it can also be seen on the VC Playground
<wes-smith> Network issues, sorry folks, the Zoom setup in the room keeps dropping
<SinYong> OpenAttestation is in production since 2018
SVG render method code of the Utopia DL: https://
Mandy: next is confidenceMethod
… this will help in confirming that the holder is the holder
… this can use hardware keys and unlink-able signatures
… here's another example
… it supports multiple methods
… back to wes-smith
wes-smith: the timeline for delivery of these range
… there are current implementations, but the specs are mostly in progress
… Unlinkable ECDSA is up next
… traditional ECDSA is strongly linkable
… but ECDSA is FIPS compliant, so the hope is to stick with ECDSA for it's various values--like that one--but add unlinkability
… Next up is protocols
… The VC API is an HTTP API for performing lifecycle management
… issuance, verification etc.
… it's most useful when you have several vendors, but wants a single interface to those various vendors
… so it can support DIDCom, OID4, and others
… VC API is already in production with TruAge, CA DMV, and others
… and in the W3C test suites
Mandy: Next, we have Wireless VC sharing over Bluetooth and NFC
… we're currently targeting First Responder scenarios, but it could also be used at border crossing and even retail for age verification and the like
… there is a demo of this available...but the room is broken
… sorry for the trouble folks on Zoom...
… there is a video of VCs over NFCs
… one phone has the wallet, the other has the verifier
… you tap the two phones together and the verifier phone shows successful confirmation/verification
wes-smith: VC Barcodes
… these are about physical credentials built from VCs
… we encode VCs into barcode and a new cryptosuite
… it includes data for the barcode and the visually readable content from the physical card
… so on a driver's license, we sign the PDF417 MRZ and sign the human readable info as well
… there are multiple implementations in progress
… if you're interested, we'd love to have your help exploring this work
… we're exploring it with the CA DMV and others
… here's the Utopia DL again showing the added VC barcode as a PDF417
… and below that is the Utopia Employment Authorization using a QR code
… Next, we have the Citizenship Vocabulary
… this vocab provides terms for governments related to citizenship status
… Another vocab is related to Driver's Licenses. This one is already in use in the CA DMV
… Lastly is one for Vehicle Titles...with a deployment in progress for CA DMV
… in summary, we're hopeful these will be included into the next VC recharter
… in the meantime, we'd love to help what other things may be of interest to the room for inclusion in a future recharter
DavidC: is it better to say how the VC be displayed via protocol? or in the VC itself?
… the OID4VCI group is putting it into the protocol vs. in the VC itself
… we also have a delayed term for ??? which we hoped to do next, will that make it in?
wes-smith: could you say more about the protocol based approach?
DavidC: essentially, it could be provided at various points in the transaction
… it's more of a headache to see these other standards bodies choosing to do it differently
<Zakim> manu_, you wanted to ask about accessibility overlaps. and to note that putting it in VC makes the render mechanism portable.
manu_: when we were looking at renderMethod, we did look at doing it via the protocol
… big issue is if the protocol access is unavailable for a time, you won't be able to display the credential
… so no offline support for example and even online it becomes protocol centric
… so it can't support Bluetooth, NFC, etc.
… but by putting it into the VC, we mode the display with the VC over any protocol
manu_: but, I mainly got on the queue to talk accessibility
… we have a few opportunities over the next couple of years
… wes-smith covered some vocabs
… we could start talking about A11Y profiles of things
… one class of work might be talking about what's needed in VCs to support A11Y
… getting rid of captcha, supporting font and color preferences, we'd also need a good bit of help around providing auditory or haptic support via renderMethod
… of those things, which do you feel are the most important?
Janina: one big thing is about minimizing effort for the person using the credential
… the other is around disclosure and not oversharing things like personal capabilities
… because it risks exposing the user to prejudice
… we don't know how to crack that nut
… we share a good deal of things in common
… if we're honest about our abilities, we can share them gradually rather than all at once
… in terms of what to support, we'd love to see support for as many mechanisms as possible: audio, visual, haptic, etc.
… everyone is just a "TAB"--Temporarily Able Bodied
… so invoking via circumstance is probably where the win is
SinYong: renderMethod is very important to us
… we're doing B2B with a long chain of intermediaries
… organizations need time to process business update procedures
… the QR code and renderMethod approach can help us provide paper VCs
… these VCs travel through multiple hands before reaching the destination
… digital VCs are harder because they don't move down the chain well
… but this technology can reduce issues by enabling their use in paper processing scenarios
… so if someone in the middle prints it on paper, the process is not disrupted
DavidC: having the renderMethod in the VC makes them larger
… and then if there's something that doesn't support any of this like mDL, then you can't do that
… and if it's in the protocol, then you could go get it later
… and the issuer could change it later without having to issue the VC again
… so maybe there's no right answer
… but maybe there's still a way to unify the approaches through some harmonized scheme
phila: I wanted to underscore what SinYong was saying
… and I like what DavidC just said as well
… often, parties are reluctant to do this digital thing and would rather just send you a PDF
… plus the A11Y issue becomes more easily handled with some of these options and multilingual options
… but those would probably be best handled in the protocol--at least if an unknown amount of options is provided
… but putting it into the VC has value also
… having flexibility here will be important
rigo: I wanted to put my lawyer hat on
… the rendering isn't just about security, but about what's being rendered
… we need to express that there are requirements on display like photo etc.
… and some of that will need to be scannable even from paper
… and the a11y requirements would also fall into this issue
… because there are requirements
<Zakim> manu_, you wanted to reflect on physical paper processes being increasingly important.
rigo: so renderMethods may be required for certain scenarios
… not just optional display
manu_: so, paper VCs.
… it's great that we have digital VCs of course, but there's clearly places where going in and out of paper and digital is clearly of interest to the room
… and renderMethod also seems of interest with many more things to explore
… so thank you all for highlighting these needs, so we can discuss them in the coming years
… I'm also hearing more needs for VC API to prevent vendor lockin
<Gerhard9> Two questions:
<Gerhard9> * How does this work interact with https://
<Gerhard9> * Has there been any discussion about clarifying the 'intent' of the sharing details, that can prevent misuse/social engineering/fraud
Gerhard9: two things I wanted to share
… I saw the Digital Credentials API demo earlier at TPAC
… I'm perhaps wondering where rendering might figure into that
… I guess on the Wallet side of thing?
… how does the work in VC land and things like renderMethod interact with the WICG Digital Credential API?
… and does the recharter need to explain that integration?
… my next question, what if I want to apply for a social grant?
… what if someone is trying to take over my account?
… has there been thought given into an intent specification
Gerhard9: I think having some explanation of intent could be useful for why the credential is being requested
wes-smith: going back to paper-based processes
… if you have a motivating use case for VC Barcodes, that's an early stage technology, so please please please come help us
… so we can be sure it will be broad enough for what you need
<Zakim> manu_, you wanted to speak to overlap with Digital Credential API and to say "intent to use" VC for verifier... "reason"
manu_: adding to that, the disability placard we've done with VCs also includes the VC Barcode
… Gerhard9 responding to you, how much overlap with the Digital Credential API
… there's huge overlap
… it's supposed to be format and protocol agnostic, and if it stays that way then it can support everything you described potentially
… we do have the `reason` field during a request, we know that's insufficient
… we are wanting more fields signed into requests and even supporting VCs stating intent and capabilities and features when making a request of what they are promising to do with that VC
… so both of the things you mentioned are under active discussion
<Zakim> rigo, you wanted to talk about usage control in the privacy area that could be transposed
manu_: and your point about needing liaison with WICG should go into the new charter for sure. Thank you
rigo: so...pandora's box is opening with these reasons and intent needs...
… if we are saying, here's my intention for using this VC
… we also have usage control requirements
… which is very common rule...except in the US...[laughs in the room]
… this is something manu_ will like because it really requires the use of Linked Data
… because there are so many potential parties wanting to express things uniquely
… and RDF is really the only way to do that well currently
Janina: there are also relationships to be considered in the use of VCs especially around intent
… things like delegation and surrogate support -- power of attorney, etc.
… questions around renderMethod get interesting when coupled with requirements
… because requiring the existence of a thing may not explain what is actually encoded in the thing
wes-smith: excellent everyone! we're sadly out of time
… thanks for coming!