W3C

- DRAFT -

Verifiable Claims Working Group - W3C TPAC 2017

10 Nov 2017

Attendees

Present
Charles_Engleke, Chris_Webber, Dan_Burnett, Dave_Longley, David_Singer, Gregg_Kellogg, Jarlath, Joe_Andrieu, Joerg_Heuer, Manu_Sporny, Matt_Stone, Nathan_George, Reto_Gmur, Richard_Varn, jheuer, Liam_Quin, Quing_Ai, kimhd, KimDuffy, ChristopherAllen, Alexandre_Bertails, David_Wood, Fabien_Gandon, CyrilV, Jean_Yves_Rossi, Jean-Yves_Rossi, David_Chadwick, Ed_Bice, Sandro_Hawke, Emmanuel, Chris_Needham, Aviv_Chandya, An_Xiao, Emmanuel_Vincent, renato
Regrets
Chair
Dan_Burnett, Matt_Stone, Richard_Varn
Scribe
manu, kimhd, gkellogg

Contents


<DavidC> I saw Liam connect to Webex but there was no sound

<DavidC> Should I leave Webex and join after Liam has started it?

<manu> scribe: manu

Identity Verification

varn: I have worked on identity management and getting government systems to improve their identity management process.
... I've worked as CIO, elected to office, etc. - working on this problem for a long time
... Working at ETS now... have questions - trying to see what answers are from the group.
... Keep in mind, we're not trying to "solve identity on the Web"...
... We are merely putting a spot in the credential for identity proofing, we're not doing identity proofing.
... we have multiple levels of assurance in the real world.

stone: Having an OBI compliant product... we don't know who anyone is from an identity perspective, we just know a badge was issued to an email... whoever has that email account has that badge.

varn: Identities we've discussed, we've talked about holder, issuer, verifier, agent, broker.
... If I say I'm a guardian, agent - holder of - you want to associate that w/ something noting they are who they say they are... don't know if there are differences for each of those roles...
... What kind of elements in the data model facilitate identity verification... what interfere?
... Are the needs different for each of those roles.
... I may have to show other things to demonstrate a verifiable claim belongs to me.
... There is this idea of a "claimvelope" - what's inside, what's outside?
... Looked at updated NIST spec, 800-63C - you need to specify assurance level - assert level to recipient agency

cwebber2: This is about how people authenticate... do you use two-factor, biometrics, government issued crypto card... do we need to put this in data model?

<DavidC> the access code for dialin 311 081 351 does not seem to work today

varn: We may need to define envelope to say what one needs to access or use the credential
... You may not want to expend resources even looking at it if the envelope....

JoeAndrieu: Identity is a means of tracking people, everyone does it in a different way.
... We don't have a field to say "use this to identity proof the individual"
... From a technological standpoint, the LOAs are useful, but they're undergoing change.
... There is work around identity metamodels - there is no one way to think about it - we don't know who anyone is... based on "security mental model" - reducing subject in question to a physical body, that's only one way to talk about it.
... Liberty mental model - my identity is how I choose to participate in society - there is a tension between security and liberty mental model.

varn: You mean, there is pseudonimity and there is privacy.

JoeAndrieu: 3rd mental model is data - your identity is what data we have on someone.
... 4th is ?social? - it's that identity is a social construct.
... 5th Identity is capability - based on object capabilities conversation - this is how american strategic deterrence works ... we don't care if you are good, we care about your nuclear capabilities. Other than saying, sometimes we think of it in one way or another.
... The issuer, verifier, subject, and holder - they need to have identity architectures and we don't have that. SSL has bundled into it a certain architecture against phishing... domain name and certificates.

varn: If I want to know if a corporation can speak for itself - if people can speak for company, issue a cert for it to back it up. Their HR system, won't go back to source identity document, they just use an identifier assigned to it.

JoeAndrieu: This is all contextual

varn: Can you boil what you said down to our data model, Joe?

JoeAndrieu: For places that we have identifiers, we need to say how you proof an identity. DIDs have it baked in, but you can have any URL, what do you do there.

<Zakim> manu, you wanted to note those aren't identities, they're roles. and to note how many of the DID-based verifiable claims are addressing this problem - biometrics, signature

<cwebber2> manu: the first comment is we made a very conscious decision to not go deeply into identity so as to not rabbithole... I think we're on the edge of that. what we need to make sure the wg delivers is that we have hooks to do the mechanism not the mechanism itself

<dlongley_> +1 for hooks to help address the problem, not addressing the problem

<cwebber2> manu: holder / issuer / verifier are *roles* in the system, not identities itself

<cwebber2> manu: what do we have in the spec right now that supports this? right now we have did based methods with public/private key crypto, a signature ... allows the issuer and holder to be strongly identified, at least with a signature. signature based identification

<dlongley_> i would say strongly authenticated not identified

<cwebber2> manu: another thing we've been speaking about in the ??? space is biometric based identification / verification

<cwebber2> manu: signature based identifiers covers every level of assurance up to the strongest level of verification up to the biometric level, and the biometric level covers everything else. our current model allows us to all ???2. DID space allows you to have proof of that individual based on signatures or potentially biometrics. the way you do that is you get the did document that gets that information, you can look up from there what

<cwebber2> their verification mechanisms are. should work with any url that allows you to fetch identifier and have that information in there

<cwebber2> manu: we've specced out how to it with DIDs loosely, but not other mechanisms

<cwebber2> varn: California has a set of biometric info but they give you the ability to phone in to get the field. e-verify says "I give you the data profile and go look"... it doesn't seem like dids have that

<cwebber2> manu: DIDs do, they have an evidence field where you can say "we use so-and-so-document to say who you are, and if you want to verify it you can phone in to see it"

<DavidC> > liam. Thanks. I am following the discussion on the chat

<cwebber2> varn: the evidence field deals with why you earned the credential, not who you are... it's the test you took

<cwebber2> manu: I was thinking it could do double duty

<liam> [ liam trying to arrange dial-in but room phone in hotel meeting room seems faulty ]

<cwebber2> manu: it's evidence for getting the credential or proving the individual

<cwebber2> manu: I completely take the point that we might not want to conflate them

<cwebber2> manu: we could say here are the documents we used... and btw here's the 1-800 number

<DavidC> I could do with that :-)

<cwebber2> manu: so the concrete proposal is let's consider an identity proofing field which is optional? It's the hook which allows for proofing

<cwebber2> varn: that would be a field in the data model but would it be...?

<cwebber2> manu: in the verifiable credential

<cwebber2> manu: encapsulation model is set of claims, verifiable credential around that, and around that a verifiable profile

<cwebber2> manu: if you want to publish your verifiable credential in a webpage you can copy-paste it\

<Zakim> burn, you wanted to agree with manu and say that we need to avoid the word identity

burn: I'm nervous when we use the word "identity" in our documents - I thought it was intersting that all of the identity proofing mechanisms could be claims in a credential... just a caution that we be careful about use of word identity... "identity roles" scares me.
... Every time we mention "identity", it takes people away from this concept - there is something associated with the role - you're talking about a bunch of claims... My physical body is not in a computer... we can take a photo, iris scan, all different levels - that's why we had this group in the first place... people were using "identity" to address a collection of claims that could be verified. Let's be very careful to not shoot ourselves in the foot.

<liam> [ AV people came into the room, scratched their heads, went off to check the line ]

nage: When we start crossing the line to the vocabulary - we may want to change that... what's minimum viable data model that works there? What makes your data useful? Maybe we should have recommendations for what vocabularies are useful... but add that to your vocabulary.
... When we start talking about the role, how do we prove possession... if we start to disclose proofs into identity proofing... better suited for claims exchange to make sure signed data exists... if we try to bind stuff directly to DID spec, data may be immutable and public... so, we have to be careful to put those pieces in the data model in the right place... so we can achieve a privacy preserving system.
... In the DID world, you can go talk to the key in question... you can just do claims to finish the authentication process... I could do traditional cert signing chains... I have hooks to talk to people... you can push all of that out of the spec, which helps.

