The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back


Credentials CG Telecon

Minutes for 2019-08-27

Shivam Sethi: Present +
Shivam Sethi: Present +
Ted Thibodeau: Voip-ccg, who's here?
Ted Thibodeau: Voip-ccg, who is here?
Chris Webber: I could scribe in the non-datashards part ;)
Chris Webber is scribing.
Joe Andrieu: I can [scribe assist by Amy Guy]
Joe Andrieu: Cwebber will scribe, rhiaro will scribe when cwebber isn't

Topic: Introductions and re-introductions

Emacsen: This is Serge, I work with Chris on a number of projects including datashards
Joe Andrieu: Anyone else new?
Orie-Steele: This is Orie Steele from Transmute. We work on etherium and DIDs, json-ld, like the jsonld-sigs library from the DB folks
Joe Andrieu: Anyone else want to re-introduce?
Joe Andrieu: Cwebber2 should re-introduce
Chris Webber: I'm Chris Webber, I work on, sometimes contracting for digital bazaar, and also a bunch of things independantly. I working decentralised social networks like activitypub, and I've got into json-ld and i'm interested in how credentials affect that work. I've been part of the RWOT community for a couple of years [scribe assist by Amy Guy]
Chris Webber is scribing.
Joe Andrieu: We have a regular call on thursdays to hand off work to the DID working group... these are still going on markus_sabadello ?
Markus Sabadello: Yes, we had some deep topics about DID resolution
Markus Sabadello: Same information is in agenda
Joe Andrieu: That's thursdays, 90 minutes, 9am pacific (?), 8 AM UTC
Markus Sabadello: Yes, and we decided on last call to shorten to 60 mins

Topic: DID working group charter / outreach

Joe Andrieu: Anyone want to speak to that process?
Joe Andrieu: I guess I can..
Joe Andrieu: I don't know the specific deadline
Dan Burnett: The current call for responses runs through end of this month for DID WG charter; if you are an AG rep, you should respond to that questionaire. If you are not with a w3c member company, we'd still love a response to that public call for comments
Dan Burnett: It's really helpful to have comments in support of the work for members an non-members alike
Joe Andrieu: The link I dropped is the index for the (???)... if you like DIDs, please join / support / get your AC to vote / or voice public support on mailing list
Orie Steele: Can we get that link again?
Joe Andrieu: Next up, we have a couple meetings starting Sep 1st; have a digital identity metup. Happening Sunday as a prelude to Rebooting in Vienna. Some of us are getting together than taking train up to Prague. Then Tuesday starts RWoT with a Monday night meetup before; we also have ActivityPub Conf and there's one with our friends from holochain. Wish I could go to both!
Joe Andrieu: Following that, TPAC will be in mid-september, 16th-20th. Following that, MyData in Helsinki
+Present ajones_db
Joe Andrieu: Ok, progress on action items? not sure where we're at since last time, just one open... discuss registries meta-process. What are we doing next on that? I dunno, kimhd or ChristopherA maybe...
Kim Hamilton Duffy: Yeah I think the idea is to look for volunteers
Kim Hamilton Duffy: Possibly a good starting task for someone
Kim Hamilton Duffy: Manu did a start for process for registries which we called a meta-process. general one for how you'd create a process for DID methods, key signature suites, credential status reg, etc
Kim Hamilton Duffy: We do need to document that, so that would be a good CCG work item to take on
Joe Andrieu: Thanks kimhd... a few registries already have a process, so we're trying to document to get a meta-process
Joe Andrieu: So you can get involved on irc, send an email to kimhd or myself, or jump on that issue
Joe Andrieu: Ok, those are the action items, so...
Joe Andrieu: Quick report on rubric work at IIW, a couple of sessions took a stab based on what might make sense as set of evaluable criteria for DID methods. huge debate for whether DID methods need to be decentralized. Clearly many definitions for what makes something decentralized. Goal of rubric is to allow a mechanism to evaluate whether or not DID method meets needs
Joe Andrieu: Rubric is not to say whether a method is good or bad, but to say lots of people say this is useful
Joe Andrieu: Not you must be this tall to ride, but to get a sense of how tall you are
Joe Andrieu: Maybe you have to be at least this tall, maybe it's a roller coaster. Goal is to not pass judgement but to get metrics
Joe Andrieu: One of the things I want to share out... you have to be a geek to tease out these methods is to separate registry and network. ultimately links to did document in resolution process. but BTCR registry and network is the same thing. for etherium the registry is actually a smart contract and the network is etherium
Joe Andrieu: Some of how it was framed didn't pull out that distinction
Joe Andrieu: We want to make clear you can talk about governance or operation of registry
Joe Andrieu: That's going to continue on, a group of us will be at RWoT and hope to make paper there
Joe Andrieu: Need to make an update about plurality
Joe Andrieu: We want to say that the entire document is a single rubric, the individual criteria are questions
Joe Andrieu: That's my update on the rubric work
Joe Andrieu: Burn I see you on the queue?
Dan Burnett: That's old but want to say about relationship with DID working group
Joe Andrieu: Sure, rubric as in terms of what does this mean in terms of VCs
Joe Andrieu: It's a non-normative deliverable for the WG
Joe Andrieu: We hope to see the rubric continue
Joe Andrieu: I know as WG gets chartered, things can change
Joe Andrieu: We'll be working unnder rebooting, where things are CC BY, then we hope to move to the newly formed WG
Joe Andrieu: So we go through that in record time, now onto the topics
Joe Andrieu: We'll start with datashards with cwebber2
Amy Guy is scribing.

