W3C

- DRAFT -

Verifiable Claims Working Group F2F Barcelona

04 Mar 2019

Agenda

Attendees

Present
Adrian_Gropper, Andrei_Sambbra, Brent_Zundel, Dmitri_Zagidulin, Ganesh_Annan, Kaz_Ashimura, Manu_Sporny, rhiaro, Matt_Stone, Ken_Ebert, Andrew_Hughes, oliver_terbu
Regrets
Chair
Dan_Burnett, Matt_Stone
Scribe
manu, brent

Contents


<manu> scribe: manu

Logistics and Introductions

Dan provides introductions, sponsors, space, etc.

burn: How many people are coming to dinner?

25-30 people raised their hands

scribe: 25-30 people raised their hands

burn: We do our communications on IRC... irc.w3.org, put in a nickname, no spaces - please join.
... We will need scribes for each session.
... We need scribes, please add your name to the agenda.

<brent> scribe: brent

burn: be nice
... introductions - quick around the room

<kaz> i/Dan prvides/scribenick: manu/

burn: Is there an animal you find intriguing, and why?
... I am Dan Burnett, I am at Consensys, nick is burn

<gannan> link to the slides if anyone missed it https://docs.google.com/presentation/d/1_AKEYKWqaiMIUb6tlo3yVONTl9Z-71H4XfdTtgUF88U/edit

burn: giraffes just look wrong to me. how can they survive?

stonematt: Matt Stone with Brightlink in Boulder CO
... always fascinated by sea anenomes. They look so soft, but are brutal predators. It is awesome.

kaz: I am Kaz, team contact from W3C, this is my first time attending.

<kaz> kaz: W3C Team Contact for the VCWG

drummond: I am Drummond read of evernym. I picked drummond as my handle before anyone else could pick it. I am in love with hummingbirds, they are the most magical creatures on earth

me: though that was a liger

Yancy: I am Yancy Ribbens. Turtles fascinate me. Perhaps they gain wisdom being around so long

manu: I really love lemurs. When you look at mok=nkeys you kind of know what they do. Lemurs are kind of hard to read.

Grant_Noble: don't have a nick. Australian marsupials are weird.

DavidC: From university of Kent. Weirdest animals are humans.

gannan: Ganesh Annan. Digital Bazaar. Kangaroos are the strangest animals. They are very aggressive.

dmitriz: With digital bazaar. Dogs fascinate me. All Canids can interbreed. The shape after a few generations converges on Jackals. Converging on standards is really good.

<manu> brent: Hi I'm Brent, from Evernym, I think that squids and octopi are really neat, they have very different brains. Story I like, aliens visit, use octopuses as biological computers because humans are so lame.

oliver: With uPort. I also picked the octopus, they have three hearts.

deiu: Andre. I am an invited expert. The mammal I really like is the orca. A mix bx whales and dolphins. Very aggressive and hunt in packs. Cool to watch.

rhiaro: Amy Guy. Digital bazaar. I love parrots, esp when wet. They look like dinosaurs.

agropper: Adrian Gropper. Slugs, the material they excrete, wow I like slime.

JoeAndrieu: Legendary requirements. Water Bear, only animal we know that can survive in space. Maybe it is responsible for panspermia.

<JoeAndrieu> Tardigrade

ned: From intel. Cuttlefish eyes are shaped like "w" they stared me down while diving.

ken: With Sovrin. I choose a cat. They choose us as pets and allow us to interact with their world. They sometimes try to teach us.

Moses: Hear as observer. big believer in digital ID. Favorite animal is the watu.

jonnycrunch: TranSendX, invited expert of task. Sharks are misunderstood.

Dolphins and Ants added to list of strange animals by two.

eric - favorite animal is the cockroach. They have some amazing properties.

snorre: likes dolphins

alex preuschett from evernym

Miguel: likes SSI, here to learn.

johannes: ouroboros is the favorite animal.

pmcb55: here as observer. favorite animal is the snow leopard.

Jack: observer, birds of paradise. Evolutionary biologists can't firgure them out because they seem to choose mates based on beauty.

achughes: Andrew Hughes. Independent consultant. Identity management world. Most interesting animal is the tardigrade (water bear)

rgrant: Ryan Grant - Kopi Frog

kaz: I like frogs.

burn: welcome everyone. thank you.

<kaz> (group photo before or after the lunch today!)

<rgrant> brent: coqui ;)

burn: most of us know this. Our goal is to make expressing and exchanging claims possible on the web.
... the educational related use cases are our primary focus.
... data model is in scope.

<kaz> fyi, VCWG Charter

burn: browser based API, protocol, Identity on the web = out of scope
... <reading Slide about what verifiable credentials are and are not.>

conversation about why the group is misnamed.

burn: If you need more info, there are links

stonematt: we have two pretty full days, and a big group. will need to manage time.
... we are at the end of our charter, time is of the essence. Our goal is to finish the work.
... We came to a feature freeze last year. we will be rigorous about changes to functionality. the agenda reflects that.
... Spend some time on the steps we need to take for CR
... also we will talk about what comes next, but keep that time-boxed.
... we also want a test vote on going to CR.
... as we move toward the next phase, implementation becomes critical. we have time for discussion and implementor guidance and feedback.

<scribe> ... <continues reading through agenda slide.>

UNKNOWN_SPEAKER: tomorrow, more of the same <next slide>
... Please be here on time tomorrow.
... goal is to reduce issues down to zero.
... some open blocks so we can be flexible with the topics we cover.
... DIDWG is coming (we hope). there are many who are interested in it.

burn: placeholder in slides for potential topics

kaz: just a clarification question. charter extension today and next phase and future are in recharting topics?

burn: yes
... will try to briefly cover process.
... <Very busy slide> trying to start CR stage

me: CR = "Candidate Recommendation"

burn: our work is the CR to PR

<kaz> s/next phase and future are in rechartering topics?/next phase and future on Tuesday is rechartering. right?/

burn: handful of docs in the charter. Names now are different
... that doesn't matter

stonematt: One of several documents is up for CR.
... we also need group notes: use cases and requirements; privacy; implementation guidance.
... these have been begun, but we need to keep working on them.
... data model status: feature complete. some editorial issues, and one or two sticking points we need to resolve.

<kaz> deliverable documents defined in the VCWG Charter

burn: we have a privacy considerations section in the data model, that may be enough.
... diagram with dates.
... quit adding features in Novemberm that still stands.
... as long as we vote in mid march, publish late march.
... earliest PR is May.
... earliest Recommendation is June.
... we are in process of an administrative extension. that does not give us more time, it only gives us enough time.
... additional CR is two more months. That takes us to the very end our time.
... this is not more time.

stonematt: set a big goal at TPAC to resolve all issues and hit CR in November, didn't happen.
... open issue count has stayed steady
... March in Barcelona. Big audacious goal is now to actually close the issues and wrap this up.

burn: we might get mean.
... it is easy to think "this thing I want must go in" but that might kill the whole thing.
... what needs to actually happen?
... <reading slide "What are we missing">
... still waiting on review from some groups.
... not sure when the review comments come. This time we also want review from TAG.
... we will need to turn those issues around in a week when they come.

