The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2017-12-07

Kim Hamilton Duffy: IP Release check:

Topic: Intellectual Property Release

Susan Bradford is scribing.
Kim noted that everyone needed to sign off on W3C IPR. You may join here
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":
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.