W3C home > Mailing lists > Public > public-credentials@w3.org > November 2017

[MINUTES] W3C Credentials CG Call - 2017-11-30 12pm ET

From: <msporny@digitalbazaar.com>
Date: Thu, 30 Nov 2017 15:19:25 -0500
Message-Id: <1512073165653.0.28003@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Manu Sporny for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

https://w3c-ccg.github.io/meetings/2017-11-30/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
Credentials CG Telecon Minutes for 2017-11-30

Agenda:
  https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit
Topics:
  1. DID Hardening Proposal v3
  2. Format Independence
  3. Optional ID Property for the DID
Organizer:
  Drummond Reed
Scribe:
  Manu Sporny
Present:
  Sam Smith, Dave Longley, Chris Webber, Markus Sabadello, 
  Christian Lundkvist, Daniel Buchner, Manu Sporny, Drummond Reed, 
  Nathan George, Kim Hamilton Duffy, Mike Lodder
Audio:
  https://w3c-ccg.github.io/meetings/2017-11-30/audio.ogg

Manu Sporny is scribing.

Topic: DID Hardening Proposal v3

Drummond Reed: DID Spec Hardening Proposal V3: 
  https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit
Drummond Reed:  This is the second of a series of calls on the 
  DID Spec...
Drummond Reed:  Manu and Dave weren't able to be on the call last 
  week - our goal here is to close on the DID spec, this proposal 
  is the next stage of discussion.
Drummond Reed:  Last CG call made it seem like these are 
  competing proposals, but that's not the case, it's just a 
  continuation of the conversation.
Drummond Reed:  We have six items we could get to consensus on 
  with folks that were on the call last time, there are two items 
  that are new-ish don't have consensus
Drummond Reed:  Haven't had much time to move those thigns 
  forward - interested in sync'ing w/ Manu, Dave, and anyone else 
  that hasn't been a part of this yet to talk about first six 
  things.
Manu Sporny:  It's a post-Rebooting version which I actually got 
  PRs in on. Hopefully over the next couple of weeks I'll get that 
  finalized so we can layer this work on top of that. Steady stream 
  of PRs from now on. [scribe assist by Dave Longley]
Drummond Reed:  Let's talk through the issues in order, 
  questions, answers, ideally come to some sort of agreement on it.
Manu Sporny:  Sounds good
Dave Longley:  Good to me.

Topic: Format Independence

Drummond Reed:  This is what we talked about at TPAC - JSON-LD is 
  great but there are people that want other serialization formats 
  as well.
Drummond Reed:  Proposal is that we have a requirement in the 
  spec that a processor can process just the JSON w/o the JSON-LD 
  so that the two formats are compatible. You're already doing this 
  w/ the other specs.
Chris Webber:  We're doing this in ActivityPub, but we need to 
  make sure you can go both ways - plain JSON also needs to be 
  parsed as JSON-LD - it can be expanded into a graph and all terms 
  are defined, new properties in the context... this is not hard to 
  do in general... even w/ apps using naieve JSON tooling. Mastadon 
  is using ActivityPub - they're not using JSON-LD tooling except 
  when they're using LD Signatures, so it's nice because you can 
  uphold both properties at  the same time.
Chris Webber:  I'd like to make sure we hold up what is suggested 
  - any JSON-LD document must be able to be treated by naieve 
  JSON-LD tooling, but also the reverse.
Dave Longley:  Agree completely.
Drummond Reed:  That's what I got from our conversation at W3C 
  TPAC - thoughts from others?
Sam Smith:  What's the overhead of carring around the context? Do 
  you have to include the context every time?
Dave Longley:  The overhead is a single key and value in the JSON 
  document.
Sam Smith:  Ok, so you don't have to download it. So plain JSON 
  is parsed as JSON-LD, don't you have to be able to see the 
  context?
Dave Longley:  Yes, if you are trying to use it as JSON-LD you 
  have to get the context, otherwise, not.
