- From: <msporny@digitalbazaar.com>
- Date: Thu, 07 Dec 2017 15:05:09 -0500
- 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