stonematt: There are a couple of discussions that seem to not be ending.
... one is ToU.
... other is syntax and proof trade-off doc.
... chairs may need to decide.

burn: goal is maximum adoption and getting through w3c process.

stonematt: no more to add.

burn: now is discussion time

discussion

stonematt: any questions?

oliver: one question - Do we want to tackle the outstanding issues after lunch?

burn: any issues we have outstanding today are the implementation issues. we will go through those today.
... talked about administrative extension. this will happen if w3c believes we are on track.
... to do this we need to publish a CR
... doesn't require a vote to extend administratively.
... recharter would require a vote from all members.
... There are those who would argue we don't know what we are doing. That is not the case.
... the ZKP and JWT elements were added late, but that was done because they are so vital for adoption.
... assuming we stay on track, what then?

stonematt: we have until noon. Maybe we can keep this discussion time-boxed to 15 minutes. then start the JWT discussion.
... quick goals or ideas for future work (WG level work)

jonnycrunch: what is demand from implementers?

burn: that is important for future groups. if there are implementers who will join a future group especially.

jonnycrunch: is there a flavor of the demand from implementers for something beyond what this group is going?

ken: what is the distinction bx what we're talking about now and tomorrow. And the future work stuff, is that this group or a future group?

burn: maybe we should have done future work first.
... recharter is really a new charter, may be widely divergent
... a charter is to constrain scope. so companies can handle patent issues according to that scope.

ken: so first item on discussion tomorrow is protocol. is that on the table for recharter?

burn: if there is wide supprt
... the group wants it.
... there is no requirement that a recharter happen immediately.
... we think a DIDWG is coming. There would be alot of overlap bx that group and a rechartered VCWG.

<Zakim> manu, you wanted to note that we have buckets for stuff, but have not defined what's in those buckets.

burn: recharter doesn't need to happen right away. so we could run those in parallel or sequentially.

manu: to give the group an idea of what these things could be. we identified a bunch of buckets in the spec. e.g. terms of use. we haven't filled that bucket. a rechartered group might define that.
... same with evidence. we could recharter to add specifics to each of the elements in the data model.
... most likely our best bet is to move forward with DIDWG. but in the meantime organizations will be self-defining the buckets.
... but maybe that's what we want to see before starting a working group to define them.
... maybe a couple of years for people to experiment would be good.
... when JSON-LD became a spec, we waited 4 years to wait for the screams of demands of implementers.
... I dont think we're ready to define those buckets. too theoretical an exercise.

burn: interrupt - charters are for 2 years (typically)

kaz: several possible options. I would like to suggest: another group has a similar situation
... their charter actually ended last year, but they extended for 6 months. parallel-wise they're finalizing the CR and working on future items. I recommend this for this group.

<Zakim> deiu, you wanted to say that future work can also be incubated within a CG, to offset waiting time for a new recharter

deiu: we can still work on future items while a recharter is underway

DavidC: some things like evidence there isn't must experience, but some buckets are almost full.

burn: opinions differ on that

stonematt: my intuition is to put this work into hibernation while we work in DIDs. VCs help showcase DIDs while we work on them

<Zakim> manu, you wanted to focus on community group

burn: yes, work on protocol can start in community groups before we go to a charter.
... we do work first, so we have a WG to transition to when we are ready

manu: I agree. I think we can do everything in the CCG.

<JoeAndrieu> +1 from the CCG chair for advancing next gen VC work in the CCG

manu: we are building products on this stuff. the quickest way to discuss interoperability is the CCG until we are ready for a WG.

<JoeAndrieu> (co-chair)

<jonnycrunch> +1 to Manu to push in the CCG

manu: let's get a bunch of people working toward interop, then form a group to standardize

drummond: I agree. Is there anyone sitting here who actually has a concrete proposal for a recharter?

ned: I'm interested in constrained environments. that points to CBOR.

<Zakim> deiu, you wanted to say that it's better to wait and collect compelling arguments for a new WG instead of trying to come up with work items right now

<stonematt> +1 on having a clear charter demand

deiu: please do not recharter while there is no clear definition of what the work is.

<drummond> +1

stonematt: 30 min topic -

implementer feedback - JWT edition

oliver: potential trade-off section still has issues. I don't think we have general consensus on the contents of that table.
... wanted to have the conversation.

burn: I'm gonna throw out a crazy idea.

<manu> The section we're talking about is here: https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/384.html#syntax-and-proof-format-trade-offs

burn: i believe the original attempt for this was to guide implementors. that doesn't belong in the spec.
... this is a matter of opinion, so in the implementation guide we could have proponents for each of the formats give pros, then write rebuttels.
... that could go in the implementation guidance

<drummond> I would actually suggest to include JUST the advantages of each.

ken: the current table doesn't mention zkps, so it doesn't seem appropriate to cram it into the spec.

<Zakim> manu, you wanted to note where the table came from

ken: there should be some discussion of the trade-offs, but didn't feel like it fits in the spec

<kaz> rendered version of PR 384

manu: I put a link for the PR. Background - a number of reviewers wanted guidance. The group decided it should go in an appendix. That's where we are today.
... TPAC started on a use case basis, not sure how to write that.
... instead, there are 3 primary combinations that implementors are implementing.
... uPort is using JSON in JWTs.

<jonnycrunch> we are using IPLD

manu: my understanding is that the zkp stuff is using ld-proofs, so there are three options for syntactic representation.
... there are now multiple syntaxes.

<jonnycrunch> Which is based on dag-cbor

dmitriz: to add to the confusion: the json-ld signature contains a JWT as a JWS.

manu: we hoped for convergence, but didn't get it.
... the greater problem is that implementation complexity has grown.
... just want to outline that it isn't easy to read the spec and make a clear decision.
... we can put a link to best practices or put it in the appendix. At least the appendix is the same doc.
... if we're going to get this done before CR, somebody's going to need to write it.

drummond: I agree that the fact that there are three options makes it important for people to understand.
... it is going to be a challenge for eventual convergence, but we should be direct.
... each of the advocates should write a rationale for their method.
... a neutral part can write a intro.

manu: how many have read the section? <raised hands> not everybody

+1 to Drummond's suggestions

manu: oliver seems to be saying that this table shouldn't exist

stonematt: is there consensus among implementors that this is a binary interpretation?

oliver: I like drummond's idea of proposals written by the advocates.
... depending on who writes the section, there would be many items included or not.
... the table seems to be biased toward json-ld

<burn> hey, that was my idea! :)

oliver: I will write the JWT section. I don't think we'll get consensus on the PR

stonematt: often times there are gray areas

<jonnycrunch> brent:

rgrant: what i'm hearing is that in this spec, implementors can create compliant credentials that other compliant implementors can't read?

manu: that is true. that is how standards work. There is a market free for all.

drummond: also evolutionary biology

rgrant: but not random winnowing.

burn: this is how it works when people don't want to be told how to live their lives.

rgrant: are we aware of some implementers who are not going to implement some options?

group: yes