Topic: Datashards

Chris Webber: If you can open the presentation linked ^ we'll go through that
... I am, in the interest of not having another way to do it, I'm going to make a beep noise every time you turn the page
... Datashards bring secure distributed storage to the web
... secure means only intended recipiants can see the messages so it's private
... which also makes it safer for node operators ot move things along the network
... you could use yoru local data store to store your data, or put it on your file system.. nodes can host content, but they don't necessarily know what that content is
... primitives for the web - it's supposed to be foundational in the way https is
... we introduce two new uri schemas
... immutable and mutable datashards capabilities
... URIs for those
... data can have the same name but live in many different places
... if you upload to your secure data hub, and download it to filesystem, and your friend puts it in their database, all of those things have the same URI no matter where it lives
... why not ipfs?
... dat?
... because datashards encrypts everything
... this is critical for users because they deserve built in privacy, should be the default everywhere
... node operators need to.. seeing content can be a big problem. Sometimes it's better not to know.
... if you imagine postal workers ship around packages
... imagine if thos epackages were wrapped in clear wrap
... you look at one andthink should I really be delivering that?
... then you get in a habit of doing that, people start doing that... maybe the local government says you should be taking more responsibility for those. Here are some rules for what is and isnt' allowed... and we're goign to hold you liable for the contents
... it's a group of volunteers, many people might stop shipping things around
... it adds a lot of unnecessary friction to the network and makes it harder to be a node operator
... so better if things are not wrapped in clear wrap
... so layering encryption after the fact is unsafe
... clear text data is toxic to nodes
... we want encrypted by default
... immutable data shards example, we have real implementations, going to show immutable today
... this is content taken from me doing an upload of this picture
... it shows uploaded chunks, each 32kb
... the first is the manifest, once you retreive and decrypt this it will point you to the rest of the chunks
... the last thing it spits out is the uri
... that says here is the hash of the initial chunk, the key you use to encrypt it
... you download it, put in that uri, grabs a chunk that has that hash and it can get the rest, encrypts each one in turn and assembles it
... the client is the one that has the union of the initial hash and the key
... even though it's fetching each one of those chunks,t he servers don't know what the chunks represent
... idsc is fine for cat photos, but we want to update content?
... these are mutable data shard capabilities, built on top of a new public private key pair
... the elpitic curve, we dump it straight into the mdsc, that's the name of the mdsc, the encoded public key, the same way the fingerprint is your pgp key
... the name of this immutable file is the name of your public key
... we generate a new key pair for each mdsc so they're not reused
... you have levels of access. Verify only capability
... the registry keeps track of what updates happen, but they don't know what the updates represent, they can't read them
... then there's read+verify, which allows you to request the newest version, and also see what the contents are. Under the hood they point to idsc revisions
... and there's write which lets you read and do new updates
... what if you can write? someone could accidentally update or maliciously write out two version 2s
... we don't provide consistency out of the box, but you can layer it on
... we don't, because if you do it in a decentralised way you have to do something like a blockchain, and we want to support garbage collectable content
... if you have ag ame and your'e killing goblins who are represented by mdscs, you don't want to load a blockchain with those
... But some other kinds of contents, where ordering of events may be important, you could specify a blockchain or a centralised oracle
... that's your choice. We could standardise some ways tod o that but it's not out of the box right now
Joe Andrieu: +1 For goblins on chain
... Example uses..
... Any documents on the web, like resiliant social network. This is my motivating example. I wrote an implementation
... A node can go down and people are no longer able to access their own content
Orie Steele: Sounds very similar to https://github.com/orbitdb/orbit-db with better crypto baked in.
Ted Thibodeau: It would be helpful to expand the IDSC / MDSC acronyms(?) somewhere in this doc
... or they can't interact with the ocntnet their friends have. This allows you to instead store it as an idsc or an mdsc uri and that content survives
... if you use an mdsc for peoples' activitypub profiles you can switch out over time what inbox they point to. If a node goes down I can push otu an update and point it to another node
... What else? These are valid web uris so we can use it to store VCs
... we can point to VCs that are stored in this mechanism
Joe Andrieu: IDSC -- Immutable Datashard Capabilities
... WE could make these a DID mechanism
Joe Andrieu: MDSC -- Mutable Datashard Capabilities
... if you store a DID Doc in an mdsc and keep doing updates, that's a way to be able to do update. WE could make a DID resolution mechanism that uses datashards. We could put it on a blockchain, or not. Perfectly viable to build that on top
... if you're talking about key recover you'd hav eto use Shamir Secret Sharing to recover the keys, but it is possible to build DIDs on top
... I think this is a better foundation for Secure Data Hubs, but it's not limited to secure data hubs
... Conclusions.. we need data shards because the live web is too fragile. Too much data people care about is lost
... we shouldn't have another burning of the library of alexandria that is geocities
... people should be able to keep their stuff around
... other content addressed systems don't necessarily support privacy or are unsafe for node admins
... datashards is like tahoe fs but they didn't support global use
... also provides a fundamental secure content addressed primitive we can build on top of, like how http is a primitive we can build on
... datashards.net is still early
... questions?
Shivam Sethi: The solution you are creating is more related to credentails than secure data hubs or it's like something similar to .. is it oriented to vcs and secure hubs or something else?
Chris Webber: Was the quesiton how is this different?
Shivam Sethi: We also have something like ipfs, how is the datashards solution created by keeping secure data hubs and vcs in mind or is it a generalised solution?
Chris Webber: If you're creating a generalised solution with secure data hubs.. I'd like this to be a generalised solution which is the foundation on which secure data hubs are built
... the discussion with digital bazaar is is it acceptable ot build this type of thing underneath secure data hubs, but that hasn't moved forward yet
... the reason I've been working on this is I want something that is general, outside of a specific web store or specifically something we stick on a usb key, or specifically any of thos ethings. It would be great if we can get convergance on something we all agree on that is the base structure fo rthings that can live offline or online
Markus Sabadello: I think it oculd be used for a lot of things. What' sthe lreationship between this and hashlink?
Chris Webber: We've had some conversations.. right now you'll see I'm using a more oldschool approach which is urn: name of has mechanism. Would be completely possible ot use hashlink instead. I have discussed that.. we are not doing that currently, partly because the serialisation mechanmis, they're using cbor and I don't have access to a cbor implementation. Maybe that's something we can resolve. I'd love to converge on a unified content addressed hash
Mechanism. Would be possible to get convergence, we just need to talk about it
Dave Longley: I want to caution, I have a big concern around the fact tha tpeople often dont' think about encryption having a shelf life. it does. If you have been using this system and you were using def(?) for example 15 years ago, everyone would be reading all of the content if it was all shared across a bunch of public nodes
... I'm concerned about not putting protections around those sorts of situations, or using technology where ther'es a network of nodes supposedly unable to read the data, it's true today but ten years from now that data can be seen
Dmitri Zagidulin: +1 Re that concern (that encryption has a half-life)
Orie Steele: All networks become public when their crypto expires ;)
... doesn't mean you can't use a system like that, just that there are caveats around it, same reason you don't put encrypted data on a blockchain
... not necessarily an issue if we use other kinds of layering
Chris Webber: We have talked about this quite a bit. I had to cut it out of the talk.. yes encryption has a shelf life. I saidi there are many store mechanisms. it's agnostic to store mechanism
... you could store it on a service you trust, or a completely global trust, or usb keys
... it's up to you what your threat level is. Butw e need to mamke clear to people that encryption has a shelf life. That said, evne if we're doing mostly public content I think it's better to use something like this than ipfs, which is for the safety of node admins. The people routing thing osn the network.
... I think ipfs is amazing, but I wolud not host an ipfs node because I don't want to help ship content around the network andthen see what it is, because it makes me more nervous about liability
... the same reason it's more dangerous to be a tor exit node than an intermediate node
... I agree with those concerns
Joe Andrieu: Have you thought about where this goes in terms of standards?
Chris Webber: That's part of the reason we submitted it as rebooting paper
... this is something w'eve beene xperimenting with over the last year, but we would like to standardise it. Is the CCG a good path to incubate that? that's a conversation for us to have with this community
Dave Longley: Quick response: good response -- just need to keep in mind the same concerns apply just at a different time scale (safe now, but not safe for "postal workers" in maybe 10-15 years... need to start dropping content... just a limitation of the system people should be aware of)
Ryan Grant: The system relies on crystal servers to registries to find the data once given an urn. How are those kept censorship resistant, how censorship resistant are they?
Chris Webber: What we could say here is if you .. it's about a censorship resistant as how many different avenues you have to find out about updates
... if an attacker is able to.. you have v2 of a document, and this other person really wants to get v3 to you. If there are 5 avenues to getting your updates and all five of them either don't see the update or are blocked, then you on't get that update
... but it could be if someone adds number 6 you can get that update
... it's pretty similar to the kind of challenges people have in other mechanisms, you might want to say if a few of these stores end up being very easily censored by an intermediary you add some other ones that are harder
Jonathan Holt: To address ipfs concerns, what you've described so far is basically ipfs. If you were to run your own node you only pin the things you want to pin, you're not willy nilly replicating data on the network. This is what filecoin is about, its encrypted data you send
... you have some interesting points but I think there are some misunderstandings with what ipfs is
Chris Webber: We should hash this out, I'd be interested in chatting
Chris Webber is scribing.

