Manu Sporny: https://github.com/w3c-ccg/did-spec/pull/41 ✪

Manu Sporny: https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/41.html ✪

Manu Sporny: Spec should now be aligned with consensus from the last call. Place to put public key, authentication suites. ✪

Drummond Reed: So delegation is one of the open issues ✪

Manu Sporny: No method on delegation right now, will probable be method specific initially. ✪

Manu Sporny: Experimental items are marked as such in the doc. ✪

Drummond Reed: Manu, can you share links to the new registries? ✪

Drummond Reed: Example 2 Service does not have a property. Manu: That was intentional. ✪

Manu Sporny: If you have a service endpoint you can put it there, but you do not have to do that. ✪

Mike Lodder: Is the "type" optional? It seems to just be a description tag ✪

Kyle Hartog: Q - Example 10 lists encryption as experimental. Where will encryption be in DID Auth? ✪

Manu Sporny: This is still up in the air, good argument for both ways (authentication/encryption) ✪

Dave Longley: Btw, i would think we're talking about "keyAgreement" for TLS, not "encryption" ✪

Jan Camenisch: I've got a question related to pseudonyms, i.e., when a public key is a pseudonym ✪

Drummond Reed: Encryption for DID Auth protocol - it is a separate property will DID Auth end up under auth or service? If all it needed was the type and the key I'm using, these 2 entries under authentication is what that is for. ✪

Drummond Reed: Justification for separation - you don't need to define it as a service. ✪

Manu Sporny: If people want to messaging encryption as a service, it can be done in encryption. ✪

Mike Lodder: In both the service and public key, are they optional or required? ✪

Manu Sporny: They are not optional. ✪

Dave Longley: Example 6 ✪

Mike Lodder: Will those types be defined? ✪

Drummond Reed: We will have a set defined in the DiD off that will be published. There will be a spec that defines that in here. ✪

Dave Longley: We should put some URL examples in there ✪

Drummond Reed: Short names established by DiD context, mapped to global url's. ✪

Dave Longley: As that's how they will appear when using the DID @context if they were not defined by the group ✪

Jan Camenisch: Public keys could be anonymous, in some context you might want to limit to one identity ✪

Manu Sporny: That sounds method specific. ✪

Manu Sporny: You could get hyper specific on the key you put in the did doc. Once you spend the key, that can be called out. ✪

Manu Sporny: You can annotate that key for a specific assumption. ✪

Manu Sporny: In the JSON world, if they reuse that terminology from JSON LD you can do it the same. ✪

Jan Camenisch: Fields in the public keys you could add a field for context... ✪

Dave Longley: Do we have a use case for putting encryption in this doc? ✪

Mike Lodder: Use a srvice, and the public key is used as a back up. Private key held elsewhere. Key encapsule ✪

Dave Longley: Use cases seem to fall under key agreement ✪

Mike Lodder: +1 To change to keyAgreement ✪

Drummond Reed: Inherent under the service, or key type when identifying the key. We are open to call encryption out if its needed. ✪

Manu Sporny: Mike-lodder, do you think we should have KeyAgreement as a form of authentication suite? or separate from authentication? ✪

Dave Longley: We have to have use cases for anything we put in here. ✪

Kyle Hartog: We dont want to make the assumption that we will be operating in a tls channel, so the way would be to use an encryption key. ✪

Drummond Reed: The DID Auth - the protocol would be assigned a URL, the name would go into the JSON LD ✪

Drummond Reed: If there are multiple keys, then we have a different situation. We only allow for one key right now. ✪

Dave Longley: The encryption to the service would be listed in the service block. ✪

Christian Lundkvist: What we are discussing could also be in a service end point. DID Doc is like a root of trust. ✪

Drummond Reed: I agree with Christian that the DID document could be just a starting point for key negotiation. ✪

Dave Longley: +1 Seems like the most common/expected approach ✪

Drummond Reed: As he is pointing out, it may be used only for provisioning. It could be a common design pattern. ✪

Christian Lundkvist: Assume we have a tls channel, have an authentification protocol for username and pw. ✪

Manu Sporny: Interesting proposal ✪