<Zakim> dmitriz, you wanted to point out, it's not really a decision for implementers. it's just "oh now I have to implement 2/3 ways)

dmitriz: I want to say - these are choices implementers must make. We phrase it as options, but really it is all of them or we lose interop

DavidC: this is partly tied to protocol. how the parties communicate os not defined.

<Zakim> deiu, you wanted to mention that while choice is a nice feature to have, it makes interop a nightmare

deiu: it is great to have choice, but that is an implementation nightmare. We want this technology to be used by the end users. But if the required formats are huge, that will limit implemenation options. they need guidance.

manu: concrete proposal - everybody write a section they are proponents of.
... looking at the existing table, the gray areas are expressed. I thought uPort was doing the middle column. Is nobody?

oliver: I don't know all of the proof formats and implementations they use. left hand column is uPort and probably microsoft.
... middle column is potentially used

manu: right column is everyone else

dmitriz: what about BTCR?

rgrant: we might use both

manu: you can't, I don't think
... also the zkp thing - this is about syntax and proof formats.

<jonnycrunch> Can I volunteer to write a section on IPLD?

drummond: i think manu captured, um. There is clearly a proponent for JSON + JWTs, is there a proponent for the second column?

manu: the comparison is there

drummond: who would write the middle column?

<burn> jonnycrunch, I don't believe ipld is a vc syntax we have defined in the spec

oliver: I know some implementers. I volunteer to write that section as well.
... JSON-LD + JWT

<scribe> ACTION: oliver volunteers to write JSON+JWT and JSON-LD+JWT sections

<scribe> ACTION: manu volunteers to write JSON-LD proofs section

deiu: since we don't have a clear medium where discussion can be fostered for these particular items, where should they go?

burn: time for a break. be gentle with what you take. There's not a lot of food.

break

<kaz> [break till 12:30]

<ken> scribenick: ken

stonematt: Let's get started

Feedback from Implementors

stonematt: Implementor feedback from non-members is welcome.
... Observer questions about how things are implemented are safe. Suggestions on how to fix problems are out of bounds.

dimtriz: I'm excited to hear from other implementors.
... I would like to have the discussion about which format implementors should choose to continue.

stonematt: How can we have a fruitful discussion on this topic?
... A free-for-all might get us started.
... What are other aspects we should cover?

dimitriz: The current test-suite has two forms for basic and advanced. No current implementation of the signature verifications.
... That is outside the charter.
... I recommend that developers that plan to support the data model, that they review the test suite.
... They should notice that there is a one-to-one correspondence with the spec.

stonematt: There is an existing test suite that focuces on the conformance to the data model.
... It the document conformant with the data model?

dimitriz: The test suite has the awkward job of testing conformance to the data model without testing protocol, exhange, or verification of signatures.

<burn> q_

<jonnycrunch> Link for vc.js test suite?

<Zakim> burn, you wanted to talk to multiple syntaxes

dimitriz: Just test the data model and validate the data model but not verification.

<dmitriz> https://github.com/w3c/vc-test-suite

<manu> Link to test suite: https://github.com/w3c/vc-test-suite

burn: There is data model, then syntax. Any number of syntaxes could exist. In the beginning there were three.
... XML was there but no one would write it.
... There should not be the implication that only JSON-LD.
... We wanted to show something so that it could be done.

manu: I don't think it is in the spec.
... I agree. If it doesn't say that we need to change it.
... Is there one thing we could discuss, it might be to only say "@context" in a VC.
... The complexity could be simplified by 33%.

oliver: There are some developers strongly opposed.

drummond: In terms of recognizing this as the prime interop issue. We need to anticipate what will happen.
... Is it ok to point from the appendix to an on-going community effort for feedback in a living document.
... I think it will help convergence.

stonematt: Maybe the CCG can consider this.

drummond: if the CCG would agree to that it could smooth things over.

<Zakim> deiu, you wanted to mention that discovery of implementer resources can be improved

joe: Give us a work item.

deiu: This type of resource would help implementors. Links would help.
... The spec and home page don't help.

burn: We appreciate your willingness to help.

<Zakim> dmitriz, you wanted to mention - the test suite does not test the JWT serialization

deiu: I can help with that.

dimitriz: With re: to the test suite, only the JSON-LD form is supported. The other two columns will need other test suites.
... One topic of contention between syntaxes is library support. JOSE have broader library support requirements.
... The crypto libraries are weakly supported.

yancy: As implemntors should we be concerned about DID resolvers?
... If we don't know if a particular format will support a particular type of DID, should we not support it?

stonematt: This is a document format.

<dmitriz> just to clarify the transcription, with regards to syntaxes: JOSE has broader library support in theory. But the actual keys and crypto methods many implementers are using, /are not/ supported by those JOSE libraries

yancy: It there a time line when we cannot make changes.

burn: We need at least one producer and one consumer for each feature.

yancy: If we are the only impementor we need to make you as chairs aware.

stonematt: If you are planning to be an implementor, we would like to know who, what features, etc.
... As an issuer, consumer, or both?
... We also need an implementation report.

drummond: Why these terms.

burn: They are W3C terms. As far as the spec goes, can someone write one and someone read one.

<stonematt> Implementers commitments: https://docs.google.com/spreadsheets/d/e/2PACX-1vRTbKsROuQzBWyuYvMBwSrjuv5X3jO-ObXpLEPpWxuPqXi6sigqfIfQwpJNHwK70cBHwV1torftKW0u/pubhtml?gid=285762982&single=true

rgrant: The only syntaxes are json-ld, json w/jwt, and json-ld with jwt.

manu: json and json-ld; json-ld and jwt

<Zakim> burn, you wanted to comment on test suite architecture

<Jesus> q

<stonematt> 1?

<stonematt> 1?

burn: Test suite architecture: this is a doc model and syntax. No computation is required.
... Manu encouraged an actual test suite because it show maturity.

<Zakim> manu, you wanted to note that not adopting @context is a philosophical stance... and to note not a separate test suite, please.

burn: If we continue down this road, we will have interop questions.

manu: json+jwt; There is a organization that refuses to put a context in the VC field. They are not participating activily.
... I'm struggling to understand why the WG is bending over backward to support a format that could be easily fixed.

dimitriz: I meant to say that we need data in the other formats.

manu: If organizations want to show conformance using these optional formats they are there.

<gannan> s/dimitiz/dmitriz/

burn: I don't want to go down this road.

manu: Is there any implementor who won't put a context in a VC?

jonnycrunch: IPLD is a format we are using that is slightly different? Mostly for security.

manu: Anyone? Anyone?

<dmitriz> question to jonnycrunch: are your concerns about @context / content-addressable issue addressed by the hashlink spec?

oliver: Refusing is a strong word.

manu: If you don't include it the test will fail.

oliver: What is needed to support json in the test suite?

manu: who adds the addtional context?
... The spec says you have to include a context.
... Are you going to follow the spec?

oliver: If you are going to support json, its about who has to accommodate?
... The you are going to insert something in the VC.

dmitriz: Test for type, there are other things?

ken: Who can contribute tests?

