Chrisboscolo: I have, but I can reintroduce myself. I've been aprticipating for a little over a year. Founded lifeID, building an open source version of a ssi platform ✪
Joe Andrieu: First, if yo haven't seen the emails, the folks who have been focussed on the DID spec and DID resolution have more calls on thursdays, one on the DID spec itself which is 1-2pm PDT ✪
... which is currently 20 UTC, that's not gonna be true in a week, we'll update this
... And then the DID resolutions spec call will follow on that, every week. The zoom is in the agenda. Please join if you want to
... The other announcements: the KNOW conference is coming up
... I think what we're going to do here is pull in the editors of that DID method registry to make sure of the process but I think that we're gonna have to start clamping down at some point and saying 1) we have to enforce for a PR you have to link to a spec and that spec has to have certain minimal properties. I've noticed drummond is enforcing that recently. But for these ones that got in there without a link we have to figure out what to do with
... There' sprobably a spec somewhere that has to be pointed to
Joe Andrieu: Process-wise, I'm trying to take a lesson from IANA's handling of when DNS records go bad, whichi s to be very slow about pulling things out becuase of failure to communicate ✪
... It was mentioned in one of our calls we should just delete those.. but these people may not know they're on the verge of being deleted. I don't want to take them out until we've gone through some process and tried to reach them and given them an opportunity to participate
... If they're old and out of date we will remove them. Want to give them some time
... Thanks Kaliya for offering to reach out to the dominode folks
... I'd love to see the specs from these folks. We don't want to kick people out, just make sure the methods that are securing names are in fact viable at some level
... Right now that means having a written spec
... The next issue is the DID exlpainer for the TAG and integration into the DID Primer
... This was assigned to me and burn, and burn has his hands full with VC today
... THere was a question on this. Namely around whether or not the explainer is something we need for the charter?
... I think that relates in particular to does the w3c TAG do anything wrt to the charter?
... I was hoping manu would be on the call because I think he knows something about that... Anyone else know the process well enough?
Dave Longley: I would say we definitely want an explainer when the charter goes out, it helps people understand who the technology is going to be used for, what it's trying to do, educate people why they should be voting for the charter ✪
Joe Andrieu: I agree we need something, but the explainer is a particular structure the TAG asked for. We now have 3 active publications. The explainer, the Primer, and a document drummond started at rebooting. I feel like we have too many documents trying to scratch the itch you just described ✪
... To me the issue is that explainer as requested by the TAG, ie something more than what we have in the primer
Drummond Reed: We wanted to make sure the document we started at Rebooting was not to start any confusion about what is needed for the w3c applicaiton process for the DID charter ✪
... whatever is needed there we want to design specifically for the DID charter. We weren't intending that document to be part of the DID charter
Kim Hamilton Duffy: I put myself on the q to disagree with that latest comment. It's the various ethereum ?? 725 is one.. There's some publications like the one uPort has published.. Chris's latest comment is that it shouldn't be closed until there is documentation in one of our repos ✪
... My personal opinion is that that's just not really required here
... I don't know why we're putting that burden on ourselves
... The things that we care about are covered in the DID method registry. If they want things to be.. if they want to reference a DID method there it's appropriate, but we don't have that reuqirement for anything else. Documentation of a different community's efforts are not required
... I also know that jolocom people have some documentation or information that lives in thier FAQ on their website that explains
... why they create their own ethereum based DID method
Dave Longley: What i'll say about the explainer and similar docs is that any supplemental material that helps the AC understand *why* they should vote for something is extremely important -- if we want a successful vote, we want to educate the AC as best we can (without giving them reams of material to go through ... and an explainer can help significantly with that) ... so it's less about what is strictly required and more about what we can do to get a successful vote ✪
... I want the conversation to be more than about the https method spec. Markus proposed tongue-in-cheek the facebook method spec. Ther eis a wider question about do DID methods need to be decentralised at a method level
Markus Sabadello: The facebook proposal is not a serious proposal, just an attempt to add colour to the discussion when I saw the https method ✪
... my opinion is that neither facebook usernames or domain names are decentralized identifiers. Every presentation about zooko's triangle, you here domain names as an example of identifiers that are unique and human readable but not decentralized
... I believe that is the essence of what distinguehes user centric identity vs self sovereign identity
... Doesn't fulfil strict assumptions of ssi
... Also don't satisify the original assumptions of the dpki infrastrcture
... which says identifiers don't depend on any central authority or intermediary
... The challenge we have here is that with DID documents we're inventing a discovery and document format that describes metadata about identifiers. that could be useful also for identifiers that are not DIDs. That's the challenge here
... We're building DIDs but we are also building DID Documents, and DID Docs as a discovery format could be useful for identifiers that are not decentralised, just domain names
Dmitri Zagidulin: I'd like to provide a counterpoint ✪
... I think an https did method could provide a really valuable bridge technology for the various providers. It's a way to include a section of the decentralised identity community, like timbl's solid project and similar ecosystems. It's a way to get them to join the conversation, join the ecosystem. After they've joined we can make an arguement that okay you took this step, here's why a ledger based DID is even better than an https based DID. But to
Deny them entrance on the groudns that they're not decentalised enough is really unhelpful ✪
Kim Hamilton Duffy: Never used facebook, but I love this method. I liek that markus called it out. For me and a lot of us are trying to present DIDs and their different properties, it's very useful from an educational perspective. To build on what dmitri was saying, it's good for teasing apart.. if you work with a facebook DID method it's easy for people to understnad what that is ✪
... One of the points of failure of using facebook as your ledger.. a good way to point out the boundaries and the strengths of other DID methods
Drummond Reed: To pre-scribe what I'm about to say, I feel *very strongly* that the DID spec needs to take a strong stance about the actual decentralization of DIDs. Perhaps even objective tests about the level of decentralization of any DID method. ✪
Joe Andrieu: Question for markus: I was left wondering what your position was. It seemed like you started out saying if the underlying method isn't itself decentralised then it shouldn't be a DID but then you made a case that the discovery method might make that interesting and therefore allowed? ✪
... Two things - we may already be decentralised. Which really gets to.. what does it mean to be decentralised?
... The fact that I can use different DID methods is a form of decentralisation. There is no central authority in charge of what methods are out there. The registry is a lookup, it's not definitive. We don't have that level of decentralisation of DNS
... I don't have an opportunity in a domain namem to say I want to use this other root. But with DIDs you can
... The ability to vary the method is in fact a form of decentralisation at the platform level
Drummond Reed: I do not, however, believe the DID spec should prohibit DID methods that are based on centralized systems. I just thing we should properly warn about them in the DID spec editorial text. ✪
... Even if that's not sufficient, the quesiton is what does decentralisation mean with enough clarity so that we could make a judgement about whether or not a particular method qualifies as a DID method
... I don't think there is such a defnition
... I haven't heard a compelling one
... I don't know how to define it to be rigourous
Drummond Reed: I love markus' post. We had good discussions at rebooting about 'centralised' DID methods. I believe we should not prohibit because we really can't, DID methods based on centralised registries. But the spec should be very clear about what decentralisation really means and that the level of trust or assurance that you can have in DID methods that rely on centralised registires is different. We shoul dnot mince words about the point of the ✪
... But I don't think we should prohibit other ones
... It be comes a different question what we should do about methods that are clearly based on centralized registires in the DID method registry
... I might consider that we look at categorising or having a separate category section fo that for if we do start to register DID methods based on centralised registiry. We could put them in a separate sectiona nd cearly warn that these methods are not based on decentralized systems
Michael Herman: +1 For the emphasis on *decentralized* identifiers ✪
Jonathan Holt: "Dnslink=/ipld/zdpuB1oR3vjYmkDc9ALfY7o6hSt1Hrg2ApXaYAFyiAW5E4NJP" ✪
Jonathan Holt: In the IPID spec we do support DID syntax, human readable names that resolve. I don't like it, it relies on DNS in the background, in particular the text field being a DNS link ✪
... It's human readable and convenient but opens all sorts of vulnerabilities. But like dmitri says, it's a bridge tech
... I demo'd this in barcelona
... It was resolving offline. Opens up issues of security, that's why it came up
Markus Sabadello: Decentralization is hard to define. There are a lot of ways to argue. There's one attempt to define a metric of decentralisation in the dpki paper. And one of the comments on the PR by sandro that says control is often obfuscated and it's not black and white ✪
... But facebook user names just like domain names are with all the background and history we have with user centric identity and ssi I don't think we can consider them decentralised identifiers
Kaliya Young: I think we have to remember about the capture of OpenID abt the big guys ✪
... If we add them to the method registry, the http smethod.. I understand the convenience and how it can be a bridge, but it will be a contradiction to what the dpki paper and the DID spec itself says in the abstract
... It simply doesn't apply to domain names
Kaliya Young: The original vision was so nice and idealist. But it was coopted by them ✪
... The challenge is that we're defining an interesting discovery format, called the DID Document, which can be very useful for metadata about centralised identifiers, but we should not call them DIDs. People who are working with domain names or https URLs, they could use webfinger
... But if they want to use DID Docuemnts, because they're cool.. there's also WebID profiles, that's another discovery format, in the solid space
... There's a WebID profile in the standard
... What people want to do is use DID Documents as a useful and smart new discovery format on identifiers that are not DIDs
... Maybe we should rename the format. Maybe not DID Document but instead something else
Joe Andrieu: I love the contributions that Sovrin and Evernym have brought to DIDs and VCs but there's a legitimate positoin that says permission blockchains have a centralising function ✪
... Those who give permission can be subject to action by the state, via subpoena or force
... Both of those ideas of what it means to be decentralised are valuable
Drummond Reed: Sovrin is "Decentralization by Design" - to have enough stewards in enough jurisdictions that no government actor could interfere with the network as a whole. ✪
... I like what drummond said in terms of we probably shouldn't deny methods that are in some way decentralised, becasue we can't, but that we should advocate for some notion of decentralized identifiers
... We just need to come up with that that notion is
Chrisboscolo: instead of trying to frame it was whether it's centralised or decentralised, can we frame it in terms of the seciruty guarantees the creator of the DID has over the DID. With https for exmaple, I can create a DID and lose control over the ability to replace the DID Document ✪
... There's some guarantee based on the method that the creator of the DID can at least identify if the Document has been tampered with or is different. Can we frame the requirements in terms of the securiyt of the lookups?
Samantha Mathews Chase: I was trying to get clear on.. maybe you could give an example of the use cases behind whether you'd want it to resolve to something like your facebook. In terms of something like machine readable terms or consent for .. ?? have expressed interest in DIDs. Would the use case be something like these are my adPreferences or my trackingTerms and that woudl resolve to somewhere that already tracks me, but now has a document that alreayd tracks ✪
... Would that be the arguement for using something like that?
Kim Hamilton Duffy: +1 To Chris Boscolo's suggestion. Degree of centralization/decentralization has more of a value judgment attached; whereas creator guarantees (or something along those lines) allows more nuanced, use-case-dependent discussion ✪
Markus Sabadello: Besides decentralisation, what we also claim for DIDs is persistence. Domain names and usernames are not persistent either. THat's a known problem in the identity space, since the days of OpenID ✪
Dmitri Zagidulin: -1 To persistence requirement. since that doesn't address ephemeral / on-the-wire DID methods ✪
Andrew Hughes: +1 To @chrisboscolo - the notion of ‘decentralization’ as a philosophy to resist central authorities makes using it as a technical categorization approache very difficult ✪
Dave Longley: Technical considerations and control guarantees are much better measures for determining the validity of DID methods or categorizing them ✪
... Ideally the DID Document should not contain any persionally identifiable information, which to my mind is likely to include preferences of the kind you mentioned
... DIDs can be a gateway to look up prefs, but they shouldn't be in the document
Drummond Reed: +1 To Markus' point about persistence. DIDs have *four* core qualities: 1) global uniqueness, 2) persistence, 3) cryptographic verifiability, 4) no centralized registry required. ✪
Dave Longley: Vs value judgments using squishy definitions of "decentralized" ✪
Drummond Reed: /Some/ DIDs have the persistence quality. not all fo them. [scribe assist by Dmitri Zagidulin] ✪
Drummond Reed: If it doesn't meet those four qualities, it should not be called a DID. ✪
... That use case might be out of scope. But I think the use case is simply to say, for example right now, facebook doesn't pvoide a way to attach a public key to my facebook login. So people who trust facebook can bootstrap a key that's associated with me
... That only has a security guarantee that fb provided it, so fb could have faked it, but for those who are willing to rely on that guarantee, at least they have a public key on which we can bootstrap other forms of interactions
Dmitri Zagidulin: About the 4 core qualities of DIDs.. only cryptographic verifiablity is a worthwhile one to focus on. Ephemeral DIDs, off ledger, on the wire DIDs, especially Sovrin ones from rebooting don't have the persistence reuqirement ✪
Joe Andrieu: I do think that's the direction we can go to in terms of talking about qualities.. I'm not sure I like all of them. We don't have consensus. but that moves us into a direction for a definition of what we mean by decentralised. We can say this is what we mean by DIDs ✪
Jonathan Holt: I think Dmtri was referencing the "peer" did method? which is not persistent, which is a valid use case against persistence. ✪
Drummond Reed: What dmitri said gave me an idea about how we might characterise it. I've been talking about those 4 qualities for q uite a while. Sovrin has test networks. They're not persistent, they can get reset. There are DIDs on them, but those particular DIDs on that particular network do not have that persistence. DIDs on the Sovrin main network, the whole reason for the network, is global uniqueness, persistence, cryptographic verifiability and no ✪
Centralisation. Even to the point that it's a permission network is that it's centralized.. the amount of work that's gone into Decentrlaiztion by Design.. you can always debate it, but there's a lot of work going into that ✪
... At least on those 4 dimensions, and maybe there are others, any one DID method could be looked at and say some DID methods don't have persistence, and some use centralized registries.. I'm on the fine line whether we can objectively judge DID methods that way
... But to markus's point, I agree with the tension about whether we can call it a DID if it relies on a centralized registry
Joe Andrieu: I know kaliya had comments in IRC about the whitewashing of openID ✪
Drummond Reed: +1 To Kaliya's point about empowering individuals ✪
Dave Longley is scribing.
Joe Andrieu: Thanks for that conversation. I'm not sure if the consensus has shifted but there's more clarification on the ideas here. ✪
Markus Sabadello: I just wanted to say, orthogonal maybe to this discussion, whether or not we want to be able to discover DID documents from domain names/usernames. To be able to discover DIDs from non-DIDs. It could start from any facebook identifier/other and find a DID from that. ✪
Michael Herman: FB doesn't even allow numbers in a Name ✪
Drummond Reed: +1 To Markus' point about enabling discovery of a DID from another non-DID identifier like a URL or domain name ✪
Markus Sabadello: So you only use the human readable identifier to discover a DID and then you keep working with the DID. There is some work that's been done on that. Discovering a DID from a domain name, etc. ... that's an additional feature, it doesn't answer whether we want to be able to discover DID Documents directly from a non-DID. ✪
Dmitri Zagidulin: Consensus wise, I at very least heard fairly uniform agreement that we /cannot/ forbid an inclusion of a DID method (such as the HTTPS method) into our informal registry ✪
Jonathan Holt: Just going back to the DNS link I shared. It is a cryptographic key pair in DNS and it's a bridge technology. Maybe how we do this with DNSSEC or signing cryptographically the link to the IPLD object... I don't like it but I think it's a bridge tech. ✪
Kaliya Young: I'm really concerned because of the history of our community developing protocols that are designed to empower end users and individuals then... differences with URLs being the basis of identities but the intentions are similar. Then big companies picked them up and implemented them. So every time we log in with google or facebook via OAuth, but they're centraliseed. I hear the idea that [scribe assist by Amy Guy] ✪
Amy Guy: DID Docs can be used for any endpoint. I don't want to see this get coopted. I want us to actually build the decentralized thing we're talking about ✪
Drummond Reed: +1 To bridging conventional identifiers and infrastructure to DIDs. That's how adoption always happens. ✪
Moses Ma: I'm working with the Universal? Postal Union and one of the things we're talking about is being able to do is resolve a postal address from a DID. The idea here is that countries are sovereign but subservient to the UN or the rule of law. And humans should be the same way, and the rule of law is what we should be subservient to and we should deal with that in our system instead of complete chaos/anarchy. I'd be happy to talk to anyone offline about that. ✪
Jonathan Holt: I should clarify the cryptographic is a password to access write to the DNS record. NOT ideal, but proves that I own the DNS record. ✪
Amy Guy is scribing.
Joe Andrieu: Other people can speak to how broadly it's used, but there's a notion of trust on first use. It's a certain level of quality yo ucan give to the underlying crypto identifier, eg. when you ssh into a server you've never been to before you'll get a popup that says hey do you want to save this key forever. You're going to be trusting that key because it's your first use an dyo udon't hav ea better key. That's a particular architecture for a ✪
Certain quality assurance about a particular key. That's all some of these bridge technologies are good for. We'r enot trusting fb, we're using fb as a trust on first use type of level ✪
... Anyone else?
... We can wrap early. Thanks for the conversation
Michael Herman: DIDs can be added to Facebook as "Life Events" ✪
... Some of this can flow into the DID spec conversation, how we might do some of that dance between what we watn to advocate without trying to prvent DID methods that aren't centralised. THere's language in there we can flow into the DID spec about what we advocate ideologically
Drummond Reed: To remind folks about the DID spec and DID Resolution spec calls on Thursday ✪
Drummond Reed: Quick reminder that we will begin regular weekly calls on Thursday, first hour on DID spec, second hour on DID resolution, starting this thursday ✪
... We sent an email to the list.
... Thank you markus for hosting the zoom room.
Joe Andrieu: For clarity, that'll probably continue past the DST skew. The set time is in Pacific ✪
... When Europe changes to DST in a week or two, the pacific time will stay the same but the meetings will shift an hour
Drummond Reed: We'll send a reminder to the list the day before ✪
... Joe, we keep the notes in a google doc and send the contents to the list? Is that okay or do we need to use irc?
Joe Andrieu: I think capturing in a google doc in terms of ipr requirements is half way there... if the google doc stays around.. I guess the problem is that you lose attribution ✪
... Or if the notes clearly say who says what then we still have it
Kim Hamilton Duffy: Markus is uploading audio too ✪
Drummond Reed: We've been recording the audio in the DID resolution calls ✪
Joe Andrieu: That is useful as well. We have an automated pipeline for these calls ✪
Kim Hamilton Duffy: The other thing about these calls, we can take this offline, we need to talk to manu about it. There's this whole thing where we're recording and I don't know how to get into the schedule to use that pipeline ✪
... So for these just do what you can
Drummond Reed: That's what we've done in the past, just double checking ✪
Joe Andrieu: On the google doc as long as you're clearly attributing who said what then that will help with ipr questions ✪