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

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

From: <msporny@digitalbazaar.com>
Date: Thu, 07 Dec 2017 15:05:09 -0500
Message-Id: <1512677109042.0.24640@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Susan Bradford for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

https://w3c-ccg.github.io/meetings/2017-12-07/

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-12-07

Agenda:
  https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit
Topics:
  1. Intellectual Property Release
  2. Two Stages of DID Document
  3. Simple Arrays of Key Descriptions
Organizer:
  Drummond Reed
Scribe:
  Susan Bradford
Present:
  Kim Hamilton Duffy, Susan Bradford, Drummond Reed, Sam Smith, 
  Brent Zundel, David I. Lehn, Manu Sporny, Dave Longley, Christian 
  Lundkvist, Markus Sabadello, Chris Webber, Mike Lodder, Daniel 
  Buchner
Audio:
  https://w3c-ccg.github.io/meetings/2017-12-07/audio.ogg

Kim Hamilton Duffy: IP Release check: 
  https://www.w3.org/community/credentials/#

Topic: Intellectual Property Release

Susan Bradford is scribing.
Kim Hamilton Duffy: https://www.w3.org/community/credentials/
Kim noted that everyone needed to sign off on W3C IPR. You may 
  join here https://www.w3.org/community/credentials/
Manu Sporny:  Editors will reject an editors of the spec that do 
  not have IPR commitment
Manu Sporny:  Everyone must sign off on the IPR commitment. 
  Drummond will bring this to to IBM.
Manu Sporny: (And Microsoft, DIF Members, etc.)

Topic: Two Stages of DID Document

Discussion from last call on 2 step resolution. DID methods can 
  always be added in the second stage.
Dave Longley: +1 To manu
Dave Longley: Don't need "two stages" or anything so 
  prescriptive, just need to say what pops out to the client
Manu Sporny:  Should we say - everything that happens during 
  resolution is implementation specific.
Dave Longley: And that also better reinforces that the DID doc is 
  about what the client sees, not how a DID method implements 
  DIDs/DID docs.
Christian Lundkvist: Q
Manu Sporny:  We should say - An identifier is mandatory in a DID 
  Spec.
Markus Sabadello:  The final result must be a doc that is 
  compliant. Change the intermediating steps to make it more 
  generic.
Christian also favors making it as simple as possible.
Manu Sporny:  We are missing the section on conformance - this is 
  what conformance means, and this is the software used
Dave Longley: +1 To conformance section
Manu Sporny: +1 To Sam - we do want a lot of elaboration on 
  non-normative sections.
Drummond Reed:  2 Conformance targets, the target system and 
  resolver
Manu Sporny:  DID agent, DID client
Drummond Reed:  Target system where the DID is registered. 
  (includes requirements)
Dave Longley: DID client, DID server (where the server could talk 
  to a separated "target system" but that may be integrated with 
  the "server")
Manu Sporny:  Can we get away with 2? What are the conforment 
  differences with a client for resolver and for a ledger?
Dave Longley: Seems like the "third" is just an optional 
  abstraction
Markus Sabadello:  Universal resolver project has a read me : 
  Local resolver - executed locally. Web resolver. Client resolver 
  - the client that calls the resolver.
Markus Sabadello:  Web resolver - executes methods directly but 
  exposes API
Chris Webber: Think of DNS client vs DNS server :)
Markus Sabadello:  Local resolver - always talks to the target 
  system
Dave Longley: DID client (give it a DID and it returns a DID 
  doc). ... how does it do that? it contacts the "DID server" for 
  the DID's method and follows whatever specific rules are defined 
  by the DID method.
Markus volunteered to do diagrams on this
Chris Webber: +1, DID resolution protocol is another spec
Dave Longley: +1 Protocol is another spec
Chris Webber: (Though it's useful to keep in mind as for what 
  decisions we have in the DID model spec)
Markus Sabadello: Current terminology of the early "Universal 
  Resolver" work: "local resolver", "web resolver", "client 
  resolver": 
  https://github.com/decentralized-identity/universal-resolver/tree/master/implementations/java
Manu Sporny:  Where are we going to put resolutions and parsers?
Christian Lundkvist:  Conformance req is like conformance for an 
  HTML page (example)
Chris Webber:  Important to the group to decide how we break out 
  the conformance requirements and still stay focused on the DID 
  core.
Drummond Reed:  Second conformance target are DID Method Specs.
Drummond Reed:  Suggests deferring second DID spec for web 
  resolver