burn: Anyone especially those who didn't help write the spec.

<Zakim> burn, you wanted to ask Manu about "treating plain JSON as JSON-LD with a default @context" and why this doesn't address the problem

burn: Why can't we treat json with a context?

manu: Because you can just pass the test, but it won't actually work.

burn: Or interpret it as the defualt context.

manu: You will pass the bare minumum, but you will fail some subsequent tests.
... There are deep reasons for this but no a good use of our time.

davidc: It doens't say that context must be present.
... You have to say the context MUST be present.

burn: Have people who read the lack of MUST as significant.

rgrant: We are collect VCs from as many sources as possible. It is not just the test suite.
... We are looking for VCs that are JWT, json-base, etc.
... This is not the W3C test suite. It is external.

deiu: T
... The way it is present in all examples. @context is used everywhere.

oliver: The examples are all informative and not normative

deiu: We need to be more explicit.

<rgrant> rgrant: and the "implicit @context" idea in the air is unclear on how to implement

oliver: should the test suite fail?

dimitriz: Can we hear from the chairs re: test suite vs. none?

burn: This is a document format? It is very difficult to separate the rules of production and consumption from the rules of the document.
... Various groups have encountered this. In the end they have assertions about does the vendor do you supoort thsi feature.
... This allows the test to occur without the fighting over processing.
... Not all implementations can or will process all fields in every VC. I could ignore the @context.
... It doesn't matter to my implementation.
... The downside is always better if you can show real implementations over just looking the format.
... If we can't resolve, yank it and publish a table.

brentz: There are other fields in the data model, that have optional characteristics. Some we are including; some not.

kaz: The basic process requirement for CR transition is just write the spec and assertions, like the table.
... What we are doing is an extended effort.

<rgrant> stonematt: thx

kaz: The test suite helps implementors. On the other hand, other groups have just generated a big table of features for manual verification.
... We need to provide a table of experience in the end.
... The basic expectation is that two organizations interact on the data. Could be manual.

manu: We could manually or automatically prove interop. Let's please not kick the can down the road.

<Zakim> burn, you wanted to respond to kaz

rgrant: I don't want a table to checklist.

burn: Absolutely love to see implementations. Most test suites don't demonstrate full interop.
... Get the spec out is the primary goal before the charter expires.
... The test suite should not give the illusion of full interop.
... I agree with Kaz that we don't need a test suite to enter CR.
... I am concerned that we can make pollyanna statements about interop.
... If a few missing features.
... What does it mean to have an implementation?

kaz: One of the most important things is does the test suite correspond to the assertions in the spec.

<inserted> burn: the current test suite corresponds to the spec nicely

jonnycrunch: In medical there were connectathons. A test suite could oriented to that way.

manu: That is what the test suite does. It does input a json struct and outputs a VC.

jonnycrunch: Between two testers, an output test result that describes the pairwise result could be published.
... The badges of pairwise result could be a dashboard.

rgrant: Implementors could publish their results.

jonnycrunch: It becomes more iterative and pairwise.

pmcb55: I strongly support a multiple language test suite.

<Zakim> deiu, you wanted to mention that we should clearly mention the test suit only covers the model, and not a complete workflow informed by the use cases document

Jesus: We are getting too complex to create an interoperability suit.

<stonematt> s/???/Jesus /

deiu: As part of the document that I am writing, I could include some explanation.

oliver: wrto JWT and ZKPs the test suite is incomplete.

dimitriz: yes.

oliver: I will add tests for JWTs and I expect Sovrin/Everym to add ZKPs.

<Zakim> burn, you wanted to mention industry fora and their implementation conformance certification programs and to remind people that we are required to test the implementability of the

burn: I want to remind people that we are required to test the implementibility of the spec; NOT the validity of the implementation
... Not interoperability either.
... An industry forum such as rgrant mentioned could be created later.

<Zakim> manu, you wanted to note how test suites usually progress

burn: There are ways to test implementation conformance that are beyond this group.

manu: I would like to get feed back from each implementors.
... I also discovered today that @context is being considered by some implementors as not mandatory.
... There
... is a new issue. It is being tracked.

stonematt: Let's review the status of implementors.

dimitriz: Basic, advanced, ???
... There is a PR pending on advanced, NO ZKP or JWT

oliver: on track. We used the table on google drive to fill out our plans.
... I have some questions on credential status.
... Is there anyone who is going to present a credential that is revoked?
... I see that there must a revocation mechanism in place.
... We might consume it.

jonnycrunch: Medical credentials are often revoked.

oliver: We will consume but likely not produce.

<rgrant> What does column H on the implementor's table mean?

drummond: In our experience, some credentials don't need revocation.

oliver: the table is up to date.

manu: The table means that you are going to generate a credential that leaves it in. Or I can consume it.

oliver: If you just process it, what's the point if you are not actually going to use it.

manu: A new column @context has been added.

burn: The group can decide if the list is public.

joe: I was confused re: credential status. RE: revocation?

brentz: It doesn't mean it is revoked. It means here is how to check status.

jonnycrunch: Agreed.

burn: if the table is up to date, we're done.

<brent> drummond: evernym and sovrin are different

<brent> ken: the table is up to date

<brent> ... two columns we don't plan on passing that through or using it

<brent> ... refreshService and termsOfUse

<brent> ... tou in its current form is dangerous and unenforceable. in the future perhaps, but not now.

<brent> ... other fields like evidence, we will pass them through, but don't have a current use case.

<brent> ... no philosophical disagreement.

<brent> ... don't have a mechanism to verify JWT and JSON-LD proofs, but no opposition to others using them.

scribenic: ken

<brent> drummond: speaking from evernym and sovrin. the larger question of test suites. in the context of testing a data model this is great.

<brent> ... in the market, interoperability will matter within governance frameworks.

drummond: Testing within a governance community is what matters in the market. Shared incentive for interoperability will drive this.
... We have communities within the Sovrin/Evernym community.

ken: We have multiple implementations. We are seeking more.

Drummond: as Evernym we are only doing one.

burn: this spreadsheet lists "features at risk". The table is not comprehensive.
... 6 or 7 could remove the item from the table. The table is to help us identify features at risk.

stonematt: We can look for feedback on other implmentors from Sovrin and Evernym.

<inserted> kaz: for CR transition, W3C WGs are encouraged to identify some of the features within specs as "features at risk" (which might be difficult to get implemented), and I thought this spreadsheet lists those "features at risk" within the Verifiable Credentials Data Model spec.

burn: be back at 3:00 to start working.
... presentation during lunch on use cases.
... We encourage to be back at 2:30.

<kaz> [lunch till 3pm]

<rhiaro> scribenick: rhiaro

Non-spec important issues