cwebber2: You mentioned having a chain of things... the very last one - having a chain... that's basically what the capabilities paper says... there may be a distinction between current data model vs. what we may want to do w/ capabilities.
... Our current data model says that we are claiming something... you can translate much of what we're doing to a badge you're showing. If you're getting into space of getting people to invoke something, or if we want to hand someone else a method... "to be managed by an agent/broker", in that case we're getting into capabilities.
... So, we need to be careful about how we're addressing some of these problems... is it a data model problem... or a delegation problem.

varn: What's the difference between agent/broker?

<dlongley_> agents have only your interests in mind, brokers have other interests.

varn: agent is a personal role - standing in your shoes... broker - party that has made a business model about making transactions connect - don't know if that's useful - but we may want to talk about commercial role - seek credentials....

<nage> In Sovrin we have a construct of a search or discovery service (a matchmaker) that fits this idea of a broker. In some sense they are both entities with delegated credentials to do something.

stone: We're getting onto other topics - come back to this - if we generalize, push the thing out to other places. Can we simplify our problem and reduce our focus to not include this as something we're trying to solve... just say "this is where it should be solved" and push it out of the group.
... We may want to speak to this in the spec... describe where it should go.
... Let's raise an issue on how we discuss this.

JoeAndrieu: The presumptions on how it could be solved may be in our data model.
... I'm not sure it can live in the claim alone.

<burn> ACTION: nage to create issue/pr describing how we can address identity verification via updating the vocabulary in the credential itself

<trackbot> Sorry, but no Tracker is associated with this channel.

<dlongley_> the meaning of an identifier and how it is treated is not unique per individual, so it shouldn't be information that's in the claim, but in the vocabulary for that reason as well.

JoeAndrieu: We're going to have baked in assumptions on how proofing is done in the data model... if we put too much in, we may violate privacy... if we don't put enough in, folks will come up with their own broken way of doing it.

<Zakim> manu, you wanted to note that we're trying to minimize terminology to ensure that it's easier to talk about all this stuff w/ others

<dlongley_> manu: Touching on the broker thing. We're trying to minimize the language in the spec so it's more composable and generalizable so it fits in with other W3C tech. Let's not put broker in there or if we put in it as another type of agent (different priorities). Let's minimize language in spec.

cwebber2: I think broker situation is already handled in the spec... you can already make a claim, "this person is a broker", what a broker would do is not a part of this spec... I also keep hearing "we can't ignore that people need this sort of thing".... what I don't want this group to do is "hard code" the delegation model.... so, we should either not solve it, or do the right thing.
... We should either decide to take on object capabilities... or not do the work... we shouldn't do something half-baked.

<burn> queue will freeze when varn is done

cwebber2: We don't want to create "confused deputy" problems...

varn: discoverability - one of the primary use cases, the seekers of credentials, want others to do credentials. Don't know if we can do those four things.
... These things are not point to point - if you don't have a way for them to be found, sorted, managed - it won't work very well. We end up with way too many transactional activities... we have bad examples of what happens when we put too much on plate for people's decisions - find the right things.

<burn> queue is frozen

<Zakim> liam, you wanted to note that ideas like "broker" can usefully go into use cases without defining it as a piece of jargon

gkellogg: We should guard against role creep - broker is interesting, but we might think of many different types of roles... the bias should be toward the minimum thing that we can do to address requirements... in tabular metadata - we established a role called a viewer... but no one created that role. So we had something in the spec that no one created... if no normative requirements derived from a role. Agent is fine for now, no need for broker.

liam: Ideas like "broker" and "delegation" - there could be a use case around it - we can talk about it in use cases document.

<varn> We should run the issue of broker by real brokers who already sell billions of dollars of services in the market.

liam: You can use the term broker in use case document without including it in the spec.

<Zakim> manu, you wanted to talk about discoverability.

<dlongley_> manu: I think discoverability has come up multiple times. I think there's a mismatch ... Google does a really good job at this. If you do, show me a great sushi restaurant around here ... they give you a great response. How do people find credentials, qualifications, etc... is that what you're talking about?

<DavidC> >Liam. What are the details for new teleconference

<dlongley_> varn: I may want to publish the entire credential, everything, anything you want to. However, you may only want to disclose only certain parts or elements of the credential. You may have some descriptor --- you may also leave some unencrypted space where you leave data in the clear that are relevant to the discovery process.

<dlongley_> +1 to use case for this

<dlongley_> manu: The use case isn't clearly defined, I think there are multiple use cases here and we address 80% of them today. schema.org+search engine addresses "i want to learn something new and who can teach it to me".

<dlongley_> varn: A credential to teach people how to learn things?

<dlongley_> manu: Absolutely.

<dlongley_> manu: Another example is I have a webpage -- not linked in -- here are the things I can do. That's use case number 2. One has to do with I want to learn something and the other is I have learned something here are my qualifications.

<DavidC> >Liam. Its working. Many thanks

<dlongley_> manu: We are absolutely working on that and the outcome of this group will enable those things to be achieved. You also have another set of smaller use cases around negotiating stuff. We're working on these things but I don't know how that maps onto your mental model.

<nage> With respect to repos like schema.org the identifiers you reference must have the proof of control or proof of possession guarantees you require (including immutability) or you can't use them for cyptographic validation

<dlongley_> varn: We can deal with the gap in understanding offline. Find a job, find an educational opportunity that fits me. You may be recruited, etc.

<nage> This is true of URLs just like other kinds of identifiers like DIDs

<dlongley_> varn: Those are two in the use cases that I don't think they aren't being addressed today.

<dlongley_> manu: I would argue those are out of scope.

<dlongley_> varn: That's in our use cases.

<dlongley_> manu: The system that has the data model for putting up a job board, etc. is out of scope.

<burn> queue unfrozen to propose wrap up / next steps

<dlongley_> nage: Let's take the identity proofing (vocab vs. data model) to a PR.

Implication of Credential Creation v. Presentation

Credential Issuance vs. Presentation

nage: Are there any clarifications we need from yesterday? JSON-LD graph model vs. CL proof style model....
... There are probably some clarifications that can happen in person - tools that are available from JSON-LD side that CL-side - we may need to use tools, or explain why we need to make changes.
... Any identifier that we use in the system has to be valid for chain of custody in crypto... that's why we identify references - in order to walk chain - thing that you issue against, can't be changed.... referencing schema.org for schemas... mixing and matching IDs in claim... we have to use the least common denominator for proofs that are provided. For example, I need to put schemas out on schema.org.... if it's possible to be changed outside of key - can't

be sure that that can be validated outside... especially problematic to URLs, resources aren't managed... you'd have to sign everything all the way down or you can't guarantee proof of possession is managed all the way down.

nage: Least common denominator allowed is sufficient for validating what you need to validate... guarantees are good enough... domain is controlled by who you think it is... wan tto make sure you're not misleading dev to ensure a strong crypto proof is provided.

gkellogg: wrt. "put the schema in the blockchain"...
... RDF uses URIs so that you can find things and so we can intersect on meaning... for properties, let's say you use schema.org/name... when a signature happens, everything is normalized... this is linked data... I should be able to follow my nose to schema.org/name to find what that means.
... Will schema.org change? Yes.... but within context of document, does that change anything. It only changes anything if toolchain relies on reasoning
... schema.org publishes other datasets to correlate their vocabulary - in case of schema/name, it might have something "sameAs" that correlates... I can reason to find things... it aids interop.
... That's not something we do in the context of verifiable claims - signed document that's treated at face value w/o retrieving other info during processing.

nage: This is one of the problems that we might want to get into selective disclosure - we might not need that all the time...
... How is it normalized, can I trust this document, I need some tool.
... When meaning changes, I need to be able to detect that...

gkellogg: Let's say we don't want to rely on external definition - we may need to embed vocabulary definition in there... I have two things, they have different definition of what name means... the only way to know that they mean the same thing is to rely on inference chain.

JoeAndrieu: If you are downloading anything, what you download can change... if you download context, then you're at risk.
... There are all sorts of reasons why resource behind URL may change... don't know if this is the right answer - fundamentally, it'll change.

nage: The problem is that you can't trust cryptographically that that's not the case. You have to have ability to do full validation.

<Zakim> burn, you wanted to suggest we put some focus on 'the context of the document'

burn: I've heard Nathan talk about context of doucment or its use - that's not something I remember seeing in document or what we describe... we don't talk about intended use, but it's that context that has led you to that archiecture and demo that you talked about yesterday.

