<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
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.
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
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
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
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
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, ...
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
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
nage: the identifier is the
attribute inside a credential
... what we bind to is proof of corelation
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
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.
<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.
<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.
<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.
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]