Sam Smith:  Ok, but only if you're JSON-LD.
Drummond Reed:  Ok, so if you are doing JSON-LD parsing, do you 
  need to fetch the context and validate the JSON-LD document? 
Dave Longley:  The only time you need to get the context is when 
  you're transforming, normalizing, etc. If you're not doing that, 
  you don't need to do that.
Chris Webber:  What's nice is that method implementers can make 
  it readable by plain JSON and parseable by JSON-LD, method 
  implementers need to be careful, but you can degrade from 
  there... use JSON native tooling... that's fine, or if you pull 
  in as JSON-LD.
Markus Sabadello:  What about JWS as signatures? Wouldn't you 
  just use LD Signatures in all cases?
Dave Longley:  That's an open question, don't know who wants to 
  use JWS?
Christian Lundkvist:  We're using JWS now - for attestations.
Christian Lundkvist:  We did some discussion that it's unclear if 
  the DID Document itself needs to be signed as it is fetched out 
  of the resolver, or if it's enough that a signature is present 
  out of band but validated in the resolver itself, and then 
  returned in whatever data format is supported.
Dave Longley:  I have a couple of comments - whether or not a 
  signature is present is up to a combination of the DID Method, 
  the resolver, and the application that's using it.
Dave Longley:  LD Signatures has a signature suite that is 
  compatible with JWS... you still need to canonicalize.
Sam Smith:  We can't enforce canonicalization in JSON.
Sam Smith:  Any time you have a JSON document that embeds a 
  signature and you reserialize - JSON doesn't have a canonical 
  serialization, you'd have to include the part of the document 
  signed in base 64
Dave Longley:  The canonicalization algorithm used is on the 
  JSON-LD data - whatever whitespace, as long as data semantics 
  change, you can use JSON-LD to conver to RDF.
Manu Sporny:  Let me jump in really quickly. There's going to be 
  a very severe mismatch between what Sam is saying and what we're 
  saying because we don't have a history. [scribe assist by Dave 
  Longley]
Manu Sporny:  We know about all of the shortcomings of the JOSE 
  stack and the normalization issues. And many of those things are 
  what led us to create the Linked Data stuff. We have 8-9+ year 
  history working with this canonicalization, etc. Our comments 
  aren't coming from a naive standpoint. I agree with what you're 
  saying Sam about there being no JSON canonical form. [scribe 
  assist by Dave Longley]
Manu Sporny:  When you sign with JOSE you do base64 encode it. We 
  understand that. We know about that issue. So this concept of 
  mixing JSON and JWS and the DID documents... I'm concerned about 
  it. [scribe assist by Dave Longley]
Manu Sporny:  But that's kind of somebody else's problem. Our 
  ledger picks JSON-LD and Linked Data Signatures for a variety of 
  reasons because we think the end result is simpler than using 
  plain JSON + JWS JOSE stack, etc. If someone else wants to use 
  JSON and JWS stack etc, they have to figure that out. [scribe 
  assist by Dave Longley]
Sam Smith:  I heard we should just stick with LDS and that's all 
  that's supported. [scribe assist by Dave Longley]
Manu Sporny:  No, not saying that. This work started out with 
  JOSE and we hit brick walls, we switched to LDS. We've been 
  there. [scribe assist by Dave Longley]
Sam Smith:  I don't say JOSE is the answer either. Having a 
  base64 field that is signed is something that will work in 
  general as opposed to requiring the full JOSE stack to manage 
  everything. [scribe assist by Dave Longley]
Sam Smith:  One of the problems with JOSE is that you can specify 
  all the signatures with all the parameters, there are security 
  holes. [scribe assist by Dave Longley]
Sam Smith:  It might be a strawman to say there are only LDS and 
  JOSE as choices. [scribe assist by Dave Longley]
Manu Sporny:  We're not saying that. We're saying we have a 
  fairly good understanding of the shortcoming of JOSE JWS and you 
  can do it that way if you want, that's allowable. If you want to 
  use LDS you can do that. [scribe assist by Dave Longley]
