The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back


Credentials CG Telecon

Minutes for 2018-06-19

Topic: Introductions and Reintroductions

Manu Sporny: Gannan: Hi, Ganesh Annan with Digital Bazaar - software developer.
Bohdan Andriyiv: Hi Bohdan, working on Validbook - universal platform for cooperation - encourage everyone to provide feedback, published idea on mailing list. [scribe assist by Manu Sporny]
Manu Sporny is scribing.

Topic: Announcements and Reminders

Christopher Allen: Summer BTRC Outreach — week of July 16th -- BTCR hackathon, could use help from JSON-LD folks.
Christopher Allen: Need to make sure we're using the right libraries, data model, etc.
Christopher Allen: MYDATA 2018 — August 29-31 Helsinki, Finland
Christopher Allen: https://mydata2018.org/
Christopher Allen: #RebootingWebOfTrust VII — week of September 24th, Toronto
Manu Sporny: Yeah, it's unlikely ... I'll try to circle back around. We still have a gap in the week right, where they could slot in? I'll try to send out an email after the call today. [scribe assist by Dave Longley]
Christopher Allen: Weekend after might be a Hackathon... DIF or Microsoft Hackathon... still no confirmation of that.
Christopher Allen: We're shooting to evangelize for a DID WG at W3C TPAC -- TPAC — October 23rd-26th, Lyon, France -- https://www.w3.org/2018/10/TPAC/
Christopher Allen: Much of us here will be in Lyon for DID WG... that's the week of the 23rd in October.
Christopher Allen: Also, IIW — October 23rd-25th, Mountain View
Christopher Allen: Any other events on the schedule?

Topic: Action Items