cwebber2: The concern that you have about context changing is not unique to this - we have the same issue with anyehwere else that uses a semantic context...

<burn> queue freezes when cwebber is done

<burn> queue frozen

<Zakim> manu, you wanted to note that there are solutions to this problem - content-addressible contexts, one-off contexts.

cwebber2: The argument is that vocabularies should stay stable... they can grow, but meaning should not change. The challenge that you're correctly identifying is if context changes, but what you want is a content addressed representation - it's not an impossible problem... you can store it at the very worst as a tuple... content location and hash. All identifiers you're referencing - they all give you certain guarantees. When you do cryptographic verification, yo

u have to make sure that works.

<dlongley_> manu: Following up on what Nathan and Chris said, it's not an impossible problem, every group dealing with a semantic context deals with this problem. Use content-addressed storage, I'm wondering if we want to do something in JSON-LD 1.1 -- a design pattern for providing a hash for @context.

<dlongley_> gkellogg: Some proposals have come in.

<dlongley_> manu: Hand waving around it is not good enough -- this is how you do content-addressing around contexts, that would deal with "name" changing over years.

<dlongley_> cwebber2: That's external to the model too, it's a real world thing.

<dlongley_> manu: When you create an array with selective disclosure, it's a one off context. We should think through how you do that. We may come up with another pattern for that, maybe don't use schema.org for that and there's something else that gives you a reference and so on, details to be explored.

<dlongley_> nage: Maybe we could get it so we can do CL-signatures against any JSON-LD and that would be cool.

<dlongley_> +1

DavidC: This is about the schema not changing... trusting the schema... we should have a trust model in the data model - if we trust that the schema should not chnage, we should mark it as a security issue. I've worked on X.500 since its inception... 1988... group said they wanted to define schema... no problem w ith schema being fixed, don't change schema once it's fixed.

<burn> queue unfrozen to propose next steps

burn: Next steps...

<DavidC> Not SSL, X.500

nage: Manu and I can close gap between CL Signatures and JSON-LD to make the crypto fit... the other mechanism, mechanics if you have data structure for CL data structure in signature, we should discuss that.

<burn> ACTION: PR for how crypto hooks are expressed in sig block

<trackbot> Sorry, but no Tracker is associated with this channel.

<scribe> ACTION: Nathan to create description around cryptographic guarantees of identifiers being used.

<trackbot> Sorry, but no Tracker is associated with this channel.

<burn> ACTION: nage to propose description about crypto guarantees around identifiers being used to make url useful

<trackbot> Sorry, but no Tracker is associated with this channel.

<scribe> ACTION: Nathan and Manu to work together on how to do content addressed JSON-LD contexts.

<trackbot> Sorry, but no Tracker is associated with this channel.

<gkellogg> JSON-LD issue on content-addressable contexts: https://github.com/json-ld/json-ld.org/issues/547

<scribe> scribe: kimhd

Credentials Community Group

ChristopherA: announcement of new co-chair JoeAndrieu
... succeeded with original charter of rolling out VC
... focus on verifiable credentials
... this work includes larger picture items -- inclusive solutions, not exclusive
... many of us are committed to self sov id, proofs by bearer, data minimization, but also include centralized and federated in addition to decentralized
... we're a CG; limited in what we can do under W3C. We can create draft specs that have weight
... basis for subsequent standards track
... also prototypes and test implementations
... not good enough just to release a spec. want to anchor in user stories and use cases.
... we deliver test suites and -- new category -- primers. Primers are for educating about this work
... work items
... went through collaborative and consensus seeking process
... we'll give more detailed about a work item DID

DIDs

nage: skipping over background context
... instead of "renting" a namespace, you can own it outright
... many interesting DLT to help enable
... DID characteristics: identifier that's yours that can be resolved globally
... did syntax did:<methodspec>:...

method determines how to resolve method-spec identifier

scribe: list of 7 method specs: sovrin, btcr, uport, v1, ipfs, ipdb, stack

ChistopherA: did top level spec says what method specs need to define, method specs define how

Nage: similar to dns name resolution

arnaud: who manages list

nage: models closer to a CA, pick which roots of trust

christophera: we want implementers to submit method spec to a WG

nage: at this point, registry at DIF

gkellog: would IANA come in

christophera: can be part of w3c process

<burn> Sounds similar to IANA's 'specification required' registries

cwebber: have a good justification for including "did:" at beginning. we may have a protocol for interacting with. allows being able to have clear components

nage: there is a universal resolver

christophera: possible to move did from 1 chain to another, but no details yet. E.g. btcr to v1

nage: each blockchain has different trust guarantees

manu: to w3c folks. this awoke Dan Conelly and Larry, they are interested in approach. Larry Masinter worked on original URI spec. they are still catching up, but we can bounce ideas off them

nage: target system, syntax, CRUD (not all have to provide all ops)
... returns a did document
... primary elements: did, list of public keys for verification, list service endpoints for interaction, created ts(not always), updated ts (both for audit), signature for integity
... updated ts can violate properties of chain -- can be harmful
... each registry may accomplish differently

<Zakim> manu, you wanted to mention DanC and LarryM

christophera: one arch decision early on was to not have the did a public key. want way to rotate

<Zakim> gkellogg, you wanted to ask about finding current/latest version of something in the blockchain

nage: intent is that did is an identifer, and key can be rotated underneath
... paths and fragments
... fragment references part of did doc
... path points to a resource "rooted" on did
... mechanic to prove you own identifier
... lots of issues in the spec, e.g. requires ld parser? are names intuitive?

gkellog: try to not distinguish btw jsonld and json

nage: more of education issue

christophera: we've proven it's feasible

nage: actual implementations are informing issues/suggestions to spec
... key descriptions: what does it mean?
... service descriptions: agreeing on universal properties
... other possible signature types; other form of presentation proof

<stonematt> can we put the link to the primer in the IRC?

ChristopherA: more info on current state available at primer, RWoT OCAP feedback, and IIW hardening proposal

DID primer: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/did-primer.md

christophera: reached consensus about some capability features at RWOT
... feedback from IIW was around implementation, naming, etc
... rwot, then hardening -- these are forks, not incompatible
... there are at least 6 companies implementing and an open source one
... blockstack just announced they are doing it
... moving over names from onename

nage: allows persistent ids, things outside cookies, dns names
... many things you can do when you have decentralized key mgmt
... privacy by design: can root things besides a person; can root things under person's domain
... designed ground up for GDPR compliance

gkello: "rooted in domain" implies correlation

joeandrieu: "domain of control

<Zakim> betehess, you wanted to ask about GDPR connection

betehess: is anything written about gdpr?

christophera: there is a draft at RWoT5
... deloitte london independently came up with same set of solutions
... possible arch for future

nage: each did can create an encrypted private p2p channel

<Arnaud> http://www.deloitte.co.uk/smartid/

<ChristopherA> Here is the draft from #RebootingWebOfTrust https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/GDPR-Self-Soverign-ID.md

nage: github repo to do TLS, can treat root of trust as distributed ledger
... decentralized id stack. did layer (where persisted). cloud layer services, edge agent (id owner interacts with)

christophera: trying to design for features like key recovery (e.g. social). premature to spec, but many are thinking about

nage: flat mechanism for idfrs. no registries
... another name is dpki
... can attach vcs

<Zakim> liam, you wanted to ask whether "cloud" third-party hosting is an essential feature

liam: comm via cloud layer. sounds untrustworthy
... can I do without cloud layer?

<stonemat_> q/

all: we mean internet not cloud. don't have to use corporation "cloud" providers, ...
... we have to be able to deal with compromise at cloud layer

nage: seeking feedback from implementers

gkellog: what if dns is compromised?
... could web be did based?

christophera: yes...some discussing

nage: isn't implying transport layer

jheuer: on edge layer, can work with hardware on devices
... can make use of security measures
...now: looking for a plce to bring this
... has taken a few years, is open. have discussed at iiw. he wants to find a vertical use case that makes sense
... does anyone have a lot of traction?

<Arnaud> +q

christophera: employer has satellite services.
... if we have any appealing e2e scenario

dlongley: sso with dids

jheuer: but want unique

