<manu> scribe: manu
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
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 -
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.
<kaz> [break till 12:30]
<ken> scribenick: ken
stonematt: Let's get started
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
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.
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.
<kaz> [break till 5pm]
<manu> scribe: manu
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.
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/
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]