[MINUTES] W3C Credentials CG Call - 2018-02-15 12pm ET

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