joeandrieu: ... in a few minutes will present scenarios to address

<dlongley_> the original use case for DIDs, when the term was first coined was for p2p payments

joeandrieu: dids aren't meant to be human readable
... more like ip addresses
... directionality different for dids

<jheuer> jheuer: have a wallet prototype which seems to fit the bill here: HTML5/ JavaScript implementation, encapsulating various mechanisms - DIDs could be

ChristopherA: was asked by TBL why w3c should be using. answer: inter stack problem. at user level, I need control
... may have to take subset to ietf

<jheuer> jheuer: the software framework supprts various communication channels and device-based security (like SEs, TEEs, OS-based things...)

<jheuer> Seeking for sceanrios and ideas how to incroporate if put out to open source

cwebber: with dids we can smash cloud layer
... can reduce distinction; don't need with dids

Arnaud: bring to other groups sooner; make sure they agree with legal implications

christophera: wg barriers too high.

<Zakim> liam, you wanted to discuss advertising cases

liam: started a business group, interested in dids as anon identifier, can be tied to info about idfr for targeted ads
... browser would send 1 idfr, reduced privacy leak

<Zakim> manu, you wanted to note advertising doesn't necessarily have the same motivations that many of us do.

manu: re ads. they don't care abt individual, jsut about ad match
... many are universal tracking ids
... have to be clera abt their motivations

credential handler api

dlongley: 2 pieces: issuing web site can issue cred to user. user can store in a digital wallet. other website can request credentials
...step1: credential repo (like wallet)
... need to get a wallet
... request installation of cred handler
...step2: auth site to become a cred handler. enables web site to enable hints in browser. meaning up to wallet and user (social id, bus id)
... may be separate hint for each, or single
... cred handler is given js to register in browser
... go to issuing web site. dmv might give digital DL. may be atomized creds
... if logging in with dids, can provide proof of possession without creating accounts.
... web site requests storage, step3: individual approves
... when make a request, browser shows hints. user sees "browser wants to store", pick a context. can be implemented many ways
... browser sends info to cred handler. other site can ask for consent
... can chose to store cred
... after stored, need to be able to use
... visit a verifier site (e.g. buying an intl plane ticket; requires passport)
... web site requests passport using js. contextual hints are shown. Which id do you want to use? selection => event sent to cred handler api. "requesting passport" prompt
... ui can vary

gkellog: over time, might have many different creds. is there some provision for filtering?

dlongley: yes, we'll cover
... can have payment handlers that only accept certain kinds of payments
... built polyfill, supports lots of browsers
... if websites include, anyone running can use code
... many major browsers.
... polyfill doesn't need to be installed by user. site that uses must include
... provides functionality missing in browser
... coverage 3.3 of 3.8 billion (based on browser coverage)
... demo
... links in slides (requires privacy setting change in safari)

manu: showing live demo

dlongley: issuer can include how to render type of credential
... issuer decides how it looks
... if browsers don't implement soon, we'll use polyfills

?: concern is that we're training users to accept UI as privileged UI

dlongley: what is recommendation?

<scribe> ?: unknown

ChristopherA: pushing up to you guys to signify that these are js, non-browser based things

manu: there is a security model, there is sandboxing. problem is central domain to host polyfill. using iframe

stonemat_: what is business risk of being an early adopter?

manu: digital bazaar will deploy to prod. security is biggest concern

jheuer: similar impl -- mechanisms were not entirely secure. interacting with os should be discussed. digital wallet -- expected to be able to work without connectivity

kimhd: arch recommendations tbd
... recommend 2 pixels of separation to indicate from browser, not site. concern that it looks like browser

manu: wallet site can notify in the manner they want e.g. mobile

soareschen: peer ids. id provider can request login url that looks native
... request for addtl perm. probably way to polyfill
... via webrtc

dlongley: layered verifiable profile on top. can also layer oauth
... talking to chrome team; how it might assist with oauth. they are interested
... 10 developers in chrome that deal with id
... follows same pattern as web payment

manu: underway encrypted card, support new payment method, ...

lifecycle

joeandrieu: davidc and joe had different approaches. included links to each. david's looking at lifecycle of a claim. Joe's based on information lifecycle engagement model
... uses model for Syrian refugee who landed in greece. 15 stages. each 1-2 paragraphs cover human experience

<DavidC> the latter

joeandrieu: working on thru credentials cg. woman amira programmer. wants to do programming anonymously. not risk job, family, etc
... goal is to show what difference it made for a given human being.
... focus is human experience

<JoeAndrieu> Draft of Amira 0.1.0, A Self-Sovereign Web of Trust Engagement Model https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/Amira-SSWOT-Engagement-Model.md

christophera: same model from edu space. We need to add more scenarios

<JoeAndrieu> Joram 1.0.0 Information Lifecycle Enagement Model http://bit.ly/joram100

christophera: medical, etc. we'll publish a couple

davidc: he's working on v1.0, not finished
... looking at how do ppl get identity attrs. natl name reg. how ? assigned. pieces of info are given by someone else
... everything given by issuer
... key points: summary. ppl who give info. degree can be revoked, nationality acn be revoked. you are not owner of id. might hold, but will be held by issuer

<dwood> Can someone please put the URL to the slides here again? Thanks.

davidc: identity theft...biometrics..(sorry background noise) =/
... mechanism is flawed. can steal stuff

<stonemat_> VCWG 2day slide deck: https://goo.gl/5NXb2v

<dwood> stonemat, I have the one in the topic, but not the pointer to the paper being shown

<stonemat_> W3C VGCG deck: https://goo.gl/4pc2FM

davidc: immigrants / functionally like baby. how to resolve? new id? roll over old?

<stonemat_> DavidC lifecycle document: https://goo.gl/S5fZeG

davidc: can masquerage
... need trust model
... simple trust model, schema change?
... 2nd version updates based on feedback. delegation by issuer to other issuer, by holder, by inspector
... dispute resolution
... negative creds
... holder not subject

advancing our deliverables

ChristopherA: a key question is how much more to do to move to standards track?
... form official wg? we don't know when. have not gotten resistance
... cred handler api similar
... is it wg? does it cross wgs?
... need advice about how to pass along?
... have supporting docs (use cases, primers, lifecycle, ...)
... not quite recommendations but important
... e.g. selective disclosure
... want to cover privacy from a more crypto perspective
... where do we draw line?
... potentially have lots of work items
... having difficulty getting thru everything. hackathons,
... patent concern
... looking for advice from w3c

stonemat_: can recharter VCWG with this?

manu: have work to do first

varn: cred handler api need to be done here?

manu: yes
... cred handler definitely belongs at w3c, more so than did

varn: other candidates?

christophera: discussing options about where items can go
... toss up

manu: TBL said DNS is achilles heel, and looking for options

<varn> squeet

christophera: blockchain groups, don't know what to do with them. Got encouragement

<DavidC> Hi Everyone. Sorry but I have to go now.

<gkellogg> scribe: gkellogg

Ed Bice from Medan, a non profit looking at colaborative … distributing citisen generated commontary during arab spring.

ebice: open source project allowing teams of people to verify/fact check or otherwise to claims, articles, …
... Also opened a sources feature.
... 1/2 years ago Check was the largest collaboration project sourcing and verifying reports from the field, some 320 news stories generated, idea to improve election in real time.
... We succeeded in some measure, but obviously (seamingly) failed ultimatey.

<JoeAndrieu> ebice: Check project recognized the need to share signals coming from journalists and fact checkers

ebice: we recognized the need for signals from journalists and fact checkers; 5 years ahead of misinformation crisis, but then were in the middle of it.

<JoeAndrieu> ... five years ahead of the information crisis and now find ourself right in the middle of it.

<JoeAndrieu> ... Credibility Indicators Working Group now renamed the Credibility Coalition

<JoeAndrieu> ... now includes platforms, Associated Press, research groups at Harvard, MIT, Berkley

<JoeAndrieu> ... In the room, we have Eviv? a researcher at Columbia

<stonemat_> https://meedan.com/credibility-coalition/

<JoeAndrieu> Sandro co-chairing the community group

<JoeAndrieu> [lost a few names]

<JoeAndrieu> ... Saw overlap with credibility indicators, especially credentials and the importance of reliable identification