Sam Smith:  We went from we want to have DID docs to both using 
  JSON tooling and JSON-LD tooling and then you need JSON-LD 
  tooling for the signature. [scribe assist by Dave Longley]
Manu Sporny:  Yeah, I agree. We have to be careful though for 
  every new thing we add here. There's a tremendous amount of 
  complexity for each of these things, particularly for security 
  audits. [scribe assist by Dave Longley]
Sam Smith:  The standard protocol practice is to attach the 
  signature after the serialization. Whereas in LDS you are 
  embedding the signature in the Linked Data, requires 
  canonicalization. You can't build a LD master schema where the 
  signatures are part of your schema. [scribe assist by Dave 
  Longley]
Chris Webber:  I've been working w/ Mastadon... seeing how they 
  use naive JSOn tooling
Chris Webber:  If you end up base64 encoding and signing, you 
  can't embed.
Sam Smith:  You can, but you can embed and base64 and embed.
Sam Smith:  You don't have a bare document that's exploded and 
  exposed and canonicalized/re-sign...
Chris Webber:  Even in their case, they use naieve tooling, but 
  they do use LD signatures stuff... dev that uses it doesn't know 
  about LD signatures - but does use the libraries. Even though 
  you're using LD tooling, you can have a naieve tooling mindset.
Sam Smith:  Except that if the Linked Data tooling is doing 
  lookups, in a data intensive app - that's expensive.
Dave Longley:  You can cache data, that's not an issue in 
  production, you don't do lookups in that case. I don't think 
  anyone is saying use ONLY LD Signatures.
Dave Longley:  We say "here are the specs on how to do X" -- we 
  point folks at that.
Sam Smith:  I think that's a great thing - we may want to make it 
  easy for people to migrate from standard JSON format to LD 
  format.
Dave Longley:  I think Chris' perspective is - it's just another 
  version of JWS and a magic signature gets attached to your 
  document, you made a call, a signature appeared, that's another 
  way to look at LD Signatures - you don't need to bring in the 
  mental model of signatures.
Nathan George:  Yes, you get this JSON data and you use whatever 
  library to deal w/ the signatures... as different tech and 
  signatures evolve, we want the central data model to keep 
  working.
Dave Longley: S/signatures./linked data./
Drummond Reed:  This keeps coming up - Jason Law said signatures 
  are optional... data integrity - ties in w/ point #2, if you 
  don't validate DID Document against target ledger, you're raising 
  other security issues.
Drummond Reed:  You don't always have the DID when you register 
  the DID Document... one possible approach here is to simplify DID 
  spec to say signatures are covered in another document.
Manu Sporny:  I wanted to go back to the format independence 
  question. If someone wants to do JSON and JWS/JWT that's fine. 
  But someone is going to have to write and maintain those sets of 
  specifications. Who is volunteering to do that? That's the first 
  question. If we want that serialization to get through the W3C 
  standardization process then at least two ledgers will need to 
  implement that to get it through W3C rec process. [scribe assist 
  by Dave Longley]
Manu Sporny:  I'd like to know who is going to be doing JSON+JWS 
  (non-LDS version). [scribe assist by Dave Longley]
Markus Sabadello:  Two code bases or two ledgers? [scribe assist 
  by Dave Longley]
Manu Sporny:  That's an interesting question. Not sure. [scribe 
  assist by Dave Longley]
Markus Sabadello:  What if there are two resolvers? One in Java 
  and one in another language? [scribe assist by Dave Longley]
Dave Longley:  This is getting to my point about the purpose of 
  DID documents and proving interop, etc. [scribe assist by Dave 
  Longley]
Manu Sporny:  I didn't hear anyone pipe up and say they will use 
  JWS. [scribe assist by Dave Longley]
