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

Mission and Goals

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.

Agenda Review

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.

Candidate Recommendation Process

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.

Documents and Background

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.

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

verifiable claims where subject is not holder

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

RDFS/OWL

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

VC Use Cases

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

test suite

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