<JoeAndrieu> ... especially in resolving disputes

<JoeAndrieu> ... I, for one, see the VC and CCG work as absolutely critical

<JoeAndrieu> ... the scaffolding annotation and credentials are essential to sorting information in a meaningful way on the web

<JoeAndrieu> ... Use cases:

<JoeAndrieu> ... In a news feed, in a browser, how do citations present?

<JoeAndrieu> ... Much of this involves negotiations with the platforms

<JoeAndrieu> ... can we get them to participate?

<JoeAndrieu> ... Seems like they want are interested in offboarding some of the burden, but ultimately it depends on their interest

<JoeAndrieu> ... For web search, we'd like to present during the websearch whether or not a returned result has been disputed for fact checked

<JoeAndrieu> ... if searching on a claim, whether or not that claim has been disputed, the sites asserting that claim and any links to the fact checkers

<JoeAndrieu> ... This community group started last week. These use cases are very aspirational.

<JoeAndrieu> ... The newsfeed use case, I'm not searching, I'm scrolling. I want to see a clear indicator that an item has been disputed and be able to navigate quickly to the detail or substance of that dispute.

<JoeAndrieu> ... It's the ethos of the software we build. A fact that simply asserts something is meaningless. One that shows evidence supporting that assertion can be interpreted by those reading the assertion.

<JoeAndrieu> gkellogg: who do you trust? seems like there could be an overloading of "authorities"

<JoeAndrieu> ebice: any meaningful discussion quickly goes to whitelist, blacklist, reputation, filtering.

<JoeAndrieu> ... right now, Facebook's strategy: they are working with IFCN. International Fact Checking Network

<JoeAndrieu> ... code of conduct is the bar they establish for letting in fact checking organizations.

<JoeAndrieu> ... Facebook says, ok, this is a way for us to have a reasonable assurance that fact checks submitted are worth surfacing

<JoeAndrieu> ... With this standard, we are opening a problem of third parties annotating web sites.

<JoeAndrieu> ... Esther Dyson said: we all believe annotation is a good thing for knowledge. When we bring that into the structure of the web, we need to think about filters and sorts.

<JoeAndrieu> ... if I own the page, I want to control which annotations I show

<JoeAndrieu> ... if I'm browsing *I* want to control which ones I see.

<JoeAndrieu> ... The platforms that are ingesting this markup will have to sort

<JoeAndrieu> ... As users start (through browser extensions) learn how to ingest and inspect, they will want to be able to fact check comments coming from, e.g., Macedonian troll farms

<JoeAndrieu> sandro: I look at it through a social graph & networking lens

<JoeAndrieu> ... every party is just saying things all the time

<JoeAndrieu> ... that includes statements about who they trust

<JoeAndrieu> ... by engine is calculating whom I trust. Within *my* world I have my own walled garden, with some tolerance for outside ideas

<JoeAndrieu> ... That's aspirational, but that's where I see it going

<JoeAndrieu> ebice: Newsfeed use case: If someone in my network is sending me clickbait or misinformation. I might want to see a graphic content warning label.

<JoeAndrieu> ... e.g., The originator of this content has been cited for publishing targeted information and has been funded by XYZ

<JoeAndrieu> sandro: I subscribe to NYT following reporting X, so it may say "NYT has labelled this an untrusted source"

<JoeAndrieu> cwebber2: seems to me you could achieve. Within a trust network, a new person coming in should be able to see what trusted people say.

<JoeAndrieu> ... you can start building up that web. If you reject that initial set, and subscribe to different organizations as a trust source, you would end up in the opposite territory.

<JoeAndrieu> .. If you really believe those are the canonical info... which is you seeing some consensus.

<JoeAndrieu> ebice: Trust and reputation are not always aligned. We need better systems that let us know when someone within our network that doesn't pass muster.

<JoeAndrieu> ... the only danger of a social filter is that trust can be a bit of a blinder.

<JoeAndrieu> cwebber2: yes, but within the online context, you don't have a way to correlate against the real world.

<JoeAndrieu> ... there is no way to know there is a banana. Someone has to go check.

<JoeAndrieu> ... INTERNET OF BANANAS!

<JoeAndrieu> manu: It seems like you guys are generating a vocabulary. VCWG will use that at some time. What's the timeframe?

<JoeAndrieu> sandro: Depends on the use cases. Some don't need VCs.

<JoeAndrieu> ChristopherA: VCs depending on consumption of identity, e.g., I work for the NYT, a claim issued by that NWT. Can we get a list of what those might be.

<JoeAndrieu> stone: we gotta run. we'll be back in an hour.

<engelke> join #wpay

<bigbluehat> scribenick: bigbluehat

Terms of Use / Time To Live (ODRL)

nage: the identifier is the attribute inside a credential
... what we bind to is proof of corelation

Attribute Based Credentials

nage: manu needs to be able to redact that...based on identification

ChristopherA: as soon as you move to selective disclosure
... you're binding to the proof
... and not to the data

dwood: this is super important

ChristopherA: this is why I stood up in the AC meeting and said "we need more cryptographers"
... Jan's been here several times, but we're not ready to understand what they have to say on this topic
... it's a big whole in this group
... that's why I keep saying that data minimization is important

nage: when we do a composite proof, we validate that all the creds are from the same secret

stonemat_: we're chartered to write a data model
... we've spent a lot of time describing how we're going to encapsulate this data that's not uncorrelateable
... is this a diff model that correlates that?

ChristopherA: you can't get to finality on your data until you get to the end of the process of proving that data
... when you're done with the proof process, then you can work on the data

nage: I don't know what the ID means until I've proven the signature

ChristopherA: you'll have to go through lots of nesting dolls to get to the thing you need inside the signatures

nage: you could do it that way

ChristopherA: that's what Schnorr(?) lets you do

<ChristopherA> Schnorr Signature

manu: that's certainly the biggest challenge

<nage> I am convinced there are multiple ways to do this that are too complex. The question is what is the minimum amount of complexity.

<JoeAndrieu> https://en.wikipedia.org/wiki/Schnorr_signature

manu: when this stuff is at scale
... lots of these in a wallet
... used across sites
... are they going to do something that is effectively out of the control of the crypto
... that will automatically correlate them
... email address, etc.
... that doesn't mean we shouldn't try to do the best we can to avoid that
... but it does mean if we use all the fancy crypto, will it matter in the general case
... there's certainly a desire in the group to make it work
... maybe we'll find that despite that, they're still overly correlating themselves

JoeAndrieu: the worst offenders are regulatory bodies
... there are some that only take Social Security Numbers in their state
... nage's going to open a PR, and we'll look at it

varn: there are usecases where I want you to correlate lots of things about me
... there are times when you really want that--customized service, etc.
... there are places to say they want to ban that correlation
... but it doesn't go away
... so we should build a system that accomodates both--or doesn't obviate the other at least
... if I make it one way, does that mean I can't make it the other?

nage: it's all about making it possible to be strongly related to be correlated within that relationship
... when you show up at the hospital, you want it to be *your* data they're correlating
... but at the same time, you don't want one hospital simply sharing that data with your "second opinion" doctor
... only to get the same answer in response
... you only want those to follow you around, if you want them to

ChristopherA: there are many indeterminate states
... you might know the integrity

<burn> queue freezes when bigbluehat starts to speak

ChristopherA: but you may not know if once that's provide if it's all going into a single profile for a person that provides a wider correlation
... we don't have the language to avoid these states or to define them
... we at least need to explain that to people

cwebber2: one of the main reasons is privacy

<ChristopherA> Here is the issue: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/issues/12

cwebber2: another one is correlation to check that you are that person

<ChristopherA> Challenges in Understanding Spectrum of Integrity/Inspection/Validation/Verification/Confirmation/Revocation

cwebber2: in our physical world system we personally provide information that "only we" know
... in the future, that information becomes something digital
... but hopefully that's not the entirety of our identity
... the other is building up enough info to build up a profile of credentials about something
... the last is invocation of things

<ChristopherA> I would love to have Nathan rework for selective disclosure:

<ChristopherA> https://www.irccloud.com/pastebin/IWiTPKWy/

cwebber2: privacy, being able to impersonate, making a personal database, and lastly invocation
... invocation is the one I hope we don't use here