Manu Sporny:  Christian? [scribe assist by Dave Longley]
Christian Lundkvist:  Probably? We are currently using plain JSON 
  and JWS for most of our stuff. [scribe assist by Dave Longley]
Drummond Reed:  Is there is a deeper question to ask... what 
  methods represented on the call plan to produce signed DID 
  documents vs. unsigned? [scribe assist by Dave Longley]
Manu Sporny:  I'd phrase it differently, at some point there has 
  to be some kind of cryptographic proof. The other concern that we 
  have ... let me jump back. We could assert that there is no 
  signature on a DID document, or say it's optional I mean, and 
  that's fine across every DID method we're looking at. [scribe 
  assist by Dave Longley]
Manu Sporny:  I think that's totally fine. Even in the Veres One 
  ledger the signature is not on the DID document itself it's on an 
  event that comes into the ledger. [scribe assist by Dave Longley]
Manu Sporny:  When you fetch the DID document there's a wrapping 
  signature there. [scribe assist by Dave Longley]
Manu Sporny:  The whole argument around JWS is moot and then we 
  could potentially stop talking about it. [scribe assist by Dave 
  Longley]
Manu Sporny:  The more options we give people the more things 
  others will have to do... if people want JSON, JSON-LD, JWS, LDS, 
  methodX, methodY, and so on -- you're pulling in more libraries. 
  [scribe assist by Dave Longley]
Manu Sporny:  The people pushing JSON-LD and LDS have a strong 
  reason for doing so. Is the JSON and JWS stuff really buying 
  people much? Saying things are optional and so on leads to extra 
  security and operational costs. [scribe assist by Dave Longley]
Drummond Reed:  Ok, with each of these, will try to see if we 
  have consensus
Drummond Reed:  There are hypothesis I'm going to ask about.
Drummond Reed:  It sounds like there is agreement that spec can 
  say format is JSON-LD, but can be used as naive JSON.
Drummond Reed:  Second thing, signatures in DID docs are 
  optional.
Drummond Reed:  Each DID Method could specify whether signatures 
  are valid - or DID Spec can say you can attach signatures to 
  document.
Drummond Reed:  Folks at table willing to specify, here is how 
  you do JWS signature, they can do that, and we're done.
Dave Longley:  I'm going to try to rewind - signatures being 
  optional - general concern that there might be some confusion 
  over purpose of a DID Document and determining what the data 
  model will look like, what serialization will look like - create 
  a common format for what is returned by resolver. 
Dave Longley:  You improve interop by having resolvers return 
  same DID docs - I'm thinking of this in terms of apps that want 
  to use DIDs, regardless of what method is being used by those 
  DIDs... when we talk about signatures - DID Document that's 
  returned, authenticity is checked by resolver, or trust resolver 
  in some way.
Dave Longley:  "The purpose of a DID document is to return a 
  standard set of metadata associated with a DID". [scribe assist 
  by Drummond Reed]
Dave Longley:  There are trade-offs in these cases - common 
  tooling, resolver can potentially be a lot simpler.
Drummond Reed: To remember what I want to say when the queue gets 
  to me: should we look at DID resolution as a two-step process.
Sam Smith: The simplest common protocol for http is to add a 
  Signature header
Drummond Reed: Also, to talk about Dave's point about a common 
  purpose of DIDs and DID docs.
Dave Longley:  That does depend on some common method for 
  retrieving things from these ledgers. That's going to cause 
  resolvers to become heavyweight... build apps that have embedded 
  resolvers, that work across multiple DID methods - it's important 
  for us to figure out if there is a common protocol to retrieve 
  things from a variety of ledgers... how do we create resolvers 
  that can pull from different ledgers, we want interop between 
  different DID Methods... there may be apps that do care about 
  that, but for apps that don't, we want to support that.
Sam Smith: The signature header signs the body of the response
Dave Longley:  It's important to understand consequences 
Nathan George:  This gets to the same point that Dave made... 
  where we get into trouble w/ variation of signature scheme, not 
  tight binding to identifier, data model... we get around this in 
  DID spec by making so many things optional.