Christopher Allen: Hackathon September 29th or 30th? Still an option? Not sure if DIF is also pushing that? Might be an opportunity for Sovrin, uPort, Veres One to do Hackathon.
Manu Sporny: Yeah, just to mention that I think we'll be there that entire week, a number of us from Digital Bazaar and Veres One. Hackathon doesn't mean just one ledger, we could work on interop or command line tools, resolvers, etc. whatever. We'll be there. [scribe assist by Dave Longley]
Christopher Allen: Any updates on action items?
Kim Hamilton Duffy: I did not make progress on any of my action items. High hopes that this week will be different
Manu Sporny: Just a question -- is Andrew Hughes on the call... not seeing him. I'm just wondering if the spec training video is out yet. I'm done there just waiting on the release, any updates there? [scribe assist by Dave Longley]
Manu Sporny: Anything we can help Andrew with to get that out there? [scribe assist by Dave Longley]
Christopher Allen: I'll assign this away from you to Andrew. [scribe assist by Dave Longley]
Manu Sporny: I think Dave Lehn has an update on opencreds. [scribe assist by Dave Longley]
David I. Lehn: I updated the site to point to the newer work. Just a simple change for now, we may want to move content over later just a quick fix for now. [scribe assist by Dave Longley]
Manu Sporny: The other item is issue #18. [scribe assist by Dave Longley]
Manu Sporny: Mike Jones from Microsoft wrote up the secp256k1 params for JWK and put a spec out there. The next step is for uPort folks to take things from there. [scribe assist by Dave Longley]
Manu Sporny: It's on them to push it forward. [scribe assist by Dave Longley]
Manu Sporny: Pelle is the one who took the action to do it. [scribe assist by Dave Longley]
Christopher Allen: I'll figure out the assignment later. [scribe assist by Dave Longley]
Markus Sabadello: Quick update on DID Auth, not an issue in CG repo, should be...
Markus Sabadello: Last week, started a paper on DID Auth, challenging because it's vaguely defined... different people, different communities, associate different things... Browser-based API? Service to service? Agent to agent? Scanning a QR code with a mobile app? The idea of the paper was not to do a specification, was to try to summarize/snapshot current state of discussion.
Dave Longley: I think the answer is "yes" :) ... there are several ways to authenticate using a DID
Markus Sabadello: There are some common elements... proving control of a DID using some kind of mechanism.
Markus Sabadello: Introduction section, identify common understanding wrt. DID Auth... DID Auth challenge, what overall architecture can look like... working with Dmitri Zagidulin, PRs for document, document is kind of content complete... want to do some editorial passes, basically everything we wanted to have in that document. Not a spec, but just document what it is about.
Markus Sabadello: Want feedback on that...
Joe Andrieu: +1 To post link to mailing list and ask for feedback on DID Auth paper
Christopher Allen: Where is the github URL for this?
Christopher Allen: Do we want a spec as a next step? Work item?
Christopher Allen: What is the next step?
Joe Andrieu: We will probably want to adopt as a work item...
Christopher Allen: We need an abstract... then discuss here... are we ready? Is there enough time?
Joe Andrieu: We said we'd wait for RWoT to work its way through.
Joe Andrieu: A couple of PRs... on the DID Method Registry... please review.
Manu Sporny: This has to do with DID Auth. So clearly we'd love to collaborate on that we're very interested in DID Auth. There are a couple of layers to think out loud. There are the messages that go back and forth. The times that W3C and IETF have really screwed up are where they didn't layer properly. Good lessons learned. Get the messages and data modeling right first. Then whatever protocol you need to build on top of that is another set of specs. [scribe assist by Dave Longley]
Manu Sporny: You're right DID Auth means different things to different people. But set of messages are pretty generic -- maybe some protocol specifics to add to each message, but pretty close in general. [scribe assist by Dave Longley]
Manu Sporny: I think the first spec that we talk about should be a data model/messaging spec and then we add specs on top of that -- how do you do DID Auth on a browser, server to server, NFC, so on. [scribe assist by Dave Longley]
Manu Sporny: I think if we start doing specs around this, I hope that we end up structuring it like that whether than trying to make one DID Auth spec. I'm not saying anyone is suggesting we do that but it's clear anti-pattern. [scribe assist by Dave Longley]
Manu Sporny: We're very interested in collaborating on that. [scribe assist by Dave Longley]
Mike Lodder: I'm interested in collaborating with that
Moses Ma: Markus, can I get you to speak about DID Auth at this virtual conference on DID? https://businessofblockchain.com/web/virtual-summits/blockchain-id
Markus Sabadello: I think that sounds great... modularity/layered approach... for me, it may be too early to work on the specs... good to work on paper.
Markus Sabadello: How does this relate to FIDO, JWTs, OpenID Connect, etc... I wouldn't want to move on all of this right now, might be too soon.
Manu Sporny: +1 To markus_sabadello
Christopher Allen: Yes, that's why we have the RWoT process... incubate this idea more until we think we're ready.
Christopher Allen: Are we ready? Who wants to work on what? What are missing pieces?
Christopher Allen: We appreciate the work and know this is the direction we need to head in... maybe we don't start on it until fall?
Manu Sporny: Also, just bringing this to the groups attention. There's a specification that we worked on with Amazon and Oracle back in 2012 -- called "Signing HTTP messages"/"HTTP Signatures" and we use it quite a bit with our customers. We didn't realize that there's been a very sharp uptick in its usage. [scribe assist by Dave Longley]
Manu Sporny: Another heads up to Markus that we're starting to use it with DID Auth. More recently it's being used quite a bit. [scribe assist by Dave Longley]
Manu Sporny: We're using it for OCAP type things as well now. [scribe assist by Dave Longley]
Manu Sporny: So we're experimenting with server to server/agent to agent authentication and ocap (authorization). [scribe assist by Dave Longley]
Manu Sporny: Doing so with HTTP signatures. There's this family of server to server communication that's based on the HTTP signatures that we can layer on top. One way to do HTTP signatures is for the key ID to point to a DID document. [scribe assist by Dave Longley]
Manu Sporny: That's just another thing -- it was really quite on that front for a while and in the last few months we've seen a sharp uptick in its usage. Primarily due to PSD2 initiative in Europe, all the banks are using it there. [scribe assist by Dave Longley]
Manu Sporny: They did that without contacting us and now it's being potentially rolled out to millions upon millions of customers in Europe. [scribe assist by Dave Longley]
Manu Sporny: That's another thing to piggyback off of to get DID Auth support in there. [scribe assist by Dave Longley]
Markus Sabadello: HTTP Signatures - also covered in the papers... used that for the BCGov project... and also used for TrustNet.

