- From: <msporny@digitalbazaar.com>
- Date: Fri, 16 Feb 2018 14:44:44 -0500
- To: Credentials CG <public-credentials@w3.org>
Thanks to Susan Bradford and Chris Webber for scribing this week! The minutes for this week's Credentials CG telecon are now available: https://w3c-ccg.github.io/meetings/2018-02-15/ Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- DID Task Force Minutes for 2018-02-15 Agenda: https://lists.w3.org/Archives/Public/public-credentials/2018Feb/0030.html Topics: 1. DID Service URLs 2. Other DID Spec Items Organizer: Drummond Reed Scribe: Susan Bradford and Chris Webber Present: Drummond Reed, Susan Bradford, Manu Sporny, Dave Longley, Sam Smith, Christian Lundkvist, Christopher Allen, Chris Webber, John Best, Nathan George, Mike Lodder Audio: https://w3c-ccg.github.io/meetings/2018-02-15/audio.ogg Drummond Reed: Links for today: DID spec - https://w3c-ccg.github.io/did-spec/ Susan Bradford is scribing. Drummond Reed: DID Spec Issues: https://github.com/w3c-ccg/did-spec/issues/ Drummond Reed: DID Spec Completion Proposals: https://docs.google.com/document/d/1aR8V_JUJdq1Sbi47wCV5aa-dEY0e-V2RqwPNP5ci1bg/edit#heading=h.21shj40jfml 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 schema.org 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: https://www.xkcd.com/327/ 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?
Received on Friday, 16 February 2018 19:45:08 UTC