Nathan George:  We can push much of this into method spec... but 
  where we talk about Verifiable Credentials - data model / 
  signature block interact - this is going to be an ongoing issue 
  as we try to deal w/ context where we don't depend on LD data 
  model... signature scheme may not be able to depend on context
Nathan George:  We can resolve on the DID spec, but on VC spec, 
  it'll become a real issue.
Kim Hamilton Duffy: https://w3c-dvcg.github.io/lds-rsa2017/
Kim Hamilton Duffy:  For those that want to use JWS, you could 
  use  https://w3c-dvcg.github.io/lds-rsa2017/
Kim Hamilton Duffy: https://tools.ietf.org/html/rfc7797
Kim Hamilton Duffy:  The intent was to help address these 
  scenarios - is this suitable for those that want to use JWS?
Dave Longley: We plan on using it
Drummond Reed:  Core purpose of DIDs and DID Documents and DID 
  Methods... I don't think there is debate about this, but we 
  should focus.
Drummond Reed:  I'm going to put a hypothesis out there... react 
  to it.
Drummond Reed:  Agree w/ Dave Longley - you need to get back a 
  standard set of metadata
Drummond Reed:  Common data that you want - associated set of 
  keys, associated service endpoints.
Sam Smith: @Kimhd  the linked document does not seem to describe 
  and attached signature block?
Drummond Reed:  A way to associate them when necessary
Drummond Reed:  That's the one thing that DID Docs need to do... 
  very basic layer for many things we don't anticipate.
Drummond Reed:  I see a pattern here - start to think of 
  resolution as a two step process - client to resolver and 
  resolver to method.
Drummond Reed:  Metadata that client needs back and verifiacation 
  that client needs - resolver is not technically required.
Drummond Reed:  Resolver needs to implement method to talk to 
  target system... then perform whatever verification is necessary 
  - that's where DID checking comes in... that becomes  much easier 
  to focus on core metadata... instead of focusing on core 
  verification.
Chris Webber:  I agree with Drummond, for good reason, a lot of 
  us are focused on the low level... but hopefully we're handing 
  this off to developers.
Chris Webber:  Their big question is "I'm not going to download a 
  full node", we're probably going to end up more DNS like - 
  resolvers that people connect to... how do you trust just one 
  resolver?
Kim Hamilton Duffy: @SamSmith sorry I forgot. This paper is the 
  one with details: 
  https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017/blob/master/final-documents/ld-signatures.pdf
Chris Webber:  Maybe we should have some general protocol to run 
  over HTTP - so common - implementers are not going to be 
  interested in running that... maybe best path is to make sure 
  there really are the economics are returning a DID Document are 
  such that people will want to run resolvers.
Dave Longley: +1, It isn't going to happen.
Chris Webber:  We can't expect most people to download full 
  chains.
Dave Longley: Downloading full nodes.
Christian Lundkvist:  Most of the DID Methods that we are 
  discussing probably don't even need the signature on the DID 
  Document - a lot of the discussion is moot - however, the 
  discussion might be shifted to talk more about Verifiable Claims, 
  which is not the purpose of this discussion, but there is a 
  question of whether or not Verifiable Credentials is a JSON-LD 
  document.
Dave Longley: There's a W3C working group for that :)
Christian Lundkvist:  I'm not sure if DID Resolver needs to spit 
  out a DID Document w/ a signature on it - the onus on verifying 
  that there is a cryptographically strong link between DID and DID 
  Document falls on the resolver.
Dave Longley: If it falls on the resolver then we're going to 
  need to have another piece (a "client" for the resolver) that 
  actual applications use, they will not be running full nodes, 
  etc.
Drummond Reed: What Christian is saying is what I was trying to 
  say, which is that the resolver can implement the verification 
  step, and that can be method specific, and then return a "plain" 
  DID document.
