- From: Steven Rowat <steven_rowat@sunshine.net>
- Date: Tue, 23 Jan 2018 15:24:10 -0800
- To: msporny@digitalbazaar.com, Credentials CG <public-credentials@w3.org>
On 2018-01-23 10:25 AM, msporny@digitalbazaar.com wrote: > Topic: DID Harmonization > > Manu Sporny: Preview link is here: > https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/41.html > Manu Sporny: Diff-marked version is here: > https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/41.html > Manu Sporny: Please look and review and make sure you're happy > with it I get two things I think need changing: 1. in 4.3, uses "DID Description". Is this an error, meaning "DID Document"? 2. "DID Method" and "DID method" both appear in various places, with many uses with the small letter, but "Method" in the Registry and a few other places. I suggest this should be consistent, ie. "DID Method" throughout. (In contrast, "DID Document" now uses capital "D" on "Document" throughout, which is correct I believe.) Otherwise there is risk of ambiguity with other non-capitalized uses of "method" for other language uses. Example: in 7.2.2. "There are two methods for proving ownership of the private key..." Since at present "DID method" (no-cap) is used repeatedly, this might be interpreted as a "DID method". Steven > 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 > Markus Sabadello: My PR: > https://github.com/w3c-ccg/did-spec/pull/43 > 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? > Christopher Allen: > https://hackmd.io/CYI2wVgDgZhBaCA2CAGeAWKSbwIZQDsw+AxgGYTAYCmAnHiuUA==?both > > 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?) > Christopher Allen: > https://hackmd.io/CYI2wVgDgZhBaCA2CAGeAWKSbwIZQDsw+AxgGYTAYCmAnHiuUA==?both > Ryan Grant: Cleaner look from this url: > https://hackmd.io/CYI2wVgDgZhBaCA2CAGeAWKSbwIZQDsw+AxgGYTAYCmAnHiuUA==?view > 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 > > > > >
Received on Tuesday, 23 January 2018 23:24:35 UTC