<stonematt> TPAC WG agenda and slides: https://goo.gl/iC6tSq
<manu> scribe: manu
Dan starts going through Agenda, calling for scribes.
<Drummond> Can someone put in the link to the slides?
<stonematt> No phone line inthe conference room yet.
Burn: If there is anyone remote that wants to follow, we're still waiting on a phone.
<stonematt> slides https://goo.gl/iC6tSq
Burn: There is an IPR policy - we follow it, you need to know it.
<stonematt> oops, that was the shared deck for tomorrow.
<stonematt> actual one is here:
burn: If you want to say anything, you need to be on the IPR list.
<stonematt> live slides: https://goo.gl/5NXb2v
burn: Code of conduct - for those of you on the AC List - these are guidelines for how groups can work together - be reasonable, be considerate, be open to other opinions/discussion.
<varn> Is anyone on the chat waiting for the phone to participate/hear? If so i can use my cell speaker phone until we get a hotel line.
burn: Dan Burnett - here because I think this is a wonderful effort, really like the approach of this group - not to create "an identity"... that, plus my interest in doing standards work... my favorite movie - The 5th Element... because I can't predict what happened next.
stonematt: Matt Stone, Pearson - work out of colorado - live in Boulder - wonderful there. I have a very low bar for enjoying movies... happy to sit through almost everything - love Miyazaki movies... hard to complain about Marvel movies as well.
jandrieu: Joe Andrieu - my favorite movie is Lost in Translation - wonderful bit about human experience, trying find meaning through humans.
cwebber2: Chris Webber, part of
what brought me into this group - Spec Ops - I do decentralized
social network stuff - share message - don't want sharing about
something you didn't say - we have an active use case around
people using Verifiable Claims - favorite movie - love animated
films - spirited away - Tripletts of Belleville.
... Such a creative delight...
dlongley: Dave Longley, work with Digital Bazaar - Blacksburg, VA - really like the Shawshank Redemption.
manu: @@@
arnaud: Hi Arnaud Le Hors, IBM and work in Hyperledger - long history with W3C, team member... I'm in Brussels now... I'm part of work in Blockchain, looking seriously into self-sovereign identity stuff - we don't have anyone following what's going on in standards side - don't know how much we'll be actively participating. Better understand the landscape... where to better engage... I like Reservoir Dogs.
drummond: Drummond Reed, Chief
Trust Officer at Evernym, one of the Trustees of Sovrin
Foundation - global public utility - Hyperledger Indy -
Chairing Trust Framework there.
... Lot of attorneys that are very excited about Verifiable
Claims ... we're up to 24 stewards in the network, last two are
law firms, large firms - self sovereign identity, verifiable
claims - the coming explosion in trust frameworks - we need to
get this right.
... I love movies - I started out in screen writing - really
liked "Crazy Stupid Love".
Jarlath: Hi Jarlath, I'm trying
to get up to speed - looking for education for employment gap -
how to use verifiable claims in that space, from education
space - here to learn.
... As far as movie - I'd say two come to mind - The Matrix
(the first one), and then Magnolia.
Charlie: From Infotech - government transportation companies - bonds, performance bid bonds, licenses, - I live in gainsville, FL and Seattle, WA. Favorite movie - the original Producers.
nage: Nathan George, I work for Evernym, work on Hyperledger Indy - from Utah, most of Evernym is there - nice to be in the mountains. I'm not so much of a movies, but anything my kids will sit through - Moana, Cars 3, etc.
gkellogg: Gregg Kellogg, from Spec Ops, native of California - here because I get involved in many different things - verifiable credentials, identity, seems so important, I just couldn't not be involved... my history of WGs, as groups become more mature, my activity level goes up. Favorite movies other than Princess Bride, most profound change... 2001 Space Odyssey.
varn: Richard Varn, Educational Testing Service, Iowa, and Princeton, San Antonio - working on behalf of educational opportunities - knowledge, skills, experiences, want to be able to disseminate and use in global market - want people to more easily acquire credentials they want... Movies... Joseph Campbell, really like Casablanca
reto: Reto Gmur - working for facts mission - goal as stated in the name, more facts, less BS - trying to find how much verifiable credentials can be used together with that . Movies can't say movie right now...
nathasha: Natasha Rooney, work for GSMA - work with mobile operators on identity. My interest in verifiable claims is from GMSA and W3C AB perspective ... movies anime person - cowboy bebop is great.
burn: We'll try to go to dinner - put food opinions into the slides... at lunch, we'll confirm who's coming, that'll help us choose a way to go.
Richard goes over VCWG mission and goals.
Richard: Express and exchange claims on Web - open to other industry participants - digital offers, receipts, loyalty programs... focused on education now.
Varn: Scope - what is in scope - vocabularies and data model - protocols analysis - out of scope - browser APIs, new protocols, attempt to create supporting infrastructure, attempting to "solve identity".
wood: Where is all of that out of scope going on.
andrieu: A lot of work is going on at Credentials CG, RWoT, Digital Verification CG, ANSI body, IMS Global, Credentials Transparency Initiative -
Varn: In education, a few folks working on that outside.
Drummond: Internet Identity
Workshop, what are the protocols - BC Gov folks, team up there
for great adoption strategy - all public claims - search
service for all government agencies - BC issuing VCs for paper
certificates - publish and aggregate - searchable service, see
all permits - sits there as beacon to businesses - here are
claims, go get them.
... They're developing protocol for doing that - they're going
to be using Sovrin for DIDs, we're going to work on protocol -
ZKP protocol - one place where that work is going on.
Manu: Also, Rebooting Web of Trust work going on there... the work is happening in many places.
burn: This is the Agenda for
today - we have target times for each session - there is a
conflict at end of day for AC Meeting - all groups have this
problem, but will schedule something that we though might be
less disturbing for that time.
... We have a couple of topics that we'd like to get to - this
is our opportunity to cover a variety of topics in enough
detail to get through difficult discussions - terminology -
it's not done yet.
... The variety of use cases and potential implications - spend
time on each of these areas - have meeting of minds -
milestones for data model and use cases - can talk about that
after everything if we have time for it. open topics session
end of day tomorrow. in slide deck - slide all the way at end -
put topics there.
burn: Scope of the WG in more
details - terminology...
... This is the W3C process - we do all the work in WD - create
a document that we think is complete - has to be tested at some
point - wide review and testing...
... CR - Candidate Recommendation - what you're supposed to do
is have a doc that's sufficient as a final REC - there may be
problems, goal is to get implementation experience - what are
the problems - if you wait until CR, you'll probably go back to
WD.
... There will come a point where we say "no changes w/o tests"
- there is a wide requirement for CR... intention is to make
sure other groups at W3C give input... a11y, privacy, i18n -
each one of them takes a look at our spec... they will ensure
that we meet their needs as well.
... Typically, when you're done w/ CR - you get sufficient
implementation, get to PR stage.
... WD does not imply consensus
... Everything in WD does not imply consesus - as a group, we
want to largely reflect consensus - some groups want to put
something in quickly to fix
... CR has requirements - we want to have two implementations
of every required feature or some sort of interop demonstration
- define criteria to produce CR.
... PR is a sanity check - you should have talked w/ everyone
that may have had a strong opinion on the doc - goes to AC for
them to give their review
... If something bad happens in PR - you'll need to move back
to WD or CR...
... At PR, you're pretty much done unless you screwed up.
gkellogg: While WD doesn't meet group consensus, the editor should reflect group consensus, highlight issues that are controversial...
burn: officially, there is no requirement for consensus - but unofficially, we try to get to consensus when editors put stuff in document.
andrieu: The Use Cases document - that's not standards track... what's the process there.
burn: A non-standards-track doc doesn't fall under these rules - it's up to the group to publish this stuff...
Arnaud: There should be consensus in the group to publish.
Natasha: Applies to any group.
Burn: We do try to get consensus, but not the same bar for the Note ...
andrieu: There is no public review, for example...
burn: I won't go into consensus right now, as Chair, one of the things we watch for is signs of lack of consensus. When there are strong disagreements, we need to work through them, ideally without voting. We try not to use votes to make decisions.
These are links for reference mostly (slide 14) - we might come back over last couple of days - look at charter - look at primer - frames the space a bit differently from charter - polyfill demo is the beginning of implementation of verifiable claims in browser... powerful to see how it works.
andrieu: Is it worthwhile to publish as a note.
Stone: Primary deliverables -
data model, use cases - we're not working on protocol.
... We have a FPWD in summer, EDs are happening often... notes
on discussing OpenID and SAML - some other tech like
UProve.
<burn> ACTION on chairs to schedule discussing publishing primer as a WG Note
<trackbot> Sorry, but no Tracker is associated with this channel.
Stone: Here are links to Github
repos for those that are interested - issue tracking - robust
discussion happening in Github.
... In the last 3-4 weeks, we've had a big discussion around
terminology.
<dlongley_> manu: I've got some slides I can share.
https://docs.google.com/presentation/d/1oQXTGGocewfrUlO6-hloR2zd7P0clMZPIMpthwgaJdo/edit
<dlongley_> manu: We've gone through four iterations of the terminology we use in the spec, trying to simplify terms as much as possible and make it easier to talk with people not steeped in this stuff. All changes in the last 2 years focused on simplifying.
<dlongley_> manu: The reason we're called the Verifiable Claims WG is because there was hard pushback from one W3C member in particular. The security community also pushed back against the use of "credential" because that means "password" (in some settings). They suggested we use "Verifiable Claims" and we went with that. For the last yera though, we've found out that people are jumping to the completely wrong conclusion. "The sky is purple" and prove that statement
<dlongley_> is valid, for example.
<dlongley_> manu: The issue is around communication, we're trying to prevent that jump from happening, but all the terminology is overloaded, so we're looking to find the least bad solution we can go with. This was most apparent at the last Rebooting Web of Trust where people said it took a whole day to figure out what we were working on.
<dlongley_> manu: Putting a digital signature on a set of claims has no bearing on the truth of those statements, we are about verifying authorship only.
<dlongley_> manu: We had a group consensus vote on the inspector-verifier ... we put in a spec with both terms, that has led people to think there are other types of "verifiers", "inspector-verifier", "cloud-verifier" so on.
<dlongley_> manu: Entity Profile has been changed to Verifiable Profile in the proposal because it matches up with Verifiable Credential. We want consistent language and a reduction in terminology and confusion.
<dlongley_> manu: The proposal here is to get rid of inspector-verifier and just use verifier.
<dlongley_> manu: People using marketing literature have been using verifier with success.
<dlongley_> manu: So a car rental agency is a verifier, or an online liquor store, etc, relying parties asking for verifiable credentials. The simple proposal here is to adopt "verifier" and just use that.
<nage> +1 to verifier
<JoeAndrieu> +1 to verifier
Proposal: Change "Inspector-Verifier" to "Verifier" in the specification.
<dwood> +1
<dlongley_> +1
<cwebber2> +1
<stonematt> +1 on verifier
<varn> +1 to verifier
<gkellogg> +1
<Charles_Engelke> +1
+1
<burn> +1
<dlongley_> Drummond: +1
<Drummond> +1
<kimhd> +1
<betehess> looks good to me
<kimhd> +straw
<dlongley_> burn: No strong objections at this point, let's do that and see if we get an objections. It's worth doing.
RESOLUTION: Change "Inspector-Verifier" to "Verifier" in the specification.
<DavidC> Yes I am here
<dlongley_> manu: This is the more difficult one. We've been using the terminology "Verifiable Claim". This is the primary thing that drives all the other decisions. Group called VCWG, VC data model and syntax is the spec. Problem is people think we're talking about truth of the statement, we're not.
<dlongley_> manu: Proposal is to strike "Verifiable" from Claim and just talk about Claims.
<dlongley_> manu: A driver's license is a verifiable credential that contains a set of claims in it. Verifiable Credentials contain claims.
<dlongley_> gkellogg: schema.org is using the word claim that I believe is consistent with this use. The example was Donald Trump said something about Hillary's emails and there was a rating about the truthiness of that claim.
<dlongley_> gkellogg: If we're using a word that's as broad as "claim" that we're not using something that is different.
<dlongley_> manu: Yes, this is the dictionary definition.
<dlongley_> JoeAndrieu: I like this definition, this is much less confusing, pretty important.
<Drummond> I am in favor of this change
<dlongley_> JoeAndrieu: We should have some language, and I don't know if it will survive, but "Yes, the best we can do is not verify that the sky is blue but that someone said that."
<Drummond> Question: if we make this change, do we need to rename the WG?
<burn> drummond, we can consider renaming the group when we come to recharter. that is for later.
<dlongley_> reto: If we're about ensuring bringing technology that allows to verify that someone said something ... signed graph technology is there. How far is credential restricting. Or are we just putting verifying statement with verifiable authorship.
<dlongley_> cwebber2: To respond to gregg, the usage of the claim is the same as the verifiable news work. If you take any one of these terms, claims, verifying claims, so on ... on their own and everything is fine, when you try to wrap the path of these terms together into "Verifiable Claims" it becomes confusing.
<Zakim> dlongley_, you wanted to agree and talk about trust
dlongley: I want to agree with Joe, we need language in the spec - proposed language brings in concept of "trust"... data model is about how to make claims... how do you decide how to trust claims... if you trust the entity making the claim, but how do you verify that? You want to be able to trust the claim... the reason why you trust the claims is because evidence.
<dlongley_> Drummond: The key thing I wanted to bring up... I'm in favor of whenever we have to talk about what we do. We don't talk about what we have to do, ... oh, it contains a bunch of claims. I'm very familiar with claims-based architecture. The MSFT approach and Kim Cameron pushing that term out there, I'm a fan, but it didn't seem to fit with the marketer. My main point is we're going to be the Verifiable Claims WG working on Verifiable Credentials. Renaming
<dlongley_> the group ... is that an impossibility? How does that work/
<dlongley_> burn: Recharter is the best time to consider for that.
<dlongley_> arnaud: The two are quite different -- there's some expectation that the spec will follow the name of the WG but not always true, plenty of groups that produce many specs in a WG with their own names. I advise you to do just that, don't bother changing WG name. You don't want people to be surprised when it comes to PR, but from a process point of view, when you publish the FPWD, there's a check...
<dlongley_> arnaud: If you have a good rational for using another name, that's totally under your control, change the name of the spec, not the WG, that's a huge hassle.
<dlongley_> burn: Many WGs produce specs that are related to the WG name. Voice browser etc -- so on.
<Zakim> gkellogg, you wanted to discuss meta-discussion of tracing back group decisions relating to normative language in a specification
<dlongley_> arnaud: You could fix issues when you recharter.
<burn> ACTION on chairs to add/update text on group home page explaining the change of term from verifiable claims to verifiable credentials
<trackbot> Sorry, but no Tracker is associated with this channel.
<dlongley_> gkellogg: The point here is that the group makes decisions that have ramifications and normative text in the document. Being able to trace back to the decision chain is important. We were pretty diligent in the JSON-LD CG and RDF 1.1 WGs to try and record that. But periodically someone comes up with "Why did you do that?"
<dlongley_> gkellogg: And it's in the issue tracker somewhere -- if you search. We might want to do something more explicit in the spec that actually traces back to specific decisions that affected changes to the document. Some way that makes it easy to find out, ideally, on a normative statement basis, their provenance.
<Zakim> manu, you wanted to respond to retos signed graph WG statement.
<dlongley_> manu: The way that we did it before was that -- whenever a decision was made we always pointed back at the issue tracker.
<dlongley_> wood: If something gets lost and you have a URL to it then someone can go find it and that's utterly invaluable.
<dlongley_> manu: You're right, this is about signing graphs but you can't use that language outside of the semantic community. The details of that need to be pushed down, even the data model/syntax that we're using is JSON-LD ... is to push those things down the stack.
<dlongley_> gkellogg: Need to be careful with that because RDF is the data model.
<nage> I will save my comment on signed graphs for the Attribute Based Credential discussion
<dlongley_> manu: We want to avoid exact that sort of discussion.
<dlongley_> manu: We're trying to put a layer on top of standard signed graph stuff. That's why we're using that language and this terminology to communicate it.
<dlongley_> reto: How will it be restricted? Driver's license signed by the catalonian gov't ..?
<dlongley_> manu: You have two graphs the graph of things being said, standard RDF graph do anything there, then another graph with who said it, evidence, etc. so on, and we're creating the thing that links those two graphs in a known standard way.
<dlongley_> reto: Ok, I think the term credential is confusing to me.
<burn> ACTION: chairs to schedule discussing publishing primer as a WG Note
<trackbot> Sorry, but no Tracker is associated with this channel.
<dlongley_> varn: I agree with this change but I want to put some color on this for the next thing we do. I didn't want to change from credential from all to begin with because that's the common use, it's how we talk about it. Everything else is construct relevant discussions whereas with claim there were many irrelevant ones.
<burn> ACTION: chairs to add/update text on group home page explaining the change of term from verifiable claims to verifiable credentials
<trackbot> Sorry, but no Tracker is associated with this channel.
<dlongley_> varn: An issuer is making claims or assertions that then become a credential. The issuer bundles more and more claims about a subject, where the subject is a participant and perhaps assents to being the subject of this claim. There's usually a relationship there ... they provide evidence if any. Then we can prove that the issuer made the claim.
<dlongley_> varn: The more problematic things is that if the issuer is making claim X but the subject is not participating. The word credential doesn't work very well there.
<burn> irc queue now closed for this slide
<dlongley_> varn: I'm very happy with using the word credential, but if it's useful outside of our context that language can be problematic.
<gkellogg> +1 to varn
<dlongley_> varn: So it may be another term using the same technology upfront.
<dlongley_> varn: All the news people want to know is "did you say that" when talking about some claim made about some subject and those are different things from credentials, etc.
<dlongley_> cwebber2: I agree with the statement just made, the very use case as the social network type stuff, where people are mostly concerned with who said something. You're not trying to do something with it. Is actually pass along the data associated with it.
<dlongley_> cwebber2: We take "verifiable" onto that thing that we're talking about there. We can talk about claims separately, and say that "Verifiable Credentials" can check that someone made a claim, but we didn't put "verifiable" right in front of claim.
<Zakim> manu, you wanted to request straw poll.
<dlongley_> varn: The only thing we can handle is the credential of the person who said it, everything else is out of scope.
<dlongley_> manu: Richard brought up a bunch of very good points. Nathan has brought up this before. The proposal is to make the change, try out the language, see if it works. If works and it sticks, let's do that.
PROPOSED: Agree to change "Verifiable Claim" to just "Claim", try it out in the spec and communities, and come back in a few months to decide how the change went.
<nage> +1
<cwebber2> +1
<gkellogg> +1
<varn> +1 regarding dropping verifiable in front of claim
<JoeAndrieu> +1 to proposal
<DavidC> +1
<Charles_Engelke> +1
<dwood> +1
+1
<betehess> as a French native, Claims really sounds more about assertions (and proofs), while Credentials are more about documents (or qualifications, etc.)
<Drummond> +1
<dlongley_> +1
<burn> +1
<stonematt> +1 to using claim
<dlongley_> JoeAndrieu: We're calling it a credential but it's not familiar. We could socialize it to help people to think of it in a more general way.
RESOLUTION: Agree to change "Verifiable Claim" to just "Claim", try it out in the spec and communities, and come back in a few months to decide how the change went.
<burn> irc queue is open
<dlongley_> manu: That's great, that's going to clean up a lot of language in the spec. Instead of saying "Verifiable Claims" everywhere we're going to say "Verifiable Credentials".
<DavidC> +1
<dlongley_> manu: "A set of one or more claims made the same entity about a subject. A verifiable credential is a credential that is tamper-resistant and whose authorship can be cryptographically verified.
<dlongley_> wood: It's an awfully broad definition of credential.
<dlongley_> gkellogg: There's a little maybe scope creep. Thinking about this in the context of the fake news presentation yesterday, where a claim was made. Perhaps what was that was is, in our current terminology, there is a verifiable credential that includes claim. That credential is somehow derived from a news statement.
<dlongley_> gkellogg: There were some annotations upon that claim that someone had rated it.
<dlongley_> gkellogg: Maybe that's just outside of our scope.
<dlongley_> nage: This is where, as we start to get into what terms we use ... that could color what protocols feel is in bounds or out of it. Is the signatures on the claim or is it the proof that is the credential?
<dlongley_> nage: When talking about presenting attributes you may need to constitute pieces together and that's the credential. Which part of the system was a credential and who was the issuer in terms of the root sources of the data. In the terms of a traditional driver's licesnse that's tidy. But when talking about data traveling between silos, etc that can cause problems.
<dlongley_> dwood: Making claims about a subject doesn't sound like a credential, or making a set of claims about the same identifier ... you get into a slippery slope with identity perhaps, there's a little bit of tightening necessary here. The purpose isn't to agree as a group, we can agree to any terms we want. The purpose of this language is to communicate with people not in this group.
<dlongley_> reto: I've just read the definition of credential in oxford but I don't see why we're narrowing to this use case. Perhaps signed graph is too nerdy, maybe signed claim set. Talking about the declaration of the independence ... because God promised God city to the ducks ... [more about ducks].
<dlongley_> reto: Claim set would be quite straightforward.
<dlongley_> gkellogg: Verified claim sets.
<burn> verifiable? rather than verified
<dlongley_> reto: And signed claim sets. We don't provide the technology to see if God really promised Duck city to the Ducks.
<Zakim> cwebber, you wanted to say that the path is the reverse
<Drummond> Speaking from a practical perspective, the use to which the market will initially put these "signed graphs" is as credentials for people and organizations.
<dlongley_> cwebber2: Here's a case where credentials make sense. You've got a university and you've got a diploma. In one sense, "the claim comes from unrolling the credential" ... I tend to think of credentials are what enable claims.
<dlongley_> cwebber2: I think the claims are made by credentials. In this case, this diploma really did give you that. Credentials give you the capacity to do something. Alice says someone else really loves ravoli. You don't do anything with that.
<dlongley_> cwebber2: If Alice says ravoli is good, we can only verify that alice said this. If anything this is an "auditable claim".
<dlongley_> cwebber2: This is why we keep tripping ourselves up here.
<dlongley_> varn: That was good. A driver's license and a diploma. In the case of a driver's license, it's a set of claims that a person makes in order to get permission to drive.
<dlongley_> varn: It includes picture, passing driver's test, so on. Not all the claims that are in the credential are signed or verified.
<dlongley_> varn: I did not think that we would have to sign every claim that became a credential.
<dlongley_> varn: A diploma is a bundle of claims. Richard attended a university with this sort of ranking, took these courses, proving these set of skills, so on. That's all bundled to become a credential.
<dlongley_> varn: We are all in agreement that we will not verify any claims. There may be an attendance credential, so on.
<nage> we walk the chain of trust to see why they were willing to sign the statement
<dlongley_> varn: Within this definition of "person, place, thing, etc" ... I was thinking of that needing a word. Is the word "entity"?
<dlongley_> JoeAndrieu: We have use cases where the subject is multiple people.
<dlongley_> JoeAndrieu: This statement about McScrooge and Minimouse ... those are two entities in the same assertion.
<dlongley_> varn: I understand what you're saying, but who is the holder, so on -- we need to start boxing these terms and make sure we don't run into the same problems that we ran into. Using subject should be about the person, not the topic matter, etc.
<dlongley_> manu: We have those discussions in the spec. Fundamentally subject boils down to RDF subject.
<betehess> do we have a full example which can be used to map terms like claim, assertion, subject, what's verified, etc. ?
<dlongley_> manu: We timeboxed this discussion for a reason. I'd like us, at the end of this, just propose using verifiable credential, understanding that it's imperfect and we will have iterate. If we can't agree this is our primary language then we have to back out the other changes in the spec.
<Zakim> manu, you wanted to note that there are "digitally signed graphs", and those may be different from Verifiable Credentials.
<dlongley_> manu: The definition for verifiable credential is problematic. Not everything verifiable is a credential, we have somewhat of a problem -- there is such a thing as a signed graph. We could be saying that a verifiable credential is a smaller subset of signed graphs.
<dlongley_> manu: Reto is pushing back and saying "Why are we limiting ourselves"? And the answer is that we're trying to keep scope down.
<reto> -1
<varn> +1 for verifiable credential term with assumption that we will work on the definition
<DavidC> I just asked my wife, who is not computer literate, what is a credential, and she correctly defined it. I then asked if she had any credentials, and she replied my passport. So this simple example shows that the term credential may be very widely understood in the social domain.
<dlongley_> manu: Fake news may challenge that, I'd like to put a propsal.
<burn> DavidC, please type in irc
<burn> thx DavidC
<reto> -1 provisional name could be something like "signed claimset", I think reducing to the credential usecase is too limiting
<dlongley_> manu: And that's driving the spec text.
<dlongley_> JoeAndrieu: The point isn't to tease out the definition, it's the shift to verifiable credentials. It doesn't mean a single RDF subjects. It isn't a graph about one subject ... where all triples are about one subject.
<dlongley_> manu: I'm going to be pedantic. It's always about one subject. Mickey and Mini attended a dance.
<dlongley_> JoeAndrieu: There is no root.
<dlongley_> timbl: That's correct, that's the more RDF way of looking at it. Marriage is another example.
<dlongley_> timbl: If had a digitally signed certificate like that matches something common, not just one subject.
<dlongley_> timbl: Credential having information about more than one person ... you need that ... RDF does that because it's RDF not XML.
<dlongley_> timbl: A set of credentials declaring that you're a vegetarian, that's just a subset.
<dlongley_> timbl: I can bring my credential to the buffet that says that.
<dlongley_> timbl: I want to make sure that use exists.
<varn> Label or type of credential can help us distinguish from the more technically laden term of subject. many vocabularies exist to label credentials and can be used to address the social interpretation of what the credential is about
<dlongley_> timbl: If you ask the X group to define X they never come back. Don't be too distracted.
<Zakim> cwebber, you wanted to ask if claim is not the danger, but verifiable is
<stonematt> q
<dlongley_> cwebber2: I'm not proposing that we have a new term here. I think the new term is less wrong but still wrong. I think there's a fast forward that gets us in the right direction. The reason for the confusion is that both of these are claims (diploma/statement). If you put "verifiable+claims" it blows up. Claims is fine we need that, if we get rid of it we have to use "statement", same problems, need to use it.
<dlongley_> cwebber2: Credentials are a bag of claims that let you do things. But maybe the right term is "auditable claims".
<dlongley_> cwebber2: We can't verify that the statement is true but we can audit it. Without moving into the external world.
<dlongley_> cwebber2: I think this is the root of it.
<dlongley_> manu: That sounds like a good direction we should discuss, something we could potentially search and replace in the spec. Let's debate auditable, whatever variation.
<dlongley_> varn: I added another comment above to try and get away from subject to some degree.
<Drummond> The term "auditable" is not as strong as "verifiable" just due to the human meaning/context of the words. Verification is more closely associated with digital signatures and cryptography, and verifying that an issuer issued a credential.
<dlongley_> gkellogg: F2F time is really valuable to get through these kinds of things. I wonder if the schedule allows for us to put things into buckets so we can come back to this.
PROPOSAL: Shift spec to focus on "verifiable credentials" vs. "verifiable claims" even though it is imperfect - work on the definition. Debate "auditable claims" or "signed claims" over the next few weeks and search/replace if that becomes the final decision.
<cwebber2> +1
<JoeAndrieu> +1
<nage> +1 so long as we keep our ears to the ground on perception (my implementation uses the term credential).
<gkellogg> +1
<dlongley_> +1
<DavidC> +1
<Charles_Engelke> +1
+1
<Drummond> +1
<kimhd> +1
<varn> +1
<stonematt> +1
<DavidC> Any update on establishing the voice link yet?
RESOLUTION: Shift spec to focus on "verifiable credentials" vs. "verifiable claims" even though it is imperfect - work on the definition. Debate "auditable claims" or "signed claims" over the next few weeks and search/replace if that becomes the final decision.
<nage> note: that auditing in an accounting sense implies more deep correctness checks than verification in a crypto signature sense
<DavidC> ok thanks
<kimhd> there are no brief English words afaik for "able to prove integrity about" or "able to prove authenticity of"
<dlongley_> also important to bring in the concept of meta data around the claim
<burn> irc queue open but we are not to discuss now . . .
<dlongley_> manu: We had talked about Entity Profile before and the suggestion is to move to Verifiable Profile, we will have to discuss later.
<dlongley_> gkellogg: We need a class for the things that include credentials.
<burn> break for 30 minutes
<cwebber2> scribenick: cwebber2
<DavidC> yes
<burn> DavidC and others, Richard will be posting dial-in information here momentarily
<burn> Nathan is starting . . .
nage: we've been talking a lot
about signing graphs, but there are other options out hteir in
the crypto communities, one option is attribute based
credentials
... Jan Kamenisch has a lot of experience in this aread
directly and we're involving a lot of his material
... we'll go for maybe 15-20 minutes so we can cover as many
details as possible and focus on how it affects vocab and data
model
... from crypto perspective there are many approaches to
provide integrity but many of them involve a lot of math etc...
so usually you point at them, but the moment you try combining
many of the approaches, you can confuse things
... the response is often that it's too expensive / too hard to
understand / too complex to use / or keys too hard to
manage
<DavidC> >Manu. Please explain 'bridge set up'
nage: but in DIDs the object can
provide its own key information which moves things to a
relationship management problem
... so this makes it a lot easier to do right and make it
easier to manage, hopefully reducing much complexity and
expense
... so that gets us to how attribute credentials work in
practice and how it's baked in
... there's a paper called ABC for trust that's well written
and concise
... the issuer shouldn't know when and how credentials are
presented
... ??? does it differently with the right nonces and blinding
and etc, whereas u-prove does a one-time-use credential
... transactions must be unlinkable
... the issue is that if all parties involved can spy on what's
going on, I can't maintain the context of my identity
... it's important that the cryptography doesn't betray
that
... the protocol itself doesn't betray me
... next important point is we want to preserve minimal
information disclosure
... currently I need to provide all information, but since
you're using correlatable data we have scary identity problems
etc... so we want to base our decision off of something more
than just correlatable information so far
... this becomes more critical in eg exchanging medical
knowledge etc. in lower assurance contexts it's equally
important
... in that case I really want to oknow if that gives me the
??? or not
<varn> phone bridge toll free domestic number is 1-866-212-8020 and international toll number is 1-832-445-3545 and conference code is 609 734 1186 # . Line is open.
nage: one important point here is
that the unit of issuance != unit of sharing
... when I issue a signed bit of informaiton I don't know how
they will use it
... it's presumptuous to assume you can anticipate every use
case... so if you can decouple the information disclosed that
simplifies it, and tha allows minimizing data disclosure
... I want to present proof of information, but I don't want to
provide all of the attributes... proof of posession is
enough
... by allowing ourselves to have this separation between unit
of issuance and unit of sharing, we can contextualize
information shared across the system
... we have an issuer issuing a claim, we have a holder which
we like to call a prover, and they send that over to a verifier
using a subset of attributes
... holder can verify that the information is correct and can
start asserting, and when asserting information they have they
can create a derivation from their claim
... there are details about how the profile works
... let's go through it
... here we have an issuer eg a general medical counsel, they
want to issue to a brand new doctor
... they want to give a verifiable C*
<varn> phone bridge toll free domestic number is 1-866-212-8020 and international toll number is 1-832-445-3545 and conference code is 609 734 1186 # . Line is open.
nage: they want to anchor what
their graph is, which is more specialized than RDF... you can't
do a generic graph with an arbitrary length
... that's a fancy way of saying "I need a fixed size array to
do the selective disclosure I want to"
... hopefully we can get to the point where generic stuff is
more possible
... it's hopefully a mapping of something more generic onto
this flat fixed array
... we put a revocation registry out on the ledger
... when I revoke I can't tell who revoked, I can just do a
proof of revocation
... if I can do timing correlation between revocation and ?? I
can break the boundaries
... when we issue the verifiable claim, notice that that it's
bound to the information on the ledger, but there is no bound
relationship between the two
... so all the numbers are valid starting now, and i don't have
to update the accumulator until i have to turn one off
... doctor wants to assert to doctor "I'm a real doctor I can
operate here"
... doctor shows the attributes are correct without disclosing
them, a zero knowledge proof
... all you have to prove is I have a credential from this
authority and I'm a subject of this
... so I can't hide the who or the wha
... then I can selectively reveal who does what etc
... I can then reveal subsets of the information
... I can prove drivers license information plus
birthdate
... when we start talking about biometrics, can prove match
against the template
... by minimizing the amount of information you disclosed... as
trust escalates you can continue to disclose information
... every identifier is a unit of correlation
... part of the point of being self-soverign is to control the
unit of correlation
... I'm adding correlation to that identifier... when I need to
add information to that identifier you need a unit of
information
... a lot of the identifiers we use in practice today are not a
unit of information like this, they're a data attribute which
has a data and ontology even though they may not reveal it to
you. SSNs had prefixes baked into them but that wasn't
revealed, once you could you could begin to correlate
... there is no connection between X and Y entity which
prevents timing attacks and other attacks, reduces
correlation... we use pairwise credentials
... I can transmit information so they know that the identifier
is correlated
... that's what allows us to have the airgap between silos
manu: so to clarify the hospital does have a concept of GMC and does have a concept a template of which item on the ledger... so there is a relationship between ??? on the GMC but they don't know ???
nage: correct
... they can have more information than what the doctor can
accept/understand
... you want an information leak to not have these
problems
... when any arbitrary data is compromised, you end up with
leaks and you can't take correlations back
dlongley: that's good but it's not completely accurate that the problem was entirely removed, it moved to a key management problem
nage: correct
JoeAndrieu: the doctor doesn't necessarily maintain a record of who they gave a record to
<stonematt> q
dlongley: but if you lose the key
of who the doctor is holding on to then they recreate every id
you've ever made
... they could potentially recreate all of those
Drummond: similar to losing the master key to a bitcoin HD wallet
dlongley: my point is that the problem doesn't go away, you're moving it to a different area, a key management problem
varn: in the subset of data the
hopital side has probably realized it's necessary that they be
able to receive the data from the hospital
... presumably the data has names that ties to some
ontology?
nage: yes
varn: how are these choices acted on? in this environment there may be a poll that says "you tell me what you need"
nage: there's a proof request, the doctor gives a proof offer, but essentially those two messages go back and forth
varn: anyone can have a UI that lets them ask what's provided?
nage: yes, and there are some UI projects now being demoed
Drummond: we're talking about
sovrin as a utility, but on top of that you have to implement
the UI etc
... Sovrin doesn't do that, Evernym does that
nage: we're really trying to get
at the technique at attribute based credentials
... I'm pointing out there are other ways to show this
varn: has there been any luck to see how to resolve these issues?
Drummond: to put on my evernym
hat, various groups like hospitals yes, gov use cases, broadly
trust/collaborative networks
... which is not industry specific
varn: no direct representation for sherm??
Drummond: people are definitely interested
nage: various orgs are aware they're forced to be part of it but if they can move some of the challenges to key management to others that reduces their responsibility
<Zakim> manu, you wanted to ask about auditability
manu: if you need to audit the hospital, fundamentally what's the hospital is collecting is what they trust.... there's some relationship between GMC andthe hospital... but the regulators need to audit this
<varn> shrm is the society for human resource management which is a broad membership association representing the human capital management industry and professionals
manu: if there's a regulator, how do they audit it? do they reach into the hospital and the gmc and poke it like a black box... have you had conversations with regulators with zero knowledge proofs?
nage: we've had some
conversations, we're trying to build something that's
privacy-by-design
... one example is needing to bring someone into court... you
don't just need a zero knowledge proof to show that someone is
a doctor, you need to know you can page someone and etc
... there's a lot of information that can be required, but by
making it so there's a requiremnet of key possession there's a
way to ensure there's some relationship
... in the case it's blocked and it's not required I have no
control over correlation
... one point between not having a direct connection between
GMC and the hospital tehre'ss no connection between that nad
the root of trust, they don't have to trust... I only have to
check what's fit for purpose proof against what's relevant...
this makes workflows for applying for a loan and etc... as long
as there's a notary I can trust in the system
... where it gets really important is when we have a composite
proof
... they've both anchored information that's on the
ledger
... what happens in the protocol we exchange a blinded master
secret with the issuer in order to prepare the
certificate
... they bind to the correlation secret they don't know
... when they assert this information I can do it with
different issuers who never know they're talking to me
... that's what creates the model of a contextual
identity
... this in practice becomes useful in escalating trust
... you can get a quote from all insurance companies, but if
getting one from one insurance company, but an identity holder
can choose to contextually enable disclosure
... *recommends recomended reading slides*
... I can help guide through that or on the hyperledger rocket
chat there are a bunch of people proofing and auditing
manu: is that in the hyperledger group or in the id group
<varn> how do we prevent a person from bundling credentials where one or more of the credentials have terms of use that forbid its use in that manner or context?
nage: there are some differneces
in how it's constructed in a distributed ledger, so the
non-creds implmenetation is a basic python implementatoin, but
we like to point to the indie-* library which is a C-callable
rust library
... those are our hooks to talk to a hyperledger indie
network
... could add universal DID resolver hooks into it
Drummond: a lot of these
questions around auditability and liability... trust
frameworks, that's where we're seeing that the network as a
whole which is very generic / low level to see what people can
plug into it
... I'm engelizing the output of this group like nobody's
business
... we can recognize what are the claims, what tare the
policies for issuing/accepting them
... we don't always have to plumb it from the bottom up
... a few weeks ago I gave it as a legal forum and laywers were
so excited
... now they can address problems that VerifiableC can provide
a trust dynamic in the business system
... once you get to that you have money flowing and a trust
dynamic
nage: there's a set of tools not
mentioned in this slide called "premium claims"
... it makes sure you can only issue under the following
contexts
... it allows a hope to ensure not decryptable/verified
... you don't want to use a credit card to open your door
stonematt: we're at time, thank
you, that was great
... next topic on the agenda...
manu: that was great, how does it impact the data model spec
nage: one difficult thing in my
talk was talking about claims vs credentials
... if I take those signed attributes, that's the thing people
usually think of as the credentials
... if I think of it globally as a credential... that's
attribute based credentials
... credentials are more closely related to the unlocking of
the thing that's signed
... the word profile is really difficult, if you look at the
bar with the ledger slide, you'll see that the wholder actually
has a wallet, in browser speak thatps a profile... when I start
to present my credentials with a unit of correlation, I'm
drawing from my profile to associate my information with a
particular site or pforile
... it makes sense for the user of the wallet
... the profile for the user or profile...
timbl: but we use profile for our things, we find that works because everyone knows about profile, very common out there... nobody changes their mozilla profile but the people...
nage: what's confusing is instead
of tying what information is disclosed you say I'm tying it
with this infomation
... facebook is managing many different relationships.. the
unit of the domain name doesnt necessarily map what's used
for
<Drummond> Suggestion: could we just call a bundle of credentials a "credential set" instead of introducing the term "profile"?
nage: in the web's perspective
you might not need to care too much
... but I'm not sure
... so picking terms like credential or profile... as you
selectively talk about data minimization etc those cause people
to do the wrong thing
manu: I get the high level... I'm
more concerned about the low level
... unless we can actually apply to a test, it's hard to have
that conversation
... we tried to look at what a ZPK style profile would look
like, there's stuff like an accumulator and etc that you need
in the data model
... have you gotten to the point where you recommend that they
retrieve....
... maybe you need an entirely different datastructure
<DavidC> yes thanks
nage: an anonymous credential is
kind of like that graph
... there's some pieces of functionality that can't be
accomodated there
... when we try to bake in some linked data concepts it causes
some confusion... I like link data but when tagging and etc
itmakes me nervous that it doens't necessarily match, I like to
think of those as part of the graph
... when it causes conflicts against systems that try to tie it
in.... there are details that don't bubble up
Drummond: maybe because this
convo does go deep maybe it should be the responsiblity to come
forth, look at the data model, see how these things map
in
... I think that's maybe the most efficient way
dlongley_: please create a bunch of github issues
nage: maybe we need to add something to the test suite so you can make it clear it's not necessarily a linked data model
dlongley_: make it clear in the issue tracker why it can't be
nage: right now it's very crypto specific
dlongley_: but maybe actually raise it?
manu: all of us are hoping it's
not wrong, but we need to be able to look at code, but if we
don't have that at least file a GH issue that outlines a
specific case
... I think this is a solvable problem... you can say you have
a graph based model and maybe under ZPK option you could use a
base64 based blob to go across the wire that's fine
... the idea is to unify/align/etc
Drummond: the combination of
issues/proposals are where we are with this
... I'm eager for the Sovrin foundation to jump in and do the
work and harmonize, but maybe the sovrin foundation should also
become an official member not just sovrin
stonematt: we'll cover this more tomorrow
varn: I've been working by what's known as sometimes "claimvelope" but why isn't it possible
nage: I can't selectively diclose
when it's over every element of the array
... maybe you say there's a certain set of fields you always
put in there
JoeAndrieu: most of our use cases
assume subject == holder, eg holding a drivers license assumes
I'm the subject of that crednetial
... we support this in some ways but this is not what we're
talking about.... there are no technical dependency that
subject == holder
... there are five cases, but I'm curious if we're missing
some... i'm most intersted in categories/examples
... posession of credentials is to claim the privilege
... I don't care that you're you, I care that you're buying my
stuff at 10% off. first come first-served offers... one time
passwords... other examples
... I could put those in a Verifiable C
... I don't think this has a lot of impact on the data
model
manu: the way you achieve it is not include the subject in there
JoeAndrieu: internally complete
credental: you have the photo/gender/height where a human
inspector thinks it's the credential... there's no OOB
mechanism
... I might give my passport, they might say we have the data
on file
manu: I think this is a subset of the bearer credential where you have some other identifier in there that can be checked
JoeAndrieu: biggest component is
privacy... if I'm using *htis* notion of a drivers license then
all that information being used to identify who that is, I'm
giving all that information
... if the photo's in there the photo is leaking
manu: this is effectively like form autofill because you have a signature on there?
stonematt: it's a delegation and agency problem
JoeAndrieu: authorized delegates, it's specifically authorized by subject... currently no delgate mechanism in data model
manu: that's what capabilities
are for
... and we went through that at RWoT
nage: when you're starting to tie a key to bind in the biometric, just using that key to bind correlations all information
JoeAndrieu: not sure how applies
nage: when you ydelegate you show all that information
w+
JoeAndrieu: mint.com logs in as me but they shouldn't be able to
<DavidC> how did I disappear from the queue
jheuer_: basically I think we need to consider a concept of identity and we have a document that authorizatoin is needed for... associated with a subject and it needs something to execute something about it and whether the issue is able to authorize it
<hadleybeeman> Hadleybeeman: This is the main use case for the Open Banking API work in the UK: giving other apps/services access to my banking data. https://www.openbanking.org.uk/
jheuer_: I know delegation is important but I haven't thought about it in context of verifiable claims
JoeAndrieu: with delegation there
are two individuals
... custodian/guardians there are other examples
... eg parents/children/care givers/wards needing to act on
behalf of other people
... how do you decide someone is able to do things
... how do we know that someone is appropriately acting under
the mechanism
<nage> This affects the validation of the graph itself in many cases (did you have consent? Do you have authorization to store/use this information for this use case? --> that changes how you can depend on the data)
<dlongley_> cwebber2: So it turns out that both this slide and the previous one are covered by the object capability model out of RWOT. Capabilities let you do a thing and delegation and attenuation. You can tell a bank they can only read. You can do delegation and let someone else do something and you can revoke it. It's covered in the RWoT paper, DIDs aren't required.
<dlongley_> cwebber2: General linked data capabilities model. It could be done with HTTP or anything.
<dlongley_> JoeAndrieu: Do we need changes to the data model?
<dlongley_> cwebber2: Separate data model.
<dlongley_> cwebber2: Could import it.
<scribe> scribenick: cwebber2
DavidC: I think the current data
model can support delegation through recursion by using signing
keys... if you allow in the data model the attribute stored
that the verifiable credential, a credential is itself a
verifiable credential
... the credential signs the outer credential then it can be
done
<Zakim> manu, you wanted to say that delegation of data within the document is improtant, and we were thinking of delegation happening through signature mechanism.
DavidC: so I think it can be done with recursion
manu: so I wanted to address
hadley's point first and then talk about delegation
... difference between delegation stuff and what's here is you
have consent in the actual data
... if you try to implement delegation at the api layer and
everything needs to have it at the api layer
... so what we're trying to do here is have the mechanism of
delegation move with the data itself rather than be at the api
layer
... the other one is that we don't have delegation in there, we
have a couple of proposals on where it could go... when you
send a verifiable profile across the wire, you do a
counter-proposal that goes across the wire
... but we have no working data there
... if you have a new field that's to delegating that approach,
we're talking about that in proposal who try to work on it to
not block it
... maybe we work with mark miller from google and chris webber
to be sure that it works
... the delegation and attenuation issue are the change
JoeAndrieu: I don't think that's
the same, the subject isn't the same
... in this case the subject isn't able to have access
... also "in case of emergency break glass" type thing
<dlongley_> cwebber2: I think that we do handle that, but can explain over lunch.
JoeAndrieu: and then the form
fill, you're presenting data to the user, and then assist as
part of user driven interaction
... that's still in the context of the user agent in terms of
the verfier
... you're just using verifiable claim as part of that
Drummond: what does this have to do it?
JoeAndrieu: I'm just using the
data transfer to move it along
... other categories, eg private shipping information, I want
to give a verifiable claim shipping to amazon etc, maybe amazon
knows its me etc
... but they never saw the address
... we never even talked about that.... in our conversation
nage, we had multiple subjects... example you gave was medical
device which automatically generates claim which is used
elsewhere, but it's not about any one of those people but
rather about the event
<Zakim> manu, you wanted to note that we've talked about encrypted claims.
jheuer_: we all start in this situation, when we're born we all start in this state
dwood: I just wanted to agree with other categories of people who aren't in that example, eg someone not having identity because family didn't believe in it and had no ability to execute on anything
JoeAndrieu: and then the holder may be UNHCR agent who's trying to deal with whatever
Drummond: entire assumption
around DIDs is a guardianship use case, a form of delegation
that will be extremely important
... there's so much abuse going on the thai fishing issue, that
may be an initial use case given the amount of abuse there
nage: turns out this issue is not just about disadvantaged, so you have to have an on-ramp of identity of what's going on
JoeAndrieu: that's interesting
about a use case where the subject is the holder but they can't
prove it?
... there's also the border patrol group, they might want to
start keeping records about what that is
<Zakim> manu, you wanted to talk about encrypted claims.
JoeAndrieu: the subject is not in control of that information
<burn> I am sure I will hold credential information about my car and my dog
manu: we did talk about having a situation where amazon has a shipping address that's encrypted but moves to ups, etc
JoeAndrieu: in that case I may be shipping it to you, which is your address, but
stonematt: about the border
control example, why wouldn't the agency be an issuer
... why wouldn't they be issuing claims about that
JoeAndrieu: has a monolithic concept of border control, but could be other entities
gkellogg: we're inevitably
getting to the point of indirection where revokability is a
part of it... it gets authority on behalf of their child, but
if parent is unwilling to revoke that and child becomes of age
there must be a mechanism so parent can revoke
... there can be tricky issues of revocation
varn: to what degree when you're talking about the parent acting as an agent, does that cover broker / agent / etc?
JoeAndrieu: this seems like a power that you want to enable
stonematt: it seems like the
important distinction of the examples is that in some in
delegation some are offered some are assigned
... so in delegation a court may assign to an individual, where
in head hunter there's an offer
... so is it authorizing or is it assigning
... globally in this discussion there's two different
classes
<dlongley_> cwebber2: Our current model is about correlating information with individuals and roles, something you can execute, delegate, attenuate, that's the role of capabilities. I'm not sure where it fits, it may be a separate modeling issue, not in the current model spec.
<dlongley_> stonematt: We have a discussion tomorrow about terms of use and maybe we should cover that then. How the claim may be used downstream.
JoeAndrieu: and we don't have
good record of that
... so here are some challenges, delegation etc, issuer may
have something to say about whether it's delegatable, not just
the person with the profile
... one thing that's come up is there's an identifier
identifying the subject, but that may be about what the proof
is about the verification method
... so in the US you may have I-9 which is how you prove who
you are, so the method of proofing isn't necessary in the
identifier, but it is in DIDs, which is cool, but it can be
this identity used with this mechanism
manu: for evidence proof we have something, but we don't have proof about at delivery you ??? XYZ
<nage> manu: though they do imply some type of proof of control at the domain-level, do they not?
JoeAndrieu: we'll have another
section on use cases.... we have a pretty painful flaw in our
data model around being one level deep
... we have a very artificial one level deep issue
... I'm not sure how to do it, it's a substantial change, but I
wanted to get it in
<DavidC> > stonematt. Hi
<stonematt> hi DavidC
<DavidC> > stonematt. Did you get my email?
<stonematt> form a couple days ago?
<stonematt> yes
<DavidC> No one hour ago
<stonematt> for us to call you/
<stonematt> ?
<DavidC> yes
<DavidC> Otherwise I will skype in again
<stonematt> let me see if that's a possibility.
<liam> there's a webex still available
<liam> see member mailing list
<liam> or you can use the regular webex meeting if you have the host key i think
<liam> ok
<DavidC> I am waiting for the webex to start
<nage> scribe: nage
<scribe> scribenick: nage
<DavidC> ok will do
<DavidC> Having problems with skype entering the access code
<stonematt> DavidC: are you on the phone?
<DavidC> skype keeps repeating the conference code digits so it is not accepted
<burn> DavidC, are you using the same number as before we stopped for lunch?
<DavidC> yes
<DavidC> i am now using my landline but it is ver quit
<DavidC> quiet
ChristopherA: Some should report the problem or the issuer isn't who they say they are
<varn> can you hear us now?
<dlongley_> +1 to nage, holder can't be subject here
ChristopherA: I'd suggest that anything beyond that is out of scope
nage: you cannot prove a negative fact does not exist, so it is better to rely on another part to disclose these types of information
JoeAndrieu: This is a special
case where the subject isn't the holder most of the time
... which means that it falls into the previous round of
complexity
... there is a special case where I need to give you the claim
because of the guarantee of the legal requirement for something
like a background check
... I think we should advocate for disclosure
... meaning if someone is using claims about me, I should be
able to get involved with that (for example GDPR concerns)
DavidC: someone said that you
cannot prove that a negative fact doesn't exist, but from a
legal perspective you are sometimes required to
... for example a child care provider is required to disclose
whether there is a blemish on their record
varn: in most states they seek
permission from the state, and in some place they push these
facts out into the world so that other people can know
... for example every time a sex offender moves into my
neighborhood, I know it. Because there is an affirmative
registry, and the subject isn't the holder of the claim.
... you can test for the presence of attributes in a record,
but that is different than proving that no such record exists
anywhere in the universe
... the important part is that you can get a null fact back
from the possible systems, and is there a requirement here in
the data model
stonematt: people are publishing
something about "me", how do they know it is really about
"me"?
... how do we deal with that in the data model, and secondly
how does the revocation policy work on an "empty
response"
... I haven't been convicted of a felony as of today, and now I
want to revoke that. How does that work or does it has a Time
To Live?
varn: its is "as of this date the answer is no"
stonematt: conceptually and linguistically I agree, how does that fit into our data model?
<varn> here is how a notice works under FCRA: https://www.occ.treas.gov/news-issuances/bulletins/2004/bulletin-2004-35.html
Drummond: in the context of the
claim protocol Sovrin uses, if the claim is revoked it is
revoked, the fact it is a negative fact is the semantics of the
data schema that was signed
... I've been looking at reputation for a long time, and in an
RDF data model we've constrained a credential to just a subset
of the claims that can be made, and in this sense you have
negative statements but you don't have negative credentials
dwood: There isn't such a thing as a "I don't have a Czech drivers license" credential
ChristopherA: from a social construct perspective this has a lot of difficulty
cwebber2: I'm responding to the
idea, "how do you know that it is really about me"
... all you really know is that it is bound to the identifier
and correlated to whatever that identifier represents
<Drummond> Joe has a good point about the "scarlett A", although that's a very interesting categorization of a "credential"
cwebber2: there isn't really any
way to guarantee one to one mapping to the real world, people
could have more than one or none at all
... you're just signing some association to the
identifier
... if you make that claim that "this is me" that is really the
best shot of knowing if something is true
JoeAndrieu: That is the job of
some system like Equifax. They attach sufficient attributes to
the attestation to try to make sure the assertion sticks
... It has an impact to the vetting for "is this the Matt Stone
that we mean?"
... on the issue of negative claims though, is this some type
of metadata? This is a false dichotomy. Metadata is data and it
relates to the meaning of the data.
<Drummond> I agree with Joe's point that "negative claims are still just claims".
bigbluehat: I was in the
annotation WG and a co-editor there and this question came
up
... and people asked us as data modelers "how do we fix
this"
... and the answer is you haven't sufficiently annotated your
data yet, and you need to do more to annotate the claim that
you're making
... you must make a claim to that end or there isn't a way to
really know that
<Drummond> Asking the "meta" question: claims about claims.
bigbluehat: the needed mechanics are create, revoke, decry, and so forth
burn: we are now 2 minutes over on the allotted time, so the queue is now closed
varn: I provided a link to a
'negative information notice' legal construct for a model for
this
... this could help people structure the disclosures correctly.
It refers to a 2004 rule.
... this crosses over from claim into credential from our
discussion before
... if I need to get into a halfway house, I might think of
this as a positive assertion
... so the meaning of the data depends on what you are trying
to do with that data
... the rest of the cases cross over into the things like fake
news
... someone gives a negative review on your restaurant
... in some ways that isn't that different than
annotations
... this is a bit about how we think about the data we can
sign
Drummond: The fact that it is
negative is context dependent
... "I qualify to be in your 12 step meeting"
... The other thing that added some clarity, is "it is a
credential when it enables you to do something"
... it gets back to the construct earlier that both those
concepts our out of scope
<burn> James Bond is a good example. Needs two kills
DavidC: I am coming to the same
agreement now, it is all about the verifier understanding
meaning for understanding the context of the data
... you could actually just punt this issue, and it is up to
the verifier to interpret the issuers data structure
... I think the driving license one is a good example, there
isn't an "anti-drivers license"
... there needs to be a purpose behind the signed data
structure
JoeAndrieu: On the credentials, I think I get where you are heading on that, but it might be off the mark
<burn> queue is closed
JoeAndrieu: they don't inherently
enable anything, they are more about an achievement
... we don't know what they might enable in the future
... this comes from Benjamin (@bigbluehat), because the need to
make a claim about claims is important
... this creates the n-depth chain of custody issue
... and our language or model doesn't talk about the verifier
giving it to someone else or the verifier making a claim about
the proof
dwood: In response to bigbluehat,
we talked about these issues in the RDF working groups
... in 2003 to 2014, I'll just say this again
... we need to recognize that people lie and we have to allow
that
... people can also disagree and it often isn't distinguishable
from a lie, depending on your perspective
... you cannot get consensus on this
... two government agencies may be willing to contest differing
facts
... the DMV might say he has a license but the courts might say
that he has lost it, but the DMV doesn't know about it
yet
... claims are a social construct and about the people
involved
stonematt: I didn't hear a recommendation to change the data model, but it seems we improved our understanding
<burn> queue is now open again for closing/next step points
stonematt: I've added an open issues item where we might be able to deal with this for tomorrow
<Drummond> Recommendation: this topic should be dealt with in an editorial section of the spec
stonematt: but otherwise, it was a good discussion and we will move on
varn: I would like that JoeAndrieu's specific request can be covered, in terms of broadening or extending the roles
JoeAndrieu: It is about n-deep,
the roles are necessarily different
... what we currently call a profile is in some sense a claim
about claims
stonematt: we have n-deep as a discussion item tomorrow, we will defer this until then
ChristopherA: My intent in the
broader things like BTCR family and how to implement it, all
claims have to be counter signed to be valid
... meaning the subject of the claim has to also sign it
(because of a particular intent that we have)
... this seems out of scope and a policy that is at a policy
level
... so I move that we say that it *is* out of scope
... and positive or negative claims are at a higher level than
the standard
... or there will continue to be people who are confused and
think that we could do it
Drummond: For the same reason we discussed here, it is something that could help in the editorial portion of the spec
burn: It provides no normative behavior, so whether it is negative or not is a subjective determination so the idea of meaning in this sense is outside of our standards scope
varn: if we introduce the idea that we don't allow you to issue a claim about someone else, I don't think that is what we're suggesting
ChristopherA: how we are enforcing this in our data use is a policy item, so that proves to me it isn't a data model issue
burn: I think there is some commonality that there is no data model change, but an editorial statement or informative text would be helpful
<stonematt> ACTION: burn's editorial comment is what we should add to the spec
<trackbot> Sorry, but no Tracker is associated with this channel.
ChristopherA: At this level there
might be something we want to do in the data model to help
refer to a dispute about an identity
... that might be something to address tomorrow (claims about
claims)
burn: dlongley_ is up next
dlongley_: this is about
"Verifiable Profiles"
... here is our VClaims ecosystem we are familiar with and at
presentation profiles come into play
... we have items here that go into what is passed there
... what we would like to do is to bundle multiple verifiable
credentials into a single object to present them
collectively
... we might want to have something about terms of use or how
you are allowed to delegate or reuse
... from the credentials CG we have an experimental query
mechanism for how you would go about getting information about
something like a passport
... I'm going to ask for a claim that is a passport, go out
into a credential respository, get the user's consent and then
send those credentials back to the website
<Drummond> I am again going to recommend the WG consider the term "credential set" instead of "profile".
dlongley_: the software has to
bundle them up, create this profile object and then it flows
through back to that website
... we have some information here that makes it so that you can
verify that all these things are about the same subject
... after you verify them, you can flatten them out to the same
object. It is a bonus for representing the data like this in
the data model.
stonematt: this idea of the single subject in the profile, how does that fit in the use case nage shared this morning?
dlongley_: presumably they have a
pairwise identifier with both entities, but there is a common
master secret that lets you prove that these identities are the
same
... in nage's use case the identifier here is the identifier
for the hospital
ChristopherA: I have a specific use case with husband and wife want to present that they are legally married
dlongley_: I don't see how this
violates the data model, because in RDF there doesn't have to
be a root subject
... you should be able to pluck a subject out of what was
claimed, so it shouldn't be a data model violation
ChristopherA: I find the husband and wife example works very well to get to these issues
dlongley_: we might always want to call out "to whom was this issued", so that you can look at it without confusion
gkellogg: just to clarify,
signatures sign credentials, so if there is n credentials,
there are n signatures on each one of these
... so a proof on each credential
... so the property here is across the entire container
... so they are all proofs of the same thing
... are the credentials named graphs? (yes)
... so there is an explicit node that can be referenced from
the signature
... so the JSON-LD seems to hide an awful lot of this
Drummond: I understand the term profile, but once you use credentials talking about credential sets seems to be more specific
dlongley_: everyone is looking for a better term
DavidC: I think I agree with
drummond and we want to say we have a set of credentials
... and I don't see the need for a new construct
... a set of credentials proven to a verifier seems like a
protocol issue
... because we don't talk about proof of posession
... we have credentials and we can present them separately or
collectively and have to have a protocol mechanism to prove you
are the subject
<stonematt> I added "profile v. credential set" to the list of Open Time topics tomorrow
<dlongley_> nage: The data model has to do something to specify how the proof of possession to how you interpret the data. Whether that's part of the claim envelope or your schema has to deal with this ... I'm not picky but we need something.
<varn> portfolio of credentials may be an option...portfolio is more often used to describe things we collect for ourselves while profile is often what others like intelligence or law enforcement collects about us...
dlongley_: I'm in agreement that we need some construct in the data model for that reason, but for the reason that making it part of the container helps interoperability across protocols
JoeAndrieu: there has been some
clarification teased out about the profile and the
protocol
... it seems clear that we can have many subjects in the
credential
... so unless we are asserting that all the credentials are for
the same subject it doesn't make much sense to have a
profile
... it seems to make more sense that I'm making a claim about
claims and in this case the claim about the claims is that
these are all about Mary
... and a profile in this case is conflating the semantics in a
way that isn't helping us
dlongley_: in this sense we might need to say something about the audience of the claims
JoeAndrieu: so this is really
directed credentials, meaning it is issued to someone
... we don't have to demand that this be the case
... anyone could claim it as evidence without having a pairwise
unique credential for me
dlongley_: this makes the utility
of presenting the data more difficult, but maybe...it doesn't
at all
... what I was saying earlier about he mechanism in JSON-LD
plays with that nicely
... if your subject can be put in the top of the profile, then
you can pull things out of the graph to support this idea
varn: two thoughts, in the case
of the guardian a mother can present claims about the birth and
innoculations (they could be issued to the parent)
... it seems more like an any-to-any relationship more than a
one to one relationship
... those should be data elements so that we have some
auditability
... and we need to be able to detect when people get claims
that they shouldn't have
... a profile is more often something people build about
you
... and a portfolio is something that you build about
yourself
dlongley_: the question is that limited to certain contexts
<dwood> That's an interesting distinction
varn: if there is a useful
distinction there, having different names could really
help
... the hope is that you don't have to dig too deeply into the
provenance
<dlongley_> nage: When you have a protocol that tries to make it so that the key possession tells you something about the data for selective disclosure, the person that issues the meaning is the issuer. The issuer doesn't know when or how you will present it, if you assume the issuer knows how the data will be presented we can cause misunderstandings of what the data means.
<Drummond> nage: the issuer is the one who gives semantic meaning to the claims being included in a credential.
<dlongley_> nage: I need to know whether each of the claims intents are compatible.
<JoeAndrieu> : yes
<dlongley_> nage: If I don't have some kind of cryptographic proof to show the relationships...
<JoeAndrieu> ?
stonematt: a question for dlongley_, in the question with JoeAndrieu, it seemed like there is a moment where we might want to go evolve the data model, what is the next step there?
dlongley_: I feel like the best
thing to do here is to document requirements
... lets write down what the requirements are there to make
that work
... I don't suspect it requires a change in the data model so
much as changes to the spec text to remove any artificial
restrictions
ChristopherA: I just resonated to the whole portfolio thing
<burn> irc queue now frozen
ChristopherA: as we've evolved to
discover this higher level structure
... that is the profile or entity there are a bunch of these
different bags
... my profile of you, including things that are unsigned,
because I made those, and might only sign to give to my
agent
... which is a very different bundle than what I might make to
sign and give to someone else to prove about you
... or even give to a trusted issuer to issue about you
... thinking about these different kinds of bundles and how
they are different seems helpful
dlongley_: I don't think we've
talked about this enough yet
... we need to figure out which bundles we are supporting
... it is related to Mozilla Persona stuff and several other
concepts
cwebber2: speaking of imperfect
names, is this really just a bag of items where there are other
bags out there?
... ActivityStreams have collections, do we really need more
terms? Can we use the most generic term possible?
... is there a real reason this particular name really
matters?
<Drummond> I am fine with "credential collection" as well as "credential set"
<burn> irc queue now unfrozen for proposals on actions/next steps
lots of folks: no, it matters
dlongley_: can we get people to
file github issues, and bring up the requirements
... we are mostly looking for github discussions around all
these issues
varn: dlongley_ do you have anything particular that you want to bring up here?
dlongley_: I'm not backing any particular proposal here
ChristopherA: It is really clear
to me that the intent and exactly what the process is for these
selective disclosure things may be limiting here
... it looks like this bag of selective disclosure things is
one of these other types, and when it is unbagged it is a
profile but until then it seems like something else
dlongley_: yes, we need feedback from the CCG about how this relates to a concrete protocol
<varn> do we need a data element called profile and/or portfolio provenance?
<varn> is their anyone on the phone?
<varn> there
<varn> Call will end in 5 minutes if no one claims to be on the call. if you join later please ask me to reopen the line on chat. thanks.
<stonematt> still there?
<varn> we are
<burn> we don't see minutes happening
<varn> just reminded the scribe to do that
<dlongley_> gkellogg provides quick background on triples, RDFS purpose.
<varn> group discussion on good notetaking
<dlongley_> gkellogg: A best practice is to include RDFS along with a @context.
<dlongley_> Drummond: Help me understand that
<dlongley_> manu: When you ask for a @context at some URL "foo" ... when you retrieve that over HTTP you could also get the RDFS vocabulary description.
<varn> discussion regarding this as a best practice or not
<dlongley_> manu: Including all of the terms, a description of the terms, so on.
<dlongley_> gkellogg: A reason not to do that is if the vocabulary is too big.
<varn> longley says a best practice is return a definition and the data but can be a lot of data depending on how it is assembled
<dlongley_> gkellogg: A document in JSON-LD can describe both the @context and the vocabulary for default @context for a particular vocabulary.
<dlongley_> Drummond: Maybe that's where I'm getting stuck here. I'm going to just talk about a @context description. A @context description ... that describes the vocabulary.
<dlongley_> gkellogg: Let's wait for examples in the slides.
<Drummond> gkellogg: other important vocabulary is RDFS
<dlongley_> gkellogg: The other important spec for describing vocabs is OWL (Web Ontology Language)
<dlongley_> Scribe: Drummond
gkellogg: OWL extends RDFS with
more reasoning capabilities. Very powerful but complex.
... With OWL you can define a class as the union of multiple
types, so you can go more general inferences.
... You can define imports, sameAs, disjointWith, inverseOf.
Also define restrictions on classes
... you can also define value spaces for properties
... there are various approaches for expressing RDF
vocabularies
... Greg next went over an example JSON-LD document that is the
basic structure of a verifiable credential.
... Greg pointed out that RDF does not let you create a value
that is a graph, but instead you can have a value that is a URI
that is a named graph. This approach does not model any sense
of context.
drummond: pointed out that the starting point for the OASIS XDI graph model was the need to model nested graphs "all the way down"; ironically the term the XDI TC used to describe the nesting of graphs was "context".
gkellogg: Said that nested RDF
graphs might be considered in RDF 1.2.
... Some named graphs can be anonymous if they are identified
with a blank node.
... The proposal is for managing context/vocabulary in a
spreadsheet.
... Greg showed an example human-readable vocabulary definition
document.
... on slide 44, Greg described how he used ShEx to describe
verifiable credential requirements.
... he linked to several example documents and referenced issue
#33.
<betehess> all that discussion makes me think of Concise Bounded Description https://www.w3.org/Submission/CBD/ and what what we did in LD Patch i.e. https://www.w3.org/TR/ldpatch/#Cut-statement
liam: gave an example of the types of restrictions that ShEx shapes can impose on an RDF graph, such as restricting them to not include extra triples.
gkellogg: recommended that we
should define a vocabulary for all the terms the WG will be
using in the spec.
... he showed an example of a vocabulary.
... next Greg showed a source file that describes the proposed
RDF vocabulary for verifiable credentials. This vocabulary is a
deliverable of the WG per the charter.
drummond: asked if the machine-readable format of the vocabulary was normative. He was surprised that the answer was no.
liam: clarified that it is up to the WG to decide whether the machine-readable file is normative or not.
gkellogg: proposes that there is should be a repository that these vocabulary definition documents. The proposed location is github.com/w3c-vcvocab/
liam: asked if it needs to be in a separate directory
gkellogg: new decision: these
documents should go in the same directory as the data
model.
... we also need a URI to identify the JSON-LD context that
should be in the W3C namespace.
<dlongley_> JoeAndrieu: I'm trying to navigate basically revising the use case document.
<dlongley_> JoeAndrieu: The scope of the conversation I want to talk about is ... we also have the user tasks, that's in teh solution domain, issuing, storing a claim, etc. I want to talk about the problem domain. What's the real value prop for users?
<dlongley_> JoeAndrieu: A lot of these are cookie cutter. If you were using the basic verifiable claim thingy, look at what it can do for banking, finance, healthcare, etc.
<dlongley_> manu: Tiny input on that, sometimes it's ok to have cookie cutter stuff. It's a comms doc to the broader community.
<kimhd> JoeAndrieu: bunch of issues; looking at them in spreadsheet
<kimhd> ...we'll talk through criteria and get feedback. we're currently expanding to determine what we've missed, then we'll pare it down
<kimhd> ...if it's in the charter, gets higher weight
<kimhd> ...determine why use case "unique".
<kimhd> Varn: what do you mean by unique?
<kimhd> dlongley_: does this mean it produces requirements?
<kimhd> joeandrieu: these are use cases that map out distinct things that are important, determine if they are in our document. Example: revocation not detailed
<kimhd> ...if not unique, can be derived from other one
<kimhd> ...other criteria capture value to implementers, market, stakeholder
<kimhd> ...whether well-formed; it is single transaction?
<kimhd> ...prefer clear use cases, single tx
<kimhd> ...pain point is clear, quality of title and scenario
<kimhd> ...determining how to weigh criteria. whether or not in charter may be more important than market
<kimhd> ...might be missing some, some may be taken out, some we possibly could make better, then score. This could lead to better definitions of use cases
<kimhd> ...get folks to volunteer to share values on weekly call
<kimhd> ...above is approach
<kimhd> ...i.e. if need new criteria, then we can add that. so goal is to pop up a level and make sure we have solid use cases and criteria
varn: asked about the "but for"
test -- comparing a tech solution to other solutions.
... he recommends that the use cases document could also
communicate the answer to the "but for" question.
... second piece of feedback is to have an overall narrative
story and technical story.
JoeAndrieu: Has 3 responses. First, use the overall engagement model to provide an overall narrative. The challenge is that "Jorum" is a 6 page document that would be very difficult to translate into a more concise use case documents.
The engagement model is a 15 stage progression.
It also defines the system's responsibility at each stage.
JoeAndrieu: added one more criteria for selecting a use case, which is how "innovative" it is.
gkellogg: normative statements in specs derive from requirements which derive from use cases. Does that help organize/prioritize?
dlongley: Use cases are BOTH a communication tool and a requirements source. For the former, there are multiple criteria for each of these.
<kimhd> dlongley_: best use cases are great communication tools
<kimhd> JoeAndrieu: need fewer, we'll cut out weak ones and define best
<kimhd> varn: charter distinguishes between primary (e.g. education) and secindary
<kimhd> dlongley: important to reduce criteria, otherwise hard to rank
<kimhd> varn: we have to produce a requirements doc. specifically, develop use cases and requirements
<kimhd> joeandrieu: score each use case. did it make any sense? And that will help us fine tune the criteria
dlongley: how will we figure out which use cases to drop?
gkellogg: Can we rate them by greater social value vs. commercial value?
dlongley: each use case can serve either for communications value or requirements value or both.
JoeAndrieu: All 12 of these proposed use cases are good candidates.
dlongley: "I don't think these use cases will be useless"
cwebber2: the Social Web group
did a huge amount of work on use cases -- it makes sense to
limit it to the core use cases on which there is a high sense
of value.
... narrowing it down to 3-4 primary use cases would be
good.
JoeAndrieu: There was a much
larger set of use cases before I got involved. Then it was
reduced down to the ones represented in this spreadsheet.
... trying to find a way to further narrow.
varn: the charter says the first
set of use cases has to be in education. Then we can add other
use cases, e.g. refugees.
... also suggests that the ones where we added new dimension,
such as guardianship, e.g., a mom registering her kids for
school.
... that can cover both education and delegation.
... the others in the charter included digital offers,
receipts, and loyalty programs.
<Zakim> liam, you wanted to comment on charter requirements
JoeAndrieu: Besides the requirements, we need the use cases that help define the "sticky wickets" -- the difficult problems that it is not clear how to handle.
liam: Suggests we should have 2-3
use cases in the area of education. Then there should be a few
more. There should also be a strong privacy and security
criteria in every use case since that was also in the
charter.
... in XQuery, every book and university course cited the use
cases that were in the use cases document. They are a huge
outreach and evangelism opportunity.
... there were a dozen use cases in the XQuery spec.
... It really can be helpful in that regard.
JoeAndrieu: "My task is to lead us to a more condensed set of use cases."
dlongley: The feedback in the Self-Sovereign Web session was that we needed more stories, and more of them needed to be commercial.
cwebber2: Welcome to the VC Test
Suite topic.
... Introduced the test suite design. Manifest is the
description of all the tests. The driver reads the manifest,
talks to issuers and verifiers and puts out the results.
... showed examples of portions of an example manifest
file.
... the driver either takes the reference issuer and/or
verifier code, OR you supply your issuer and/or your
verifier.
The manifest file specifies if a given test should pass or fail.
scribe: The log file includes the
results of each test.
... Current status: more tests are needed, more issuers and
verifiers are needed, more human-readable documentation.
gkellogg: There are some additional requirements. A test report puts out an individual result. Greg has a tool that compiles these into a larger report that measures multiple individual reports to aggregate them.
cwebber2: Suggests filing github
issues with feature requests.
... all the hard work has been done by Manu and David Lane.
dlongley: anyone else who wants to contribute needs to code up implementations that meets the test interfaces.
cwebber2: wants people to use the test suite and how to make it better.
gkellogg: We need people to write tests and exercise the suite.
dlongley: we now need to figure out what other tests we need to have.
varn: What about the ZKP claims that @nage proposed?
dlongley: it should still fit into the test suite.
cwebber2: The model does not
technically specify the serialization format. JSON-LD is used
by default.
... so how would we test something that's not JSON-LD? His
answer is: replace both the issuer and verifier.
... to run it, it's a python script, you specify the issuer and
verifier as URIs.
... you could even have your script call out to some other URI
to run it.
varn: the action items are: 1)
expand the read.me file about the tests
... 2) get other implementers to use the test suite -
specifcially for the ZKP claims
... 3) test more things - expand the tests - and tap Greg for
his expertise.
... we declared success and ended the topic.
The dinner location is ***New England Lobster Market and Eatery***. It is only about 10 minutes away.
varn: checked the agenda to see
if there were any more items on today's agenda.
... The meeting is officially over for today.
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/reto/arnaud/ Succeeded: s/PROPOSAL/PROPOSED/ Succeeded: s/wood/dwood/ Succeeded: s/be used/can be used/ Succeeded: s/nage: ??/nage: Jan Kamenisch/ Succeeded: s/ggg/gg/ Succeeded: s/holder/subject/ Succeeded: s/slides// Present: Arnaud_LeHors Benjamin_Young Charles_Engleke Chris_Webber ChristopherAllen CyrilV Dan_Burnett Dave_Longley DavidChadwick Drummond_Reed Gregg_Kelloggg HadleyBeeman J-Y_Rossi JeanYvesRossi Jeff_Jaffe Joe_Andrieu Joerg_Heuer Kim_Hamilton_Duffy Liam_Quin Manu_Sporny Matt_Stone Natasha_Rooney Nathan_George Richard_Varn TimBL jean-yves Found Scribe: manu Inferring ScribeNick: manu Found ScribeNick: cwebber2 Found ScribeNick: cwebber2 Found Scribe: nage Inferring ScribeNick: nage Found ScribeNick: nage Found Scribe: Drummond Inferring ScribeNick: Drummond Scribes: manu, nage, Drummond ScribeNicks: manu, cwebber2, nage, Drummond Agenda: https://goo.gl/iC6tSq WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: add burn chairs comment editorial is s should we what WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]