Markus Sabadello:  Some comments on lightweight and heavyweight - 
  Drummond said something about two-phase or two-part resolution 
  architecture... logic that you need is lightweight, you could run 
  it on a local machine... sometimes you need a full node (more 
  heavyweight)
Markus Sabadello:  BTCR DID, you can resolve it in 3 different 
  ways... 
Dave Longley: If "sometimes" you want a full node -- either 
  people won't use them or we need another piece in the 
  architecture to make those DID methods more tenable.
Markus Sabadello:  Some ledgers return a DID Document itself - 
  Veres One is very lightweight, for example... but you can't do 
  that w/ other methods that are more heavyweight.
Markus Sabadello:  There will be different setups/configs - not 
  much value in having signature in DID Doocument itself, how do 
  you setup the components, how close is resolver to source of 
  truth, how do you trust resolver -- those questions are 
  important.
Manu Sporny:  The conversation we're having is good but 
  meandering a bit. I want to close out the format independence 
  thing with a specific proposal. I think we all agree that we want 
  format independence. There's an abstract data model, services, 
  keys and identifiers as concepts in there. [scribe assist by Dave 
  Longley]
Manu Sporny:  JSON/JSON-LD may be used there as a format for it. 
  [scribe assist by Dave Longley]
Manu Sporny:  It sounds like signatures are optional. Does that 
  close out option 1? [scribe assist by Dave Longley]
Drummond Reed:  I think there's a third thing. Will we in the DID 
  spec still specify standard signatures that we can recommend? 
  [scribe assist by Dave Longley]
Drummond Reed:  That methods can refer to. [scribe assist by Dave 
  Longley]
Manu Sporny:  When it comes to W3C and how it does stuff like 
  that, you tend to give some examples. You split into core data 
  model where you say "here's how you express the data model as 
  JSON/JSON-LD in examples" and you leave other serializations to 
  external specs. You don't prevent other serializations from 
  happening. That's perfectly reasonable, some people go more 
  academic than that and say you should just talk about the data 
  model full stop. Go to other specs [scribe assist by Dave 
  Longley]
Dave Longley: For that.
Manu Sporny:  To shortcut the conversation for this let's just 
  put JSON and JSON-LD into the spec. [scribe assist by Dave 
  Longley]
Manu Sporny:  If someone wants something else we can reopen. 
  [scribe assist by Dave Longley]
Drummond Reed:  I think there's broad support. Anyone on the call 
  disagree with that approach? [scribe assist by Dave Longley]
Dave Longley: None
Drummond Reed:  I think we're there. [scribe assist by Dave 
  Longley]
Dave Longley:  Regarding resolvers - Markus said that some 
  resolvers might need full node, others you'll only need 
  lightweight... DID Methods that require full method in resolver 
  will only be used by mechanisms that ... don't want that to 
  happen, don't want full nodes to be left out where DID is... they 
  just want to use DIDs... run lightweight resolver for anything... 
Dave Longley:  Get the DID Document, do something with it.
Chris Webber: Or incentivize them to do so
Dave Longley:  We need another layer in the architecture here - 
  we need a protocol -- we might want to push more complex stuff 
  into ledger nodes... embed lightweight clients/resolvers... 
Chris Webber: If you got paid something like filecoin to provide 
  DIDs
Chris Webber: There may be motivation to provide all these DIDs
Christian Lundkvist: Strongly disagree about putting DID 
  resolution in blockchain nodes
Dave Longley:  For example, if all DID Methods  -- lightweight 
  protocol on HTTP... applications want to use any data across DID 
  method, implement HTTP GET - don't want to reopen #1, but a piece 
  of that might be that resolvers then place signatures on DID 
  Document that come back and that's part of authenticatoin method, 
  trust resolver, trust authentication that came back - sigs appear 
  on DID Docs as they come back from resolvers... run a full node 
  for this - people aren't going to do that for lots of apps.
Markus Sabadello: Agree with dlongley that resolvers can be run 
  as a cloud service