<burn> queue is frozen

<manu> bigbluehat: Two anecdotal things about this... first

<cwebber2> correlation concerns about:

<burn> bbh: two points: friends of mine use loyalty cards in the grocery store. They throw membership cards in and mix them up monthly.

<cwebber2> 1) privacy

<manu> bigbluehat: We have a BiLog (loyalty) card... we have an identifier - membership card... throw your card in a bowl to throw off correlation.

<cwebber2> 2) impersonation (hopefully not an issue within the system since we want keys etc to actually express your identity)

<burn> ... it messes with the correlation data. 2nd idea is having your eyeballs replaced.

<cwebber2> 3) constructing your own database from which you reason about others

<manu> bigbluehat: You could have your eyeballs replaced and that creates issues.

<burn> ... you might want to change identity. You don't always want that correlation, but sometimes not that precise.

<cwebber2> 4) invocation of your authority (which hopefully is NOT done via credentials, but instead by object capabilities)

the movie is Minority Report (fwiw)

<scribe> scribenick: bigbluehat

<burn> good movie

dlongley_: do we want to be defining potentially correlatable data models?
... or to mix them in a single data model
... if we were to use selective discloser tech, we need to understand what those ramifications are
... there might be cases where you are effectively not using it

nage: as the selective disclosure person, I'd say you don't always use it
... it's not efficient

ChristopherA: data minimization is the first strategy to avoid this situation

varn: we built this stuff up as a verifiable credential
... you can imagine an integrity check prior to me knowing anything else
... is that's what needed?
... to prove integrity prior?

ChristopherA: especially true wrt to blockchain

varn: however I do it--in/out of band
... if they run an integrity check and then they get the information, they won't be shocked, because they've already checked integrity

nage: in the case of an audit, I can at least check consistency

varn: you've described a process--when you're using the thing we're calling Verifiable Credentials

<burn> queue is unfrozen to propose next steps

varn: then I think clarifying what the expectations of what must be done to prove integrity
... would be helpful

nage: at presentation time, you may not be minimizing the data, but at proof time you might be

ChristopherA: there's also the entry as a whole or partial data

<stonemat_> what's the difference between data minimization and selective disclosure - I didn't understand them to be different.

ChristopherA: we might want to recommend some cypher suites that make partial data handling easier

<stonemat_> ChristopherA: The community group is planning to write a primer on the difference

stonemat_: Time to Live / Terms of Use (ODRL) / Revocation
... useful terms, but not directly related

Time to Live / Terms of Use / Revocation

ChristopherA: there's a scope thing I'd like to propose
... we've set several times that said we need to clarify the terms used for the actors and actions in the process
... wrt to revocation, we can focus this to the claim assertions themselves
... if it's only about the binding to the identity of the claim--that's it's only for a year...or to disclaim the identity--then I would say it's within use
... but if the issuer is no longer wanting to say something is no longer true--and does not change the identity
... then I'm not sure it's within use
... let's say I give JoeAndrieu a graduation certificate
... and let's say someone else has a problem with that fact
... it's not possible at the layer we're defining here, there's no way to disclaim that
... you can say that ChristopherA has a problem
... or to say the target (in this case JoeAndrieu ) is at issue
... but it can't be about the content of the claim itself
... because then you're into the data itself

cwebber2: more slides coming!

JoeAndrieu: I spent a little time attempting to define some of these situations
... Term of Achievement--optional date that the claim status expires
... additionally, there are business requirements, like a notary, that are used for accessing certain things
... I called it "Time to Live" for lack of a better name
... we might rename that...as I'm not sure where that lives in the stack
... lastly Revocation, act of de-issuing a credential or claim
... in the VC ecosystem, I need to provide proof that it's still valid
... and that there are not issues that might mean that gets taken away
... then JoeAndrieu ended up in a long discussion
... the ended in this almost response code like thing that the inspector might go through
... when validating the authenticity
... it might come back as either Verified or Valid
... I think it's getting to ChristopherA's words--something between integrity and verified
... I don't know how many of these terms there are, but it's somewhere between these
... in the professional world it might be a certificate I might have held in the past
... is that verified? is it valid? etc at it's current time?
... the inspector has to verify that data
... hopefully that's some level setting for some term exploration
... there are some other situations where the issuer or the verifier wants to limit some use of the claim
... ODRL is on the list because they have terms for this sort of thing

<gkellogg> JoeAndrieu: We came to the realization that any expiration needs to be a component of the claim and not the credential. The TTL on a token should be “there”

<gkellogg> … One of the use ases was that a credential may only be used for a day, vs a Drivers License expiration.

<gkellogg> ChrisA: I don’t want to issue you something for that long (5 years), I’ll make it so you need to come refresh it.

<gkellogg> … The claim isn’t verifiable, the credintial is.

<gkellogg> Joe Andrieu: The revocation method should tell me when to check again, or how long to cache, not the credential.

<gkellogg> Stone: We have a case where the issuer might verify that a person has a credential, and you don’t need to ask again for some time. 5 mins later, you don’t need to ask again, and the issuer can control this.

<gkellogg> JoeAndrieu: we clarified that “verified” means it was “valid” at one time. “Valid” includes whatever is in the claim as to if it has currency today.

<gkellogg> varn: we need to decide which of these to handl. First is a “proof expiration”, saying that it will last so long. May be different than the claim being good for 5 years. Secondly, time may change things, and cause revocation. Could require a reissue, or could be revoked for cause.

<gkellogg> … Also, “earned, but expired”.

<gkellogg> … WIthin “verified”, is the simplest state, except to say open it up and read it.

<gkellogg> ChrisW: We said we were going to talk about capabilities.

<gkellogg> ChrisA: Part of the problem is a confusion between the envelope and what’s in the envelope. A VC is an envelope; there are things that could be wrong about it (stamp, address, incorrect data).

<gkellogg> … We can address these cryptographically. When we open the envelope, it may have different things, which can also be wrong/false/dated …

<gkellogg> … I want to move that to the discussion about schemas.

<gkellogg> … I’d like to look at mechanics and not semantics, right now.

<gkellogg> ChrisW: A lot of what we talk about is how to do things. I want to distinguish between claims and credentials, which include from and to information. THis allows her to use credential to talk about stuff.

<gkellogg> … One of the dangers is that we’re talking about using VC as invocation. I’d like to move from ACL to capabilities.

<gkellogg> … THese have bugs such as “ambient authority”, and “confused deputy”.

<gkellogg> … (uses illustration of tech support and Alexa). This could combine commuication channel with authority.

<gkellogg> … THis could happen when you’re logged into your bank account and the connection is compromized.

<gkellogg> … There is a mechanism called “Object Capbabilities”, which allow the ability to execute within context, revoke and scope.

<Zakim> dlongley_, you wanted to say a use case for expiration on a credential is for short lived credentials with no revocation and to say that TTL is like the issuer saying "the data is

<gkellogg> dlongley: Short duration credentials vs revocation.

<Zakim> manu, you wanted to note that we're conflating a bunch of concepts and talking about all of them together, which makes it really hard to get anywhere.

<gkellogg> … Varn was talking about TTL, which indicates that a credential is unlikely to change within some time. (It’s a cache)>