Topic: Work Items

Christopher Allen: We need to drive the DID WG stuff forward - what are the things we need for DID WG.
Daniel Buchner: Just wanted to note... over in DIF - talking w/ Sovrin - elaborate schemes for authentication and message transfer... waiting to figure out what that final scheme is going to be... in DID Auth schemes - HTTP Signatures are far less elaborate... standardize the message scheme? Some want elaborate messaging flows... what direction is that heading in in this group?
Joe Andrieu: Amira use case moving forward...

Topic: Requirements for DIDs

Joe Andrieu: Amira is out to contributors & authors for sign off. Should see it as a formal work item soon.
Christopher Allen: What are the requirements for DIDs, what are the minimal features?
Daniel Buchner: Makes sense, I am just trying to get an understanding of what the most common variants this group will support, so we can support them as well
Daniel Buchner: We need to implement some sort of DID Auth flow in the next 4 weeks - mutable after that, but we would at least like to be close to the final direction :/
Christopher Allen: We have a few questions that are open around... social revocation/recovery, no updates, etc.
Christopher Allen: Some of the Blockchains like Sovrin or Veres One... organizational/institutional has revocation process that is independent of the key holder... any other mechanisms that people can think of that we're missing?
Daniel Buchner: Specific to recovery?
Christopher Allen: Specific to kinds of revocation?
Daniel Buchner: Layer 2 for DIDs... blockchain agnostic, run adapter, large scale DID integration on data in transaction...
Mike Lodder: Sovrin's proposal for DID revocation is to set the DID Doc to null
Daniel Buchner: This is not a "Microsoft thing"... open source -- not under patents... encapsulating a hashed completion value, put hash out there, layer2 can create DID document... if someone publishes the recovery... don't know if that's common, trying to use this construction to be more human-friendly.
Christopher Allen: Does that mechanism fall under ... who has the authority to publish that hash and what information is required to be able to publish that hash.
Daniel Buchner: The hash is set by the user - DID document state... here is my initial state...
Christopher Allen: Is it a key revoking itself? Use of key can revoke itself?
Daniel Buchner: This is by inference... hash(bigvalue)... put hash of value in DID Layer 2 substrate... at some future time, something happens, does some bad stuff... wipe slate clean... a set of keys are invalid?
Christopher Allen: I'm trying to understand, in order to do that action... you have to have access to original key?
Christopher Allen: What is it that authorizes that revocation to happen?
Daniel Buchner: A secret value, not key-based...
Christopher Allen: It's generated by the key...
Daniel Buchner: You are adding a secret value on top...
Christopher Allen: So, it's a random key?
Daniel Buchner: It's a random secret...
Christopher Allen: Ok, I'll add to list... a secret revokes.
Mike Lodder: Can you hear me?
Christopher Allen: Can Sovrin, can Veres One?
Manu Sporny: Veres One: ... MofN for social recovery, you can do an institution (local/state gov't), for profit company paying for recovery, it just comes down to some key that has the ability to rotate your keys out. [scribe assist by Dave Longley]
Mike Lodder: Sovrin its up to the DID owner, the only way to revoke a DID is to have the DID keys
Mike Lodder: Or DID auth proof
Christopher Allen: Marking reasons for revocation... revoke based on reason, revoke and present a new key, revocation of a single key in a DID vs. the root key of the DID.
Christopher Allen: Root key vs. transactional keys.
Daniel Buchner: We are looking at a model where there is no single root key
Christopher Allen: Remove key... no longer list a key... discussion about different types of revocation holes... don't rely on the key right now... any other kinds of revocation?
Daniel Buchner: More or less, you declare a 1-N set at create
David Challener: Real problem we see in industry, manufacturer of device drivers... someone in company gets bribed to sign some malware... you can't revoke the key because of device drivers out there...
David Challener: But what you would like to know is that this thing has been signed and shouldn't have been... this particular signature is invalid... whitelist vs. blacklist.
David Challener: Here are things that are signed by this key that are valid...
Christopher Allen: So, blacklist vs. whitelist... for signatures instead of keys.
Christopher Allen: Any other types?
Daniel Buchner: There may not be a single root key... instantiate a DID, declare multiple keys to add/remove keys... those can be overridden via revocation mechanism (secret-based)
Daniel Buchner: You can come to life w/ keys with equidistant power...
Joe Andrieu: Equipotent keys rather than root/transactional
Daniel Buchner: The power relationship is equal... creating a new ID... three keys that have a top-level of authoritative power that can add/remove keys. If one is compromised, it can be removed...
David Challener: Couildn't someone with access to one of those keys revoke all the other equidistant keys?
Chris Boscolo: What I heard described is where we are revoking individual keys... DID spec is talking about revoking individual DIDs.
Mike Lodder: DIDs
Daniel Buchner: I was strictly talking key revocation
Christopher Allen: That's what I'm trying to articulate... updating keys, updating DID document keys...
Mike Lodder: Keys are mechanisms to control DIDs
Daniel Buchner: Or revocation of other DID Doc values
Mike Lodder: I thought it was revocation of DID Docs
Christopher Allen: There are a bag of keys inside DID document...
Christopher Allen: Do we have to deal w/ revocations at method level, or only how you revoke DID as a whole or rotate DID as a whole.
Chris Boscolo: Is this better solved w/ a credential vs. revoking entire key?
Christopher Allen: What does rotate a DID mean? ... keys used to update it are changed.
Dave Longley: In some methods there is no "root key" so that doesn't make sense for those
Mike Lodder: Dlongley +1
Manu Sporny: In IRC it became clear that some people think we're talking about keys and others think we're talking about DIDs themselves. To be clear in what I'm talking about, I thought we were talking about key rotation in a DID Document. Not anything about revoking DIDs or that a DID is no longer useful or any of that stuff. [scribe assist by Dave Longley]
Manu Sporny: Our clarity comes from two layers -- the lower one, how do you say a key is revoked, etc. All those annotations go in the DID document itself where you talk about the keys. You can say this key has been revoked as of this time and date or provide status reason for revocation. [scribe assist by Dave Longley]
Mike Lodder: Sovrin too
Manu Sporny: We will likely borrow quite a bit from the vocabulary used to revoke credentials, key status, reason, date of rotation, so on. All those annotations go on the key in the DID Document itself. That's how Veres One will approach it. [scribe assist by Dave Longley]
Manu Sporny: There's a possibility to refer to keys outside the DID Document but creates complexity and no compelling use case. In the future it would be very good to say we're specifically talking about key rotation in DID Documents. [scribe assist by Dave Longley]
Mike Lodder: Manu + 1
Manu Sporny: That could be something that the DID Document actually talks about. You need to know it to process the DID Document properly. Can this key be used for authentication and has it not been revoked, it goes in the DID Document. [scribe assist by Dave Longley]
Manu Sporny: Unless we move that off into DID AUth itself somehow. [scribe assist by Dave Longley]
Christopher Allen: Right, I wanted to raise these questions, revoking DID as a whole vs. keys in the DID document. Is the idea of rotation ... we all have different approaches and ways of thinking about this. One of the fundamental differences in thinking about this ... classical cryptographic identifiers with DIDs is the ability to be revoked in it. [scribe assist by Dave Longley]
Christopher Allen: Are methods that don't do these things truly DIDs or something else. [scribe assist by Dave Longley]
Joe Andrieu: Part of the question that came out -- what happens when you can't trust the DID because the key that signed it is compromised?
Joe Andrieu: Equipotent other keys... little broader framework than just how you deal w/ the DID Document.
Daniel Buchner: We have "cryptographic suites" for that [scribe assist by Dave Longley]
Dave Longley: (That indicate purposes ... and those could be specific to a particular method)
Mike Lodder: If its public then I wouldn't put certain annotations like importance. Anything you put there would be ammo for attackers
Bohdan Andriyiv: We add "purpose" to keys in Validbook DID Documents.
Christopher Allen: Anything pressing for next week?
Moses Ma: Thanks, bye all!
Joe Andrieu: Adrian, your item will be first next week... thanks all!
Chris Boscolo: Great discussion! cheers