Drummond Reed: Resolvers adding signatures? From the resolver 
  itself?
Dave Longley:  To accept users ... we want interop - we're 
  missing critical peice of architecture, push stuff into ledgers 
  or resolvers are services.
Chris Webber: But +1 we need a way that people can use resolvers, 
  and we need a way to have general-cross-interoperability
Mike Lodder: Then we need to be able to verify the resolver 
  results
Dave Longley:  We want to push complexity to DID Methods, not 
  resolvers.
Drummond Reed:  For two steps - client / app talking to resolver 
  - lightweight protocol there - Markus made the point, multiple 
  configurations - because of the crypto involved, where the 
  verification takes place - DID Spec, defines conformance targets.
Drummond Reed:  Say "here are the different configurations"
Drummond Reed:  Can work w/ Markus - you cover those so you are 
  defining ways to resolve a DID, and refer to conformance 
  targets... if you talk to resolver, that's how X is done, if 
  you're adding signature, that's how Y is done - I don't think 
  anyone is saying we should do it all at ledger/client ... all 3 
  are possibilities.
Drummond Reed:  We can put that back out as topic - define 
  different configs - conformance targets for implementers of spec 
  and we need to do it in the spec. DID Docs / Methods and 
  resolution - tackle that in context of definitions.
Christian Lundkvist:  What do you mean by that?
Christian Lundkvist:  If you have DID Method, it's only valid if 
  you run a full node?
Dave Longley: Perhaps we want a DID resolution spec instead -- 
  where DID methods would define a mapping to a common protocol
Dave Longley: And not mention this in the DID spec (other than to 
  say "look over here for interoperable DID resolution")
Mike Lodder: This distinction seems more important to a library 
  implementation, rather than the method spec itself
Drummond Reed:  Resolvers that have different capabilities - 
  client, DID Method can talk directly to target system - resolver, 
  resolver is local... resolver is in cloud... resolver in cloud 
  but light client - all of these configurations - there is a 
  standard set of options.
Dave Longley: We're going to end up creating a centralized point 
  of failure if we do that -- markus.
Dave Longley: Everyone is going to want to use a monolithic 
  resolution service
Drummond Reed:  The reason we need to define those config options 
  is so a DID Method spec - for pattern A, this is how you do that, 
  for pattern B, this is how you do it - method spec don't have to 
  recreate wheel.
Drummond Reed:  We did a simpler version of this for XRDS
Markus Sabadello:  I think we can define common interface for 
  talking to resolver 
Dave Longley:  I want us to be aware of making resolution too 
  heavyweight - we might create a single point of failure... might 
  recreate a problem. Don't want us to get totally derailed.
Manu Sporny:  I originally put myself on the queue to say exactly 
  that. DID resolution sounds like a full on sprint and we need to 
  walk and maybe run. [scribe assist by Dave Longley]
Manu Sporny:  If we could have the rest of the folks in the group 
  pull us back to the items we're talking about -- because 
  meandering conversations don't help on spec text. [scribe assist 
  by Dave Longley]

Topic: Optional ID Property for the DID

Drummond Reed: +1 To making sure to focus on the spec using 
  cloud-based resolvers does not reintroduce centralization.
Manu Sporny:  Yes, I disagree with having the ID be optional. 
  Playing off a number of things I heard on the call today. One of 
  the purposes of the DID document is to provide a common piece of 
  data an application can use regardless of the DID method that's 
  behind it. The closer the DID docs look between multiple systems, 
  the easier it is for the ecosystem to use them. [scribe assist by 
  Dave Longley]
Drummond Reed: Ah-ha! Light bulb. If we specify a two-step 
  resolution process, then the DID doc CAN require the DID.
Manu Sporny:  Let's make it look almost identical, that's a 
  design goal even if we can't fully actualize it. [scribe assist 
  by Dave Longley]
Manu Sporny:  Making it optional is because there's an "emergent" 
  value that is the ID. [scribe assist by Dave Longley]