Manu Sporny:  Focus on DID data model and parser
Manu Sporny:  Hard to juggle between specs

Topic: Simple Arrays of Key Descriptions

Christian Lundkvist:  This was the simplest possible way to 
  gather up all the data we would be interested in for the DID Doc. 
  The DID is a root of trust, a certificate of yourself as a root 
  authority.
Manu Sporny:  Concern is multi fold. We had this array of keys. 
  Then we moved to auth cred (which was imperfect). Use 
  "authentically material"
Sam Smith:  Key rotation is at least as important use case as 
  authentically material
Manu Sporny:  Argument - when you have a giant bag of keys, it is 
  expected to be abused more. So instead of keys, we use 
  authentication materials.
Mike Lodder: I don't see how this makes it better because 
  authentication material can be interpreted as passwords
Drummond Reed:  Must decide what is going to be in this array.
Drummond Reed:  At RWoT there was a large group that felt almost 
  unan to call it biometric key.
Drummond Reed:  DID docs are the foundation to address key 
  management
Drummond Reed:  Auth is one of the classic use cases, but not the 
  only use case. Boiled down to a type, idea, and a value
Sam Smith: While I agree with Manu that a generic field could 
  tend to overuse as in the data example, I think that 
  cryptographic keys are not nearly so generic. And keys are used 
  for at least two purposes that make sense both authentication and 
  encryption  but why should we care
Sam Smith: About the use. We just specify the key and suite and 
  let the user fo the key material decide
Sam Smith: If we want to have relationships then have a separate 
  section that defines the use of the key
Dave Longley:  How do these things relate to the subject? How you 
  use the key is defined by another spec. Ex: data sig
Dave Longley: "Keys" can be private.
Mike Lodder:  Does not agree that it should be called auth 
  materials. You are opening it up for people to put other stuff in 
  there. It's too specific.
Dave Longley: (The same problem exists) ... "public" could be 
  used as a prefix to address those points.
Dave Longley: "Indexed by type" is the proposal here -- no clear 
  relationship between subject and object.
Manu Sporny:  Need to have separate discussions between arrays 
  and service objects
Dave Longley: The array should be considered a set, not an 
  ordered list
Mike Lodder: +1 Dlongley
Christian Lundkvist:  We use DID docs to look up auth keys, not 
  to look up encryption keys. But that may not always be the case.
Christian Lundkvist:  Need to include Key material for roots of 
  trust (ex: signing something)
Manu Sporny:  We need to remember that we're using a graph model, 
  information from different graphs can be merged (open world 
  assumption), therefore we should be very specific with semantics 
  [scribe assist by Markus Sabadello]
:)
Sam Smith: If we accept the relation model then we should not 
  have a keys field we should have each key have its specific 
  relationship as determined by the user.  We merely specify what 
  the format of a key looks like not where it is stored
Chris Webber: I'm not sure the type property specifies what it's 
  used for but what kind of key structure it is...
Manu Sporny:  The type field is too general.
Dave Longley: It would be better (for implementations) if you 
  can't get to the key unless you've gone through the proper 
  relationship to arrive there. -- that is a key distinction in how 
  the data is modeled, it's *not* the same.
Manu Sporny:  Identify the conflated arguments with the specifics 
  on relationships.
Manu Sporny: I don't think that the 'type' is used in the way 
  that Drummond wants it to be used ... :)
Sam Smith:  Each key should have its own field.
Chris Webber: That still doesn't address the ambient authority 
  problem
Manu Sporny: I think we're miscommunicating big time :)
Susan Bradford:  Should we have a separate meeting just on this 
  topic?
Manu Sporny: I think we keep going, suedonym -- it's a part of 
  this discussion.
Manu Sporny:  Still need to have purpose discussion.
Sam Smith: I think there is some conflating of type and purpose 
  there is a general purpose of cryptographic operation type and a 
  specific purpose within a given application
Dave Longley: You don't get to the data unless you've gone 
  through the appropriate relationship to find it
Manu Sporny: SamSmith, I agree, we need to unpack that 
  discussion.
Dave Longley: If we uphold that as the model, people are less 
  likely to mess up their implementations
Sam Smith:  Conflating purpose within an application and crypto 
  field
Sam Smith:  Define ALL the standard purposes
Drummond Reed:  Ok, let's pick this up next time.
Manu Sporny:  I think we need to propose two things, discuss 
  differences. Maybe we want to back burner this discussion and 
  pick up some of the other more easy ones.
Received on Thursday, 7 December 2017 20:06:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:17 UTC