Topic: Solid

Kayode Ezike: Kayode Ezike
Joe Andrieu: Next topic is by Kayode Ezike
Kayode Ezike: I'm interested in taking on any role in the VC ecosystem
Kayode Ezike: In the state of Solid
Kayode Ezike: I'd like to get into more about what this is, here's the link for what recently we started migrating into Intrupt last year (?)
Kim Hamilton Duffy: Great presentation cwebber2. At rebooting I hope some of us can discuss further alignment of this, secure data hubs, and id hubs. Also interested in discussing the multihash / cbor issues you had
Kayode Ezike: Going to give a demo
Kayode Ezike: Putting a link in case now or later following along from where you'd download the platform from
Joe Andrieu: Just fyi there are some audio problems
Kayode Ezike: So that's the link I just listed, first thing you do is npm install, installs the deps
Kayode Ezike: Including json-ld sigs library, install credentials
Kaliya Young: Can you talk just a tad slower and enuciate
Kayode Ezike: Linked data module, allows you to set up your remote pod
Kayode Ezike: Allows you to add your own accounts, allow for ability to store data in pod, in profile document if indexing account, there's the ability to see information, store public key document, store credentials management folder
Kayode Ezike: I'm actually realizing that the demo is a visual demo, so it occurs to me that a lot of it you might not be able to see
Kayode Ezike: You can do npm install, you should be able to add web id and password
Kayode Ezike: From there you should be able to set up "what folder should my key live in"
Kayode Ezike: That would actually be stored as a personal document, here's where my public key is
Kayode Ezike: Allows you to verify data later on
Kayode Ezike: Allow you to verify where the revocation folder is that keeps track of a list of credentials with issuer (?)
Kayode Ezike: Have a verification folder for that credential
Kayode Ezike: If revoked later on, it'll say revoked
Kayode Ezike: On the platform, you go to the platform, you can review a request for a credential, you select credential type, there's finance/etc
Kayode Ezike: Once you select that, you include title / issuer / id of issuer
Kayode Ezike: Optional description of credential
Kayode Ezike: From there you click "request credential"
Kayode Ezike: From there you are able to decide (???)
Kayode Ezike: Still optional, make available
Kayode Ezike: Determine if credential still is valid
Kayode Ezike: Include your image and etc
Kayode Ezike: Keep information that ascertains (?)
Kayode Ezike: If determines it's sufficient, share credentials with issuer
Kayode Ezike: Can share rdf issues with subject, subject can now get ... inbox
Kayode Ezike: Stored in user's valid pod
Kayode Ezike: Allows user to store it right away on their machine
Kayode Ezike: Allow to verify if it does have a license
Kayode Ezike: Can see before that whether you share via share interface
Kayode Ezike: The cop can see that there's a credential there waiting for them
Kayode Ezike: Can enter in URI of the credential
Kayode Ezike: Whether or it's valid, if it's correct
Kayode Ezike: They can proceed to pick up a (???)
Kayode Ezike: Stored with issuer, see if it has an active status, is it valid
Kayode Ezike: That's more or less what the platform is able to do
Kayode Ezike: After downloading it, give it to verifier, verify it's valid
Kayode Ezike: Can provide a link to a video
Kim Hamilton Duffy: Thanks for the presentation, one thing I wanted to mention is that many of us are new to solid, many of us want to hear about the basics; what's a pod what's a profile, how to verify both credentials, etc
Kim Hamilton Duffy: Some of those basics are things people would like to hear as well
Kayode Ezike: Basically, solid... a pod, it's structured kind of like a filesystem, different set of olders, there's an inbox and a public folder, other kinds of folders
Kayode Ezike: Other kinds of capabilities
Kayode Ezike: And other kinds of files
Kayode Ezike: Read/write/update/etc
Ted Thibodeau: POD is sometimes called "Personal Online Data" ... it's a personal dataspace, roughly porting Linux filesystem (and then some) to the web
Kayode Ezike: During the setup, programming, when you use the platform, it authenticates you to the solid pod, updates your pod document, points to a public key
Kayode Ezike: Whenever someone verifies the credential, they look at... search for the public key...
Joe Andrieu: Any other questions? we have one more minute
Joe Andrieu: Thank you very much kezike and cwebber2, I may not have mentioned earlier that we have no call next week since many of us will be at RWoT
Moses Ma: Bye gang, see y'all in prague!
Google doc has a different phone number and code than the email notification