brent: we want o move quickly. We're not here to hash out the issues, the goal is to decide what next steps are, who is repsonsible for it
... if you can help, accept responsibility
... And learn to let go. If there is an issue that we could close, let's close it
... if there's some tender feelings then maybe we could defer somethings we don't want to quite act on but can't let go of
... Maybe an option.
... The issues that ended up in this deck either somebody told me to put it there or it is an issue in github that does not say CR blocker, does not say defer, and didn't seem to be realted exactly to the spec
... if there's something missing, feel free to add a slide, insert it at the end
... Slide with links to all the issues in gh
... The rough break up is implementation guidence, registries, and then all the other stuff
... if looking over the list you see something that's an issue and we're not talking about it, make a slide, we'll talk about it
... Under implementation guidence, there are 4 things, with 6 associated issues (some related)
... First one is default namespace URL #206
... Summary is maybe we should cahnge the context URL to something else. Should it be w3id or w3.org. There is a task list from tpac and the two remaining things on the list are to request the proposed URLs from the web team. Has that happened?

manu: yes

brent: have we documented the integrity proofs as a note?

manu: no

brent: so should we close it?
... As we are moving quickly, if someone wants to look at an issue, go look at it, come back to this deck and then make a comment on the slide
... or go to the issue and make a comment on the issue

manu: should we give everyone an update on all the things that happened or is there too much?

brent: there's not a ton of stuff, but..

manu: I'd like to skip that but I'm afraid that people care and don't know what happened and will come back later and reopen

brent: before it's closed we should make a comment that we determined at the f2f the tasks were done and it was clsoed

jonnycrunch: before we consider which URL, should it even be a URL as there are other representations of resources like IPLD

brent: that was a different issue
... I believe it was closed
... There was a question, should we explore using webauthn with VCs. Implementation guidence tag was added
... Does this belong in implementation guidence? Should we publish a guide for people who want to implement VCs in webauthn?
... That seems to be what is implied with the label

manu: no

brent: I have my own opinion but I'm presenting

manu: There were successful experiments, we notified the webauthn groups what they needed to change to make it a core feature. I think it's too early to write it up in the implementation guidence. The CCG can update the docs when it's more secure

brent: I think we state that and close the issue?
... That it's done by the CCG and this isssue doesn't have to track it

burn: exploratory items can be done by the CCG, but not just anything to do with implementation guidence

manu: there's a question around who maintains the implementation guidence after this group closes. The guess it's going to be the CCG

burn: That's a nice suggestion

brent: implementation guidence decision maintenance is not this issue
... So we close this issue.
... There were a copule regarding attachments in credentials. One regarding outside data, and other regarding credentials inside of a credential. Labelled implementation guidence
... does it belong there? Is it possible to do this according to the data model?

manu: yes and yes
... if specs like hashlink or named information or..

brent: is the idea that the whole implementation guide is written by the CCG?

ken: we're going to have at least a first version

brent: this issue should be addressed in it?

manu: yes

ken: does the implementatio guide correspond to this version of the data model?

burn: yes

brent: the suggestion here is implementers might want a json schema they can use to validate the credentials against, an official schema, and should it be referenced from the spec
... is this an implementation guidence thing?
... it feels like this is being accomplished by the test suite

dmitriz: this is not being accomplished by the test suite. This is whether we recommend another property that points to a schema

brent: addressed by credential schema?

manu: yes
... There were two issues reaised that sounded like the same thing but were different
... one was what can I use to validate the default VC thing
... and what can I have that does specific types of credentials, eg. drivers license, what schema goes along with that. that's what credentialschema is for
... The other is whether there's a generic json schema that checks the core fields in the spec

brent: how does it differ from using the test suite?

dmitriz: test suite is for libraries, schema is for individual credentials

brent: 128 is need for a schema to test against. 129 is addressed by credentialSchema
... This has been addressed and should be closed. 128, do we need this?

dmitriz: would be helpful

brent: I agree, do we need to do it now?
... if it is helpful, who is going to do it?
... Volunteers requested. if it's not important enough for anyone to do it right now but we don't want to let it go, we should label it defer

manu: +1

brent: unless someone has a valid reason to not defer it or claim ownership
... or is the valid schema against which to validate the verifiable credential something that would be included in implementation guidence

burn: if we're gonna provide it it doesn't belong in implementation guidence
... either it has normative weight or it doesn't

dmitriz: schemas are a really easy verison of the test suite. they are a machine readable way to test individual credentials for conformance
... I gues I'm volunteering.

jonnycrunch: json schema implements MUSTs

??: something about shacl

brent: I took notes about registries, but I don't know what it means

burn: we have a timeslot for registry discussion

brent: context URL doesn't point to anything

manu: cannot close, needs to be done

brent: this is new, it's ongoing
... manu owns it

manu: *makes a noise*
... I can't make that happen
... it's in kaz's hands

kaz: I checked with webmaster about the namespace files, it's okay to have actual content on the github site, but concerned about the sustainability for the github site, so he suggests we set some mechanism to copy it from github to the w3c side with a webhook. I think that's fine.

brent: we would regularly move the github content?

kaz: automatically yeah

brent: but the context that gets pointed to by the URL shouldn't that be more immutable..?

manu: I think that's a security issue and we can't auto copy it. We can until we hit PR, then stop the script

ken: it's supposed to be immutable. So auto copying it does violate that

manu: so the latest copy is up there through PR that's fine but once we hit PR close it

brent: should we track the need to turn off autocopy at PR?

kaz: we don't have to use auto copy every day
... we can negotiate with the webmaster how to deal with that

brent: shoudl we track the need to make sure the context that is referred to by this url is somewhat immutable here, or should that be separate issue?

kaz: maybe another issue

burn: it would be clearer to open a separate issue about that that remains through PR. So we can pull it up and say we know about it with the director

ken: what happens when the immutable data changes?

manu: in the spec we say implementors are urged to hardcode it and use local copies and not go out to the network

ken: when we found a small problem..

manu: we will never change it
... even if it's wrong. In general we should never touch the file
... we will release a v 1.1 if we have to
... we can release a.. there is a plan. if significant changes need to be made we have to release a new version of the context

brent: verifiable credentials should have a unique mime type?
... The purpose is not to discuss *whether*, but what are the next steps to take in making that decision?

manu: this would be a normative change to the spec so if we go into CR without it we'll have to go through CR again if we decide we want it
... daniel opened the issue. It raises a really important question

burn: this is an open topic

deiu: is there suggestion that this is a real issue?

manu: an implementor brought it up as a real issue
... they want to at the minimum ask for a specific mime type

brent: there's discussion in the issue that clarifies what this is asking for
... so we keep talking about it?

burn: yes

brent: because changing this would affect CR is it a CR blocker?

manu: yes

brent: should we put an end of life date on the spec?

manu: this was christopher's issue, he said he wished they did it for TLS. I don't know how you could enforce it

drummond: what's an end of life date on the spec?

manu: it means we say the spec will no longer be valid after a certain date

drummond: an example of a spec that has that?

rgrant: if I see a spec that's end of life, the result is that I go to the next google entry and look for another one. I think it's slightly helpful

deiu: seeing as we don't have a recharter date in mind, we shouldn't put an end of life date either

<dmitriz> +1

manu: also w3c has a process where they rip out old specs. It took 15 years for some of them, but..

brent: defer means not this version possibly the next. Other options are act or close. Act means somebody volunteers to take action to move forward on this issue

