The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2018-01-23

Chris Webber is scribing.
Kim Hamilton Duffy: Let's review the agenda and then we'll get to introductions and re-introductions
Kim Hamilton Duffy: I redid the agenda this morning
Kim Hamilton Duffy: Quick check-in on current action items and work items
Kim Hamilton Duffy: Focus of the meeting will be any feedback from open pull requests from DID hardening spec
Kim Hamilton Duffy: Finally we'll talk about refining some DID hackathon bits
Kim Hamilton Duffy: And go through specific notes/questions about BTCR
Kim Hamilton Duffy: Format of DID document, etc
Kim Hamilton Duffy: Any volunteers for introductions/re-introductions?

Topic: Introduction to Akila

Akila Natarajan: I'm with ConsenSys we're working to build in credentials, have been attending for the last couple months, a few other participants from my team are on the calls
Kim Hamilton Duffy: Let's move on to announcements
Kim Hamilton Duffy: As we mentioned earlier as we went through the work breakdown section, I think last week, we want to try to give more structure to meetings, not just in terms of structure of work items but also will help us when we talk about eg crypto experts etc

Topic: Announcements, Focus for 2018

Kim Hamilton Duffy: For now I have announcements about upcoming focuses for the next 11 months
Kim Hamilton Duffy: Next week we'll have the educational task force present
Kim Hamilton Duffy: We've been breaking down issues in a github issue
Kim Hamilton Duffy: We have Nate Otto and Kerry Lemoie joining us
Kim Hamilton Duffy: Have been very active in the open badges communities
Kim Hamilton Duffy: We'll be having Crypto Tuesdays, starting on first tuesday of the month
Kim Hamilton Duffy: And review of digital verification suites, including ld digital suites
Kim Hamilton Duffy: On february 13th we'll review Linked Data Capabilities
Kim Hamilton Duffy: Implementor standup DID post-draft
Kim Hamilton Duffy: RWOT:
Kim Hamilton Duffy: Next RWoT is March 5-8 in Santa Barbara
Kim Hamilton Duffy: IIW:
Drummond Reed: What is the date/time of that "Implementer standup DID post-draft"?
Kim Hamilton Duffy: Next IIW will be April 1-5th
Kim Hamilton Duffy: At IIW, April 5-6 we'll have a post-IIW Verifiable Claims face to face
Manu Sporny: Basically book your flights for an additional day if you want to be at the F2F meeting... but you need to either clear with chairs if not a w3c member, or be a w3c member
Joe Andrieu: Rebooting Web of Trust has a disc golf tournament for those who can come a half day early. Please sign up ASAP to help us make sure we have enough flying discs for everyone. Sign up as an option on your standard RWoT ticket.
Drummond Reed: When you say leaving friday, will it bleed over onto friday?
Manu Sporny: Probably
Kim Hamilton Duffy: Progress on action items, just wanted to see if anyone has an action item they want to report status on, if so add yourself to the queue
Manu Sporny: I'm having a hard time seeing... the registries are done and out there, the DID spec is in a fairly good state right now I think... I think we're going to talk about the DID spec in a bit, but just wanted to note that Marcus has an outstanding PR to resolve before we pull it in. current action item is to get the DID hardening spec changes in there. Please look at it people, we're going to pull it in soon
Kim Hamilton Duffy: Action item 5a: "W3C-CCG to complete reconciliation of #RebootingWebOfTrust & Hardening changes (All, due end of January)"
Kim Hamilton Duffy: So for action item 5a, this one you're referring to, can I update to "the draft is in we need feedback"?
Manu Sporny: Yes, we should probably set a date to pull it in, there's been decent discussion and implementation against
Kim Hamilton Duffy: What's a good date... let's see...
Joe Andrieu: Great, Drummond. Should be a fun time.
Manu Sporny: I'd prefer a week, it's been out there for a while
Kim Hamilton Duffy: Perfect, let's say we need feedback on the DID hardening PR by next week
ACTION: Group needs to provide feedback on DID hardening PR by next week Jan 30
Markus Sabadello: Should we talk about my PR?
Kim Hamilton Duffy: How about during the DID hardening section of the call
Markus Sabadello: Ack
Kim Hamilton Duffy: Manu, I'll follow up with you on registry items submission etc... I think there isn't anything pending
Kim Hamilton Duffy: I'll take an action to clean up registries
ACTION: Kim to clean up registry action items
Christopher Allen: There is in the current action items the spec text of the registry process needed
Christopher Allen: Needed to move back from the list to the github
Manu Sporny: Can we make that just a separate action item?
Christopher Allen: There is currently, it's G
ACTION: Manu to write up Registry Process spec text still needed
Kim Hamilton Duffy: Let's move on to status of current work items... we have 3... let's start with the CCG process
Christopher Allen: I put the first two here as there wasn't really an owner, I mean the registry process I guess the owner is manu as a work item, but we don't have an owner/lead editor for the overall CCG process
Joe Andrieu: You can put my name on that one
Christopher Allen: Btw I'm in our next week, I'm editing action items document (?)
ACTION: Chairs to assign Joe as owner of CCG process
Kim Hamilton Duffy: JoeAndrieu said can assign owner of CCG process?
Joe Andrieu: Yes
ACTION: Chairs to assign Manu as Registry Process owner
Kim Hamilton Duffy: Lastly we wanted to check in on Verifiable Claims browser polyfill
Dave Longley: Yes we need to talk to Google's team... no major progress lately or feedback on what people would like to see on query mechanism on issues
Dave Longley: If you have feedback, please provide it on IRC
Kim Hamilton Duffy: Thanks dave.. let's move on to DID hardening PR