<gkellogg> manu: We’re all over the place :(. We’re conflating things. I’ve been trying to map to the data model, and it’s complex. I’d like to focus on one thing, such as revocation or TTL.

<gkellogg> … I want something to come out that gives direction to spec.

<gkellogg> stone: what should we focus on? Terms of use is hard, revocation could be done on call.

<gkellogg> ChrisA: These are schema-specific things; it’s hard to have a generic thing to say that it applies to an important schema.

<gkellogg> JoeAndrieu: Envelope vs payload is important. Verified means envelope has integrity, valid relates to the claim. Revocation has to do with the payload, not the envelope.

<gkellogg> ChrisA: This is conflated in other groups.

<gkellogg> Joe: DMV may revoke DL.

<gkellogg> varn: I’d like to try to resolve envelope’s problem. We need a phrase “Terms of Use”; it will exist in a credential. May need to agree ahead, or may be in credential.

<gkellogg> ChrisA: Repudiation is a good term.

<gkellogg> varn: in government, we don’t repudiate, we revoke.

<Zakim> manu, you wanted to ask that we focus on something.

<gkellogg> … We need to articulate for user community (Key rev or Proof rev)

<gkellogg> burn: the chairs put these together, only because people say they’re related.

<gkellogg> manu: I assert that they are not related. It may not be apparent, but it’s clear in the doc.

<gkellogg> … We don’t know what we’re doing for ToU. I’m not clear if people don’t know its in the spec, or if they don’t agree.

<gkellogg> … I’d like to focus on revocation. ToU will take too much time. TTL is already in the spe.

<gkellogg> dwood: We’ve heard how hard naming is. DC community spent 5 years to come up with names for 15 items, and even then, the term for “author” became “creator”. WHich was fine, until taken out of context. When it it the Middle East, it ran into cultural resistance.

<gkellogg> … You won’t satisfy everyone, and there’s a point of dimminishing returns

<gkellogg> stone: I’m fine with Revocation as focus, but I don’t hink it’s done in the spec. (manu agrees). It’s in a F2F that big problems, like ToU, can have progress made.

<varn> 3.5 Revocation Model Revocation information for the claims in the Verifiable Claims Model may be provided by adding the following property: revocation The value of this property must be a revocation scheme that provides enough information to determine whether or not the credential has been revoked. The revocation scheme will vary depending on a variety of factors, such as whether it is simple to implement or privacy-enhancing. ISSUE 35: Establish criteria for use

<gkellogg> Joe: I like focusing on Revocation. I’d like to say that “expiry” can be a ToU.

<varn> cases, provide outlet for examples The group is currently determining whether or not they should publish a very simple scheme for revocation as a part of this specification.

<gkellogg> … It doesn’t seem to me that language relates to invalidation; that the key has been compromized.

Revocation

<varn> https://www.w3.org/TR/verifiable-claims-data-model/#revocation-model

<manu> Revocation section of the spec: https://w3c.github.io/vc-data-model/#revocation

<Zakim> manu, you wanted to introduce revocation

<renato> yes, renato is on the phone ;-)

<gkellogg> manu: I added link to spec (varn put in text). We have a section that deals with revoking the credential (VC).

<gkellogg> … The complaints are that it can be done wrong, one rev per cred creatse a blocking issue. COuld be put in blockchain, but might b too big.

<dlongley_> not only put in a blockchain but use an aggregator, etc. (just saying there are more details)

<gkellogg> … We have to provide an example of how to do it, the safest thing is to have a big chunk of revocation, so that a list may have 100K entries. “An issuer MUST not make a rev list 1:1 with credentials)”

<gkellogg> … instead, have a list which includes the one you need, but also previous.

<gkellogg> … The follow on is to use the blockchain, and we may want to create an experimental spec to point to.

<gkellogg> stone: needs of large-scale programs (eg Cisco). What rev list does Cisco maintain, all ever revoked?

<gkellogg> Chris: BIg failure of SSL, all 4 attempts have been broken. now at cert transparency; it’s an unsolved problem in centralized crypto.

<gkellogg> varn: I manage rev lists. What am I producing, what am I reading? Do I need to look at all 1M creds?

<gkellogg> manu: proposal is to manage multiple (10K+) lists, and you manage the size. You don’t want verifiers always downloading large files, and you don’t want to maintain too many lists. There’s no 1 strategy that works for everyone, and because of that we can’t mandate it other than to require no easy correlation.

<stonemat_> q

<gkellogg> ChrisA: some if it is a scaling issue, we’re trying to be decentralized.

<gkellogg> stone: we focused on revocation, and may not get to ODRL.

<burn> queue is now deactivated

<gkellogg> varn: are lists binary, do they have annoation? Reasoning (manu 2nd).

<gkellogg> … That’s good for me. YOu can find out why.

<gkellogg> ChrisA: if we give a limited list of reasons, we can say that something outside is not one of those revocations. (key compromized, hange of affiliation, …)

<gkellogg> ... repudiation is not revocation.

<gkellogg> Joe: Cisco revocation is different the envelope revocation, which is repudiation. We’re misusing terms.

<gkellogg> … Repudiation is an aspect of the content of the VC.

<Zakim> manu, you wanted to ask why ...

<gkellogg> manu: my model: when a VC has a revocation list, and that credential shows up as revoked, as a verifier, I’m not supposed to trust that. I don’t distinguish between claims being true or not, just that I don’t know.

<gkellogg> varn: what’s a Credential, envelope or something else. I’m confused about if issuer is revoking, or what?

<gkellogg> varn: In one case, we’ll say that the thing your checking is no good anymore, with a list of reasons why.

<gkellogg> … IN the other context, we say its not good, because your right to use it has been withdrawn. We need language to describe that.

<gkellogg> … When you get “declined” on your credit card, that’s bad. It can mean different things. I’d like to have more context.

<gkellogg> ChrisA: In my internal view, “repudiation” is what we’re talking about what’s inside the envelope. You’re deploma is no longer valid, ...

<gkellogg> … Different from crypto problems with key problems, or other technical issues.

<burn> queue freezes after Joe speaks

<gkellogg> … THere’s a gray zone. At the rev level, there is a set of things, and otherwise at repudiation.

<varn> -1 on repudiation. actually -100

<burn> queue is frozen

<gkellogg> Joe: Revoked means you can’t trust it, it may be accurate, but you can’t know. Repudiation means that credential is withdrawn.