JoeA: I volunteer to have Chris talk on a weekly call about why he wants this

brent: images in documents produced by this wg should have descriptions as recommended by the WAI

burn: we will get those comments already from the accessibility group after asking them to review it

manu: tzviya volunteered to do it

brent: she's not volunteering to do it in the issue

stonematt: we were working together on it, I'll take that

brent: if a credential may be delegated, what prevents a verifier from taking a presentation and pretending they are aholder? It was supposed to be discussed by JoeA and DavidC after tpac

DavidC: It's really important but out of scope

manu: there is a protocol answer to it

burn: should go into implementation guidence?

stonematt: is it a defer issue? it's out of scope for now but we might have to solve it eventually

manu: it's probably implementation guidence

stonematt: they're gonna get stuff wrong

dmitriz: this isn't a protcol level issue. It could be a data model issue for example the way the question is solved in oauth2 is it requires an audience property
... that way each presentation, each credential, is only good for one verifier. that's what prevents it. that's a data model issue. It requires that property to filter it.
... Our solution could be something else, but it could be a data model solution

DavidC: first of all we're different to oidc. we're putting hte user in charge. In oidc the issuer is in charge. We have another solution which stops it being passed altogether. Subject-holder not transferrable is a solution to it being passed at all. It's an even more constrained solution
... The solution to it is it's not allowed to be passed on at all, exists. Not allowe dto be passed on *again*
... You can have a relationship credential.. there are solutions already

manu: the way that it's solved right now with JWT is through the audience field, and same with LD-Proofs. outside of the data model

brent: and with zkps all the verifier can do is know that they got it. it has been solved on the protocol level by the people who are using it

manu: all of the solutions are outside of the data model
... We could mention in the implementation guidence that that is what people have chosen to do and that would be better than not saying anything

brent: who's gonna act?

burn: there is a very beginning outline of th eimplementation guide

dmitriz: can we open issues on that repo?
... I'll create an issue.

burn: there may be a timing issue. We need to be clear about if this is a CR blocker. i'd say no.

<dmitriz> what's the link to the implementation guide repo?

burn: We were restricted from doing protocol work by the charter. But we are continually asked how peopl euse it. We say it's a data model, you're not allowed to ask that. The conclusion was to have an implementation guidence document that includes our best thinking now. It's not normative. It may not even be our best thinking.. We may disagree
... the reason for it is that people will see the document and people will begin doing thing swith it before we get to definining the protocol. I fwe give them nothing they'll go crazy. If we at least say this is what w'ere thinking about they're more likely to move in that direction. That's what's going on.

drummond: is that an official decision? Will it be referenced in the spec?

burn: there are osme issues where we must put something in the implementation guide to address the issue
... we can't normatively reference it

manu: we should have a non-normative link to the implementation guide that says it's maintained by the CCG

deiu: I'm supposed to be tasked with creating that document that lists all the other resources, do you want to put it in that document? That's outside of the spec

manu: good idea

deiu: I suggested earlier we have a home document to discover useful resources for implementers to get started

brent: Anything more for this?

manu: kaz can you move it to vcwg first?

kaz: copy or transfer?

manu: transfer

<kaz> implementation guide repo

brent: how JSON/JWT and credentials will fit together. THere were 4 work items. i believe it was owned by Kim. I don't know hwo can speak to the status of the work items, but it feels like this may have been resolved because we have an example of using JWTs inside a credential

burn: Publish rebooting guidelines doc, did that go anywhere?

manu: it was never completed. Nobody agreed to it. The appendix is that. That's what we were supposed to produce

brent: it feels like this is close as everything was addressed elsewhere
... create tooling for vc creation?

burn: and schema creation

stonematt: tooling has to come outside of this wg

oliver: what is meant by create tooling for vc creation?

burn: I'm looking for anything about tooling in there...

brent: i remember it coming up at tpac

gannan: it was around trying to create a site like jwt.io so develoeprs could create a credential

brent: like a playground. Definitely outside of the scope of this group. Already being done. Awesome.

manu: I'd suggest close. Overtaken by events

brent: on this we said let's leave it open with the implementation guidence tag on it, but we should change it to an issue in the implementation guidence repo

manu: +1

everyone: applauds brent's issue handling.

Registries

manu: The spec talks about a number of different registires, kind of in a handwavey fashion
... the status registry is for different status schemes, like revocation, are you going to have a method that does revocation through a list published to the web, through a blocckhain method. Kind of like a credential status method registry... does that make sense?
... Its' for the things that plug in to the credential status field
... that's what the registry is supposed to hold
... just like there is a DID method registry

drummond: Can I clarify? that's totally different than what ?? calls revocation registry which is an implementation of a cryptographic accumulator

manu: tha twould be one method in the status registry

drummond: and you would describe other types. I see

ken: and there are other types such as a list

burn: any other questions about that one?

oliver: examples?

manu: one of them is .. we have one that is basically a list that you publish to a website. It has a bunch of things that have been revoked in it. That's the simplest form. You publish a file on the web of all the things that have been revoked. Not the best for privacy preserving
... you do'nt know who someone is checking the list for
... The next would be a blockchain based one. Waving my hands there because there may be multiple blockchain based status registries. I expect they'd be the two general types of methods that would go in there
... We do need the registry because people are going to start working on this stuff, more than likely the credentials CG should be the maintainer since they maintain other registries that th ecommunity uses
... THe general quesiton at this point is do people think we need it?
... Suggest yes. Who is going to maintain it? Suggest CCG

<Zakim> burn, you wanted to discuss chair interrupt

drummond: My first suggestion is just.. I don't thikn it's a very good name. Registry of credential status types.. as in ways to check the status of a credential

<Zakim> JoeAndrieu, you wanted to ask if we have good, documented criteria for acceptance in these registies?

drummond: The second thing is if it's just that I'm not too worried about it being centralised, because the same situation is with the DID method thing, it's just a reference tool, you're not trying to create an iana style list. I agree that the CCG, if it agrees, would be good to take on the task

<Carlos> 3Cq

<Carlos> q

JoeAndrieu: are any of these well defined enough yet to understand the criteria for acceptence

manu: no. There's one example fo the list type

JoeAndrieu: the lesson from the DID method spec is that we've had to refine the criteria for what you can put in a method spec because we got name squatting. There's wokr to be done around consensus around how you get in there. The CCG will do that. ther eis longer term risk that it's not clear that the CCG is not the right place, but there doens't seem to be a better place. Does w3c staff like this weird ambiguous architecture?

manu: we don't know yet

JoeAndrieu: it's kind of weird given how lightweight the governance to become a chair an set up a CG that we're using them for infrastructure maintence

kaz: another possibility is creating a dedicated CG for that purpose. A registry CG or something.
... my personal opinion, I need to talk with team. WGs used to use a group note for registry publication, but that's for after. Some other working group tried an IANA registry but that's really complicated
... I need to talk with ?? about it

Carlos: makes sense to have a registry also for presentations?

manu: we haven't talked about this yet

<kaz> ACTION: kaz to talk within the W3C Team about having a CG to manage registries after WG