Drummond Reed: The challenge with an assumption of a TLS channel for DID auth is that it requires bootstrapping decentralized identity solutions from centralized CA PKI. ✪

Dave Longley: I think we're talking about two different things ✪

Dave Longley: 1. Getting around the CA system ✪

Dave Longley: 2. Authenticating once you have a TLS channel ✪

Dave Longley: Where in #1 you try and do both at once ✪

Dave Longley: But with #1, that's really messy on the Web. (doing both at once) ✪

Manu Sporny: The design pattern you are pointing out christian is upgrades. ✪

Dave Longley: So combining both approaches would be more ideal, IMO. ✪

Dave Longley: And you can do #2 without doing #1 if you trust the CA system. ✪

Mike Lodder: You have to be careful with that and address two issues: the absence of forward secrecy for all data, and the replayability ✪

Drummond Reed: It does seem like including "encryption" as a defined branch of a DID document is on the bubble, and we should not include it if no one has a good use case for it. ✪

Dave Longley: +1 To using authentication or service ✪

Manu Sporny: Key agreement - Could we say that did auth or tls will either go in an auth bucket or service bucket? ✪

Markus Sabadello: Sorry I need to leave.. I don't see any big problems with this version of the spec, and I'm also looking forward to further discussing the details of DID Auth. ✪

Drummond Reed: Mike Lodder makes a good point about encryption for key agreement being something that should be done outside of the DID document. ✪

Mike Lodder: +1 To remove encryption ✪

Kyle Hartog: +1 To removing from spec ✪

Dave Longley: +1 To removing encryption ✪

Dave Longley: "DID-TLS" is a good name for this ✪

Dave Longley: And it should use TLS ✪

Manu Sporny: Remove encryption from the spec ✪

Drummond Reed: End up with just a set of keys, and a set of types, and the pattern we have in there will be just fine. ✪

Dave Longley: You could also just list a certificate in a DID Doc. ✪

Dave Longley: And then bootstrap that way ✪