Topic: DID Harmonization

Kim Hamilton Duffy: Hardening PR:
Manu Sporny: I think that the update to the DID spec wasn't too difficult, reflects what I believe is where we got on nearly everything... some sections I needed to comment out, like delegation, which we haven't figured out yet, and authorization will go into method specific specs
Manu Sporny: Please look and review and make sure you're happy with it
Manu Sporny: Hopefully not controvercial because it's what everyone has agreed to... markus_sabadello has come up with a useful PR giving updates to some parts of the spec... other than those 2 things if we get that pulled in, we'll be in a good place to nail down more parts of the implementation
Manu Sporny: One thing to note is people are implementing against the spec now
Kim Hamilton Duffy: Thank you... markus_sabadello do you want to talk about your proposed changes?
Markus Sabadello: Yes like Manu said it's updates about the examples... some examples didn't have the services properties array, so I updated them to have the service array
Markus Sabadello: Most of the changes fix a lot of simple bugs which were not controvercial
Markus Sabadello: I was wondering about what examples for service endpoints... I wonder what examples for openid service, etc... in harmonization were using all sorts of service examples
Markus Sabadello: So I ??? without explaining what it was
Markus Sabadello: I added a lot of examples of whatever specific examples, including openid auth, social web inbox service
Markus Sabadello: And I think all the other changes shoud be non-controvercial
I was wondering about the service types a bit
Markus Sabadello: In RDF / json-ld the format typically uses UpperCase resource names
Markus Sabadello: So some of the recent examples used lower case
Markus Sabadello: So that's what I was addressing in there
Kim Hamilton Duffy: I see no comments in the queue... from the DID hackathon last week, we were using it and the updates looked great... only feedback we had which we're not proposing to block on was to add more examples
Kim Hamilton Duffy: That's something that I can take a stab at as we get feedback on BTCR examples as well
Manu Sporny: +100 To more people doing PRs againstn the spec.
Kim Hamilton Duffy: Aside from that, it was great
Christopher Allen: I wanted to appreciate the work that markus_sabadello has been putting in to normalize names and etc and do some cleanup on examples
Christopher Allen: In particular I was looking at endpoint types and etc and ran into something related which we were talking about w/ BTCR... BTCR specifies a particular kind of endpoint. I wonder if there are other DID methods that are also specifying a specific endpoint or something? does Veres One have something very, very specific? does ViewPort, etc?
Drummond Reed: To answer ChristopherA's question, can only speak for Soverin, can't say it'll be required but there will certainly be a standard Sovrin endpoint
Drummond Reed: As we complete the Sovrin DID method spec it may turn out it's necessary to control auth, etc
Drummond Reed: I haven't seen that yet... but it doesn't surprise me... I can only speak for Sovrin and not others
Christopher Allen: Christian
Christian Lundkvist: Speaking for uPort, we'll probably have a backup endpoint, but still being worked on
Manu Sporny: Veres One doesn't have a specific endpoint so far, we were trying to point to other specs... nothing Veres One specific
Manu Sporny: I agree with Markus
Dave Longley: +1
Markus Sabadello: To be honest I'm surprised that some DID methods support/require some service endpoints that others don't
Moses Ma: Can someone share if there's a DID testnet? We'll start implementing a prototype using DIDs soon.
Christopher Allen: Your concern is exactly one of my feeling weird about the endpoints... in BCTR we have only one 40 byte, sometimes 80 byte field to refer to the DID document. We're in effect saying that "here is the place to begin to construct the DID document", as in terms of a standard URL it may have more stuff in the static object, or in case of IPFS it may be only one of several things that have to be grabbed. But it could also be where we put in issuer date, etc as well... I'm confused if we had a very specific BTCR function, but maybe it could also store other verifiable claims that other people could grab
Christopher Allen: Should we specify in a generic way that "here's an endpoint with a static bag"
Christopher Allen: Whether we had two endpoints... etc... it just felt weird
Christopher Allen: I just wanted to get a feel for what other people were doing
Adrian Gropper: I like to think in terms of what's public and what will be indexed by various entities and what is not strictly public. the endpoint that matters to us is the one that points to the authorization server related to that DID
Ryan Grant: IOW, the patch files (often retrieved over IPFS) which are used to create a DID Document by the method handler may also include other verifiable claims and such that are not patched into the DID Document.
Adrian Gropper: Agency that derives the ??? and the other one is the agency that has to ?????? credentials for private information
Adrian Gropper: I think the issue of an authorization server is fairly general so we might consider it
Ryan Grant: Above was for markus_sabadello [scribe assist by Ryan Grant]
Christopher Allen: I think this is all worthy of next draft
Kim Hamilton Duffy: I think that was a good transition to the BTCR topic
Manu Sporny: +1 To dealing w/ this stuff /after/ we get a stable draft based on harmonization/hardening changes.
Kim Hamilton Duffy: Reminder that you have a week to get to the outstanding DID spec
Drummond Reed: By "next draft", is ChristopherA referring to the next draft of the DID spec or of the BTCR DID Method spec?