Carlos: what we are missing in the implementation is a presentation request. When the verifier wants to ask the holder what the verifier needs for providing the service to be in some format, if not all the implementations will defer

manu: this is the query language for credentials. What's the query language for asking for a credential..

oliver: that's prtocol specific right?

DavidC: you could standardise a data format, like a policy

manu: those are registries we haven't even contemplated in the group, we should make a note, but

oliver: we need it, but I don't think it's in scope of this document

manu: once we understand what all these registries are there will probalby be a bulk decision on who manages them. I expect most folks to say the CCG

<Zakim> burn, you wanted to mention IANA model as good for understanding options

jonnycrunch: does it have to be done by committee in the CCG? In ?? I represent, each of the member boards have each different ways of maintaining a certification. Each method in this registry.. is it a list on the web or a ilst on a DHT.. there's a whole bunch of complexity, but the burden of something having to go through committee to get something registered it's goign to take forever. It should be self describing. it should stand on its own, eg.

with JSON-LD

burn: this has come up.. I've heard people talking about wrt to the CG.. what should we allow people to do with registries, who should be able to register. IANA has been mentioned, for peopel who don't know, it's what IETF uses, they're a good model to look ath requirements for how to register something. A lot of good thought went into that

<Zakim> manu, you wanted to clarify self-describing and to raise Evergreen Specs proposal raised by wseltzer.

manu: wendy is watching..
... wendy noted that ther eis an evergreen spec proposal to the w3c process. I don't know that much about it. Does anyone?
... I think in general its' the how do you do a living spec, living document, what's the process behind it
... if it's official w3c process it might not be a CCG thing, it might be implemented elsewhere. Id on't know the current proposal
... jonny, to clarify, self-describing, these registries are not meant to be official, they're advisory. These are the things we know about. All you need to get into them.. longest is a couple of days
... The requirements are super low. Same as the did method registry

jonnycrunch: but it took me goign to meetings to get in
... then the process changed

manu: it's the CCG. Anyone can join it. It's not W3C members

JoeAndrieu: the proposal of CCG managing the governance, not approving what goes in there. What we learned with the DID method spec is we have to have better criteria and process. We don't want this, we have to omuch work to do, but this seems like the lightest weight way to figure it out
... if the w3c figures out how to do it that'd be great. Or if there's another way. But it's about governance, not about approval

kaz: the github issue on w3c process. There is some discussion about evergreen approach including registry as a possible use case. And another issue about registry itself. There are two different threads
... we shoudl watch the thread on registries defined by w3c process

<kaz> discussion about registries on the W3C process thread

<kaz> ACTION: kaz to watch the discussion about https://github.com/w3c/w3process/issues/168

manu: the other registries are the data schema method registry. JSON schema is the only example we have right now
... I don't know where evernym and sovrin folks are with reusing that?

ken: it has to be in the proof but could also be in the schema field. The proof points to something more complicated, a mapping and some keys, but eventually points to the schema. Could point to the schema if that's useful for interop

manu: maybe the sovrin/evernym stuff could go in the data schema method registry
... the refresh service method registry. When you're credential expries you need to go to the.. the manual refresh service gives you a URL so when the credential expires it gives you the URL to request a new one from the issuer
... people have contemplated protocols about automatically refreshing credentials
... and refreshing them before they expire (eg. like letsencrypt does automatically behind the scenes). that would be nice for things like drivers licenses

JoeAndrieu: in the use case conversation, it's a nice fit for the wallet to handle that
... I don't want to have to go get it. We talked about whether or not the verifier gets it, that's not what this is most likely

manu: it's in the credential. The verifier would see it

JoeAndrieu: they'd see it but they can't use it without a capability

manu: and there's an arguement to move it to the presentation. The issuer puts a refreshService and you're moving presentations around not credentials. It's been proposed. Nobody has made a decision.
... Terms of use method registry. As people build different types of term sof use it would be nice to have a registry so you understood the different patterns
... The presentation type registry was just raised to contemplate.
... We also have a LD-PRoof cryptosuite registry, which specifies all of the cryptosuite types, like sovrin zkp, rsa would be another
... and so on
... and then there are other ones like anchoring proofs like the bitcoin and ethereum folks might want

JoeAndrie: is it really ld-proof? isn't it just a cryptosuite registry?

manu: ldproof is a very generalised format? JWTs have their own registry at IETF

JoeAndrieu: just wasn't clear if there are cryptosuites we carea bout that aren't ldproofs that should be included

manu: not that I'm aware of
... those are all the regstries, who neesd to manage it.. clearly this group isn't going to do anything except maybe say they shoulld exist and say who sets them up and manages them. The suggestion is let's have the CCG take it over and create all the registries and copypaste the process we use for the DID method registry

ken: is this something that could be handled in a protocol type discussion?

manu: no I don't think so. Those are all.. half of them are data model things. Theyr'e not protocol related
... if you rechartered a group you could say the new group should manage those registries. The easiest thing would be the CCG doing it.

coffee break

<kaz> [break till 5pm]

<manu> scribe: manu

Use Cases

Joe: I put the link into the current draft of the VC Use Cases into the slide deck

<burn> https://w3c.github.io/vc-use-cases/

Joe: We have put some work into the document over the last couple of months, not under same time pressures of Data Model.
... we made some changes in spec. There are issues with the PR, we'll need to fix it.
... we wanted to map requirements to use cases in document. All use cases have about a paragraph explaining things.
... don't know if this is best representation, but we wanted to get an idea on where things are.
... We have recently added 2.5 use cases, we are going to spend some time on instructor.
... citizen by parentage -

Joe explains Citizenship by Parentage use case.

Joe: Challenge with this use case is because parent's name change... mother sends birth certificate... he gets his passport.
... That's it, but we try to tease out details in these.
... International Travel with Minor and Upgrade... current US Passports don't note parentage, letter to travel if traveling with child.
... What we did for this use case was, what are the things that could go wrong... what are things could ameliorate that threat.
... There is a stolen key, -- kidnapping her own kid, but Rajesh could store key w/ 3rd party... nothing to do with our technology. Could use a hardware wallet/pin/passphrase on key.
... For our third example, want to focus on threats to third document, etc.
... Third focal use case is PADI Expert instructor...

<stonematt> https://docs.google.com/document/d/1O-PYcHZYvbjbhONRSdSwdCP2cwg77bxadAJQdHdI66A/edit?usp=sharing

Joe: Pat earned multiple diving credentials in Fiji, Australia... later hired by NOAA - requires they maintain certification, remain instructor... instructor certifications are public, personal certifications are not public.
... Part of certification is logging hours ... NOAA hiring local divers... counter-signature of credential, important because we haven't had that use case here yet.
... Certification in Fiji/Australia -- different schools issued credentials... different expiration cycle -- validate future credential status changes...
... Wanted to put in ocap stuff because we've talked about that use case in this community... certified log of all divers.
... NOAA makes sure PADI approved those schools... then those schools issue those credentials.
... Upon accepting the job, get token to check all certifications, not just single credential.
... when things expire, NOAA's check provides next valid credential. Archives on laptop.
... Once Pat retires, he revokes token.
... VCs that exist, Advanced Open Water Instructor, Drysuit Dive Certification, Night Diving Certification, etc...
... Just one VC when going for job application.