Dave Longley: (It's like certificate pinning, but putting it on the blockchain instead of in the client) ✪

Drummond Reed: Decision: take "encryption" out of the spec. ✪

Kyle Hartog: I've looked at finding a way to translate an auth key in a DID Doc into a CA. Not sure how it would be done, but if it could it wouldn't require any changes to TLS. Also not an eloquent solution to the problem. ✪

Drummond Reed: Feature discussed early on that solves a significant problem of being able to map a did doc that maps to a url. Name element (property) for a service. ✪

Dave Longley: Yeah, not elegant but would be a better "plan B" than rolling a new TLS ✪

Dave Longley: IMO. ✪

Sam Smith: Ex 2. we have the id which is the did, then the public key with the same did. In key rotation, how do I change the auth in this example? . Earlier we only had the frag identifier. ✪

Dave Longley: Btw, we may want to use a full ID for simplicity instead of using a fragment identifier: https://github.com/w3c-ccg/did-spec/pull/41/files#r163934080 ✪

Manu Sporny: Fragment ID - resolved are specific to JSON LD. Frag dont necessary work the same across specs. ✪

Manu Sporny: Frag ID's are resolved on the base url. ✪

Drummond Reed: Example 2 has reference to frag identifier that just has a hash sign. Why is it not the same reference? ✪

Manu Sporny: It could be. ✪

Sam Smith: That is how it used to be. ✪

Sam Smith: Why woud you not always do it with the hash sign? ✪

Manu Sporny: If you are a machine, you will want to work with the full url. ✪

Sam Smith: Are we doing examples for machines or for developers? ✪

Sam Smith: Examples should be consistent ✪

Manu Sporny: All examples will use frag identifiers ✪

Manu Sporny: Authorization did doc you may point to other keys, you will have to include the full url. ✪

Dave Longley: Recommend we use the full url everywhere. ✪

Manu Sporny: As long as we are consistent. ✪

Mike Lodder: As a programmer, I useually end up using an absolute path 90% of the time. Agree we should use full url. ✪

Kyle Hartog: +1 To full path. Helps remove any convolution that may occur ✪

Sam Smith: Explain the variants somewhere else. ✪

Dave Longley: A foolish consistency... ✪

Sam Smith: The original hardening doc V3 had a write up on meta data syntax component. ✪

Drummond Reed: DID Hardening Spec Proposal V3: https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit#heading=h.abon80m52d50 ✪

Sam Smith: Its in Sec 10. ✪

Sam Smith: With the current way that did frags are being proposed with JSON ld, would that conflict with using rfc6901 or being able to reference other parts of the did spec using rfc6901? ✪

Manu Sporny: This is JSON pointed ✪

Manu Sporny: This cold be problematic for JSON/JSON ld compatibility. ✪

Sam Smith: JSON LD is the problem. ✪

Manu Sporny: The group wants compatibility between the two. We use identifier. When there is not an identifier, that is when it gets hairy. Need use cases for this. ✪

Dave Longley: What's the use case? ✪

Dave Longley: You can have the same problem if you pick other technologies -- many technologies are mutually exclusive ✪

Sam Smith: Concern: If assume so much with JSON LD we wall off any other options. ✪

Drummond Reed: I think what Sam is proposing is that the spec say that the DID spec supports JSON Pointer. ✪

Drummond Reed: Summary - th did spec in the fragment portion, we say were going to support json pointer for syntax. Make one modifying assumption - if it references a did fragment identifier. ✪

Drummond Reed: If you follow with a slash, now your'e using a json pointer. ✪

Sam Smith: Does anyone see where that is not compatible? ✪

Sam Smith: 2 Proposals in Ex 10 on fragments. ✪

Sam Smith: Is that 2nd proposal compatible? ✪

Sam Smith: The shards are not keys, they are parts of keys ✪

Sam Smith: Are we truly supporting naive json and json ld? ✪

Drummond Reed: Sam is going over an example of why he wants to use JSON Pointer style fragments to support references within naive JSON documents. ✪

Drummond Reed: Dave thinks there may be some compatability problems with supporting JSON pointer. ✪

Manu Sporny: Trying to map as cleanly as possible what web developers use in general. ✪

Chris Webber: I just joined ✪

Manu Sporny: Accept that fragments do have some special encoding. ✪

Manu Sporny: Fragment identifier resolution is defined by the media type spec [scribe assist by Drummond Reed] ✪

Drummond Reed: Manu feels that using a "brittle" approach for addressing within a DID document (and he considers JSON Pointer such an approach) could be dangerous. ✪

Manu Sporny: If we are going to give this stuff special meaning, it means that we are talking about something that is a new media type (not json/jsonld0 ✪

Dave Longley: Actually, i don't think there would be any incompatiblity with JSON-LD libraries right now ... it would just be a layer on top you'd have to run -- and JSON-LD users would have to make sure to frame the document a certain way (and know what that frame is) ✪

Drummond Reed: This means that DID documents would need to be a separate media type. ✪

Dave Longley: Which might not be possible ✪

Drummond Reed: I would very much like to avoid having to make DID documents a separate media type ✪

Sam Smith: In the current did spec, we have a special meaning for a fragment. ✪

Manu Sporny: The library that processes the url is highly specific library ✪

Manu Sporny: Fragment ids for did's re more complex, then call in pointers. ✪

Manu Sporny: Concern this will lead to security issues. ✪

Drummond Reed: Q - do you still want to make a specific proposal for json syntax? Sam: yes, but dont want that to hold it up. ✪

Drummond Reed: Sam will consider making a future proposal about supporting JSON Pointer. ✪

Manu Sporny: If pathing is that important, we should address did paths. ✪

Drummond Reed: Drummond is open to talking about DID paths. ✪

Manu Sporny: Any objections to merging this change set next Tuesday? ✪

Mike Lodder: +1 To merge ✪

Mike Lodder: After review ✪

Drummond Reed: Any objections to merge this PR in by next Tuesday? ✪

Drummond Reed: Continue this meeting next week? Yes. Pick items that are blocking people. Bring those to the meeting. ✪

Drummond Reed: If you have items that are blocking, send them to the mailing group, and Manu and Drummond to be added to the agenda. ✪