<stonematt> good morning!
<nage> scribenick: nage
<stonematt> Slide deck
<stonematt> Agenda
<stonematt> IRC and Scribes
The logistics page will be updated with dinner plans and other details as they are decided.
Please volunteer for a scribe assignment
burn: we do abide by the W3C
Patent policy
... we care a lot about the substantive contributions with
respect to this policy
... if you are trying to influence the direction of the
specification you must have agreed to the patent policy
... also a reminder on the code of conduct, it says a lot of
important things
... lets now go around the room and do quick
introductions
... please share name, which organization you represent, and
what do you like best about traveling and what do you like
least
... Dan from ConsenSys, there is always something cool about
every place I have ever been
... but after a while I just don't care and want to go back
home
stonematt: I am Matt Stone,
co-chair of the group currently an invited expert
... favorite thing food or perhaps the thrill of the unknown,
but the unknown is sometimes too much
BrentZ: Brent Zundel of Evernym, favorite thing catching up movies
nage: Nathan George of the Sovrin Foundation
<manu> nage: Nathan George, from Sovrin Foundation, least favorite is trying to sleep on airplanes, favorite is seeing new things in different locations around the world.
ken: Ken Ebert of the Sovrin Foundation, loves meeting people
Allen: Allen Brown Invited Expert
jeff: Jeff Jaffe of W3C
... least favorite finding kosher food
tzviya: Tzviya of Wiley
gannan: Ganesh Annan of Digital Bazaar, experiencing food/music, least favorite sleep issues around the travel
manu: Manu of Digital Bazaar, least favorite time zones, really enjoys the subtile differences between cultures (like the traffic barrels are black and orange, not white and orange)
dlongley: David Longley of Digital Bazaar
Dmitry Z of Digital Bazaar
DavidC: ..
sangrae: ....
jay: of NTT
... enjoys jogging
Tony: of Microsoft, just observing. Likes the mass transit
duga: Brady
resplin: Richard Esplin of Evernym
Joe: Joe Andrieu of Legendary
Requirements
... likes the interesting details of how people interact
burn: looking for a rough count
of who will be joining us for a group dinner this evening
... about 12
... invitation to figure it out
stonematt: a bit of level setting
as we get into the meeting the next two days, we will review
how we got started
... we got started because there is no standard way for
official bodies or individuals to issue a claim about a person
or another company that can be verified by a third party
... that is privacy protecting or usable by a third party for
the verification phase
... so we are making a machine readable mechanism to solve that
problem
... the charter specifies that education is our focus, when we
launched participation was a driver for that choice
... we also called out web payment and commerce roots regarding
retail use cases and commercial activities
... we are trying to deal that spectrum from college
transcripts to coupons for things like a box of cereal
... we tend to be an informal group in terms of our style, any
time you want to interject please add yourself on the queue in
IRC (q+)
... so the scope of this work is pretty narrowly defined
focused on the data model
... we are not trying to build an API or a protocol, we are
very careful to keep the work in front of us focused on
modeling the wide variety of credential and claim data
... so what do we mean?
... the key thing we are trying to enable is for one party to
express a statement as a fact about another party
... it may be a fact, it may not be
... we do not represent if something is true or whether it is
believed
... we can make a claim, we know who it came from, it can't be
tampered with and it has some provenance
... we want the holding party to be able to collect those
claims and combine them together for the purposes they have to
share information about themselves
... and present them to a body to be verified
tony: can you clarify "verify", it can mean the statement came from someone or checking the actual fact
stonematt: one is that the
issuing party and the holder are knowable
... second that cryptographically-speaking it has not been
tampered with
tony: so a claim is still in doubt
stonematt: yes
<tzviya> The process that cryptographically demonstrates the authenticity of a verifiable credential or a verifiable presentation.
tzviya: there is a definition in the document (see above)
JoeAndrieu: So the ability to revoke also means "and they still stand by it"
burn: thank you for that question, it is one of the key points
stonematt: there are links for
reference in the slide deck
... these links take you to the resources introducing the
work
... last year for TPAC Digital Bazaar put together a demo of a
polyfill demonstrating how this might work in the
marketplace
<tzviya> https://w3c.github.io/vc-data-model/#terminology
stonematt: the theme of the
agenda is that we are coming to the end of our work and trying
to close down
... we will spend quite a bit of time doing updates
... we have joint sessions with the web commerce group
... and other work that is adjacent to us to help us go to the
next level of a protocol and ecosystem
... there are background discussions around threat model and
trust model
... and a test suite update from gannan
... tomorrow is more of a roll-up-your-sleeves working
session
... we have a set of issues that will be helped by our
face-to-face presence
... To that point, since there are some open sessions there is
a call for "open topics" in the master deck
... there is a list of issues in github that must be
addressed
... if there is something pressing that we want to ensure that
we cover please raise a hand or throw it in IRC
burn: We had "getting to
candidate recommendation" in the deck last year.
... we need to get there
burn: there is a lot on the
technical report progression process slide
... there are a number of working drafts
... one or more candidate recs
... all the real serious dev work is supposed to be part of the
working drafts
... it should be functionally complete, and then you are
looking for implementation experience
... you cannot leave CR until you have reports from
implementers
... demonstrating they have implemented the features of the
specification
... you want at least two independent implementations of the
specification to demonstrate that it can be implemented
... a proof that two parties can read the spec and end up with
something that does it the same way
... it does not mean that we will not find bugs to be fixed,
but it does mean that we must quit adding stuff
... once it goes to PR->REC it is pretty much out of our
hands
... any questions on that?
DavidC: You said it is functionally complete, but then call out "not warned about"
burn: the way it works, you must
do another candidate or working draft if you have made a
substantive change that you haven't warned about
... for example, if there have not been sufficient
implementation examples
... then if that happens you can remove it without another
candidate
DavidC: we have discussed potential features we might not include in the first go
burn: we mean for things for this
version of the recommendation
... there is a link in the slides where this is described
tony: things that affect the implementations must be called out
burn: yes there are a lot of
nuances to how this process works in practice
... what we need to decide right now is "we're done and we're
not adding new features"
stonematt: an inventory of the
deliverables we are chartered to produce
... we are working on the data model and syntax
... and three notes we must addresss
<dmitriz> *can somebody re-post the link to the slide deck?*
stonematt: we will speak about
the other deliverables in a moment
... this is a review of what is in the data model and
syntax
<dmitriz> *or link to it from the doc in the channel topic*
stonematt: this content came right out of the charter
<dlongley> https://docs.google.com/presentation/d/1uYpGnciqzR3g0cfrWRrhCoHhqV8VyBxPclqz3co3Oq4/edit
stonematt: as far as status goes, we think we are "nearly feature complete"
<dmitriz> *thx!*
stonematt: we have about 40 open
issues in github, 30 have been deferred
... those are the issues we will work from for the next day or
so
... the use case document is nearly complete, but has a lot of
open issues.
... it has not had the same level of review for the deferred
items
... the privacy note will be published as a document, we have a
start on that
... there are discussions with PING on that now
... the implementation guidance has not started yet
JoeAndrieu: A question on deliverables
<Zakim> JoeAndrieu, you wanted to ask about the missing deliverable
JoeAndrieu: we are playing "hot
potato" on the gap analysis
... it is not on the list
... the Use Case Requirements needs a comparison to SAML,
OpenID and u-prove
stonematt: we need some expertise there to help
tony: can you restate which ones
we are concerned with?
... what about idemix?
nage: that isn't specifically called out in the charter, but we are better prepared to call that out in the analysis
stonematt: one of the original discussions is about "why do we need VCs?, SAML does this" so we need to show us how this is different
burn: Here is the note in section 3.1
manu: it says "technologies like U-Prove" so idemix is clearly covered under that statement
resplin: the VCTF was the precursor to the WG, the CCG is still active and has many participants from the WG
stonematt: a note about timing,
we are scheduled to be done in March of 2019
... I'm going to let that sink in for a minute
... especially as we start backing up from that date, there
isn't a lot of time to get through the required phases ahead of
that
... we need to have our first candidate rec this month
... and expect to rev it at least one
... December is a tricky time to do work, so the expectation is
to publish again in January a final
... which is optimistic, but realistically is the schedule we
are on
... there is urgency, because there is a strong interest in
moving onto DID work
... we would like to finish with this focus so we can move on
to the related specs
... Big Audacious goal for TPAC to resolve all outstanding
issues for a CR in November
... resolution is a PR, closure or deferral
... many issues should be able to drop into those buckets
... our meeting focus is to decide, get text done and move on
to the next thing
... what do you think?
manu: it is audacious
<BrentZ> +1 to audacious
ken: what happens if we don't?
burn: that is a discussion that
happens tomorrow where we talk about the charter
... so we need a test suite for implementations
... do to some substantial work from cwebber we now have
one
<dmitriz> *for the curious - the other gap analysis spec requested by Tony is https://hyperledger-fabric.readthedocs.io/en/release-1.2/idemix.html / https://www.zurich.ibm.com/identity_mixer/ *
burn: our focus is "what is
preventing us from calling the spec feature complete?"
... the two big topics are terms of use and zkp alignment
... if there is something else we need to know
... we are going to call a feature freeze on Tuesday November
6
<Zakim> JoeAndrieu, you wanted to ask about use case timing
burn: if there is something that is critical to work out, let us know
JoeAndrieu: I have a question about use cases, that doesn't get wrapped up in this time does it?
burn: the march deadline applies,
but not the others
... so your deadline is Jan
DavidC: the whole issue of schema
and the verifier knowing "what should I have?"
... I think that should be in that big issues list
burn: would you add that to the list of open topics for discussion
(slide 14)
burn: thank you
Lionel_Wolberger: are there any
place to talk about throughput and bandwidth
... like the quantity of data in a credential?
burn: that sounds like a performance requirement, that would belong in implementation guidance
<Zakim> tzviya, you wanted to mention spec process
<tzviya> https://lists.w3.org/Archives/Public/spec-prod/2018OctDec/0011.html
tzviya: there was a session
yesterday about spec editing processes
... the people among the best spec editors talked about best
practices
... it is worth running through these practices
<Zakim> manu, you wanted to share numbers
manu: back to performance, there are numbers we can share, and currently it isn't really a concern
burn: The other item to address
here is what we need for implementation reports and so on
... we will be looking for implementations, and fair to
ask
... at this point who will have an implementation "in some time
frame"
... will that be within six months? (hands raised)
... sooner is better, but that is a good start to give us an
idea
manu: cwebber has done the test suite, it isn't hard to do an implementation
burn: because the goal is to demonstrate the spec is implementable it isn't about a high performance commercial solution
manu: so people are wondering
about state of adoption
... so we have tried to identify things by market
vertical
... we have got education
... these orgs have already deployed or are in the process of
deploying
... note that the decks are member confidential
... some are public but some are not
... publishing is working on things
tzviya: there are a number of use
cases that fit very well in publishing like author
identification
... for now it is very experimental
manu: we would like to engage
better with many of these groups, like publishing
... after PR at some point we need to engage more heavily
... we are very thankful that tzviya is here
... there is a lot of interest in financial services
... lots of organizations looking for ways to register who is
transacting and in many cases issuing credentials
<Zakim> nage, you wanted to talk about where cases came from
manu: this information came from
responses from the surveys
... so it isn't a "we heard" it is a "I know"
... we would like additions and to have this be a living
document
... if there is anything else, we'd love to add it
... lots of things going on for workforce credentials
... shifting gears radically the trade and logistics
credentials are being issued
... some are very interested in POCs, most are actually
implementing as per the specification
... we have good examples of folks picking up the spec and just
using it to move products
... there are probably 10 other large organizations in the
trade and logistics areas, but these are the ones we could
specifically identify
... Decentralized Identity Foundation members are in general
supporting this specification
burn: any questions or comments before we go on break?
stonematt: will we get an implementation report from any of these companies?
manu: no
... this is probably the only time we will see them until there
is a DID WG or similar
karen: has there been discussion besides these one-on-one? what about public promotion of what this means or whitepapers?
manu: as this group, I think that is a question for the chairs, we haven't talked about it yet
stonematt: we are getting into a phase where we are asking for implementations, so at or near CR we can start to turn the volume up on these things
karen: the communications director can help do more outreach for it
burn: in early days customer releases went out for all kinds of things, we are curious about expectations
karen: there are other means to get the word out
manu: one thing we should do is to make sure there is a mention of the W3C Verifiable Credentials in press releases and supporting whitepapers and implementations about them being free standards
burn: as anyone is aware of a press release using this technology, please help the rest of us become aware of it
tzviya: I'm brining experience
from other working groups, people don't know W3C is working on
"the blockchain"
... please help folks know what verifiable claims mean
... there were talks about DID, but it wasn't strongly
associated with VCs
... I copied a lot of material from Kaliya, but we would like
to share how much new stuff is going on here
<stonematt> +1 to tzviya comment about sharing our work
tzviya: do not assume those who already know are the only ones interested
dmitriz: question about press releases and so on, is there a place on our page where we can list these things?
burn: discussing our website, there will be notice-able changes to make it more friendly, like a place for these releases
tony: I heard there is some
relationship between VCs and DIDs
... do you see that there would be a pre-requisite for VCs
between DIDs
dmitriz: I would like to give my
personal opinion on this
... we are making claims and need identifiers, which are
effectively links
... but because of these new technologies and blockchains, we
must link into these new networks
... which is a technology that can point to stuff on these
chains
tony: I was thinking the opposite
way
... of dids requiring VCs
dlongley: no
DavidC: our implementation of VCs did not use dids, we used the raw key
<manu> nage: If you are the issuer, you need to know all the pieces are the same... DIDs have different properties there.
<BrentZ> nage: another thing we need to be careful of, is that the credential is a signature on something that is collectively immutable. Blockchain isn't necessarily the key.
ChristopherA: in order to take
advantage of new forms of crypto that do anti-correlation,
blinding and other properties, we don't have approaches for
giving that extra information with a standard URI or bearer
public key
... so if your use cases don't need those guarantees other
types of identifiers may work
... but if you want these advanced things, you end up
re-inventing DIDs
<Zakim> manu, you wanted to say that VCs are identifier agnostic
manu: VCs are identifier
agnostic, they don't really care, but as mentioned you get
additional benefits
... we do have folks using URLs and URNs, which is a legitimate
way to use the spec
... if you combine VCs with them you get some benefits, but
they are not dependent
stonematt: we have a break scheduled and need to start for a join session
<dmitriz> I wonder if it makes sense to add a brief section to the VC spec addressing this. (the relationship between DIDs and VCs)
burn: break now, we will be back
in Roseraie 3, level 3 at 10:15
... joining the web commerce interest group
manu: for those who are new, this is a good intro to the group that is building around VCs
<DavidC> I will be scribe now
<DavidC> scribenick: DavidC
JoeA: asked are the 6 domains
presented the correct ones?
... These are: Education, Retail, Finance, Healthcare, Prof
Creds, Legal Identity
... What about publishing?
Manu: wants to underscore that we
have lots of examples. Should we cut some out.
... refugee use case has caused problems with some people
taking the use cases back to their companies
... lets not use emotionally charged use cases
JoeA: refugee use case is very big (too big) so should replace it with simpler one(s)
chaals: should add a Note - please delete use cases not applicable to you
JoeA: we need to go through domains and conceptualise them
ChristopherA: issues related to
refugee case are common to nations as well, such as control
over identity
... there is a super category of cross domains
resplin: new domains are supply chain security and web of trust
JoeA: Q1 are these the most
relevant domains?
... since they all take time, lets focus on the most important
ones as we dont have time to do them all
?: Can insurance use case go under finance. Can we remove healthcare
<Zakim> kimhd, you wanted to ask about C1-3
JoeA: bad issuer occurs in every domain so we can move this to a remaining domain
<Zakim> manu, you wanted to remove H4, E2, add Digital Offer to Retail, add Intellectual Property, F4
Manu: suggest dropping H.4 and E.2
stonematt: I like E.2
JoeA: we can merge E.2 and E.4
tzviya: digital offers use case is not there yet
JoeA: what is the best example of proof of age for our audience?
ChristopherA: Business licensing is needed use case
<gannan_> s/??/BrentZ/
JoeA: to reach success we want them all on one page, then appendice to most important ones in detail
<Zakim> tzviya, you wanted to point out that disability should not be healthcare but legal
ChristopherA: use case should be clear and focussed without a lot of extra baggage that distracts readers
tzviya: H.5 (disability) should be under Legal Identity
xy: can the key features of each use case be in the summaries and the powerpoint
JoeA: the use cases do say what their key features are, but not in the summary
ganesh??: suggested marking each use case with each feature it demonstrates. Then we might see that some use cases
... can be removed because all their features have already been covered in other ones
stonematt: went on about
currating credentials and what it meant
... collecting credentials together and then presenting
them
JoeA: C.7 and Web of trust are surely not both about issue 31
DavidC: why don't we list the
features that we want the use cases to cover, then show which
features are covered in which use cases
... then we can remove some use cases that simply duplicate
what other ones do
<stonematt> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22W3C+TPAC+2018%22
<burn> scribenick: BrentZ
manu: one of the big things is that Sovrin/Evernym can slot into the ecosystem
<nage> nage: we have a time slot of the ZKP topics tomorrow with details on what is happening there
manu: PING review happens tomorrow, also Claim vs Subject
<nage> manu: default namespace url is an ask to host a namespace context at w3c
manu: JSON-LD context at w3c,
chairs need to request the url from w3c. The group should
commit to something
... #204 delegated authorization & VC distribution (this
may not mean terms & conditions)
... #93 implementation guidance about JWT/JOSE stuff.
... clarification, anything in the issues list that has "W3C
TPAC 2018" and "defer" is a proposal to defer
... anything with just defer will be dropped (and they
must/should be willing to do the work).
... anything with just defer will be dropped (and they
must/should be willing to do the work).
nage: JSON Schema is possibly very important to using zkps
<stonematt> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3A%22W3C+TPAC+2018%22+label%3Adefer+
nage: the implementation protocol
we have now requires this, it is in use. So if it is deferred
to V2, we can't use V1.
... I also have concerns on #203
ChristopherA: there were concerns on that in the JSON LD group
stonematt: which do you object to deferring?
JoeA: what is the difference between 128 and 129?
manu: one is "what is JSON schema
for a drivers license" the other is "what is a JSON schema for
a VC?"
... JSON schema for VC doesn't need to be in the spec, there is
conformance data in the spec. That is number 128.
... 129 is credential specific JSON schema.
ChristopherA: JoeA and I are happy to defer #32, bootstrapping.
many people are talking
#32 has been deferred
manu: I would imagine DavidC
wants to discuss delegation (it is already marked blocker and
on the queue for discussion.
... #128, 129, and 203 are all up for discussion, we don't want
to defer them.
... If we're actually going to create something lasting, we
need to have a generalized solution (128).
nage: for zkp it needs to map down to types, they need an encoding
manu: is it possible to put all of that in the proof?
nage: that may make serialization really difficult, it could potentially conflict
JoeA: can't we use a property that points to a self-describing resource instead of using a JSON Schema?
manu: we already use that for many things
<ClareNelson> WebEx sound just dropped
dmitryz: we're trying to solve
this in JSON-LD so that we can link to a JSON schema by adding
the vocabulary.
... could we put it in the implementation doc?
ChristopherA: I don't know if we can put that in the spec.
DavidC: I had a discussion with
Jan Camenisch. He said it doesn't really matter what the VC is,
because the verifier never gets it.
... so why does the structure of the VC matter?
<ClareNelson> All sound dropped, will call in again
burn: let's follow queue discipline, the scribe can't keep up :)
nage: when you do predicates and zkp, you still need agreement on the types so the verifier can undetstand what he needs.
manu: I would argue that is more of a proof question than a VC question.
burn: what we really need to plan for is
phone: BEEP BEEP BEEP
<stonematt> calling back in
nage: I believe we will need some sort of schema thing for zkp
manu: we will include that in the zkp discussion we already are planning
burn: I missed the plan, but if you caught it, good
manu: There are others who care deeply about this. it may be implementation guidance that covers it, so it is not deferred.
stonematt: I will make that a part of the issues.
burn: any more defers?
manu: DavidC and nage have expressed concerns about 203.
DavidC: I'm happy to defer it, because there isd tension and I thing it may be mutually exclusive.
nage: there's a couple of peices that relate to our use of idemix and uprove. my issue is we haven't written the implementation guide or the gap comparison, so we still need to do thins
<ClareNelson> sound is back
manu: one of the verification steps is: is this presentation of a credential that was issued to the holder. holder == subject optional parameter.
JoeA: is that a thing for all use cases? this is in the terms of use anyway.
nage: what 203 is, can the VC be transferrable. can only the holder present it?
JoeA: a person I'm travelling with credential
nage: that could be re-used.
manu: I think we have this addressed at some layer so that JoeA's concern doesn't happen. It may be through terms of use.
JoeA: I don't think it is solveabkle in the general case. it is only in specific uses.
DavidC: there is that tension where the subject is in control. if there is a restriction, where is the freedom . I don;t know the resolution for that bit
<Zakim> JoeA, you wanted to say its about holder and secondary presentation, which is a new holder
nage: when we fixate on the subject, we're focusing wrong. If we lose the sematic meaning of the keys, we lose the value of a VC. when we don't address if it is transferrable, the majority use case goes away. the verifier needs confidence that the holder is the one who received the credential.
<burn_host> btw Clare, we are looking at this list: https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22W3C+TPAC+2018%22+label%3A%22defer%22
JoeA: subject doesn't matter,
holder's [resentation does matter. There is also the problem of
a Verifier passing on the original presentation.
... this is what matters.
dmitry: is this not a business rules issue? The airline checks to make sure the credential was issued to the right person and they are using it.
<Zakim> stonematt, you wanted to say should we remove "verifier" from this issue?
<dlongley> certain capabilities are "baked in" at signing time
nage: the V=VC presentation shouldn't be passed on-able
stonematt: is there a proposal
<Zakim> manu, you wanted to say we're talking past each other.
JoeA: the lie is in the presentation, not the holding.
manu: we have too many
conversations. this is not what you think it means.
... I think we need to actually understand what we're talking
about. the title is misleading.
burn: this is going to require discussion, plus reading and proposal time. Matt, are you willing to look at the agenda and pick a time we might discuss this?
stonematt: I will
burn: otherwise, we've discussed
all the defer issues.
... would manu's suggestion be to look at the blockers?
manu: yes
stonematt: if the titles are misleading, how do we fix that?
JoeA: they're not
<burn_host> Clare we are now looking at https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22W3C+TPAC+2018%22+label%3Ablocker
<ClareNelson> thank you
manu: I think we could knock off
#248.
... people might want a simple description of their credential.
can we add "summary" to the standard vocabulary?
proposal is to add a human-readable summary to the credential
<dmitriz> +1 from me to what ChristopherA is saying.
ChristopherA: the issuer is the one who creates the VC. when I hear about the use case, this is making it readable for the holder. In that sense I'm fine. When it goes to the verifier, they may not be able to use it. There is a semantic meaning that isn't tranferrable to the verifier.
<Zakim> nage, you wanted to talk about how this hurts selective disclosure (think PII in medical records)
<Zakim> stonematt, you wanted to say is this a wallet feature?
nage: when your're doing selective disclosure, you can't know what's in it. It really only has utility from the issuer to the holder.
<dmitriz> manu: why isn't 'virginia driver's license' appropriate in the claim?
stonematt: I had two opinions. If it is for the holder, seems like a wallet feature. if it is issuer control, they can just put it in the credential as a claim.
<Zakim> manu, you wanted to say "How do we do Virginia Driver's License"
stonematt: either we don't care or we can already do this
manu: can we put "Title" on the
top of the credential. but then the wallets have to read the
attributes and figure out what the name might be.
... we could have a summary.
ChristopherA: this should be in
the protocol, no opposition to that. my problem is VC are to be
shared and anything extra we put in that can't be verified
shouldn't be in there. This should be guidance for the
implementation of the protocol.
... so don't put it in there.
DavidC: I'm repeating. this is a GUI/wallet issue. If we want a title, add a title field, but then the Holder can't change it because if it is in the credential it is signed.
burn: closed the queue.
<dlongley> i'll just type -- the ability to edit a description has nothing to do with its original existence (or lack thereof)
<Zakim> nage, you wanted to ask isn't that a driver's license semantics issue not a general VC issue -- the types are for that
stonematt: I still think it is the issuer's discretion. adding a type foield is a minor field.
<dlongley> you just would have to store the user description separately
<Zakim> manu, you wanted to note that as a wallet developer, this sounds like a very difficult thing to not have.
nage: the types are for machine processing. so if it for the holder, that should be a claim.
<nage> +1 to the fact we _are_ developing wallets (yes, yes we are)
<dlongley> it's less of a nightmare from specialized code -- it's more a nightmare for authors who won't provide this information if there's no easy way to do it ... and then there's nothing for a wallet to work off of
manu: we are developing multiple wallets. not having this feature may be a nightmare. Not having a type for this sounds like a nightmare.
<stonematt> this is not "Type" (capital T)
manu: just because it is in the credential, doesn't mean the holder can't give it an alias in the wallet.
burn: one minute open queue. I don't want to give up the break.
JoeA: this is a bigger issue. We can't do it in V1.
<Zakim> manu, you wanted to respond to christophera
ChristopherA: it can't be in the credential because of other things that need to be presented to the Holder. this confuses what should go in the claims in other cases
manu: we are suggesting that the summary/title field should be in the claim envelope
stonematt: this issue is not talking about type. we keep talking about some machine readable thing, but this is for the issuer to give the holder.
<Zakim> dlongley, you wanted to mention tension between usability and security
nage: the issue I have it: if we provide a description field that describes the credential, the holder may not look at the actual credential to check. If we have a way to automate the machine readable part, we should.
<nage> no issue with additional hints, but the UX must emphasize the verifiable parts or we get them in trouble
dlongley: this is the machine
readable/holder tension security vs. ease of use.
... the issue is complicated. we have to make some trade offs
and determine the consequences.
<Zakim> manu, you wanted to propose a resolution.
burn: queue is open for next-step suggestions
manu: resolution - defer
all I heard voted +1
<ken> +1
<manu> PROPOSAL: Defer credential titles/summaries until v2.
<nage> +1
<manu> +1
<ClareNelson> +1
<ken> +1
<gannan_> +1
<burn> +1
<BrentZ> +1
<dlongley> +0
<DavidC> +1
RESOLUTION: Defer credential titles/summaries until v2.
<stonematt> +1
burn: we ar eon break until the
hour.
... we are on break until the hour.
... we are a half hour late. shoot.
<stonematt> scribenick: stonematt
BrentZ: proxy/partner with
ClareNelson who's on the line
... what to do to prepare for security review
DavidC: should we do threat model before trust?
BrentZ: recap trust model as it's
in the spec now
... reviewing slide
BrentZ: transmission related
trust issues seem more protocol related.
... objections?
DavidC: this doesn't look like the current trust model
manu: this is what's in the DM trust model
<burn> still on slide 47
DavidC: yes, but I edited it since then
<ClareNelson> yes, pulled this from the Data Model document
BrentZ: some content added
<DavidC> DM states The subject trusts the issuer to issue true
ClareNelson: this came from the DM. there were a comments on this slide. I made a change that's no longer here "holder expects verifier not to compromise subject of holder"
<DavidC> Slides states The holder and the verifier trust the issuer to issue true
<BrentZ> could we add the word "verifier" to the trust model? i.e.: "he holder and the verifier trust the issuer to issue true (i.e., not false) credentials about the subject, and to revoke them quickly when appropriate."
<BrentZ> could we add the word "verifier" to the trust model? i.e.: "The holder and the verifier trust the issuer to issue true (i.e., not false) credentials about the subject, and to revoke them quickly when appropriate."
the DM doc has been updated. new text is here:
<dlongley> One way to put it, BrentZ is: Either the proof is in the VC itself or it is outside of it (via some protocol).
https://w3c.github.io/vc-data-model/#trust-model
ChristopherA: would like to update this slide from the current model
<DavidC> I suggest that DM changes to The subject, holder and the verifier trust the issuer to issue true
https://w3c.github.io/vc-data-model/#trust-model
JoeA: what's the ask for the converstation?
BrentZ: a review of the trust
model so we're all on the same page
... reviews next slide
... want a volunteer to scribe on the whiteboard
manu: I can
... review next 49
BrentZ: big one is the last one,
"An attacker steals the VC wallet and uses the VCs"
... review Focal use case re: International Travel with Minor
and Upgrade
<Zakim> cwebber, you wanted to distinguish between trust that claim has been made vs trust that the claim is true
<JoeA> https://w3c.github.io/vc-use-cases/
BrentZ: reviews credentials required for the use case and what they establish
<burn> on slide 52
BrentZ: reviews threats in the Focal Use Case
<dmitriz> *where do these particular names / use cases come from?*
<dmitriz> *it's not super thrilling that we're talking about potential spousal abuse etc situations*
<dmitriz> *stonematt: I see :( *
<dmitriz> *burn: no prob. thanks for the heads up tho.*
<dmitriz> *burn: no, I'm fine with them being minuted. (good to know that /me doesn't get minuted tho.)
ChristopherA: I have 24
adversaries that we've used. how far do we want to go?
... I could come up with a long list.
I would like to have that analysis so we can make a stronger case for this technology
ChristopherA: I can share the paper privately
DavidC: this isn't a complete list. and this is the objective of the time
BrentZ: let's review the next slide of existing slides and discuss other threats
burn: timecheck
BrentZ: time box to identify missing threats 10min
ChristopherA: I have an
adversarial analysis that we can discuss.
... some of these may not be applicable to VC
... ticket agent is assisting fraudulent upgrade
<Zakim> cwebber, you wanted to distinguish between trust that claim has been made vs trust that the claim is true
<cwebber2> http://world.std.com/~cme/trust.htm
cwebber2: 2 trust issues 1) is the person saying the thing is the person in question 2) the thing being said is true
JoeA: please stay focused on this use case
<JoeA> cool
some of the threats are beyond the scope of the technology. just to identity which issues we can and can't address
BrentZ: what are the threats, what can we address
ChristopherA: I'm interested in coercion and consent threats
<cwebber2> I do not agree with that at all
<cwebber2> that issuers always make true statements
DavidC: looking at original threat model
<cwebber2> we should document threats we can't address because otherwise people will think we can
<cwebber2> +1 to JoeA
DavidC: we shouldn't document threats that we can't address
JoeA: no, we're trying to ID threats that we can and can't, so we can describe the ones that we don't or can't address
<cwebber2> I'd even go so far as to say explicitly that our trust model allows issuers to make false statements
JoeA: trust model allows the
issuers to make a false threat
... we cannot trust that the issuer will not share the data
<cwebber2> +1 we can't stop delegation from a system level and shouldn't claim we do
ChristopherA: what happens when there's a system failure? denial of service
<Zakim> manu, you wanted to note infineon, heartbleed...
manu: chip failure
ChristopherA: systemic key compromise
DavidC: implementation
failure
... bugs and intentional, like backdoors
ChristopherA: man in the middle?
BrentZ: Front Running, person
using VC as a token that can be redeemed, verifier rejects
token and keeps it for themself
... what direction from here?
JoeA: 10 min turning the generic threats into something specific to threats for this use case
DavidC: I thought we were going to work on threat model in the DM doc, not UC doc.
JoeA: TAG suggest WG to include reasoning for decisions in the DM
ChristopherA: use slide 50 to document where consent is required and coercion is possible
<manu> stonematt: to that point - in order to do that, let's highlight things in the data model that need more nuanced text around it - these are the 10 decisions, with long discussions, someone go and justify those and then assign them. Let's do consent now.
BrentZ: would like 5m to do assignments at the end.
<hadleybeeman> Re the TAG's plea for explanations... We have a format for an explainer that may be useful to you. https://github.com/w3ctag/w3ctag.github.io/blob/master/explainers.md
BrentZ: consent points: Rajesh
Permission
... Malathi consents to upgrade
... agent consents to accept payment
... malathi consents to ticket her child
... child is consenting to travel with parent
... agent/TSA consent to accept presentation and allow
travel
... issuers consent to continued use of credential (not
revoked)
... one of the party is a bad actor and wants to blow up the
plane
... airline consents to pull away from gate and take off
... at what point are they bigger that we need to discuss
(before we document "meteor hits the plane")
dlongley: when we hit the line that there isn't magic fairy dust
ChristopherA: discuss up to point that aggregation of claims are or could be an issue
JoeA: financial impact - probabilistic cost. no one spends money on stopping a meteor-we can ignore it
ken: is the a priority issue
JoeA: editorial decisions will help that
manu: Datamodel content, or Use content content?
BrentZ: both - DM to discuss why certain decisions were made
DavidC: add section of DM that highlight these issues. relates to trust model
manu: will have to be careful
about to document details about things that we don't cover and
what it means
... threat model docs can be gigantic
DavidC: maybe a separate doument
JoeA: maybe identify examples of threats that we want to document
manu: point from DM to threat model in UC doc
BrentZ: who want to document these threats?
DavidC: I can volunteer time to address the threats in the DM and point to the UC
ClareNelson: I can also help with
future work
... security reviewer may ask what we might have missed? this
discussion shows that we did the best job we could
... to identify the threats
<burn> that we made a serious attempt to consider threats
BrentZ: threat model could inform implementation guideline
manu: I'll make the issues in github
<manu> Add threat model to use cases: https://github.com/w3c/vc-use-cases/issues/90
<dlongley> another threat: user confusion, for example, malathi is issued a ticket that she misunderstands (or that intentionally misleads her) and she winds up in the wrong country... probably a few more in that category
manu: assigned DavidC and ClareNelson to GitHub issue 90
BrentZ: this was DavidC and ClareNelson - I'm just a voice today
<manu> And complimentary issue in vc-data-model: https://github.com/w3c/vc-data-model/issues/251
<ClareNelson> ok
cwebber2: reviewing slides
... there are a lot of requirements to test
... identified some that aren't "MUST"
... reminder that tallTed says data model, not protocol
... reminder verification process is flexible, different
proofs, etc.
... 28 of 31 tests in the suite work, some include
sub-test
... Javascript version is working for all but 3
gannan: here's the demo
cwebber2: more review
gannan: more demo
cwebber2: reviews reporting
... expects Greg to ask for EARL and plan to add it
... many tests can be written as JSON,
... if you want to contribute and know python, I can run python
in line
<nage> I don't know of anyone in the Indy/Sovrin community who is a racket native, we will probably have to get help on the python thing
cwebber2 are you there?
we can't hear you. we'll reconnect
<ClareNelson> bye, I'll call in tomorrow after your lunch
<ClareNelson> WebEx just kicked me off
manu: what about the 2 failing tests, do you have a handle on them. are there other tests that need to be added
cwebber2: key must not be revoked
or expired needs revocation service. need to add
expiration
... need a little more code
... last is trickiest
... none of the other tests involve profiles and aren't setup
to work with profiles yet
... will deal with it after TPAC
... haven't considered missing tests yet
... need a volunteer to help
<resplin> scribenick: resplin
Getting set up, making greetings, and reviewing the agenda.
<manu> Meeting: Verifiable Claims Working Group Meeting (W3C TPAC F2F)
[Conversation about non-dialog in the meeting minutes]
burn: Welcome and thank you to
everyone who is ontime
... Matt will be joining later.
... We swapped ZKP and terms of use timing in the agenda. We do
have a PING meeting at 11:30, and their input matters a lot for
this work.
... We received a lot of challenges on privacy and security
grounds, mainly privacy.
... In the end they will have to sign off on this or it won't go
anywhere.
... We need to have a discussion about rechartering as we think
about our plan going forward and completing the specifications we
have and if we want to pursue potential work going forward.
... Near the end of the day we will discuss the interesting topic
of JWT and JSON-LD
... The rest of the time we will continue to work through issues,
focusing on the ones that are blockers. Manu will prioritize as
editor.
Moving on to Brent's slides
brentz: Agenda for today: briefly
recap Zero Knowledge Proofs and why we care about them for our use
cases.
... Will discuss outstanding pull requests and changes I am
proposing to make them palitable.
... A zero knowledge proof is any proof that has three
properties:
... Completeness: people can be convinced it is true if it comes
from an honest prover
... Soundness: people can't cheat with a false proof
... Zero-knowledgeness: if it is true, the verifier doesn't learn
anything else. That's the kicker: nothing else is leaked.
burn: isn't it also the case that no one else observing can learn anything
brentz: Yes, not just the verifier,
but anyone else too. Any non-verifier can't even learn what the
verifier learned
... if they are videotaping, they still can't prove that they
didn't orchestrate the situation
... Ecosystem: Issuer signs the credential, holder puts it in their
wallet and selectively discloses what claims they want to make.
They pass it on to the verifier
... The proof is not transferable
... Each party has access to a data registry ,an immutable data
store, that they can use to verify the proof.
... This allows a holder of Sovrin credentials to present multiple
credentials without sharing a common identifier, selective
disclosuer of claims, and after presentatino the holder can't send
the proof on in any cryptographically meaningful way
nage: Number 3, the lack of
impersonation, is the most important. You can't transfer the
cryptographic properties. It's not just important because of
anti-correlation
... when you continue to have those cryptographic properties you
have something better than what anti-correlation measures give you
today.
Slide 67
brentz: The issuer of the credential
will have a DID on the ledger, but may also have a pairwise DID for
interaction that isn't on the ledger
... The schema will have a public key to validate the
credential
DavidC: How do you indicate revocation?
brentz: You have a cryptographic
accumulator. Alongside the credential is a revocation credential
that has an index into a list that accumulates the various
values
... If your credential is revoked, your value is removed and you can no longer prove that your value is in the accumulator.
... The verifier doesn't do any of this, it's the holder that gives the non-revokation proof. The verifier can then check it against the accumulator registry.
nage: You only ask the holder for the
credential, and then verify that it hasn't been revoked.
... You only prove the non-revokation at the time of credential
presentation. If the revokation registry changes you don't know if
that user has been revoked or not. You have to ask the holder again
in order to know.
... it is possible to share a secret so that you know it has not
been revoked over time, but that is not the default behavior
burn: As long as no one else makes any changes to the accumulator registry, then the master public file would not change, and you would know that your credential had not been revoked
brentz: That is not correct. That's not what the massive public file does. It is a static file.
dlongley: Does that gigantic file grow in size as you add new credentials?
brentz: You have to reissue the file over time, and there are practical limits. You eventually need to break it up into additional files.
nage: There is a bank of switches, and you can turn them on and off for individual credentials.
ken: The list starts out fairly long so that even if there is only one credential you still can't identify it.
brentz: First pull request: PR-214
Slide 68
brentz: We want to substitute the term "Verifiable Data Registry" for "Identfier Registry"
Slide 69
Slide 70
brentz: This is literally the entire extent of the pull request as it stands now.
manu: Can we just resolve this now? I think it's easy to resolve because this is fine.
The orginial reason we called it an identifier registry is because people complained we weren't being specific enough
manu: That's the only reason. We
wanted to tie it to DIDs. We want to keep the name registry because
it isn't just a binary store.
... +1 to the PR. We could do a formal proposal, or we can just
accept it.
burn: Any objections?
dlongley: No objection, but I wish that we had a better name than schema, which we use to mean 10 different things. But it seems good enough here.
manu: Perhaps we should add a clarifier to the beginning of the word.
brentz: A verifiable credential schema?
burn: back to the question: any objections to accepting PR-214?
No objections
manu: We should bike-shed that one
more time on git hub before pulling it in.
... if we can't figure something out within a week, we will just
pull it in.
brentz: Moving on. PR-217
... This statement from the data model supports some of the changes
being proposed in the PR
Slide 71
brentz: My thinking is that verifiable credentials contain the claims that we are presenting, so we can change the next picture.
slide 72
brentz: Not all cases require an identifier
manu: I agree that "counter-signature" needs to be replaced with "proofs". The presentation identifier is Joe's thing, so he might want to say something about that.
<dlongley> an alternative: https://github.com/w3c/vc-data-model/issues/237#issuecomment-428224637
manu: We need to figure out a way to
express both mechanisms. The image was trying to be more literal
than high level.
... At a high level I agree with the presentation, but in our
implementation we do package up the credentials in the picture.
nage: Our implementation literally does the second picture
manu: Yes, and our does the first picture. We need to figure out a way to show that both are possible.
JoeA: The reason I push for the
presentation identifier is that I have been convinced that it is a
privacy problem.
... I'm still on the fence, but I don't believe it strongly enough
to argue against it
... Sovrin's approach breaks other assumptions that I have, but it
seems valid.
... I don't think it's wrong, but it's different from what I had in
my head.
manu: So you are fine with removing "presentation identitifier". Be clear that it's a random identifier. It's in their because of you Joe. We can remove it, as its just scrubbing some text.
dlongley: This is related to the issue Mike Lodder raised in GitHub issue 237.
See dolngely comment 17 days ago in GitHub issue 237
dlongley: Not all credentials will look the same way
DavidC: I want to draw attention to
figure 5 as well.
... Figure 5 is very similar to the figure we have been
discussing.
... Figure 5 in the stack.
brentz: We will be talking about figure 5 in a couple of slides.
DavidC: OK. I thought we should do figure 5 first because it is implictly included.
dmitriz: The difference between the
two picutres is that the first one has one or more fully formed
verifiable credentials
... The other one has just the claims that are included in the
credential. Correct?
brentz: Yes.
nage: If you include the credential
or imply that the credential can be included without a ZKP is your
mechanism of proof
... If you include the entirety of the credential in the ZKP, you
are including a large amount of information that you do not want to
include. It's the wrong assumption for a zero-knowledge
protocol.
JoeA: I don't see a functional
difference between a presentation and a credential itself.
... a presentation is a credential about other credentials.
... The reason I want a credential ID is to make it easy to make
statements about other credentials. It's not a pattern that is well
flushed out, but there are a lot of use cases where we need it.
<Zakim> manu, you wanted to further elaborate on what dlongley is saying.
JoeA: I think that same architecture of credentials referencing other credentials can apply to your approach, but I don't understand th edetails of how it applies
<dlongley> +1 to joe's comments
nage: I think that works, but we should talk about it.
manu: Getting to a PR: we have cut
out the presentation identifier and agreed that hte signature
should go away and we should have proofs
... The point of contention is "claims" or "verifiable
credential"
... I get your point Nathan that we don't want the default to be
the wrong thing, but that would be such a fundamentally broken
thing that the software on the other side would blow up
... They are not interchangeable data formats
... Yes it's true, but I prefer to say that the presentation is a
bunch of VCs with proofs
... The packaging format as described throughout the specification
is that you have VCs with a set of claims in them. The thing at the
right conflights the presentation with the credential.
That's point one.
DavidC: It seems to me that we do two
separate diagrams becasue they are two separate ways of
behaving.
... we should have a diagram that shows how we behave with ZKPs
and a figure showing how we behave without it. (Back to figure 5)
JoeA: manu's point that it looks like
a VC supports my argument that presentations are just VCs.
... We have the example in the citizen use case where we show a
birth certificate and a marriage certificate showing a name change.
The subject needs a place to show the relationship.
... As a result, we might need to construct a separate verifiable
credential.
<Zakim> nage, you wanted to talk about how ZKPs don't follow that packaging
nage: There is something more to the
data model than that. The semantics of the claims graph in a ZKP is
a composition of the two claims graphs rather than presenting a
single credential
... When you do a composite proof I can fulfill a proof request
using more than one credential. I can disclose that in the
mechanism of proof without disclosing two data graphs.
<Zakim> manu, you wanted to note dlongley's point and to say that perhaps VCs are AFTER all the ZKP stuff happens.
nage: The use case we usually use is three issuers. Issuer 1 stops cooperating with me, so I need to use a composite of the credentials from issuer 2 and 3. The verifier is ok with that because they see it as the same data graph.
manu: Going back to the issue Dave
Longley raised in the issue discussion with Mike Lodder
... One of the unsaid goals of the VC data model is that we expect
every day web developers to work with this
... They will shove the data model through a signature model, and
then use the data directly as long as the signature is valid.
... We may want to look at VCs as the step that happens after all
ZKP processing is done.
... You will get a ZKP style proof in, which is a binary blob of
data (see GitHub issue 237)
... You process it, and what comes out of the processor is the
claim as shown in the issue. That is what the developer cares
about. They way they work with the data is the same.
... The benefits there is that web developers can work with ZKP
style things and non-ZKP style things in the same way. They don't
care about the crypto. The library says "ding" and everything is
good and they move forward.
nage: That is reasonable. As long as we do something about transferrability so that people don't do something stupid because they don't understand the ZKP part.
ChristopherA: Ultimitaly the DID
document should be what the developer wants. Not all the material
we use to create the DID document.
... Like with BTCR there are a lot of steps that in the end the
resolver doesn't need to give to the app. Just the final thing that
has the bag of keys.
... Thsi is a parallel thing. A bunch of magic happens in the
processor, but what you get at the end is something consistent that
you can manage in the app.
... That first graphic has to be replaced. The whole
counter-signature thing is intimitately related to my comment on
the differed issue 32. There si a semantic thing about the
countir-signature that should be a VC about a set of VCs, not a
counter signature that puts semantic information outside of the
claim.
<Zakim> dlongley, you wanted to ask if it's clear that the data is coming from two different issuers (in nathan's example) and if so, how is it the "same" data graph?
ChristopherA: We never properly finished that. Joe and I are in agreement that adding a sigature is not a semantic statement, you have to have a separate VC. But we need to finish going through it.
dlongley: Is the information given to the verifier also include the fact of which statements came from which issuer
nage: This part of the point is
really important for a multi-sourced identity being interoperable.
Because of the usualbilyt of the developer
... The data graph needs to be processed correctly, but there are
crypto implications to calling it the same thing as what was given
up front. I need to be able to say "this is the data graph that I
want" in the proof request
... And the prover will assemble it from how ever many credentials
are needed in order to fulfill the criteria in the proof
request
... Interoperability means that I got my proof request and met
it
... It ruins the usability to have to say where everything came
from
dlongley: I'm in agreement, but we need to be clear about keeping the layers separte.
brentz: Great discussion. It's what I was hoping we could have. Moving forward, I don't thing we'll come to consensus on the right hand picture today. It needs some tweaking
<Zakim> manu, you wanted to try to propose resolution.
brentz: I'll change the picture and we'll have the conversation again
manu: I'll make a proposal that might
move us forward
... Use the image on the right. Replace "claims" with "verifiable
credential" and add a healthy dose of warning text talking about
the nuances when it comes to ZKPs around ensuring privacy like
Nathan said.
nage: Yes, and Dmitry and I should bikeshed calling it a credential presentation to see if there is a better name.
dmitriz: Yes, we should see about tweaking the name "credential presentaiton" "derived credential" to indicate it is a different entity.
manu: That's the sticky point.
<gannan_> (image on the right on slide 72 pertaining to PR-217)
brentz: +1 to Manu's proposal, but we need to think carefully about the name
JoeA: The provenance of the data field matters. If a ZKP only gives the data, but not the source, that's not sufficient.
nage: You always disclose at least one who and one what
JoeA: That should be a note on the slide.
brentz: Let's move forward as we are running out of time
slide 73
brentz: We added some text to the 3.1
claims section
... the point is that the ZKP doesn't have to be a predicate, but
we can derive the predicate.
manu: That looks good
slide 74
manu: It means that if you are doing this, you could get a derived credential. +1 for clarifying that point. The only issue would be editorial
Slide 75
manu: +1
Slide 76
brentz: Continuing the discussion of
whether the pictures reflect the intention of the text
... I thought that if there is an identifier in the proof, it
doesn't need to be in the envelope. If it is in the envelope than
it is just part of the metadata and doesn't need to be called out
in the picture.
manu: The reason there is a
credential identifier is that in the linked data world everything
gets an identifier. I'm fine with removing it, it doesn't remove
the possibility of someone giving it an identifier
... We can suggest that an added identifier would be
correlatable
nage: We need a note about that
manu: +1 to the image on the right
DavidC: Now that he has given the rational, I think it's a very sensible thing to say.
brentz: For PR 217, I'm going to mess
with the presentation pic a bit and add some clarification
text
... The rest of the slides are more principle based. I'm looking
for guidance from people more familiar with the data model. I'm
looking for help on these last ones.
burn: We should allow you to just go through the slides and talk to them.
Slide 77
brentz: Selective disclosure isn't
just something we care about, it should be required. You should
always be able to choose only one item to share. All fields need to
be selectively disclosable.
... I don't know necessarily that the data model allows for
this.
manu: It does. Effectively, everything is optional.
DavidC: Going back to the figure on the presentation: why is the metadata not in the presentation diagram. It is in the credential diagram
manu: I agree
brentz: I agree
Slide 78
brentz: Expiration date and birth
date are fields in the credential. We want to express these dates
as predicates (less than or greater than)
... The ID would be selectively not-disclosed.
manu: Would you be open to "expires after" in relative terms
nage: That's not how it works
manu: I know that's not how it works in the foundation, but when we expose it to developers we probably want to put it in relationship to the expiration date.
JoeA: It's not currently a valid date
nage: You don't want to add new terminology in the data graph. There are a bunch of different predicate proofs that are possible against a single object in the vocabulary.
manu: The alternative is to do a
MongoDB style greater-than style thing. Do you actually want to
expose that to developers? They will need to understand how to
parse all of those predicate proofs.
... All they want is a "has expired" field.
brentz: If we are thinking of the derived credential as its own data graph, is this as much of an issue?
<dmitriz> *So, specifically, instead of expirationDate: '2001-01-01' you have expirationDate: { greaterThan: ..whatever… }*
nage: The proof request itself will have to express the lanugage of "I want a predicate on this request, and this is what itis called"
stonematt: It would be hard to make
an infinite number of fields that represent all of the set checks
that could be done by having a simple greater than operator against
a known entity like "date". I want to evaluate a date against
comparitors.
... I don't need to know what everything is called, I just want to
do the comparison.
nage: I want to say "I'll prove something about my birthdate, but I'm not going to give you my birthdate."
JoeA: I think you are breaking the
data model. I understand why, but it's an anti-pattern
... You are asking for new predicates.
... This notion of Age over 21 years is not expressed well as an
RDF object.
dmitriz: It is
<Zakim> manu, you wanted to note this can be done either way
manu: What is nice about the data
model we picked is that we don't have to agree. I think you are
exposing too much to the developer, but you can do that as a range
proof.
... This is the format of a range proof, and we are done. This
issue is resolved. There is room in the data model to do exactly
this as range proofs. We would say give us an ISO 681 date, and you
would say "give us an expriation date with a range proof"
nage: Yes, I would just ask how to do that with a JSON-LD
manu: We should figure that out off-line.
brentz: The point of this wasn't to
come to a conclusion, but to begin the conversation so you know
where we are coming from.
... We need more than just context, we need a credential registry
with revocation.
... We need to know where these best reside. if they all go into
proofs, then it may make sense for other things to go in proofs
that aren't already there.
Slide 80
brentz: It should be clear that if you are pointing at a context and the context changes then any external reference changes. Any external reference needs to be immutable, so language needs to be added.
burn: If anyone wants to continue discussing these topics, go ahead and put that on the open topics list for the end of the day.
<manu> We should talk about ZKP and COSE
nage: We do have a demo that walks through all of this that we could schedule in a special call if there is interest.
<gannan_> +1 for demo
<kimhd> also +1 for demo
<stonematt> +1 for demo
burn: Please also add that demo to
the open topics list to track what we didn't get to.
... Go David
DavidC: Context: More people understand JSON than JSON-LD. JSON people get confused because there is a massive amount of implicit knowldege that is not in the spec.
Slide 81
slide 82
slide 83
slide 84
DavidC: The orginial transformation
was very clear. I could apply the JSON to the diagram and it made
sense to me.
... But when you move it to the JSON-LD you get a more compact
representation, but you lose the subject. It's gone and replaced
with some random ID.
... Who is the property about? In the previous JSON there was a
piece of text that you could read that says subject.
<Zakim> ChristopherA, you wanted to when David is done
ChristopherA: There are two different
things going on here. You are correct that people won't understand
the graph model. But yesterday this same discussion came up
... about everything in the claim having to be about the subject,
but that isn't precisely true
... CLearly in our own community we are having some of the same
problems. We could potentially solve these problems by changing
"claim" to "subject claim"
... But this same type of problem came up yesterday with you
guys.
dlongley: For people that know JSON,
it doesn't say up there using english letters that there is an
object you are talking about. It uses {}
... Those curly braces are what tell you that you have some object
with these properties. JSON-LD re-uses these concepts.
... The orginial thing up top was removed because it wasn't
idiomatic JSON. I was part of the RDF WG that spent lots of time
discussing this.
... There were concerns about a very rigid format
... It is not composable in the same way that people would
naturally compose idiomatic JSON in their applications. JSON-LD
addresses those concerns. The curly braces contain the information
you are looking for.
<Zakim> nage, you wanted to add something but will probably q- based on what dlongley says
DavidC: You are talking about some objects, but you don't know what those specific objects are.
nage: We all agree that the sementacs
need to be clear. To trust a credential you have to understand what
the issuer meant. But you can't force idiomatic presentation on all
applications.
... Dictating a specific shape to the graph won't buy us what we
need. You need to make a decision about whether you will use a
credential or not.
... We don't need to go too deeply. We could specify as beautifully
as possible, but people will see it as constraining and just ignore
it. It might fit, but it won't work.
<Zakim> manu, you wanted to note that people do have problems w/ JSON-LD.
nage: We make it work by deciding on the semantics and telling what the semantics are when we assign it.
manu: JSON-LD is not an unasailable
technology. It has warts. We had this conversation multiple times
in the RDF WG, and those conversations continue. It's a real
problem, which no one disputes. But I think it is the best thing we
have now. If there is a way to better communicate this stuff to
developers, then we should be doing that.
... For example, subject -> property -> value is an
approximation. The more correct approach was considered confusing
by developers. Everything you see in there is a compormise between
die-hard RDF linked data people and JSON web developers.
... It's hard to find the right balance for that.
... You are making a good point, but what you are proposing (one
slide in . . . ) might cause push back due to historical stuff.
Slide 86
Slide 88
DavidC: You have lost what it is
about
... So you combine the two and you get a property->value
slide 89
slide 90
DavidC: Subject has identifier, in
JSON-LD would become this . . .
... It has become implicit
... The application to VCs is that if we have this graph here then
the traditional JSON will be perfectly understanble.
dlongley: Where did object go at the top? It disappeared?
DavidC: It turned into Claim
dlongley: How did you decide that?
How does someone follow your rules?
... Your original argument was that the rules are implicit, but it
seems like we have the same problem here.
JSON-LD has a set of rules that I agree are poorly communicated. But they are consistent.
DavidC: What I look at now is the
inconsistent use of JSON-LD. To a person who understands JSON the
properties can be confusing.
... When we look through our spec it is difficult to know what the
rule is . There is no rational as to what is there and what isn't
there.
Slide 93
DavidC: These all have ID and type,
but I want to answer the questions in the speaker notes on slide
93
... These questions need to be answered so that people are
clear
dlongley: The answer is that these
things are clear in the JSON-LD specification, but I know that
isn't the answer people want.
... There might be multiple objects that are related to the same
other object.
... The relationships to the thing don't define the type of the
thing.
DavidC: We don't give the properties the types of the objects. For instance, the relationships are not labeled.
dlongley: If that is true, then we should fix it. We need specific examples.
Slide 95
DavidC: The refresh service
It should be a property: a verb. It's a noun.
JoeA: I agree with that
<Zakim> manu, you wanted to ask about about verbs vs. nouns
manu: This is a discussion that has
been happening in the RDF community since 1997.
... The community has decided to go with the name of the
relationship instead of a verb.
... Skipping the history. At some point the community switched from
"HasA" and "IsA". It became repetitive. Everything is a "HasA" or
"IsA". Switching back will make a lot of W3C people mad at
us.
... It's how the industry uses the technology.
... You are right that these are "HasA" and "IsA" things.
DavidC: That's fine, but we should be consistent. The subject then becomes the object.
nage: The answer to that is that it
could be. It might.
... I like that is what you want to imply for the credentials you
are issuing. For some credentials that won't end up clear.
... It would be nice if we could dictate how everyone understands
the information. But in practice how each application decomposes
the data graph will be different. And that's OK.
<nage> an example data graph someone will stuff into a credential https://www.hl7.org/fhir/encounter.html
dmitriz: I completely understand the desire to turn the property values into verbs, but it is not only the RDF community that chops off the "Has" and "Is". The Database community does as well. All the data modelling communities across computer science has implicitly decided to drop the verbs.
JoeA: I didn't know the shift from predecate to relationship. But it makes sense. The noun is naming the relationship, not the object.
DavidC: But in most cases it is, but
in some cases it isn't. That's the annoying thing.
... Occasionally it doesn't which throws you off.
gannan: There is a large
inconsistency issue in the data model such that we should revise
the data model.
... A credential has a claim. In that claim you can define the
relationship.
... I ran into the same thing when I was learnnig JSON-LD. When you
think about it as a graph, you are following the edge to the second
node, so it is a subject ID.
ChristopherA: We won't be able to
change the JSON-LD, but I do believe that you have something right.
To make what we call the "claim" we should probably call it
"subject-hyphen-claim"
... We can make that a two-word word to give a clue that "claim" by
itself doesn't.
burn: Opening the queue for proposals
for next steps
... there is one option. We are about to have a break. I would
suggest that we continue this conversation during the break.
manu: Continuing the conversation
after TPAC would be good.
... It is a valid point. People will continue to get confused about
it. But there are a couple of things we didn't discuss that could
help us to formulate a change. We should discuss on the calls.
brentz: There may be specific examples where you feel this dissonnance. If you point out the specific examples with a specific proposal, it would help.
<scribe> ACTION: DavidC to record specific examples with a specific proposal to clarify this problem.
<ken__> scribenick: ken__
<cwebber2> on in a sec
DavidC: Agreed, VCs are verifiable
credentials.
... Disagree on VCs are also a authorization framework or just a
proof framework.
... Have we correctly used SHOULD or MUST
... Are Terms of Use enforceable?
<dmitriz> *cwebber: can you hear DavidC speaking?*
cwebber: Do credentials necessarily imply a framework?
<nage> +1 to cwebber2's point, the verifier then makes some sort of decision based on policy, so authorization is a verifier activity, not a Verifiable Credential issue directly
stonematt: Do we need to discuss whether this is up to the verifier?
cwebber: It should be up to the
verifier. This is a simplification.
... but does the spec require this as a framework?
<nage> the verifier can add whatever data understanding, additional data, or policy to make the AuthZ part, the VCs alone don't do it
dlongely: should we push this off.
<Zakim> manu, you wanted to authorization framework on another layer
manu: an authorization framework can
be built on top?
... other work in other groups can build an authorization
framework.
... We could discuss it, but it is out of scope.
<Zakim> JoeA, you wanted to ask who thinks it should be an authorization framework?
DavidC: If we agree that a verifier can depend on a credential then the issuer should know.
<Zakim> stonematt, you wanted to say there are two discussions today
JoeA: The DMV doesn't need to know that a bar is going to use the credential in a particular way.
stonematt: The 2 points we need to
cover are
... authz
... and terms of use.
cwebber2: let's blast through the slides.
<nage> [ consensus of verbal +1s to blast through the slides ]
stonematt: let's go through the slide without interruption.
DavidC: What's the difference between VCs and OCAP?
cwebber: they are not the same (see
literature)
... we don't need to decide in this group.
... Multiply verifiers don't have all the information to do a
pass/fail.
<dmitriz> *. o O ( time to rename the group back to "V. Claims"? :) )*
cwebber: An employer could use a VC as an ACL but it is another layer.
DavidC: Are terms of use
mandatory?
... We need to decide.
<nage> Note: ZKPs make it selectively disclosable, you can say SHOULD ask for them to disclose, but you cannot force disclosure
DavidC: What happens if not mandatory and then what conditions apply?
<nage> and there isn't a cryptographic construct to prove compliance (so it seems futile)
DavidC: Just because a machine can't enforce doesn't mean they are not useful.
<dmitriz> cwebber2 and DavidC - are we talking machine-readable ToU or human-readable?
cwebber2: What is the behavior for the verifier? It is a signal.
DavidC: It should still be a MUST
even if the enforcer is a human.
... Some are machine enforceable by machines.
cwebber2: Even without a protocol
enforceable method, it should be clear to the issuer or subject
that the terms may not be upheld.
... Violations may be outside of the essence of the data model
specification.
<nage> In ZKP the second constraint is enforced by the issuer's inclusion of the blinded link secret and is enforced as a cryptographic capability if the issuer refuses to issue to anyone without their criteria for a strongly authenticated wallet AND where they have passed the identity on-boarding criteria of their business case (ultimately if it isn't in the issuers capability to enforce, it is misleading the verifier or holder to indicate otherwise).
cwebber2: The examples may not
adequately show the out of protocol enforcements.
... I don't care about should or MUST in this instance.
DavidC: In X.509 user issued
credentials could follow all the steps but not have the same weight
as CA rooted credentials
... We could repeat the mistakes of the past in VCs.
... We can't say its not an authz system because it will be used as
one.
... This will lead to problems.
cwebber2: Both models don't have CA
authorities.
... we can't make guarantees. We're making a data model.
... We are deciding that authority models should be on a different
layer.
... We can figure out outside of this group how to make that
work.
DavidC: Because anyone can become an issuer they can issue a credential to anyone else.
brentz: Not an issuer has the authority.
DavidC: If you get a CR from Issuer, you can pass it on.
JoeA: An issuer has no control.
burn: Back to the slides.
DavidC: Generic terms of use must be
MUST
... properties needed to constrain VCs
... When the holder is not the subject, the verifier needs to
know.
cwebber2: We can't guarentee terms of
use.
... We are not defining a protocol; we are defining a data
model.
DavidC: Decide: MUST to SJH
... SHOULD
... Subject only terms of use.
... Review 6.5.3.2
burn: No decisions yet.
cwebber2: The spec should say that the VCs are not directly a auth framework.
burn: close q
matt: The language is easy to conflate. We have some verbs that need more attention.
<dmitriz> *+1 to avoid using "gives" in the spec, and instead use either "issue" or "transfer"*
matt: More specific language, such as issue a VC to HOLDER, etc.
<Zakim> nage, you wanted to say something about trust frameworks
nage: The transferability of the
roles are critical to the specification with regard to the privacy
issue.
... If we try to do this in a way to preserve privacy, negative
reputation is likely not possible.
... Even if we have terms of use, we can't guarantee
disclosure.
... Terms of use can be part of a claim. Making them a part of the
Metadata outer envelope, do we need to decide that here or kick it
up a level ore down the road.
<Zakim> stonematt, you wanted to say credentials may used to authorized to do/know something
stonematt: Are VCs always used to
auth? Just because you have a license, doesn't imply a right.
... We should resist discussion of enforceability, that's not our
layer.
<Zakim> ChristopherA, you wanted to ask Is TOU in envelope or claims? I'm uncomfortable with any spec MUSTs about contents of claim blocks
<cwebber2> I agree enforceability is protocol :)
stonematt: It could be loose, or enenforceable.
ChristopherA: We are talking about
terms of use for claim material, the entire package, and key
material.
... I'm ok with putting in a term of use in a claim.
Whatever.
... In regard to key material, we don't have a CA. You trust the
issuers (or not).
<ChristopherA> Our trust model is not transitive.
JoeA: What are the symantics of the
claims.
... A Control framework must enforce; we don't want to go
there.
... Find an alternative to subject only terms of use; it blocks
many interesting use cases.
resplin: The issuer only has control over the claims in the VC.
brentz: I'm struggling to see how an issuer terms of use is applicable.
<Zakim> dlongley, you wanted to say suggest that the security vulnerability happened when something was added to the model to allow delegation but did not constrain it -- and we have not
dlongley: What you can verify is the an issuer said something.
<stonematt> Can I “issue” a credential that was issued to me and have it look like it was issued by the original issuer? -- I don't think so
dlongley: You can get in alot of
trouble when start to imply authz.
... Issuers make statements.
... Verifiers can confirm the statements are made and then act on
their own polkicy.
... The base core spec is not an authz framework.
<Zakim> gannan_, you wanted to suggest a terms of use registry
<cwebber2> +1
gannan_: If we want to go the terms of use; create a registry so that they can be shared.
<dmitriz> gannan_: +1 to ToU reuse. In fact, Creative Commons have made a great start, for reusable terms of use.
burn2: 16 minutes to next topic
<Zakim> manu, you wanted to propose text - warn that base spec is not an authorization mechanism.
manu: We should warn that the core
data model is not an auth system.
... That would occur at an other layer.
<cwebber2> manu, want to type that as PROPOSED? :)
manu: There is some overlap with terms of use.
<cwebber2> wait, don't remove terms of use!
DavidC: I propose that we go along with Joe's suggestion.
<cwebber2> it's still useful
<manu> -1 to removing termsOfUse
<JoeA> -1 to removing ToU
<cwebber2> -1 to removing ToU
DavidC: This issuer issues a
statement, but its out in the wild.
... Remove terms of use from version 1.
<dmitriz> can somebody remind us what the original intention for Terms of Use was?
burn2: We are not getting proposal of how to continue discusion, just further discussion.
<stonematt> dmitriz I can give a couple of examples of ToU from an issuer perspective at the break
ChristopherA: We should draft a statement and put together a pull request to separate what we do and don't do.
<nage> (only if we also vote on terms-of-use or not-terms-of-use -- I'm guessing they correlate)
cwebber2: Can we get a show of hands of who is in favor that the core spec is not an auth framework.
burn: please respond to cwebber2 suggestion on irc
<cwebber2> Say VC core spec is not an authorization framework on its own?
<cwebber2> +1
<manu> +1
<dmitriz> +1
<dlieberman> +1
<Zakim> manu, you wanted to continue discussion on calls.
JoeA: Verifiers should understand terms of use; if they don' understand they should reject the VC.
<JoeA> +1
<nage> I can't vote on that binary statement, it isn't an auth framework, but has auth framework-like dangers
<stonematt> +1 VC is not an auth framework on it's own
manu: Just say that the spec is not
an auth framework.
... push of the terms of use to later.
<manu> Remove Terms of Use entirely from the VC Data Model spec?
<resplin> +1
<nage> +1 no terms of use in v1
<stonematt> -1
<cwebber2> remove ToU? -1
<JoeA> -1
<manu> -1
<DavidC> +1
<brentz> +1 remove entirely
manu: Remove Terms of use from data spec? answer in irc.
<dmitriz> still not understanding what ToU is meant to do
<dlongley> -0.5
<dlieberman> +0
<ChristopherA> (confused on if someone can still put it in claim section)
<ChristopherA> +0.5
burn: No clear decision.
... Call a decision on VC is not an auth framework.
<stonematt> -1 to be silent on ToU. should have advice to issuers/presenters
DavidC: I believe ToU is part of an auth framework.
burn: We will state that the VCs spec are not an auth framework.
cwebber2: I submitted a PR; It will focus on the "not an auth"
burn: If anyone has information that they think would be helpful for us to collect in advance of our next conversation, suggest it now.
<stonematt> ACTION: cwebber2 will modify the PR that included auth/terms of use, etc to be focused on the new Auth language as agreed
DavidC: We have answered the privacy questionairre and I have a draft for the PING.
DavidC: If we remove ToU, we may have removed our protections.
dlongley: This is just a data model in a privacy discussion.
nage: Some of the thing in the privacy discussion don't take in to account the ZKP features.
burn: I would like to conclude this discussion.
manu: We don't know what the PING will discuss.
DavidC: PING indicated that they
would discuss the conflicts with the web data privacy spec.
... They don't have it available.
... When the data is instantiated, it will enable a protocol that
will have privacy implications/
burn: Manu, would you pull up relevant documents for the discussion?
DavidC: PING is concerned about
secondary use.
... This consists of use beyond the original intent.
nage: The use case of HOLDER different than SUBJECT should be made clear.
burn: Welcome to PING!
... This is important to us to consider any privacy issues.
Tara: We are happy to be here. (Chair)
burn: We have answered the PING
questionaire. We would like to hear you concerns.
... Introductions
... On screen PING questionaire response.
<dmitriz> *does it sense to link to the questionnaire response here?*
DavidC: We distinguish between US an GDPR
ChristopherA: California definition
is looser. EX: a hash is not correlateable.
... Salted has is in question in EU.
manu: Some US states are moving toward GDPR.
ChristopherA: There is an Trump movement to override CA.
<manu> VC Data Model spec: https://w3c.github.io/vc-data-model/
jnovak: How is this work interacting with protocol.
ChristopherA: This group does not
handle it.
... Other groups are bring things from IIW, etc. to the W3C.
... At this point there is no protocol in progress.
... Web Auth seems likely.
<Zakim> manu, you wanted to mention protocol work - there are multiple protocols.
burn: Verifiable Claims === Verifiable Credentials
manu: Rebooting Web of Trust is
looking at protocols; 8 in progress.
... Sovrin is working on ZKP
... Ditigal Bazaar on a second protocol.
@@a: Is ZKP in the data model?
<ChristopherA> A survey of DID auth progress last year is at https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/did-auth.md
@@a: How do address the privacy protection if ZKP is not mandatory?
<Zakim> manu, you wanted to mention "for operational purposes" in charter
manu: ZKP is not baked in. That would
exclude other uses in favor of a single implementation.
... In Operation there are many different types of exchanges. A
name or phone may be exchanged between parties.
ChristopherA: That is not a mandate
for ZKP. Many are interested in making sure that ZKP will
work.
... We are looking at cryptographic disclosure; data minimization,
etc in the CCG
... There are multiple approaches in progress.
jnovak: Doe the model have the fields marked that are required included?
<Zakim> JoeA, you wanted to ask about user triggered exchanges versus automated exchanges of state
JoeA: The privacy questionaire does
it distinguish between data that is exposed voluntarily vs
not?
... The user decides what to share.
<Zakim> nage, you wanted to talk about careful identifier translation
manu: Consent is a primary consideration.
nage: If I want to share my favorite
color, because it is attached with a digital signature that could
create an unintended collelation?
... I want a cryptographic proof without leaking data.
... That is a protocol consideration.
manu: Sovrin is such a protocol.
Sam: I find myself uncomfortable in considering the data model in exclusion of the protocol.
manu: We are too. We tried to include
it.
... It is an opportunity for improvement.
burn: We welcome discussion regarding protocol.
manu: We would welcome data
model/protocol and also discussion of the data model alone with
respect to our deliverables. discussion, but in regards to the
specification, it is out of scope.
... We have taken into consideration privacy; security and other
aspects of protocol without focusing on a single protocol.
ChristopherA: There is a movement to
charter the DID WG
... We would like DIDs to be more than just a data model.
... Non-correlateable DIDs is a strong interest for us.
... Sovrin is a specific implementation.
Sam: Is context cleared in each
browser session?
... Don't answer now. Consider and adjust.
<Zakim> manu, you wanted to speak about pairwise.
<nage> Including revocation guids, etc
manu: There is other work happening.
IDs, pairwise relationships.
... Information exchanged should go through the pairwise
channel.
... PI will be transmitted.
... There is a spectrum of privacy.
<nage> (with a ZKP model you can minimize it's disclosure, and prove it in zero knowledge such that proof doesn't come with transferrable signatures or delegatable proof)
manu: Some contexts should be psuedonomys; some contexts (Dr. prescriptions) should not be psuedonomys
<Zakim> manu, you wanted to talk about wallets in incognito
ChristopherA: There are a wide range of use cases. Without a protocol it is difficult to deal with. We cannot limit the whole data model based on browser-only use cases, but it would make sense if a browser-specific protocol is designed that such limits be considered there.
manu: Many organizations in the
ecosystem are issuing credentials and providing wallets.
... The is a strong preference for data minimization and ZKP
disclosure.
... In incognito mode, you should be able to provide a pairwise ZKP
connection.
jason: From August the editorial
comment: examples are weighted toward fully identifiable
variety.
... I think the examples should be flipped the other way
around.
nage: We are moving towards a verifiable registry model and examples that support it.
<Zakim> brentz, you wanted to say that the data model is agnostic to PII usage, but perhaps the examples of how the data model is used could better reflect zkp
nage: What are recommended boundaries.
brentz: The data model is agnostic.
<Zakim> dlongley, you wanted to say we've been having conversations about those sort of canonical examples
brentz: They are in the protocol. We should add further examples of ZKP style disclosure.
dlongley: We have had strong
conversations about better examples that match real-world use cases
and verticals.
... We are open to suggestions.
<Zakim> wseltzer, you wanted to discuss charter and its limits
Tara: Do you have sufficient use cases.
dlongley: No.
Wendy: The charter should not be a
limitation on privacy discussions and protocols.
... Guidance can be included on best-use practices.
Sam: Provide strong normative guidance.
<Zakim> manu, you wanted to note privacy considerations section...
ChristopherA: We are heads down. Give us a suggest list of words that give us a starting point.
manu: We do make Sam recommendations
in the specification.
... We talk about correlateable data (Time, id, etc.) in the
non-normative sections of the specification.
... We can add to that section.
... It would be helpful from the PING to identify areas we have
missed.
... If we add this information, will it help?
... "Do not track" is an example, where our hands are tied.
... Misuse is beyond our control.
... There is a gray area in the middle where the SUBJECT is not
protected.
sam: Perhaps "Use ZKP protections as
the default, unless the can't"
...
... Also make applications fail gracefully.
<Zakim> burn, you wanted to say that strong makes sense, normative could be more challenging without the protocol work being done. Thoughts?
burn: If we were doing a protocol and
data model, outside of that you still have possibility of
abuse.
... Strong guidance is appreciated.
<Zakim> nage, you wanted to note that it is also a protocol consideration
burn: Risks occur as protocols go different directions.
nage: Can we talk about example
protocols and use that to inform the specification.
... How do we talk about it without talking about protocols?
moneill: There needs to be a way to identify countersigners.
<Zakim> brentz, you wanted to talk about implementation guidance
<Zakim> manu, you wanted to talk about query protocol
brentz: We will be creating an implementation guidance document.
manu: There is work around
progressive trust (the query protocol).
... "I would really like this set of information." at a point in
time.
<nage> There is protocol specs for this in Sovrin as well both in terms of request protocol and in anchoring it to prove you used the regulator-approved question
manu: This can be cryptographically proved.
Sam: Are promises included?
manu: Terms of use are included.
<nage> Doing this as terms of use is very problematic in terms of implying an AuthZ protocol and undermining selective disclosure
manu: There are options for proving
using the least disclosing method.
... Some of these items could take a long time to realize.
burn: Proposals for wrap up and going forward.
ChristopherA: Consent receipts. I
would like guidance. Kantarra? Privacy problems?
... Prove that you can provide consent before you decrypt.
<Zakim> nage, you wanted to mention revocation
Jason: I think that broader PING guidance: If you are leaning toward law enforcement with long delays, the harm will have already occured.
nage: Revocation can help support consent.
<tara_> But in those places where all you have is regulatory/legal backstops, then you need to plan to have things in place (audit etc) to help those efforts as best you can
nage: We should review the questionaire with this feedback.
<Zakim> manu, you wanted to invite PING to RWoT to work through details... and future calls.
nage: We should review the data model and make sure that the data does not flow to the top levels of the stack.
manu: We have events such as
Rebooting Web of Trust. PING participation would be helpful.
... Weekly meetings are also welcome for the PING.
ChristopherA: Feb 27 - Mar 1 RWOT *
<stonematt> https://www.weboftrust.info
moneill: Specification of data
indirection in the JSON allows origin specific context.
... Policy data can be contained there.
burn: Thank you to PING for you
feedback.
... We aren't complete until we have had your review of the
privacy.
Lara: Thank you for caring about
privacy and doing so much.
... Keep it going.
<stonematt> ACTION: chairs to make issue to follow up with plan on gap analysis in UC repo
<dmitriz> scribenick: dmitriz
stonematt: as a reminder, the charter
expires on 31 March.
... we know that deadline is quite tight given our todo list, so
we're here to discuss what we can do about it
... and that's the impetus for requesting Feature Freeze on Nov 6,
so that we have a chance to hit the March 31 deadline
... the fallback position from that, if we're not successful, is to
try and extend the charter deadline, with the same scope
... we can extend up to 6 months without triggering an AC review,
though obviously we don't have to use the full 6 months.
... so we have a bit of time to have that discussion
... lastly, if we want to go big, we can try to re-charter with
more scope
... which would maybe include more protocol work
... opening the queue for discussion.
<Zakim> manu, you wanted to suggest we DO NOT do a recharter.
manu: seeing that there's potentially
a DID Working Group down the line, and many of us will want to
participate,
... running 2 parallel group seems nightmarish
... so I'd like to argue against a re-charter
... we need more experiments on the protocol front, before we move
to standardize it
... there could be discussions about specific charters (such as for
the Sovrin protocol)
... but aside from that, we're not there
... also, I feel like we should try and hit the existing
deadline
... if we just say "oh we have another 6 months" that'll be impetus
to just kick back and relax
... and deal with extension if we have to
... a re-charter is much more difficult than an extension
... with a re-charter, you have to convince the management that
you're ready, a lot of questions to answer
... whereas an extension is much easier
stonematt: so for perspective, the original charter took over a year
manu: the good news here is that we have a little more wind at our back currently, but still.
<Zakim> nage, you wanted to propose extend (minimally) with protocol
nathan: a question as much as a
proposal
... can we add another few months, add a little bit of protocol to
the charter, so we can address some of the concerns with data model
vs protocol (like with respect to ZKPs)
... it'll give us more time to implement and experiment, so we can
do a better job with the data model
stonematt: we're all trying to
support implementers as they're proving out the data model
already
... I don't think we need to change anything in the charter
formally, to make the data model support that
... so just implement as fast & hard as possible, and that'll
guide data model
... we can address a lot of this in the Implementation
Guidelines
... back to the DID WG coming up, since the earliest conception of
the VC WG, DIDs were in the discussion
... so it's pretty clear that it's critical path tech, for protocol
to even happen
... so we have to address it first, it's the next thing to do
ChristopherA: I concur
... that there's a bunch of critical paths that we can't advance
on, until some of the other pre-reqs is hit
... like, there are parties that want to do non-DID identifiers
with VCs, so that's an open question
... but for the most part, we're gonna need DID-Auth and so
on
... that said, I believe there's various things we can do that
don't require CR status. We can have Working Group Notes
... and we should start planning now what those'll be, what notes
we should publish
... so we can say, here's the experiments being conducted right
now, read up. there's not a lot of limitations for what goes into
Notes
... so maybe that's the only reason for extension, to work on
notes. otherwise, I'd love to see us hit the current deadline
ken: my question was - there's more
than one candidate protocol that can be standardized. How do we
choose between them, what to standardize?
... do you do multiple?
stonematt: I was going to have a
similar question
... if we say "this is a reference protocol", do we run into vendor
lock-in?
... but if it's just an example, we can do that without
re-charter
... as far as ChristpherA's comment, what happens at the end of the
WG — can we continue to get together after the WG is done, to work
on notes?
... if we wanted to spin up a committee as part of CG, but publish
through the WG, is that possible?
<nage> Sovrin's plan 1) update to a compatible envelope to reveal data model issues, 2) Move to a speculatively conforming DID API, 3) Update Sovrin's schema protocol to match envelope conclusions, 4) Introduce/discuss related data model objects for the protocol's data objects **notice protocol implementation isn't in the list, we already have one of those that is open source and chain/vendor agnostic**
burn: no, when a WG done it's
done
... so when members joined, they agreed to IP rights, the scope was
defined
... so we have to be very careful to do stuff outside of
charter
... that said, WG Notes do not officially reflect WG
consensus
... that's why once our primary group & charter is ended, we're
done.
... since part of it is the companies' expectations around
IPR
... the CCG will continue, so we can continue work there
... if WG is re-chartered, we can put in there which Notes we can
expect to write
<resplin> +resplin
<Zakim> manu, you wanted to talk to "what protocol to focus on"? and to talk about live document in CCG
manu: Ken, I think you asked about
what protocols to focus on
... it really boils down to who the 2+ independent implementations
are
... as far as deciding on what protocol, it's the usual, we get a
set of W3C members together to decide that this is something we
want to standardize
... if it's a charter around a protocol, then there may be several
standardized
... for example, there could be a browser-based protocol and a
non-browser-based, etc
... so just like in our case, where we're standardizing on a data
model, same deal with protocol
... it doesn't have to be a deathmatch, it can be N protocols
... but yeah, sounds like we should be focusing on DIDs instead of
rechartering
resplin: the work that Sovrin doing for DHS is open, and is in the IndySDK repository
manu: same with Digital Bazaar, all the work's public
<Zakim> burn, you wanted to remind about process and timing
burn: we have to be careful to
address fears that we're doing will lead to decreased privacy, and
increased lock-in
... which is ironic considering what we're trying to do
... we're getting increased interest and request for more
information, with our work, so we need to do a better job of
that
... we need better starter material
... even the CCG site, which is better, if you walk in cold, it's
hard to figure out what's going on
... we haven't focused on marketing, but we need to do a better
job
... I want to emphasize again, that there's a huge difference
between extending and re-chartering
... there are minimum timeframes required for review
... there's a minimum 28 day review period after each CR, and
that's /for each CR/
... and there's a time span after each review begins and when
another starts, there's also advanced notice we have to give to
w3c, so there's all sorts of time limitations
... if you put March 2019 as our final date, that means PR can not
happen any later than Feb (and we're not even talking about precise
dates, that gets even tighter)
... that means CR in January.
... that means that's the last point we can do any substantive
change, Jan.
... I'd be very surprised if all the feedback and review results in
no substantive changes.
... so that means we're looking at two CRs, at least
... meaning, we're looking at November for the first CR
... this is also discounting holidays (everyone's gone the last 2
weeks of Dec, and everyone in the US is gone the last week of
Nov)
... We can get this done.
... we may get into extension. but that doesn't mean we can kick
back and say "ok we can enjoy our holidays"
... we are unlikely to finish without an extension. however, in
Nov/Dec, Matt and I will need to decide how much of an extension we
need, just to finish everything
... so when we talk about re-charter and our next WG, that's good,
but we need to focus on what we're doing, on finishing the current
scope
... we need to start focusing more on "Is this spec 100% unusable
as-is" type of questions.
phila: when asking for an extension, be sure to already be in CR
ChristopherA: we can publish new notes as late as March, right?
burn: that's correct.
<Zakim> stonematt, you wanted to say interoperability of independent implementations
stonematt: back to more of a process
question in the cycle
... we mentioned independent implementations that are
required
... and I know Digital Bazaar is working on one, same with
Sovrin
... what's the requirement for interop between them?
... since their strategies are very different (ZKP vs not)
burn: it's up to the WG to define
what the exit criteria are, from CR
... most groups follow recommended guidance, at least 2 independent
implementations
... keep in mind that those are intended just to help guide the
spec. they are not for interop certification
... the focus is - we need at least 2 implementations /of each
feature/
... so this (implementations) is one of the conversations we need
to have for CR
manu: good news - because it's a data
model spec, it's much easier to test (than a protocol)
... because we haven't entered CR, we haven't invited
implementations yet
... oh also, the way that our test suite is designed, we can do
cross-library interop testing
... which is great, it sets us up for success
... the other question, around interop with ZKPs vs not,
... I still think it'll be possible to validate stuff at least on
the data model layer
... things like the issued: field, claims in the right place, that
kind of stuff
... we can talk about verifying the data model (without necessarily
verifying signatures)
<Zakim> burn, you wanted to ask for implementation commitments
burn: at the beginning of yesterday,
I asked for who is expecting to implement
... now that the group understands our practical limitations (re
CR)
... who thinks that they'll be able to produce an Implementation
Report within 2 months
... ok, so it looks like at least 4 implementations within 2
months. thank you, that's great
nage: re ZKP protocol, it's meant to
be transport-agnostic
... so if you can at least read em from disk and validate it, that
should be enough
<Zakim> nage, you wanted to respond to Manu's comments on ZKP
<dlongley> we might want to add a "validator" to go along with "issuer" and "verifier" that just looks at the data model post verification
nage: we need to do more testing, with regards to the test suite, in terms of its fundamental assumptions
<dlongley> to the test suite
<nage> Turn around time on the test suite issues could be significant with the current timeline
stonematt: I'm hearing some consensus
is that we should just finish the scope of the WG, as we are, as
fast as we can
... also, that we need a CR before we ask to extend
... so we go to CR, then call for implementations
burn: we can't leave CR without implementation reports.
<nage> burn: what is the minimum number of implementations we need? And how much non-overlap must they have? If they use the same crypto library? If they use the same transport?
burn: if there are substantive changes to the spec, then it has to go back for another CR
nage: 2 minimum per feature
<nage> dmitriz: we have a large and growing community, I'm looking to tell them what we need (they have options for implementation and want to be helpful)
phila: we want to be careful to make sure that there are implementers outside of this working group
nage: I have the same question, re crypto library, myself
<nage> dmitriz: I don't see why signature validation libraries would hurt us there (roll your own crypto is practically verboten for good reason)
<danbri> Since we are talking about "skeptical outsider" concerns, note that having Drummond Reed's name on WG specs may get noticed by folk who remember the Intermind Patent controversy from P3P times, i.e. https://www.cnet.com/news/w3c-seeks-backing-against-patent-claim/
<danbri> (if DID is a WG spec...)
hadleybeeman: the more you can show that this standard is happening outside of the WG, that it has a life outside of it, the stronger a message that sends to W3C leadership
<nage> danbri: and please talk to drummond about that, I know I have done so very directly
burn: we expect to have a standard
table, features on the side, implementations across
... <shows ActivityPub table, for example>
... at the very beginning, I asked a question — This is the last
chance to tell us about anything else other than the things we
discussed at this TPAC (Terms of Use, ZKPs, etc)
... we need to get to a feature freeze
... I don't believe that there's anything else sitting out
there
... but we have some open time for discussion now
... let's hear about some of those unknown-unknowns
ChristopherA: I think it's not going
to be the data model that'll cause the problem. It'll be protocol,
signing, and so on
... the structure of the wrapper envelope
burn: yeah, we need to be make sure to address people's concerns, otherwise they won't want to use it
nage: we need enough time in the
schedule so that we can do enough practical implementations, to
address issues
... when we picked up the test suite the first time, we couldn't
figure it out
... because of assumptions about the way data was signed and
process
burn: before we talk about next week, anything else we're missing, as far as completing the current work and next charter?
nage: I've gotten a lot of comments
(hallway track) of "how can we make privacy even more
required?"
... and that's a very general topic, means many different things to
people
... but we should do another critical reading with that in mind
dezell: How many features at risk do we have currently?
burn: we haven't talked about that
yet
... I mentioned that there can't be substantive changes from one CR
to the next
... the one exception is - if you have warned in advance (about
at-risk features if there are no implementations), and they haven't
received implementations, then you can remove those features from
the spec without any problem
... you just can't /add/ new stuff
... so, is anyone aware of features at risk?
stonematt: my next question was, how many features total do we have?
manu: roughly 40-52
... Terms of Use is the only one that is a bit shaky, at this
point
nage: our problems have been
systemic, not feature-related
... like most of the claim envelope problem
... so it's hard to say
dezell: features-at-risk are an
important metric for chairs
... to move the process forward
<danbri> nage, we talked about it years ago. For now I consider it a matter for the WG, its chairs and staff contact; but my prediction is that his participation does the WG no favours.
burn: concrete statement - let's say
we do the first CR, and coming up on second one, and there's any
disagreement for features
... that's when we'll put a stake in the ground and mark them at
risk
<Zakim> stonematt, you wanted to say privacy comments
stonematt: we're in the process of re-drafting the UseCase doc language with an eye towards emphasizing privacy and data minimization
<Zakim> burn, you wanted to ask again if anything else before we finish this conversation for today
burn: once again, anything else must be brought up?
manu: Kim, are you and Learning Machines going to do an implementation?
kim: we intend to
stonematt: ok, next topic, call
schedule
... we have a call coming up this Tues
... is that going to be useful?
ChristopherA: half the world has
daylight savings time change, for one
... plus all the travel, recovery
manu: we'll schedule ad-hoc meetings later, to get through some of these items
stonematt: ok, so when's the next call? (if not Tues)
burn: of the people in the room, who
knows they'll /definitely/ not be able to attend? (travel
etc)
... ok, I declare victory
... moving on to next topic
CristopherA: I'm discovering that a
large segment of our community are basically picking a single
heuristic, and getting totally stuck
... and then not looking at the other heuristics.
... I've been trying to capture what are the kinds of things that
meet with resistance
... like JWTs, JSON-LD, and so on
... for example, the IPLD guy came to us several times, had
interesting things to say, he's not necessarily persuaded.
... the four big categories:
... 1) tooling and simplicity, 2) Trees vs graphs/contexts, 3)
Readability / Developer Friendliness, and 4) Canonicalization and
Messaging Envelope
... plus some other misc things
... on Tooling and Simplicity, the claim is: we've been doing JOSE
for 10 years, it's great, we've got lots of code and libs and
middleware
... and it works great with hardware. and thus, proven and
simple
... that being said, there's a whole another group of people that
say, no, JOSE is a terrible implementation, it should be thrown
away
... these are mostly the security and cryptography community,
mostly around JOSE's algorithmic agility
... as far as JSON-LD, some of the concerns are - hardware
questions, availability of libraries and deployment
... the hardest area is 2) Tree vs Graph
... there's going to be a lot of people who will bump up against
that.
... there's also the difference between Closed World and Open World
assumptions
... some of the areas in which this causes problems are:
... non-conformant metadata
... difficulty of creating their own schemas / contexts
... JSON-LD requires graph model (and json-ld specific)
knowledge
... I myself have been stuck several times, so I can't really help
people
... there's a lot to learn
... culture shock, coming from "plain JSON" background
... then there's cryptography
... graphs are hard to canonicalize and sign, in some edge
cases
... a lot of people don't like how opaque the JOSE stack
looks
... it's ugly, it's hard to read the specs
... on the other hand, it's been around long
... JSON-LD looks better, but it's also complicated under the hood,
cause we don't often show them the expanded form
... so people think the compacted form is the real thing, and are
surprised
... especially when they're trying to bundle multiple credentials
into one
... they end up with multiple signed things about the same subject,
and they don't know how to do that
... ok, Canonicalization:
... JOSE does not require it (so that runs into all sorts of JSON
non-canonicalized issues)
... causes problems with parsing it, multiple signatures
... JSON-LD /does/ require canonicalization
... so you can discard the message envelope if you want
... a number of other Graph Model teams (non-JSON-LD and non-JSON)
have problems with non-immutability of the json-ld @context:
links
... one of the things that has given me trouble is - it's IETF,
they've refused to support sec256k key standard, so we've had to
roll our own libraries and so on
... so there's that, concerns about multiple signatures, and so
on
... then there's the various proposals for compact binary
serializations
... so these are the issues. may or may not be true, but this is
just what I've gathered and heard
... one of my fears is that we win the battle in some minor way
(say, the JSON-LD 1.1 group addresses some of the minor concerns),
but the rest of the world will do billions of non-conformant
non-JSON-LD objects
... around the same time that we'll be shipping the spec, a whole
bunch of companies will be shipping their first major
deployments
... Blockstack has already shipped. not sure what uPort is
doing
... Microsoft is planning to do a big announcement, but nobody is
sure what they're doing
... over to manu
burn: what is the risk that only a minority of the industry will adopt the spec?
manu: ok, so let's look at
ChristopherA's slide (about the 4 major categories)
... we should expect those kind of concerns to continue
... we've talked to various groups. for example, the JOSE folks,
the COSE folks (that's CBOR-based signing and encryption)
... for example, the WebAuthentication spec (and all the new IETF
specs) are COSE, not JOSE
... so there's a part of IETF that's moving away from JOSE
... so that's the good news. We can just adopt COSE
... and by the way, we already use the JOSE stack, we use JWS in
our implementation
... (we as in Digital Bazaar)
... and Sovrin and company are using CL Signatures, which are not
part of IETF / JOSE specs
... what we're /not/ using is JWT.
... for reasons that have been and will be documented, that it only
works for a small subset of our requirements
... so let's talk about community alignment
<kimhd> is DB's JWT implementation via the detached signature JSON-LD stuff?
<dimitriz> kimhd: yes
manu: one of the complaints: you
don't use JOSE/JWK format for keys
... so that's on purpose. JWK exposes way too much key innards to web developers, becomes a major foot-gun
... so instead, we can use COSE key encoding
... for signature values, we can use COSE signatures
... so we'll be using all the stuff they provide
... on top of that, we have the cryptographic suites
... so we can do stuff like CL Signatures
... without going through an IETF process, though eventually you'll
probably have to
... but at least you can ship now
... so, as far as tooling and simplicity — the downside of COSE is
that it's new
... not a lot of libraries / tooling. worse than JOSE, in that
way
... but that'll hopefully change
... Tree vs Graphs:
... so, most of us are using graphs
ChristopherA: is there any way we can have a graph-to-tree flat projection, a simple template so people can just do stuff with it?
manu: that would be great. somebody
needs to invent it
... because JSON-LD was supposed to be that
... if there's a simpler way that addresses all the requirements,
that would be fantastic
kimhd: the feedback that I get is very actionable
<Zakim> kimhd, you wanted to summarize Blockcerts-related feedback
kimhd: since it comes from very new
developers.
... everyone wants to add custom metadata
... which requires modifying a context
... which then requires hosting that context
... so there's friction there
... so we can modify the tooling, to help with that
... the other thing is - I actually don't want Linked Data unless
the links are to immutable resources
... I just can't deal with the possibility that something might be
tempered
... and Ganesh and I have been collaborating on that Integrity
Proofs paper
<nage> note that the "customize things on a per-credential basis" idea also breaks ZKP (you need a pre-made commitment for each disclosable unit)
kimhd: so, because IPFS-type
solutions have appealed to me.
... I've been looking at the IPLD protocol (interplanetary linked
data)
... so it provides a convenient way to refer to immutable
targets
... so yeah, I've heard a lot of feedback on that - Linked Data is
a problem when it doesn't have immutable links
... so one question out of that - would COSE be compatible with
that? how would canonicalization work with json-ld and cose? and so
on
scribenick: kimhd
dimitriz: I agree with kimhd that this group should be aware of ipld
...manu has started an implementation and discussion with IPLD folks.
...I encourage everyone here to be aware of what they're doing
...much of the industry is rediscovering graphs
...graph dbs gaining traction
...in our decentralized blockchain world, ppl wanted the immutability guarantee hence IPLD
...rest of industry is moving towards graphs
scribenick: dmitriz
manu: all of the concerns people have
around graphs and json-ld
... are similar to the concerns that have been there from the
beginning
... the thing that is missing is - what's the alternate
solution?
... when there's something that does what we need, and it's
simpler, we'll jump on it
... I mean, we're doing things like Student Transcripts - that's
not a simple use case, we're trying to do multiple signatures,
trying to get interop between all these parties
... for example, of the major JWT using companies, how many of
those are using multiple signatures in the way that we're trying to
do? none that I know of
... so what we need to put together
... is some simple tooling. for example, a simple vocab/context
creation wizard
<ChristopherA> Here is a web page with Blockstack's claims: https://github.com/blockstack/blockstack/blob/master/posts/identity-attestation.md
manu: for devs to quickly create and publish their context
stonematt: we've had similar
discussions for a couple years. this is a perennial problem
... perception is reality.
... is tooling sufficient to reduce the noise to enough of an
extent that we should invest into some of that?
... how do we shift the perception?
<Zakim> stonematt, you wanted to say perception is reality?
<Zakim> nage, you wanted to mention the "open issue" that I added at the back
nage: the perception that JWTs aren't
interoperable I personally agree with
... the folks who have decided to go with JWTs, they don't think
that, they've already drawn conclusions and think they're going to
interop
... so I don't know if that's something that's still negotiable, in
terms of compatibility?
... it's true that we have data graphs, I'm not sure how
approachable that will be from the outside world
... it might be worth the thought experiment (and perhaps
publishing a note) to list what we've found out, the concerns we've
addressed
... and ask folks like uPort, who participate in the group, to give
feedback
stonematt: an FAQ kind of thing?
nage: the starting point would be
this slide! talking about some of these issues
... here's the tradeoffs, here's the friction points
<Zakim> kimhd, you wanted to let nage go in front
<Zakim> nage, you wanted to say if webauthn hardware strong security is a done deal, then CBOR may already be the defacto standard (perhaps the Dec conference is the right venue, but
+1 to cargo cult!
<Zakim> manu, you wanted to talk about generalization and to say cargo cult works
nage: we've been debating this stuff for years and years
manu: for 20 years!
... this argument around graphs vs trees for 20 years, ever since
beginnings of RDF
... I've talked to some of the IPLD folks
... and they don't know much about RDF and its design choices, so
there's a bit of Not Invented Here syndrome
... so I want to talk about kimhd's concern about, is there a way
to flatten/generalize the graph to a tree?
... this has basically been an academic holy grail, a research
project
... json-ld has been the closest anybody's been able to come
... it's deployed on 160 million domains right now
... and the way it got there, is with cargo cult like
copy-and-paste
<stonematt> Zakim: close queue
manu: people copying a template,
changing the fields, pasting, and stepping back
... if we can do as good of a job as Schema.org did, this is how
you mark up a person, a review, etc
... have that kind of tooling, that will get us pretty far down the
path
... I do think it's a tooling thing
... we don't have tools to have people create their own
contexts/vocabs, and we don't have good examples
<Zakim> nage, you wanted to add back in webauthn
nage: I'm afraid we'll have to choose
between key mgmt and data management
... because of the WebAuthn spec and the deep integration
there
... we know many developers can cargo-cult their way through
stuff.
... but we /also/ know that devs /cannot/ be ignorant of key
management and survive
<Zakim> kimhd, you wanted to comment on RDF
nage: we need to move really fast on determining whether we're moving to COSE for serialization
kimhd: perhaps for high-stakes use
cases, field tested RDF schemas are perfect. for other scenarios,
for low-stakes cases,
... there aren't available and well known schemas
... so perhaps we can make more of those available?
stonematt: ok, in closing
... what are our action items?
<stonematt> Zakiml, open queue
nage: let's take some really complicated records, like FIHR, and try to stuff them into a VC, see if we're able to
<stonematt> ACTION: dmitriz make a blog post contrasting technologies to highlight JSON-LD
<Zakim> kimhd, you wanted to ask for clarification about what Christopher is saying
nage: 3 DIF members have already decided to go with JWT-based claims
<stonematt> scribenick: kimhd
dmitriz: re some DIF objections:
perhaps framing of question was wrong. Perhaps we can convince
objectors to use COSE?
... worth pointing out that WebAuthn group started with JWT and
moved to COSE
nage: this might work out
dmitriz: we should add a note about compactifying
manu: maybe; it might be a different use case
nage: we prefer more compact serialization
<stonematt> scribenick: dmitriz
joeA: have we talked about some of
the IIW conversations?
... for example, there were a number of conversations on JWT vs
JSON-LD
nage: there's an email about it on the credentials list
manu: unfortunately, all the stuff about crypto keys and signatures are in the proofs section, which is outside the WG charter
nage: well, but we can use COSE for all the places outside the charter
manu: I started working on Implementation Guidelines last night
<kimhd> Manu's implementation guide: https://msporny.github.io/vc-imp-guide/
<stonematt> any objections to pull in the implementation guide to the DM repo?
<stonematt> +1 pull it it
<stonematt> no objections.
<stonematt> ACTION: pull in the Implementation Guide
<kimhd> scribenick: kimhd
burn: we'll review github issues. Any objections? Anything missing from the Open Topics list?
manu: 128 and 129 are pretty much
done. Implementation guide has 2 sections that need to be filled
out
... need to make sure indy/sovrin stuff is addressed to their
satisfaction
nage: we need to make sure testcases pass
burn: where is this recorded?
nage: we have jira issues; they are tracking
manu: prefer not to open additional
issues
... is there consensus that we are close to passing?
nage: not blocked
manu: I think no blockers on issue
93; it is an ongoing issue
... not a blocker if we can close the spec without addressing
... it's not in the critical path. We do need to do things, e.g.
tooling, blog post, but that can happen independently
burn: we need to distinguish between PR blocker and blockers to shutting down the group
burn: *created label non-spec important thing*
manu: let's create checkboxes such
that we can close when everything is checked
... checkbox items to add: publish RWOT guidelines doc, create
tooling for schema creation, create tooling for VC creation, blog
post about json-ld vs jwt
... and other alternatives
... fin
... brentz is working on 237
brentz: for 207, we need to update examples
<dmitriz> *debates over whether to rename claim: "" property*
manu: this is still a blocker
... 204 next
... text needs to be added to assert that vc data model is not by
itself an authorization framework
... also add "discuss whether terms of use is removed"
... manu and DavidC talked about an additional restriction. Joe
would object because it's too locked down
... *exact restriction not clear to scribe*
ChristopherA: there needs to be restriction that trust model isn't transitive
<nage> I still really think TermsOfUse is a problem and very much want it removed, it is a claims data graph issue that must understand the nature of disclosures (terms apply if you disclose attributes A-C not D-F, etc)
ChristopherA: this issue is related to others (see issue for details)
burn: these will be CR blockers
manu: 272 next.
... suggest we close this. Obsoleted by other issue clarifying that
it's not an authorization framework
burn: *updating issue with these
details*
... *closed*
manu: issue 206: where do we want to
host json-ld context?
... 2 options. I'm suggesting we datestamp
ChristopherA: why not tag to a
specific commit?
... *explains mechanics*
manu: against w3c policy
... because of retention requirements. w3c wants to host on their
side
... they want to put it under ns.
... can publish by year so that we can have a different v1 in a
subsequent year
... also gives understanding about when created and whether it's
current
... we need to propose 2 URLs to w3c.
general agreement in the audience
dmitriz: we can lock down with RIPs
manu: we send when group
finishes
... note that content at w3c never changes
nage: cryptographers don't buy that arg
<dmitriz> *RIPs - Resource Integrity Proofs https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/resource-integrity-proofs.md *
manu: add action items reference urls in spec, and request URLs from W3C web team
no objections were raised from group
ChristopherA: don't we want a RIP?
manu: document a RIP in the
Implementation Guidance
... if it's published there, implementations can fetch it because
they know it will never change
... also add action item: document static caching for Credentials
JSON-LD context
... after these action items, we can update the issue to not
blocked
issue 222
manu: wanted more ZKP examples
ChristopherA: also wanted something indicating that it isn't just for browsers
manu: wanted us to focus on privacy
aspects before getting to driver's license example
... also provide specific guidance for private browsing mode
brentz: can link this to 237
kaz: also mentioned that we should consider failure cases
manu: should be in implementation notes. either progressive trust or graceful degradation
clarifying that progressive trust is a new term of art
ChristopherA: we're moving it to a CCG work item
manu: we should also check with PING
that this is the list
... issue 245 next
... we should have an example context showing how it works when you
layer
... it will be an example schema that can be used for test
cases
ChristopherA: can also put caviar on the example schema
manu: create an example schema for
the spec
... document that the context should not be used for anything other
than examples
stonematt: where does that go?
manu: w3c uses example.com or
example.org for such instances
... we could add ability to load it off of disk
... if they use it in their app at runtime it would fail
issue 247 next
manu: add action items: document that
all conformant implementations will check mandatory properties and
add a link to this issue
... referencing the spreadsheet
discussion about proof/signature check
JoeA: thinks this is a bad idea
ChristopherA: no transitive trust that the claim can be sent on
dlongley: challenge is giving guidance to verifiers and placating Joe
nage: what we decided with zkp is what presentation has proof but not the claim itself (?)
stonematt: non-verifiable ones are useful for datamodel (i.e. pre signing)
manu: 2 options. 1: we have Credential & VerifiableCred. 2: other option is make proof optional
JoeA: use case is that I want to send data I/O
manu: then we add guidance about 3 modes (pre-verified, verifiable, and does not require)
nage: discussion about zkp has
similar characteristic. want a way to drop proof but keep
format
... my use case -- I have a Credential, it needs to drop proof when
moving into presentation
kimhd: we'd also benefit from 2 types (design-time vs issued)
manu: 2 types. Unverifiable and
Verifiable
... distinction is that one has a proof and other doesn't
... do we want to make sure things that we deferred are indeed
deferrable?
next up: issue 203
manu: we need to fix the title
discussion about details of this will happen later
burn: anything else?
ChristopherA gets sudden burst of energy, wants to review CR-blockers that aren't marked TPAC2018
ChristopherA: much of this will be in
implementation guidelines
... 231 can be removed as CR-blocker
... or maybe not.
burn: any last stuff before done?
JoeA: notion of spec expiring came up
ChristopherA: do we want to end of
life this?
... liability doesn't go
manu: w3c has a rescinded process
RESOLUTION: ask w3c to rescind