<ChristopherA> (withdrawn isn't bad alternative to repudiation)

<gkellogg> ChrisW: Payload attaches to envelope, and revoking payload also revokes envelope.

<gkellogg> Joe: There were use cases about the number of times it’s issued, but it still may be invalid.

<Zakim> manu, you wanted to wonder if we should say "CurrentStatusList" - revocation being one of the things you can check... along w/ reason.

<gkellogg> manu: it’s apparent that revocation is not broad enough, and we may want something else. It may be a “Current Status LIst”, revoked, lost, …

<gkellogg> … Verifier must check rev list, make that thing broader. It may get something says revoked, network down, etc.

<gkellogg> … The card network didn’t provide info for reputaiton reasons. THat reviels too much. We could violate privacy.

to manu's example: "that's a valid email on this site, but that password is wrong"

<gkellogg> varn: I like “status list” as less value-laden. If the proof doesn’t work, then the answer is no. That’s another indicator that something list wrong.

<gkellogg> … You could get problems because of crypto.

<gkellogg> … The status list is for things that have problems, not things that are okay.

<gkellogg> … quesiton is, if no, do we provide reason?

<dlongley_> in response to Richard, just as a detail: you probably want the status list (in the implementation details) to contain all the valid things (e.g. through a cryptographic accumulator) ... even if the response to a status list inquiry says "no problem", more privacy aware

<burn> queue unfrozen to propose next steps

<gkellogg> ChrisA: in most cases, these aren’t singular proofs. YOu get envelope status and there’s key revocation, but there’s also a time signature issue.

<gkellogg> … long lived things may have more proofs than short lived.

<gkellogg> … proposal is to identify reason codes; I’m uncomfortable to say that’s the solution, otherwise not interacvie, but it’s a good start to get codes. Which are envelope, which are inside?

<Zakim> manu, you wanted to discuss specific proposal

<manu> PROPOSAL: Change "revocation" to "foobarXYZ" in spec.... create a "FooBarXYZ2017" non-normative spec to explore revocation, status codes, explanations, and other things of that nature.

<gkellogg> … THis allows us to experiment before going normative.

<gkellogg> varn: I like it; the use case we described about something earned being revoked. (manu, that’s covered).

<gkellogg> … we require that someone keep a list, but not the descriptions? (optional)

<gkellogg> ChrisW: A concern about going from revocation list to status list is that you introduce a new issue: you may be introducing information about things that are on the system, you find one once it’s invalid.

<gkellogg> manu: you never say it’s good, only when it’s bad.

<stonemat_> +1 especially to have the spec differentiate between "envelope" and "payload" revokation

+1

<gkellogg> +1

<JoeAndrieu> +1

<manu> +1

<varn> +1

<jean-yves> +1

<cwebber2> +1 given that we'll be discussing the implications as we go

<dwood> +1

<ChristopherA> +0 (I'm concerned it may become another rathole, but don't block as we'll learn something)

<dlongley_> +0 if we are literally doing "foobarXYZ" in the spec, then i prefer to just add an issue in the spec but won't block

RESOLUTION: Change "revocation" to "foobarXYZ" in spec.... create a "FooBarXYZ2017" non-normative spec to explore revocation, status codes, explanations, and other things of that nature.

<JoeAndrieu> proposal: correct the use of "credential" v "verifiable credential" to be rigorous

<gkellogg> Joe: We drop “Verifiable Credential” after having defined it in the spec.

<gkellogg> … where we say Envelope, it should be Verifiable Credential.

<ChristopherA> (mine is a new proposal)

<gkellogg> manu: diff between “unverifiable creds” vs “verifiable creds”.

<gkellogg> Joe: Credentials are a set of claim, it

<gkellogg> … it’s the verifiable part where we add proof.

<gkellogg> manu: it’s editorial.

<burn> ACTION: manu to correct the use of "credential" v "verifiable credential" to be rigorous

<trackbot> Sorry, but no Tracker is associated with this channel.

<gkellogg> ChrisA: I’m disturbed the the consequences of the status thing killing a bunch of stuff. Now it’s a new correlation, privacy requirements, layer violations.

<gkellogg> … Can we say that there are cases where you don’t need to check status? you should do it in some way that’s non-correlatable.

<Zakim> manu, you wanted to note about "credential" and to say you don't always have to do status.

<gkellogg> manu: I agree there are issues, but I think we always had them. Status is optional. Someone should put forward a non-correlatable approach, eg blockchain.

<gkellogg> varn: We can’t issue something we can’t withdraw, neither can DMV.

<gkellogg> … Some things will require you look, can’t be used without checking status.

Capabilities

<gkellogg> ChrisW: See whiteboard for overview.

<gkellogg> … We have a good system for correlation, that helps people decide if to use. It can also be used for invoking, and then is an ACL.

<gkellogg> … It’s the status quo, but causing problems.

<cwebber2> https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/lds-ocap/lds-ocap.md

<gkellogg> … Capabilities talked at RWoT, and coauthor would like to work with us. We have an opportunity, but haven’t escaped people wanting to use our work for invocation.

<gkellogg> … We could point someplace else, or CG, or WG takes it on.

<gkellogg> … We have an initial proposal that needs to be tested, and needs actual implementations and refinement.

<Zakim> manu, you wanted to mention that delegation, guardianship, possibly terms of use, and n-deep all fall into capabilities.

<gkellogg> manu: capabilities covers delegation use cases and gardianship and ToU, and N-Deep. Working on this would allow manythings to be addressed in a provable way. THat said, it may belong in the CG. It will eat up a lot of time.

<dlongley_> +1

<cwebber2> +1 also

<gkellogg> … Incubate in CG.

<gkellogg> … WG work is actually not hard, and we can insert later.

<gkellogg> stone: it feels abstract. How does it change the DM? Do we just plug in a doc?

<gkellogg> Joe: I like working on it in CG with a hook in DM spec. We should allow the issure to attach it to the credential, not just the user. If ToU is from the issuer, that helps.

<gkellogg> ChrisW: ToU combines capabilities and credentials.

<gkellogg> ChrisA: I brount in Mark because I like what he’s done, but when this comes up it get’s knocked down. Perhaps language, or not useful on singlue-user machine. Warning: you may hit something that makes you throw your hands up. Please give it a chance to get past those blocks. Language will need to be improved.

<Zakim> cwebber, you wanted to say also we clearly specify that we're marking invocation as out of scope

<gkellogg> ChrisW: a walkthrough…

<gkellogg> … consider car key. ALice has a car C. She has a capability to drive it (a key).

<gkellogg> …Her friend Bob wants to drive car. She creates sends bob a link to to go to the car.

<gkellogg> … basically, copy the key,

<gkellogg> … Now, bob can drive car.

<gkellogg> … Problem is that Alice is worried Bob likes to drive too far. Maybe Bob is a valet.

<gkellogg> … She wants to give bob a capability to drive car for 10 miles (linked to Bob).

<gkellogg> … What if ALice stops trusing Bob?

<gkellogg> … We can add a restraint, such as a fuse that Alice can trigger that revokes Bob’s access. (Attenuated capability)

<gkellogg> … Capabiliites are principle of least authority.

<gkellogg> … each one does a specific thing.

<gkellogg> … Contrast with ACL, where you can do a lot, and you can do too much.

<gkellogg> … New use case. We have a cloud storage system and a dummy-bot.

<gkellogg> … Alice can save to cloud. She’d like for Bob to save objects on cloud, but she’s worried that he likes high-def, and only wants small images.

<gkellogg> … Bob has a bot that he’d like to test for 30 days, and then revoke access.

<gkellogg> … Alice creates a capability with 10Meg limit to cloud store, sends to Bob.

<gkellogg> … Bob gives bot a 30-day version of restricted capability that only allows 10meg uploads.

<gkellogg> … bot uploads using capability, checks constraints (30 days, 10 megs).

<gkellogg> ChrisW: proposal shows how to use capabilities to do credentials.

<gkellogg> … Derived capability is new proclamation that points to the original with the addition of a limit.

<gkellogg> ChrisW: An example is a programming module that’s passed arguments and a function.

<gkellogg> ChrisA: I want to be sure you say why you’re talking about invoking, and why it’s important.

<burn> queue is frozen

<gkellogg> ChrisW: It’s more “alive” than other systems, as it is like method invocation.

<gkellogg> … You can add many interesting restrictions to capabilities. Who uses the capability isn’t important.

<gkellogg> ChrisA: It should be clear that you’re actually giving something to use.

<JoeAndrieu> Dinner Recommendation https://www.yelp.com/biz/new-world-cafe-burlingame 833 Mahler Rd Burlingame, California (650) 239-9750

<gkellogg> Generall acclamation that CG take on Capabilities.

<gkellogg> burn: thanks, we’ve had a lot of discussion, and it’s been great.

Summary of Action Items

[NEW] ACTION: manu to correct the use of "credential" v "verifiable credential" to be rigorous
[NEW] ACTION: nage to create issue/pr describing how we can address identity verification via updating the vocabulary in the credential itself
[NEW] ACTION: nage to propose description about crypto guarantees around identifiers being used to make url useful
[NEW] ACTION: Nathan and Manu to work together on how to do content addressed JSON-LD contexts.
[NEW] ACTION: Nathan to create description around cryptographic guarantees of identifiers being used.
[NEW] ACTION: PR for how crypto hooks are expressed in sig block
 

Summary of Resolutions

  1. Change "revocation" to "foobarXYZ" in spec.... create a "FooBarXYZ2017" non-normative spec to explore revocation, status codes, explanations, and other things of that nature.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/11 01:58:40 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/identifiers itself/identities itself/
Succeeded: s/mplication/Implication/
Succeeded: s/SSL since/X.500 since/
Succeeded: s/Larry/Larry Masinter/
Succeeded: s/SNOR/Schnorr/
Succeeded: s/these are together,/the chairs put these together, only/
Present: Charles_Engleke Chris_Webber Dan_Burnett Dave_Longley David_Singer Gregg_Kellogg Jarlath Joe_Andrieu Joerg_Heuer Manu_Sporny Matt_Stone Nathan_George Reto_Gmur Richard_Varn jheuer Liam_Quin Quing_Ai kimhd KimDuffy ChristopherAllen Alexandre_Bertails David_Wood Fabien_Gandon CyrilV Jean_Yves_Rossi Jean-Yves_Rossi David_Chadwick Ed_Bice Sandro_Hawke Emmanuel Chris_Needham Aviv_Chandya An_Xiao Emmanuel_Vincent renato
Found Scribe: manu
Inferring ScribeNick: manu
WARNING: No scribe lines found matching previous ScribeNick pattern: <bigbluehat> ...
Found Scribe: kimhd
Inferring ScribeNick: kimhd
Found Scribe: gkellogg
Inferring ScribeNick: gkellogg
Found ScribeNick: bigbluehat
Found ScribeNick: bigbluehat
Scribes: manu, kimhd, gkellogg
ScribeNicks: bigbluehat, manu, kimhd, gkellogg

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: manu nage nathan pr

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]