Manu Sporny:  I'm thinking about BTC-R there's this initial 
  bootstrapping process and you don't know the ID until it's 
  created after the fact. But would you ever have an application 
  ask a resolver for something ... it has an ID it's asking for. 
  [scribe assist by Dave Longley]
Manu Sporny:  So you would expect the DID doc to have the ID in 
  it when it resolves. [scribe assist by Dave Longley]
Manu Sporny:  I can't think of any DID method where it's 
  optional. [scribe assist by Dave Longley]
Daniel Buchner:  Composition of merkle root hash and [missed 
  details while listening] [scribe assist by Dave Longley]
Manu Sporny:  But you can add the ID later. [scribe assist by 
  Dave Longley]
Daniel Buchner:  But the payload may be signed. [scribe assist by 
  Dave Longley]
Dave Longley: (And adding the ID could affect the validity)
Dave Longley: Cwebber2: It's completely reasonable that you could 
  have an emergent document so you can't have ID when you generate 
  it, but you can always tack on the ID when you hand it over to 
  the user. Even if there was no way to have the ID until you do 
  all the generation.
Drummond Reed: I agree with Manu's point that the resolver will 
  ALWAYS have the DID, regardless of whether it is emergent. This 
  is why a two-step resolution process makes sense.
Dave Longley: ?: If you're trying to validate this, maybe or 
  maybe not, but if you're trying to ensure that hashes match up -- 
  removing the ID to check things would have to be known to the 
  client.
Dave Longley: Cwebber2: I don't see any reason why that wouldn't 
  be possible [to include those instructions to remove the ID 
  before doing validity checks].
Dave Longley: Yes, we need to think about this in terms of 
  resolution more than in terms of DID methods!
Dave Longley: That's where the interop is.
Drummond Reed:  This further enforces concept of two-step 
  resolution process - you don't have to stick in another 
  component, two step can be implemented directly by a client... 
  two steps are separating execution of method, and whatever is 
  returned.
Drummond Reed:  Here's a common metadata that needs to be 
  returned, here's what needs to be returned by target system - I 
  think we can all agree on that - DIDs are emergent property, 
  Sam's got use cases aroudn that - that's cool, that can happen in 
  step 1... but step 2 is where the DID Method thing comes in.
Drummond Reed:  Getting back to point - app can make its own 
  security decisions on what resolver it trusts for what 
  verification... or needs to talk to full node, or resolver - 
  resolver code is in me - I'll trust it...
Dave Longley:  Completely agree with that - We don't care what 
  DID Methods do, but DID DOcuments are what pops out and that's 
  what we're trying to standardize.
Dave Longley:  These are the checks I did, there are a variety of 
  thigns we can do that - what's going on w/ DID Methods, etc. We 
  care about same DID Document pops out on other side - includes 
  whatever information is necessary.
Drummond Reed:  Resolver could add signature? You said that 
  earlier.
Dave Longley:  It could be, there might be a variety of ways to 
  do that.
Drummond Reed:  Some might have thought of signature on DID 
  Document coming from resolver, some from ledger... we want 
  everything to create similar documents.
Sam Smith:  One of the suggestions was that there be an ID field 
  that has the DID, but the DID might not be the actual DID, but 
  the type or algorithm to generate the DID.
Sam Smith:  I'm fine w/ supporting the concept that we're talking 
  about final document that's resolved, not some interim version.
Dave Longley: The "mapping" from however things are stored by a 
  particular DID method to how you get to the "resolved" DID 
  document is up to the method... but it does need to say it
Drummond Reed:  What is the best way to continue discussion of 
  next 3 items?
Sam Smith:  How do we update the hardening proposal?
Drummond Reed:  Add change suggestions to docs, try not to use 
  only comments.
Dave Longley:  Use the suggest feature, easier to find stuff.
Received on Thursday, 30 November 2017 20:19:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:42 UTC