The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

DID Task Force

Minutes for 2018-02-15

  1. DID Service URLs
  2. Other DID Spec Items
Drummond Reed
Susan Bradford, Chris Webber
Drummond Reed, Susan Bradford, Manu Sporny, Dave Longley, Sam Smith, Christian Lundkvist, Christopher Allen, Chris Webber, John Best, Nathan George, Mike Lodder
Audio Log
Drummond Reed: Links for today: DID spec -
Susan Bradford is scribing.
Drummond Reed: DID Spec Issues:

Topic: DID Service URLs

Christopher Allen: Service address stuff. What is the scope of how much we will be standardizing? What is the minimal verifiable claim Repository service?
Drummond Reed: The proposals still need to be added to the spec. Action item for drummond.
Proposal to solve: how do you go from did service url to a target url.
Manu Sporny: We should not assume everything after the semicolon is a service description.
Manu Sporny: The other question - how will we pass perimeter services? Why don't we make that the general mechanism. The thing after the separator we should make more ostensible than just services.
Sam Smith: Service end point. shouldnt it just be end point?
Manu Sporny: There was a specific reason for that.
Christopher Allen: Why isnt this handled by the method spec? ALlow a resolver to handle some of this.
Drummond Reed: Purpose of service names is to solve this problem. if you want to build a service url, there needs to be a general standard to turn the did service url to a target url.
Chris Webber: There's more to services than just returning URLs
Manu Sporny: Yes, the resolver doesn't touch this most of the time
Chris Webber: More information that's available
Manu Sporny: Other apps will need this as well
Chris Webber: This also *has to be* one of the things that all of the methods need to agree on
Chris Webber: All applications should be able to understand this and not care how the guts of the method works
Chris Webber: I have lots of opinions on this :)
Christopher Allen: F is this actually something that is returned by the did resolver to the app?
Chris Webber: Note
Chris Webber: That I originally wrote up the version of this
Chris Webber: And I put a colon
Chris Webber: And someone switched it to a semicolon
Chris Webber: I'm not sure why still
Drummond Reed: Limited by the character set. we can revisit the semicolon
Drummond Reed: This is method independent.
Chris Webber: Can't use colon.. we use colons all over the place in Veres One as other forms of delimiters [scribe assist by Manu Sporny]
Chris Webber: I'm not opposed to it but I still don't understand why a colon wouldn't be used since we're using a colon for the others
Manu Sporny: Ah ok [scribe assist by Chris Webber]
Manu Sporny: Short answer it id not did method specific. the services we are hoping for are a common mechanism across all methods.
Manu Sporny: Responding to Sam asked about service vs end point. concern if people mix vocab into methods (name, description, end point, etc) as a result there is a chance if we just end point it will get clobbered
Manu Sporny: Developers can always change it in their method using JSONLD mapping
Manu Sporny: Pending action item: we should claim all of the terms in
Chris Webber: Comment on resolvers will do the work of transforming this into the url.
Dave Longley: New option submitted. Would like to see other use cases for transforming the url.
Christopher Allen: Can you add in those use cases here please?
Manu Sporny: We don't say what the did-path does.
Drummond Reed: Happy to go in and fix that stuff. Its all standard URI.
Manu Sporny: Concern that what we are agreeing to will paint us into a corner. We need to give folks more time.
Christopher Allen: Need definition of minimal viable service for this.
Manu Sporny: What happens when you just want to select from a set of things. Its not a 1 to 1 mapping. Its not a service look up.
Chris Webber is scribing.
Drummond Reed: This solves the problem by putting the service in the authority component
Drummond Reed: I've never seen a use case for this where you need to do anything else
Drummond Reed: What you're doing in discovery is going from abstract discovery to...
Drummond Reed: Those mechanisms for selecting that would use a fragment on the did document itself, or a query on the did document itself
Drummond Reed: Nothing prevents us from doing that
Christopher Allen: Let me suggest we take this, puzzle through when you have multiple paths
Christopher Allen: A service can be accessed through http/tor/etc
Christopher Allen: They're equally valid but you want to prioritize one
Drummond Reed: I don't think i understand, this is a url translation mechanism
Christopher Allen: This is you're trying to move from something you understand to something you don't
Christopher Allen: IPFS can go through a variety of mechanisms, ignoring http
Christopher Allen: If I want to go through a number of centralized services that convert IPFS to HTTP, so I can use an http url, but that's lossy on decentralization compared to ipfs://
Drummond Reed: I understand, you've got multiple services you want the same url to map to
Drummond Reed: I've seen that before, I'll say you can write custom code to do that
Drummond Reed: If we complicate that about the simplified use case... doesn't preclude that you can do the simple standard way
Christopher Allen: But then you're in the category of service type is an http service
Drummond Reed: Which you could absolutely write the code for
Christopher Allen: I'm maybe saying if you can spend a bit of time puzzling through resolving to two different things that give the same result in the end, maybe there's an easy way to do it, maybe it's just having serviceType through IPFS, something, a priority tag... but if you spend a bit of time puzzling through then tell me you can't do it, then I'll feel bettter
Drummond Reed: We'll take it a look before, it's come up before, we'll see what we can come up with
Chris Webber: Christopher gave a better example than I was going to, but it may be not incompatible syntax wise to reserve the `=` char and the `&` char... and if you don't specify a parameter it defaults to "service". [scribe assist by Dave Longley]
Chris Webber: Similar to how languages have default parameters map in certain ways. I don't know this would make things better or making our lives harder with more options. [scribe assist by Dave Longley]
Drummond Reed: Good suggestion, I'm the last one to argue against extensibility
Manu Sporny: Why can't we just do did:example?resolve=serviceName/foo/bar/baz#frag-1
Drummond Reed: I do like that point, and the particular point of keep the simple case simple
Drummond Reed: Next peron on the queu is... sam
Chris Webber: Manu, maybe if there's no path it could be confused with the query parameter?
Sam Smith: I like to keep the simple simple, but maybe simple service is an array, it's a namespaced aprameter, have a whole cap of semicolons
Sam Smith: I'm not sure people commenting realize the syntax allows you to do that
Sam Smith: I agree strongly that the 90% usecase will be a single service
Sam Smith: Every time you do an = it makes things verbose, and there's a cost to verbosity
Sam Smith: Especially when refering to identifier has a cost
Drummond Reed: "Minification" <== love it
Drummond Reed: I'm opening to the idea of reserving = so that we can add parameterization later
Drummond Reed: Since manu wasn't here last week, I wanted to cover these other 2 things