Topic: DID Hackathon Outcomes

Kim Hamilton Duffy: We'll start with Veres One then move to BTCR
Manu Sporny: Want to cover anything with Veres One?
Manu Sporny: So most of the hackathon, unfortunately didn't get as much time we wanted to, we looked at the DID spec to make sure it works, also work on Christopher Webber did on the linked data object capabilities spec, also working on updating the DID client to handle the current DID spec. nothing bad to report so far, everything seems like it will work out, but we'll learn more as we finalize our implementation
Kim Hamilton Duffy: To move on to BCTR I think most of what we did was mostly work on the example of the generated DID Document that generated from the combination of transactions... combination of making the output to the latest version from the DID hardening process
Kim Hamilton Duffy: We had some thoughts/questions about resolvers
David Chadwick: Present +
Drummond Reed: Very quickly because I have to jump off before the end of the call, we also like everyone else were saying "well now that we have a hardened DID spec we need to work on the Sovrin DID spec... key management is a major piece of what a DID spec method does, so I expect it'll mature a lot over time with a pretty robust set of changes post-?rebooting
Drummond Reed: We'll also have an update for (DKMS?)
Drummond Reed: Yes, we'll have an update on both the Sovrin DID method spec and DKMS (Decentralized Key Management System) by Rebooting the Web of Trust the first week of March.
Christopher Allen: I'll put the URL again... this was the document we were working on. so one of the things we discovered was we needed to go back... what things were happening, what's the process... if I get a DID document I need to resolve I might have to go to the BTCR specific sub-resolver and it has to do something specific to return back to the app. So we looked into what happened there... some were BTCR specific and some may be relevant to others
Christopher Allen: The BTCR resolver has to create an "implicit DID document" solely from the bitcoin blockchain data which may not be everything. If people want to know some extra values there we have an audit trail tag. one thing the BTCR method does is go to the BTCR endpoint to get the first json type DID document. So what it's going to do is go there
Christopher Allen: There's a sub-note here in that the ID, the BTCR number, may not actually be in that DID document because it may be an immutable filename by a content hash. There's a catch-22 in that there's some information we can't put in there. So the BTCR endpoint has to construct the id when it's creating the final DID document back to the app
Ryan Grant: Stated more narrowly: the DID "ID" may not be in the pre-compliant patch used by the method resolver to construct a fully compliant DID Docuemnt (diddo), which will by then actually have the "ID", and other known values.
Christopher Allen: So the next thing the DID resolver does is validate that the json-ld document is valid. If it's ??? it's implicitly part of the graph because it's signed by bitcoin. Bitcoin has the public key, the hash, we don't have to it again. If the BTCR thing has to call it again we may have to do it again. This raises the question, is there a standard way to refer to the bottom-most key in a DID. Finally the resolver grabs and resolves known DID documents into the final DID document value, but we explicitly say you cannot overwrite the DID value, it's addative only
Christopher Allen: If there are other json-ld values we don't know about, such as somebody else may be referring to the same DID document, since IDs are constructed by the resolver and Etherium could sign it, maybe they both point to the same value
Christopher Allen: Because of IPFS we may have to pass in additional DID document material
Christopher Allen: That part the resolver ignores and we return the final DID docuemnt
Christopher Allen: We have an example of what it did
Christopher Allen: We have a json structure in there
Christopher Allen: One of the things we had was a resolver-specific envelope
Christopher Allen: The resolver can do satoshi-audit-trail, say what the resolver did to resolve the DID document, etc
Christopher Allen: Then we have the public key which comes from the bitcoin transaction, by default the transaction is only that id, we refer to the service audit etc
Christopher Allen: We refer to the Satoshi id as the ??
Christopher Allen: This raised some questions, why would an app need to know about updates
Ryan Grant: SatoshiAuditTrail
Christopher Allen: The DID resolver has to see if there are updates etc
Christopher Allen: It will keep on doing that until it has the proper DDO
Christopher Allen: Why would an app ever need that
Christopher Allen: If it is going through old DDOs to get to the current DDO, is this an audit trail, what layer is it happening, etc
Christopher Allen: Our other big open question is the timestamp
Christopher Allen: A bunch of other things timestamped by the bitcoin transaction
Christopher Allen: Not a bunch of timestamps on the DID document as a whole
Christopher Allen: Btw because it's constructed there's no ??? as a DID ?? as a whole, relying on the resolver to assume it's correct
Christopher Allen: Since it's not the issuer it can't sign the DID document as a whole
Kim Hamilton Duffy: No signature on the DID as a whole ^^
Christopher Allen: We have some ideas a document extensions
Markus Sabadello: Do you have a pointer to your resolver implementation ?
Christopher Allen: With other BTCR documents, we're ignoring those
Christopher Allen: That's the summary of our thought process
Chris Webber: There's no owner signature enveloping the whole returned DID Document (diddo) [scribe assist by Ryan Grant]
Christopher Allen: Did we miss something, do something wrong
Drummond Reed: Sorry, must leave early today. Will make sure that Evernym and Sovrin folks provide input on DID draft this week.
Ryan Grant: I put myself on the queue before ChristopherA got to the updates
Ryan Grant: For people familiar with the DID hardening spec and status of the update field, what's going on there
Kim Hamilton Duffy: Marcus is next, I noticed your question on irc... we're just talking through the steps of what we would expect a resolver to do... I'm looking forward to hearing your feedback
Drummond Reed: What's the "update field"?
Kim Hamilton Duffy: @Drummond it's the transaction output, which, if spent, says go to the next tx in the chain to find updates
Markus Sabadello: I did some earlier work on BTCR... what we've been calling ??? we've been calling drivers(??), what you've been calling ??? we've bene calling envelope?
Markus Sabadello: I think this would be metadata, on the envelope, rather than being on the service endpoint, method specific, not really an endpoint one would interact with, metadata of the resolution process rather than ending up in the final DID document. other than that I think the link you posted with the resolution steps is super helpful
Kim Hamilton Duffy: One point before I move to the next person on the queue
Manu Sporny: Just wanted to provide thoughts to the markup... the first thing I think ChristopherA pointed out was that the BTCR endpoint might be able to be moved to signature / audit trail in some way
Manu Sporny: We've been calling this... based on the last RWoT we had request from u-port / evernym folks to not put that in there, say that's DID method specifc, so that could be specified by the BTCR method in the spec
Christopher Allen: One of my open questions is... the DID document you give an app which says "please resolve this DID", should the app ever give the authorization things? that's for something else, that's for determining whether the DID was authorized, and it is or isn't
Christopher Allen: It almost feels like two different things here
Manu Sporny: I may be missing a nuance
Ryan Grant: Markus_sabadello, the idea of the BTCR endpoint, it's not a required endpoint but it's something that will probably be available because of the way the DID documents are ???
Ryan Grant: Ie it means if finding something through IPFS it would be this is the URL you can go to in IPFS to collect some other verifiable claims that a BTCR method resolver would be very good at parsing through and perhaps other clients would be able to read, but it's not a required thing
Ryan Grant: Does that sound like a good use of a service now?
Markus Sabadello: Sounds more like a service now that you've described it
Markus Sabadello: It's a service endpoint in the DID document, it's metadata... in the envelope rather.. I'm undecided
Ryan Grant: My understanding is the purpose, one of the 3 main purposes, is to retreturn services
Ryan Grant: Is that wrong?
Christopher Allen: Other way to approach this, redefine a service, a static json-ld service with json-ld objects, and if one of those json-ld documents is a DID document, others should probably just ignore it. can define a static endpoint which points to a single file or single json object, some bag (?) from which BTCR uses it to get (???) but others can use it to find what to put in that bag
Christopher Allen: So the spec for that bag may store some method-specific things in here as well
David Chadwick: This is not on the current agenda, on previous agenda, but unfortunately I missed it... there was an item on the agenda for me to review the current spec w/r/t lifecycle, so I sent outt an email listing what I thought was missing from current DID document
David Chadwick: What should I do? I didn't do it initially because I was looking for feedback before PRs
Christopher Allen: I think it's up to you if there's a pull request or an issue... a number of them felt like whether you had some questions about it, or even whether you had your own questions about it, which may be seaparate issues. I don't think anyone's going to complain about it, can make specific PR requests about it. Manu, as the editor of the current DID document, does that make sense?
Manu Sporny: I missed a lot of what you said, let me read and I'll respond on IRC
Manu Sporny: Yes, that makes sense... do some PRs
Christopher Allen: Ok! back to BTCR hackathon observations
Manu Sporny: We can sort it out in an issue or the PR
Christopher Allen: Are any other methods having to reconstruct the DID Document in some way? Does viewport have to do that where it's in fact in various pieces and then constructed?
Manu Sporny: I suggest folks don't let the spec slow them down as long as there is a solid plan for interoperability via a PR at some point in the near future.
Kim Hamilton Duffy: This is Christian_Lundkvist speaking
Christian Lundkvist: We had same issue with DID document, where DID object is the object's hash, so that document can't be the final DID document because it contains the id which has the hash of the document... same issue ChristopherA described. I think we've been thinking of doing the same thing where DID document does not produce the same document, it's up to resolver to make sure everything is valid
Kim Hamilton Duffy: I think action items for next week is to make sure DID resolver document is valid
Kim Hamilton Duffy: We'll find the right way to follow up
Kim Hamilton Duffy: We have two people on the queue
Christopher Allen: I just have an open question for manu / dlongley ... we have this json DID object which some pieces are timestamped, some of them are provably timestamped... some aren't... some are signed in one way some are signed in another way... how do we refer... how do we do that in json-ld?
Christopher Allen: The time signatures spec was for the object as a whole, so are most of the other signature things... how do we do when "this value, this value, and this value we signed by the eterium blockchain, this value and this value were signed by this key which we got from the blockchain but isn't signed on the blockchain, this and this are implied from data we got elsewhere..." how much of that do we actually have to put in?
Christopher Allen: Seems like the resolver / driver needs to do some, how much of it has to be delivered to the app? I'm not sure they're the same
Dave Longley: It may be as simple as the resolver signing and saying it did all those checks -- it's only important to try and represent all of that data if someone else can do the same checks
Christopher Allen: We don't need an answer now just would like you to think / give thoughts
Markus Sabadello: Wasn't too important and we're at time
Dave Longley: Could be done by specifying a JSON-LD frame in the signature data, but like manu said, can get messy/hard to understand.
Manu Sporny: Just quick ChristopherA, the short answer is we can do whole object signatures, set signatures, chain signatures, as long as it's the whole object. We can do different signatures today. Doing the cherry picking signatures, that requires a new mechanism, we've avoided it because it really complicates situations and creates possibiltiy of security vulnerabilities where developers assume the object is signed where it may not be signed at all. I'm very hesitant, we've done that before for http signatures, but it's kind of a landmine when you do that
Manu Sporny: Short thoughts, we can discuss more later
Kim Hamilton Duffy: We'll follow up on that... we can have an audit trail to check that, but I agree once it's in there there's an issue where there's an expectation that it's fine. I'll follow up with BTCR folks to see what they think
Kim Hamilton Duffy: Questions around resolver, specific schemas
Kim Hamilton Duffy: Thanks all