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

Kim Hamilton Duffy: 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.) ✪

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. ✪

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. ✪

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 ✪

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. ✪