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: 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? ✪
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
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 ✪
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 ✪
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 ✪
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 ✪
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? ✪
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 ✪
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 ✪
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 ✪
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 ✪
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 ✪
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 ✪