Day 1 (Thursday, 25 October 2018)

<stonematt> good morning!

<nage> scribenick: nage

Welcome, Introductions, and Logistics

<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

Getting to Candidate Recommendation

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

2018 commercial update status

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

Use Case and Problem Domain Review

<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.

Threat Model, Trust Model, Security

<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

https://docs.google.com/presentation/d/1uYpGnciqzR3g0cfrWRrhCoHhqV8VyBxPclqz3co3Oq4/edit#slide=id.g45017ee23a_18_15

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

<BrentZ> https://docs.google.com/presentation/d/1uYpGnciqzR3g0cfrWRrhCoHhqV8VyBxPclqz3co3Oq4/edit#slide=id.g45017ee23a_18_15

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

Test Suite discussion

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

Day 2 (Friday, 26 October 2018)

<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]

ZKP style/spec alignment

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

Issue 207: Rename Claim to Subject

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.

Terms of Use and Rights

<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.

Privacy

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.

Meeting with PING

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.

<burn> https://lists.w3.org/Archives/Member/member-vc-wg/2018Sep/att-0000/W3C_Privacy_Questions_to_Consider.docx

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

Future of VCWG Charter

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

JWT and JSON-LD Industry Direction

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

<stonematt> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22W3C+TPAC+2018%22+label%3Acr-blocker+sort%3Aupdated-asc

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