Topic: Other DID Spec Items

Drummond Reed: We had query components, wanted to add things back in
Manu Sporny: Not sure if your suggestion is to just use the query... but you'd have to encode the '/'s i think (if it was in the query) [scribe assist by Dave Longley]
Manu Sporny: Why not follow a standard url component, you'd have to escape the slash, but anyway... you can't do ors I don't think
Manu Sporny: I feel uneasy about it
Manu Sporny: Maybe if we have an issue and have further discussion there
Manu Sporny: Query component, that's great
Manu Sporny: I don't think the query part is controvercial... that could probably go in a PR
Manu Sporny: Also Markus has done a PR, he added a publicKey and authn section to spec (?)
Manu Sporny: Look at those PRs
Drummond Reed: Completely agree, and goal was to turn all three into PRs
Drummond Reed: Let me just say we did stop on the json pointer thing, folks on last week's call understood the case but dave understood the case on it
Dave Longley: I haven't had time to think further
Chris Webber: Little Bobby Tables reference:
Chris Webber: I'm nervous that xpath style things like json pointers can be brittle and can lead to people having little bobby table type problems
Manu Sporny: We haven't had a lot of agreement about ways to fetch things, especially because there are at least 3 valid ways we haven't agreed on
Manu Sporny: We can say that if you're in json-only mode you can apply json pointter as is, in json-ld you can frame it... we can explore and if patterns emerge we can put it in
Manu Sporny: That's the same issue we've had in json-ld and we haven't gotten consensus there, I think if we do the same thing we'll have that problem with path based resolution here too
Sam Smith: I think if notthing prevents it a should as opposed to a MUST is fine
Sam Smith: It's an important use case to access metadata
Chris Webber: I'm really worried about putting this as a SHOULD -- it may not be obvious , non obvious risks. [scribe assist by Manu Sporny]
Drummond Reed: We're at the end of our hour, good discussion, I'd like to go through the process
Drummond Reed: Just to take a sec to discuss between now and then: RWoT, discuss having a DID day there
Drummond Reed: I think our goal betwen now and then is to work on as many issues as we can, so we can have a stable of a spec with as few issues as possible
Drummond Reed: Everyone on board?
Drummond Reed: In that case, let me just ask, do people want to have additional calls on thursday?
Drummond Reed: I'd suggest hour long calls and look at issues
Drummond Reed: Let's get into issues and work on the spec
Drummond Reed: Anything else?