adrian: This overlaps significantly with the prescription use case.
... I'm not sure there is a difference.

manu: Sounds like it's good that this is same as prescription?

matt: Yes, but we needed an education / cross-jurisdictional use case.

adrian: Prescription one may have a revocation requirement.

ken: Is purpose of focal use cases to show off all use cases? Scare people of complexity of credential management?
... What is the selection criteria?

Joe: This is an opportunity to provide more depth. Some of the other ones felt cookie cutter, no distinct characteristics of feature set.
... Let's get something accessible, with a sticky wicket.
... Something that the VC part of it has... not meant to be exhaustive.

Ken: Do we have a beginner use case?

Matt: We have 20 of them.
... VC Data Model spec is based on university credential. Ganesh wrote lifecycle of that, embedded in Data Model spec.

Ganesh: It was pulled in a few weeks ago, into the data model spec.

Joe: Trust hierarchy -- PADI is liable for correctly certifying dive schools, school is liable for Pat's schooling, Pat's liable for their actions... this is about who has liability.
... I don't think this is complete - want to flush this out -- threat model. Pat revokes update permission, NOAA checks it anyway.
... Pat revokes capability, in hopes that a revocation isn't detected immediately,
... PADI revokes permission to issue, PADI invalidates issuing credentials, PADI invalidates affected certifications...
... Pat could have cheated -- PADI revokes certification, School revokes certification....
... Pat could lie about a diver

Ned: Malware could take control

Manu: Pat could be Phished.

Joe: Could give capability to wrong entity.

Ned: A lot of these assume that these issuers are well known -- could make changes to names.
... Is there a way for Pat to not be spoofed when he gets certification from school - fake issuer provides credential.

jonnycrunch: If diver needs credential, based on swimming exercise... charging the diver for proving that... requisite on diving... do swimming lessons...

Joe: You're talking about hacking the VC in some way -- monetize as much as possible, overcharge you by 3x... but no one notices it.
... No monetization architecture.
... Pat could hack their own credential.
... Boat could sink...

Group adds responses to threats...

Discussion around how dives are logged in the real world... how certificates are published... how one diver can log dives for another diver.

deiu: How are these issues handled today? Seems like we're trying to come up with solutions for things that may already have solutions.

joe: We are trying to capture all of the threat models... and state that VC are not magic fairy dust, there are things that they don't solve.
... These are a bunch of data trails that can be authenticated.

deiu: Couldn't a lot of these threats be mitigated if diver's present VCs before all of this happens?

Matt: These are in tough locales, a lot of this might happen in disconnected locales.

jonnycrunch: Movie "SWIM" where they leave diver's behind... manifest could be captain of ship headcount before/after. Proof that everyone is on board, put name on manifest.

Joe: Some of the things said, vacation, not handled in this use case. In emergencies, sometimes you throw protocol out.

deiu: Attaching evidence of proof of identity, record driver's license and photo, could handle these threat models.

Ned: Is there an assumption that verification can't happen P2P.

Drummond: No.

JoeAndrieu: If you are offline, how do we deal w/ revocation?

manu: If you are offline, you can't check revocation.

Drummond: IBM has a whole offline driver's license use case and system they deployed a while ago.

Ned: There is a lot of assumptions/trust baked into current systems.

Joe: Thank you for the feedback, we'll polish that up.

Planning for Tomorrow

Matt: This is the plan, is it the right plan?

Burn: Is this the right framing?

Dmitri: I heard no test suite?

Burn: I said that's a last resort if we can't figure out the test suite.

Matt: We have MIME Type discussion.

Ken: Let's bring up MIME Type in first open block

Matt: Could we shrink some of these items down?

Group agrees to have context discussion first, then open issues, then mime type, then test suite

<stonematt> http://www.bar-celoneta.es/

Summary of Action Items

[NEW] ACTION: kaz to talk within the W3C Team about having a CG to manage registries after WG
[NEW] ACTION: kaz to watch the discussion about https://github.com/w3c/w3process/issues/168
[NEW] ACTION: manu volunteers to write JSON-LD proofs section
[NEW] ACTION: oliver volunteers to write JSON+JWT and JSON-LD+JWT sections
 

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/03/04 17:18:53 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/rragent, draft minutes//
Succeeded: s/introductions/introductions, sponsors, space, etc./
FAILED: i/Dan prvides/scribenick: manu
Succeeded: i/Dan provides/topic: Logistics and Introductions
Succeeded: s/Transendex/TranSendX/
Succeeded: s/pan <something>/panspermia/
Succeeded: s/targrade/tardigrade/
Succeeded: s/... most/burn: most/
Succeeded: s/DIDWG/... DIDWG/
Succeeded: s/charter extension/just a clarification question. charter extension today/
FAILED: s/next phase and future are in rechartering topics?/next phase and future on Tuesday is rechartering. right?/
Succeeded: s/extended for/extended for 6/
Succeeded: s/they finished/they're finalizing/
Succeeded: s/worked on/working on/
Succeeded: s/topic/Topic/
Succeeded: s/party/partly/
Succeeded: s/though/thought/
Succeeded: s/olliver/oliver/
FAILED: s/dimitiz/dmitriz/
Succeeded: s/dimitriz/dmitriz/
Succeeded: s/basic process requirement/basic process requirement for CR transition/
Succeeded: i/jonnycrunch:/burn: the current test suite corresponds to the spec nicely
Succeeded: s/???/Jesus/
FAILED: s/???/Jesus /
Succeeded: i/burn:/kaz: for CR transition, W3C WGs are encouraged to identify some of the features within specs as "features at risk" (which might be difficult to get implemented), and I thought this spreadsheet lists those "features at risk" within the Verifiable Credentials Data Model spec.
Succeeded: s/our test suite is the list./this spreadsheet lists "features at risk"./
Succeeded: s/w-//
Succeeded: s/about registry evergreen approach/about evergreen approach including registry as a possible use case/
Succeeded: s/another issue about registries/another issue about registry itself/
Succeeded: s/JoeAndrie:/JoeAndrieu:/
Succeeded: s/:w//
Present: Adrian_Gropper Andrei_Sambbra Brent_Zundel Dmitri_Zagidulin Ganesh_Annan Kaz_Ashimura Manu_Sporny rhiaro Matt_Stone Ken_Ebert Andrew_Hughes oliver_terbu
Found Scribe: manu
Inferring ScribeNick: manu
Found Scribe: brent
Inferring ScribeNick: brent
Found ScribeNick: ken
Found ScribeNick: rhiaro
Found Scribe: manu
Inferring ScribeNick: manu
Scribes: manu, brent
ScribeNicks: manu, brent, ken, rhiaro
Agenda: https://docs.google.com/presentation/d/1_AKEYKWqaiMIUb6tlo3yVONTl9Z-71H4XfdTtgUF88U/edit

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: kaz manu oliver volunteers

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]