Kim Hamilton Duffy: No one new, let's move on to reintroductions. ✪
Jeff Orgel: Hi, Jeff Orgel, professional appreciator and technologist in St. Louis, MO. ✪
Jeff Orgel: Been watching this group work through this - typically a bystander, but don't quite undrestand language/nuance - don't know if I'm qualified there, but been a technologist 27 years, put first computers on shelves in Best Buy... digital anthropologist, try my best to do what I can to help. ✪
Topic: Announcements
Kim Hamilton Duffy: Big announcement! We're adding Markus to the list of Editor's on the DID spec. ✪
Kim Hamilton Duffy: RWoT8 is in Barcelona, Early Bird discount is over... regular ticket prices open until Feb 22nd. ✪
Andrew Hughes: 57 People are registered now for RWOT 8 in Barcelona ✪
Christopher Allen: RWoT8 has about 30 advanced topic papers submitted, 7-8 on DIDs, 4-5 on VCs, 3 so far on social key recovery, quite a few other topics... GDPR, SSI, etc. ✪
Andrew Hughes: Prices go up on February 23 (due to catering order deadlines) ✪
Manu Sporny: Issue 59 is talking about that there are a copule of DID methods that did not have a spec attached to them, in some cases we were promised them and they never came. We've asked them to submit a spec, many responded. If peopel continue to not provide specs (can be two paragraphs that you will update over time) then do they get to stay in the registry [scribe assist by Amy Guy] ✪
Amy Guy: ... Already got confirmation from a number of people.. I do'nt know if there's any further action to take, other than revisit in a month to see who still hasn't done that ✪
Kim Hamilton Duffy: Yes, we don't need to talk abou tthis every week, but will check back in in a while. ✪
Drummond Reed: I believe that the requirement should now become that a new method is not accepted until the registrant has a method spec. ✪
Drummond Reed: It's okay if the spec is changing; almost all the DID method specifications are still evolving. ✪
Jonathan Holt: Yes, these are still early days, many of the specs are changing rapidly, difficult to support something that's changing quickly. ✪
Jonathan Holt: What is the formality of this registry process? Ledger process? ✪
Kim Hamilton Duffy: Publishing that document is just informational, doesn't have to be in line/supported. ✪
Drummond Reed: All DID Method specs are evolving, may need to raise bar to you need to at least provide document for DID Method spec. ✪
Drummond Reed: The last thing we want is a name grab. ✪
Christopher Allen: Yes, similar - you don't have to implemented the spec, just that there is a place where people can go and get things, who is doing what -- what are general thoughts on how it works, how to get on a mailing list... doesn't mean you need to have implementations, doesn't mean you need W3C IPR, it's supposed to be a lightweight thing. ✪
Drummond Reed: +1 To Christopher's point that the spec does not have to have been implemented. Just that you have published a spec in someplace where it can be viewed. ✪
Christopher Allen: Part of it is to avoid "centralized registry" -- too soon to try to create "decentralized registry" to register dozen or so real DID Methods. ✪
Christopher Allen: Maybe we will have lightweight registries like that in the future, the requirements are light, we can't have just everyone squatting on names... have to be serious enough to begin draft. ✪
Manu Sporny: +1 To everything everyone just said. We outline the registration process in the registry and we do say that you have to create a spec. Like Christopher mentioned, the spec does not have to be complete or implemented, but you do have to give general guidence on what you're trying to do [scribe assist by Amy Guy] ✪
Amy Guy: ... Mots of the ones that are there are going to submit in the near future ✪
Drummond Reed: Also, this registry is *informal*, for the benefit of the community, and has no formal authority. ✪
@Drummond that's not true, the formal authority is whoever has write access to the git repo ✪
Amy Guy: ... The other thing is that this became an issue because people said they want to be in the registry but the spec is going to be 6 months from now. We need to take a stance against stuff like that, as weeks roll on, some companies are clearly trying to name squat on the registry. We want people who are actively implementing this stuff ✪
Markus Sabadello: I've been in touch with Jolocom and they're planning to submit a method spec soon. ✪
Drummond Reed: @Justin_R I meant "standards based" authority. Yes, it does of course have access permissions in github. ✪
Joe Andrieu: It's the name squatting that's a problem, if people can grab a name and sit there, that's not good -- write a spec is the minimum bar. ✪
Topic: Review ABNF PR
Joe Andrieu: Dmitri put together a PR addressing a variety of issues, which is not addressing my issue. So let's have him start, and then go to me. ✪
Ganesh Annan: What's the link to the issue and PR? ✪
Dmitri Zagidulin: That PR integrates a bunch of different conversations in issues/PRs/calls - some confusion the relationship between service references, links to services that require intermediate DID resolution and the DID URIs themselves. ✪
Dmitri Zagidulin: The PR clarifies the ABNF rules to define some of the undefined terms, splits the ABNF rules into two sections, one dealing w/ just DID URIs, and another wrt. DID References on top of those URIs... key identifiers, links to service paths and queries and such. ✪
Joe Andrieu: Yes, thank you for putting that PR together, Dmitri ✪
Joe Andrieu: There is the hierarchical part and the rest... maybe we can get away with customizing the hierarchical parts in a traditional URL. ✪
Joe Andrieu: I proposed a strange quirk, no consensus around it - seemed to me that the query part is a good place to put the service ✪
Joe Andrieu: So, move service to query part, would like feedback on that. ✪
Joe Andrieu: If you have a DID w/ a query on that, what are the semantics? What about paths? ✪
Drummond Reed: When I saw the thread, I do understand what JoeAndrieu is getting at... ✪
Drummond Reed: I discussed this w/ Markus, the evolution of the term DID has always corresponded to actual identifier that is "resolved" ✪
Drummond Reed: In order to get the DID Document. From the outset, we used the term DID for that - we wrote the ABNF around that - the DID Identifier... we've never formally come up with the term... for... that identifier by itself is a URI. it is technically a URL, because it can be dereferenced. ✪
Drummond Reed: DID identifier, by itself, is a URL. ✪
Drummond Reed: We've never come up with a formal name, we had something in ABNF, add path/query/fragment - then you have a DID URL... something that is more than just the DID. ✪
Drummond Reed: That's why DID didn't correspond to same thing that URI/URL does. ✪
Drummond Reed: We may want to say DID-URL is something beyond just the identifier. ✪
Drummond Reed: For service IDs, how we select a service, this is the fourth identifier/discovery spec I've worked on - what we discovered in XRD work was that we had the same challenge there, we had a syntax for putting service identifiers in query components, but it was a nightmare to implement. ✪
Drummond Reed: The problem is in order to create URLs that resolve to services, you want to reserve everything after the service -- pass on everything as it is composed. ✪
Drummond Reed: It is much simpler to put service ID selector as component of hier part, before path query or fragment. ✪
Drummond Reed: There are only a few characters you can use to distinguish that component. ✪
Drummond Reed: I'm happy to go deeper, Markus can explain challenges. ✪
Dmitri Zagidulin: Excellent points, want to address a few of those. ✪
Dmitri Zagidulin: Putting service in query is something that was discussed, that's one of the things that has been brought up multiple times - implementation experience that drummond mentioned, goes against various subtleties of URI spec, so, "no" on "let's put it in the query part" ✪
Dmitri Zagidulin: Current PR that is being discussed, uses exact same term... DID URL -- instead, uses DID Service Reference. ✪
Joe Andrieu: Q to ask how does using query as service violates 3986 ✪
Dmitri Zagidulin: Unlike traditional URLs, DIDs, since they are based on distributed ledgers, DHTs, there is no server on the other end to execute a query... that's why it doesn't make sense to semantically have a query to the DID itself. ✪
Dmitri Zagidulin: The only context where paths/queries make sense is in reference to the service inside the DID. ✪
Dave Longley: And they are method independent! :) ✪
Dmitri Zagidulin: That's where the current PR is... that's why we make a sharp distinction between this is a DID and this is a DID Reference. ✪
Jonathan Holt: In the IPID spec, we use IPLD, we have RESTful endpoints behind the scenes, gateway, cloudflare, etc... that dereferences the key attribute, DID method specific identifier to CID ✪
Jonathan Holt: The beauty of that, use slashes to represent path traversal, you could get previous version of DID Document, to get all the way back. We don't use DID fragment, that's coming from HTML protocol, fragment in DOM. ✪
Jonathan Holt: Echo what Dmitri said, some concern - pseudo like URI, but we're carrying over the query language that is focused on HTTP protocol. In some cases we use the hash as a secret share to decrypt the payload. ✪
Michael Herman: This always gets so complicated, reiterate something I said a bit ago - this whole query part, everything that comes after identifier, should be removed to DID Resolution specification. ✪
Michael Herman: I feel like we never are going to get to the end if we keep talking about protocol stuff. ✪
Michael Herman: That being said, drummond and Joe engaged in a discussion around the ABNF - Drummond proposed something... very clean separation between DID and DID string... we've come a long way in separating what the identifier is, we just need to make sure we don't lose that. ✪
Markus Sabadello: The DID is just the idnetifier itself, if we have path/query/fragment, then it's something else... DID Reference, DID URL, or something else. ✪
Markus Sabadello: It helps to be clear on what we're dereferencing. I think the way Dmitri has explained it, when you dereference, the DID reference, then you either get resource in DID Document or to service endpoint. ✪
Drummond Reed: -1 To "removing everything but the main DID identifier from the DID spec". The treatment of how paths, queries, and fragments are resolved is IMHO core to how DIDs can be used. Furthermore, the syntax for that is defined in the "hier-part" of the identifier (from the URI ABNF), so it really needs to be in the DID spec. ✪
Markus Sabadello: Wonder if DID Resolution spec should be called DID Dereferencing spec... don't think ABNF should be in DID Resolution spec, but think Dave has explained it in a convincing way to separate data model and syntax from protocol. ✪
Markus Sabadello: With respect to service name, I don't think that should be in query string, don't know if that's what we're proposing, advantage of doing that, service name would be a resource in the RDF graph, in JSON-LD... so, service name isn't a query, it's an identifier of the resource that represents the service in the DID Document. ✪
Drummond Reed: +1 To identifying the service-id in the "hier-part" so it does not interfere or complicate a path, query, or fragment. ✪
Manu Sporny: Two things, one - having a bit of a problem following the discussion [scribe assist by Dmitri Zagidulin] ✪
Dmitri Zagidulin: … It would help to actually look at the various proposals side by side ✪
Dmitri Zagidulin: … Not that this conversation is not useful, we just need to get on the same page ✪
Dmitri Zagidulin: … Regarding calling something a "DID Reference" vs a "DID URL" — the problem is that the DID string itself is a valid url ✪
Dmitri Zagidulin: … So calling something /else/ a did url (what's being referred to now as a did service reference) might confuse the TAG and others ✪
Kim Hamilton Duffy: If we could discuss at RWoT or have a proposal w/ some ABNF in it, that would be helpful. ✪
Joe Andrieu: I'm trying to understand the service identifier in the "hier" part so it doesn't stomp on the path or query. ✪
Joe Andrieu: Query and path seems to have no meaning ✪
Joe Andrieu: Dmitri said use of query might violate RFC3986, so would like to hear more. ✪
Joe Andrieu: I want to say "this service endpoint is how you reach me", and I'm going to put a DID there... ✪
Joe Andrieu: Or, I say, here's my public key, get it from my DID, and the key will apply to the fragment. ✪
Joe Andrieu: I'm having a hard time understanding the nuances/distinctions, users aren't going to understand that... people will just say "DID starts with did: and that's it" ✪
Christopher Allen: My issue is, looking from developer perspective, I'm the equivalent of a browser or curl or some other network-enabled application. ✪
Drummond Reed: Again, that's another reason in my mind to establish the term "DID URL"—and use that all time to refer to a DID used as a URL. ✪
Christopher Allen: When I ask for a traditional URL today, when I hit the "#" character, everything after that is for the client to process. ✪
Christopher Allen: What I'd like to see in our spec is what the ultimate end client has to do themselves, which to me is after the "#" sign. ✪
Christopher Allen: For example, keys... vs. what the resolver does - resolver doesn't do parsing, right? ✪
Drummond Reed: The DID spec is already very clear about how to handle a DID URL fragment. ✪
Christopher Allen: As for what the resolver -- the resolver may handle the "?" stuff ✪
Christopher Allen: If you are asking for "?" things, you're getting a subset, need to understand distinctions. ✪
Christopher Allen: With BTCR, it's a service that cannot give you the data... Bitcoin core isn't going to give you a DID. ✪
Christopher Allen: There will be other services where you need an intermediary. ✪
Dmitri Zagidulin: Addressing a couple of the points... ✪
Ted Thibodeau: An HTTP/S server doesn't receive anything from the # to the right. (other URI schemes may handle the # differently) ✪
Dmitri Zagidulin: It's important to distinguish the URL of interacting w/ resovler, service reference... what jonnycrunch was describing wrt. resolver, that's important because it'll differ from resolver to resolver. ✪
Ted Thibodeau: The fragment separator ("#") and everything beyond it is strictly client-side, for instance, inside the web browser ✪
Dmitri Zagidulin: The parameters passed in query to resolver, that's one thing - we will talk about it in the DID Resolution spec... but that's outside of DID Resolver spec. One thing is us communicating w/ resolver. Queries, paths, fragments to DID Document itself, not talking about resolver, talking about DIDs... queries/paths don't make sense, fragments do. ✪
Dmitri Zagidulin: Queries, fragments, paths could pass through resolver, through resolved DID, to resolved endpoint. ✪
Drummond Reed: +1. Very nicely stated by Dmitri. ✪
Dmitri Zagidulin: I understand JoeAndrieu would like to unify all of those things into one ABNF, I would argue in the other direction, 3 ABNF rules, two of them in the DID Document, one elsewhere (resolver) ✪
Drummond Reed: I am totally fine with separating the ABNF into three parts as Dmitri suggests. ✪
Markus Sabadello: +1 To what Dmitri said about the meaning of path,query,fragment to 1. the resolution process, and 2. to resolved endpoints. ✪
Drummond Reed: To establish lifecycle, those three stages, ironically hearing things on this call that take more time to explain at Rebooting... what Joe has been calling a DID and meaning by DID is what we call a URL. URIs come in many schemes, HTTP URI, mailto: URI, those are all referred to as URLs. ✪
Drummond Reed: So you put a DID URL in your blog... a DID by itself is a URL ✪
Drummond Reed: When it's a DID plus anything else it's a DID URL ✪
Drummond Reed: Looking forward to spending time in on DIDs in Barcelona. ✪
Dmitri Zagidulin: To manu: I think I can address that ✪
Drummond Reed: @Manu—I think to accommodate that (having paths point inside the DID document), we'd need to establish syntax to support it. ✪
Dmitri Zagidulin: Paths could be used as JSON-pointer into document itself - one of the things that could keep the clean separation, and I expect IPLD, mentions syntax to specify a syntax as a part of the hash fragment. ✪
Drummond Reed: +1 To putting the path in the DID fragment ✪
Drummond Reed: If it points into the DID document ✪
Jonathan Holt: We are working on more robust querying in IPLD, but for now it is limited to "/" ✪
Moses Ma: The level of acronyms has gone way up, we need to be careful when communicating w/ the public. Use common language. ✪
Moses Ma: Maybe use "context free grammar using ABNF" when writing for the public, we're using a lot more jargon these days ✪