Drummond Reed: Dan Buchner at DIF said Microsoft is doing DIDs... going over requirements w/ them. ✪
Drummond Reed: This is stuff is advancing quickly... Microsoft giving talk at Davos, decentralized infrastructure is one of the things being talked about by MS head. ✪
Drummond Reed: Kim Cameron is thoroughly involved and behind effort that Microsoft wants to build API support into Azure Active Directory. ✪
Drummond Reed: On to specifics... sent URL to the mailing list -- link forthcoming... ✪
Drummond Reed: Since proposal was published, had DIF meeting, had chat w/ Markus and Sam. ✪
Drummond Reed: Let's dive into this - quickly go over five specific things ✪
Topic: DID Harmonization
Drummond Reed: I found explanation of tree and graph harmonization helpful. Because of requirements, you can do tree and graph oriented processing... designed to do that, editorial recommendation. ✪
Drummond Reed: From a tree-oriented perspective, I'm calling 'id', 'publicKey', and 'service' core. ✪
Drummond Reed: Theme of minimalist is that we just need those 'tree' properties and can get stuff done - Manu's proposal allowed that you can have both tree-oriented and graph-oriented in the same document if you design it elegantly enough. ✪
Drummond Reed: If you look at it from the tree-oriented perspective, satisfied on extensibility model - graph / richer perspective... from tree-oriented perspective, if you look at these three properties, if you look at authentication as a service that may not need an endpoint, then the same thing can be described as a service w/o an endpoint. Type property could be used in that way. ✪
Dave Longley: Hmm, slightly concerned that what Drummond is describing might end up turning "services" into a "bag" ✪
Drummond Reed: Service type descriptor -- protocol for doing authentication, doesn't use an endpoint, in band protocol... but there can be a different version of that... DIF planning on new WG for DID Auth - site you're logged into w/ different endpoint, different protocol, service with endpoint. ✪
Drummond Reed: Moving on to public key property... owner property -- JSON-LD signatures requires it... other key descriptions may use it, it may be inferred, when it is required it's clear why it is. ✪
Dave Longley: About the owner property, if it's assumed, then what we recommend that we do the same thing that we did with 'id'... resolvers inject that property where it should be... some DID methods might not have ID, produced/implied... but you inject it into final DID document when you're done. We can inject into key information in same way as key ID. ✪
Markus Sabadello: Basically, DID document will have owner for every public key. ✪
Drummond Reed: It's either explicit or implicit. ✪
Manu Sporny: So the only thing that throws a wrench into the works there is that there are potentially DID ledgers that might sign things [scribe assist by Dave Longley] ✪
Manu Sporny: We dont' do the implied thing in Veres One, we'd be careful to include owner before signature [scribe assist by Dave Longley] ✪
Manu Sporny: The one wrench in the works is that auto-included signature would invalidate the signature. [scribe assist by Drummond Reed] ✪
Manu Sporny: Injecting the owner field post signature would make it invalid. [scribe assist by Dave Longley] ✪
Manu Sporny: It's not a blocking thing, just considerations. [scribe assist by Dave Longley] ✪
Manu Sporny: Specifically about owner, keep in mind that this isn't just about DID documents but it's useful outside in the general Web. If you express keys on the public Web, for example. [scribe assist by Dave Longley] ✪
Manu Sporny: We do need owner elsewhere, we can't assume who the owner is. It can be kind of dangerous to assume, it could turn a programming mistake -- a DID document authoring mistake into a security vulnerability. We should consider heavily about presuming certain values are certain values when it comes to things like key material. [scribe assist by Dave Longley] ✪
Manu Sporny: Want to be explicit, not implicit. The owner of a key that's listed may not be the DID -- you may list keys that belong to other poeple. [scribe assist by Dave Longley] ✪
Manu Sporny: You may have M of N signatures, for example, where you list other people's keys. [scribe assist by Dave Longley] ✪
Manu Sporny: We should be careful and have a further security analysis on this. [scribe assist by Dave Longley] ✪
Manu Sporny: Moving make to the key references stuff, that's fine, we were hoping that would happen. [scribe assist by Dave Longley] ✪
Manu Sporny: Key references looks good. Core tree properties, I'm wondering if something was missed. Christian on the mailing list said that he likes the idea of purpose and application being split out from the general key description. [scribe assist by Dave Longley] ✪
Manu Sporny: The proposal on the mailing list did just that. Authentication/encryption/whatever, uses following the tree based path or the graph property. [scribe assist by Dave Longley] ✪
Manu Sporny: We were not going to put that in with the key. [scribe assist by Dave Longley] ✪
Manu Sporny: That means the core tree properties needs to have that there. Not sure if we're challenging that or what here. [scribe assist by Dave Longley] ✪
Manu Sporny: This raises the question about where does the purpose go. I thought there seemed to be general consensus on the mailing list that the purpose should be outside of the key, not part of the key description. [scribe assist by Dave Longley] ✪
Drummond Reed: Just wanted to do an overview, didn't want to get into discussion in depth. ✪
Drummond Reed: In response to Manu, what we've illustrated here is what was proposed, but it recognizes that the 'authentication' type, referencing public key used for authentication... another way to look at that - what does the type represent... that's a service, an in band service, doesn't need a separate endpoint. ✪
Drummond Reed: If you cross-reference a key from a service description, you're effectively doing the same thing... it's clearly an authentication service - described in type of that service... more of a tree-oriented description... but accomplishes the same thing. ✪
Drummond Reed: Part of the original proposal, big believer, doesn't matter where type is defined, type for service, type for authentication -- it should have a spec... what is this type for. ✪
Drummond Reed: You can also model this as a service - that's what I'm trying to illustrate here. ✪
Dave Longley: I'm concerned about this approach... anythign can be a service, so let's make a giant bag of services. ✪
Dave Longley: To a certain extent, we can argue that keys are services as well - if we make our bag generic enough, but if we do that, we lose core ideas of splitting it out - clear purpose and relation to follow to get to the information you need to get to. ✪
Dave Longley: I like the idea of following a certain relation to where we want to go - same arguments apply for bag of keys. ✪
Christopher Allen: Sorry I’m late. Too many Thursday calls. ✪
Drummond Reed: Just want to reinforce that write up is about tree-oriented processing viewpoint -- do not think it's a repudiation/replacement of graph-oriented viewpoint. I'm not trying to say we shouldn't have/define well known graph contexts. ✪
Drummond Reed: Folks who want to do it that way can do it that way... we can define how a DID Document can be used from a tree vs. graph-based standpoint... ✪
Drummond Reed: It's fairly elegant, both world views can be put together. ✪
Drummond Reed: Folks who have a graph-oriented view can see how it can work from a tree-based and vice-versa. ✪
Drummond Reed: This is not to say we shouldn't have the exact set of fields being proposed and spec should say "for graph oriented view -- here are standardized properties" ✪
Drummond Reed: The DID context that we'll be defining in the spec, will be defining these base properties... ✪
Drummond Reed: Those properties are you can only use the raw name for in that context. ✪
Dave Longley: What do you mean by "can only use"? ✪
Drummond Reed: To clarify - property names map to items in JSON-LD context. ✪
Drummond Reed: What's being proposed in B is that it's not that it's a tree model, it's a minimalist view of description - a simple model of description, not as rich as graph-based approach. ✪
Drummond Reed: Basically, you can reference things from a service instead of via authentication. ✪
Drummond Reed: Manu's proposal says that if you have to reference a key, you have to do it via the authentication field... if you have an authentication service w/ a endpoint, is that not a service? or is it? ✪
Manu Sporny: All I wanted to do was that we are way down the extensibility rabbit hole. [scribe assist by Dave Longley] ✪
Dave Longley: When we're minimizing - we could reduce properties in document... or alternative - minimize on differences between approaches. ✪
Dave Longley: You don't have to worry about tree and graph distinction - the more important thing is to minimize towards reducing differences. ✪
Dave Longley: I'm not clear on why it woudl be better to go in that direction. ✪
Sam Smith: It's not clear what the purpose of the authentication block is. ✪
Sam Smith: In my mind, there is a target of authenticating someone for some purpose. Are we authenticating owner of DID document? Are we authenticating some other service or protocol that is yet to be determined. I'm very concerned about the latter. Generically specifying authentication. If we were talking about just authentication to the DID document, but then we're talking about a protocol for how we authenticate DID documents. ✪
Sam Smith: If you could clarify that, that would be helpful. ✪
Manu Sporny: Where are we putting the purpose and application related to the key. That's not an answer to Sam yet. If we remove authentication, it follows that we have to put application and purpose somewhere. [scribe assist by Dave Longley] ✪
Manu Sporny: The assertion is moving it to the service array and we're not putting it in the key. I wanted to clarify ... it's not pointed out in the proposal, but that has to be true -- that info has to go somewhere. [scribe assist by Dave Longley] ✪
Manu Sporny: My assumption is that application/purpose is going into service descriptions now, but I don't know what those look like I can't easily analyze what's being proposed. That's an option question on section B. [scribe assist by Dave Longley] ✪
Manu Sporny: Sam, I think you're right... the reason we had authentication and encryption was because there's a general use case for authenticating as the entity associated with the DID. [scribe assist by Dave Longley] ✪
Manu Sporny: That's a use case everyone has. [scribe assist by Dave Longley] ✪
Manu Sporny: What you say is true that it can be a bit concerning when you use "authentication" and when you don't. On the mailing list, I explained that that property expresses the purpose and application fairly clearly and it's a meta protocol. It's not a service with an endpoint. [scribe assist by Dave Longley] ✪
Manu Sporny: I think what's being argued is that the services array could contain both services with endpoints and these other things. [scribe assist by Dave Longley] ✪
Manu Sporny: We have a specific set of use cases where the authentication would be used, one is Web-based authentication ... [scribe assist by Dave Longley] ✪
Sam Smith: As soon as you say a set of use cases and you sign something and the something you are signing is authenticating you as the owner and controller of the DID document. [scribe assist by Dave Longley] ✪
Manu Sporny: Yes, you're signing something to authenticate as the entity associated with the DID document. [scribe assist by Dave Longley] ✪
Sam Smith: That makes a lot more sense. We want to authenticate control of the DID document and we're going to have a spot for that specific purpose and define a protocol for that. And every different protocol for that needs a document somewhere else. [scribe assist by Dave Longley] ✪
Manu Sporny: Yes, and that's what the authentication suites were about. [scribe assist by Dave Longley] ✪
Manu Sporny: It defines exactly what the protocol would be and my assumption was that the services would have an endpoint ... and now they don't necessarily have one. [scribe assist by Dave Longley] ✪
Sam Smith: So we could have authentication suites be subsets. It's the same information, where do you put it? [scribe assist by Dave Longley] ✪
Manu Sporny: The argument for splitting it out would be to be very explicit about these containers. It's the anti-bag argument -- don't let the bag lose meaning because it has everything in it. [scribe assist by Dave Longley] ✪
Manu Sporny: Maybe authentication suites only go in the authentication bag. For the encryption bag, only encryption suites/protocols/mechanisms go in there. [scribe assist by Dave Longley] ✪
Drummond Reed: Drummond invites others on the call to weigh in on this topic. ✪
Manu Sporny: That seems to be the discussion we keep having -- how generic do we make these containers. We tend to push back when it goes to such a level that you can just put anything in the container. [scribe assist by Dave Longley] ✪
Manu Sporny: That's why you split those things out. [scribe assist by Dave Longley] ✪
Sam Smith: I would say that that is not specific enough. [scribe assist by Dave Longley] ✪
Sam Smith: Having an authentication bag and an encryption bag isn't specific enough. [scribe assist by Dave Longley] ✪
Drummond Reed: This seems more and more an argument about the best way to do description (of both keys and services). ✪
Sam Smith: We're saying we want to have this more specific but still generic way to do authentication. I disagree. If we're going to authenticate DIDs we should outline that protocol and standardize or have a set to suggest to standardize on. Until we're prepared to do that, let's make it simple and just do keys. [scribe assist by Dave Longley] ✪
Manu Sporny: I was with you up until your last sentence. [scribe assist by Dave Longley] ✪
Dave Longley: I believe we have a need for DID auth, not a need so much for generic keys. ✪
Drummond Reed: I like that we're getting down to the nub of it, different viewpoints on description -- the more specific, more complete the spec behind a type, the more it can be used to identify what's needed. It's a different type of description, not discoverable in the graph in a DID document, defined/identified via URL/mapping. ✪
Sam Smith: I agree that DID auth is important, essential But DID auth is not Auth for any other purpose ✪
Drummond Reed: It's one way of doing description, graph model, authentication - neither approach is wrong, if we are not going to convince one another that we - both methods supported and away we go. ✪
Sam Smith: As soon as you expand beyond DID auth you are on a slippery slope ✪
Sam Smith: That's fine .. but let's pick a relation that's for DID auth specifically and make that thing then. [scribe assist by Dave Longley] ✪
Christopher Allen: I have similar concerns, new bags emerging - adding more and more things in that nothing in DID would be anything but how to do stuff w/ the DID. ✪
Christopher Allen: Stuff in DID Document is only about DIDs -- e.g. IDs, Verifiable Credentials, etc. ✪
Christopher Allen: I wanted to be far more specific - part of the challenge is we're calling these topics areas generic words - rather than being "encryption" -- be more specific. ✪
Christopher Allen: Maybe it should be "didAuthentication"? ✪
Christopher Allen: Even the section name sounds like a bag. ✪
Dave Longley: I'd be happy if we got this down to a bikeshedding discussion ✪
Dave Longley: Let's agree that this is how we ought to model things ... and then just pick the things we are ready to standardize, like a place to do DID auth. ✪
Sam Smith: Then we can all agree that this is essential, and we should say how to get key material for DID owner/signer/etc. ✪
Drummond Reed: Types of authentication for entity identified by the DID... other auth protocols -- absolutely authentication services out there, what do you do w/ authentication service? authentication or do you put it under service? ✪
Drummond Reed: What about FIDO, OpenID, WebAuth -- there are subprotocols/profiles. ✪
Drummond Reed: They are different protocols, part of a family, are they all defined there? If we had a branch, it would be for that set of DID Auth stuff? ✪
Dave Longley: Yes, it's PURPOSE is for authenticating the subject of the DID ✪
Sam Smith: We have an DID authentication branch that points to the key bag, both people can be happy, but we limit discussion to auth branch to being DID Auth... any other form of authentication is off of the table. If we want to add something to that bag in the future, I don't think we'll ever get there to limit to essential things to move forward. ✪
Drummond Reed: So Drummond proposes two questions: 1) should we have a LIMITED "authentication" branch that is only about DID auth? 2) What do we do about other authentication services (e.g., OpenID Connect)? ✪
Christopher Allen: Yes, if you do a DID Auth, you can do other objects, then you can authenticate additional things -- progressive trust, verify via DID Auth, then you can go further. ✪
Dave Longley: +1 To bootstrapping post authentication of the DID entity. ✪
Drummond Reed: Two questions I'd love to close on the call are above. ✪
Dave Longley: Doing OpenID or whatever to authenticate yourself as some other thing (or whatever) belongs somewhere else, not in the DID auth bag we're talking about.. .. that was *always* the intention from my perspective. ✪
Christian Lundkvist: I'm cool with limiting "authentication" to DID Auth ✪
Dave Longley: I dont' think we need to call it "didAuthentication" because it is a *relation* where the DID is the subject ... from a graph model perspective, but i'm happy to bikeshed. ✪
Dave Longley: To be clear, that was *always* the intent ✪
Drummond Reed: It was always the intent, but that was not clear -- term meant that it's for all authentication. ✪
Drummond Reed: This also answers question - what about other authentication services? There are endpoints, we need services, any service except for authentication... someone can say that's a service... as long as we're clear -- about our guidance, if you're going to do DID Auth, it belongs in this branch. ✪
Dave Longley: I think the reason we weren't making it clear, if you look at it from a graph model perspective, the subject of the DID is explicitly stated and the property is authentication, so it's clearly about DID Authentication. ✪
Christopher Allen: Yes, if you think of it from tree-way of thinking, you need extra hint that it's didAuthentication - good observation, maybe there are other places where graph way of thinking may need clarification. ✪
Christopher Allen: In effect, we have a tendancy to want to do things at once, in my head, it's more of a progressive trust model... we talked about it in CCG and what is progressive trust blog post that I did. ✪
Christopher Allen: Authentication isn't an atomic operation, it is a process where you start w/ little things ✪
Drummond Reed: Christopher has a good point about property names ("terms" in JSON-LD parlance) - the preferred semantics depends on whether you are looking at the term from the tree-oriented view or the graph-oriented view. Dave's point illustrates that. ✪
Christopher Allen: I encourage you to focus on this being part of a bootstrap process. There may be things before and after, it's not authenticated or not... you're authenticated enough for the scenario. There is no end to authentication. ✪
Christopher Allen: The process stops short of real world truth. ✪
Dave Longley: And unfortunately, the meaning in the "tree model" is mostly derived from specs only, there's no explicit underlying data model. ✪
Dave Longley: But we can be clear about the meaning in our spec -- even if you get it intuitively with the graph view. ✪
Markus Sabadello: I agree with having branch called authentication, should be used for DID-based authentication. Not sure if it should be limited to DID Auth - limit it to one specific protocol, OpenID would be a service? Wouldn't service also use key material used in authentication branch? ✪
Markus Sabadello: Would it apply to all services/endpoints? ✪
Dave Longley: OpenID, you'd be authenticating some other piece of information, from graph model perspective, authenticating as entity that owns DID, if you want to authenticate as something else, that goes somewhere else. ✪
Markus Sabadello: I didn't mean authenticate someone else, I meant using different protocols.... but OpenID might where you identify as DID. ✪
Markus Sabadello: Different protocol, uses same key material as DID auth... should use what's in authentication branch. ✪
Dave Longley: We'll have to be more careful about DID auth ✪
Dave Longley: It means authenticating a subject of DID document. ✪
Markus Sabadello: Good question.. is "did auth" a specific protocol ? ✪
Drummond Reed: OpenID does the same thing... what this highlights is that there is a specific protocol for DID Auth, what do we do for v2? ✪
Christopher Allen: If openID wants to do a method spec, then sure ✪
Drummond Reed: I do understand that we can create a new relation... branch for each type of auth service - I get that, ones that are services are easy... but where does it end up? ✪
Drummond Reed: Does it force us to pick one path or other. ✪
Manu Sporny: I'd like us to claim victory while we can and move on. [scribe assist by Dave Longley] ✪
Manu Sporny: We have agreement, so the core tree properties id, publicKey, authentication (or didAuthentication), and service [scribe assist by Dave Longley] ✪
Manu Sporny: And we're only going to talk about DID auth and put that in the authentication field. [scribe assist by Dave Longley] ✪
Markus Sabadello: +1 To id, publicKey, authentication, service ✪
Manu Sporny: We can discuss things further and make solid progress. I'm wondering if we have enough to say we've got the core properties, id, publicKey, authentication, and service and put that into the spec and implement against it. [scribe assist by Dave Longley] ✪
Manu Sporny: We still need to have a discussion about what goes int those fields, but it's significant progress. [scribe assist by Dave Longley] ✪
Drummond Reed: Good constructive point. Please think about that. [scribe assist by Dave Longley] ✪
Sam Smith: I agree, let's declare victory before we lose it. :) ✪
Sam Smith: In example that manu provided, there are two types - crypto type in key... application/purpose type in "authentication". ✪
Dave Longley: To sam-- yes, but *what* are you authenticating -- it's the *subject* of the relation, which we want from a graph modeling perspective. ✪
Drummond Reed: If you approach authentication from service standpoint, you could also have authentication protocol identified by type. ✪
Dave Longley: So that's all fine from our perspective. ✪
Dave Longley: +1 Its essential, let's call it out in its own branch. ✪
Sam Smith: Authentication is an essential feature of a DID document, so I'm ok calling that out in its own branch. ✪
Drummond Reed: That branch is for DID authentication protocols... if you're using any other auth protocol, put it in service branch... but we expect this to be multiple protocols over time, how do we design it over time. This resonates w/ me. ✪
Dave Longley: This generalizes for other identity documents on the Web (which makes what we've been doing with Linked Data signatures ... it's why we want it this way! :) ) ✪
Drummond Reed: I can see why encryption wasn't brought up in the same way -- they really meant it in context of key/protocol... key negotiation protocols. ✪
Drummond Reed: What about key negotiation protcols? combination of key type which is cryptographic operation... like Diffie-Hellman - I need to talk about BOTH keys AND protocol. ✪
Sam Smith: We can be specific by nesting types where each type adds new information that isn't essential to previous level of Type... or have long branches that break up types into individual fields (but that's slippery slope of too much algorithm agility). ✪
Drummond Reed: Markus brought up discomfort w/ public keys, auth, and services - but wanted to invite Markus to weigh in. ✪
Dave Longley: Another reason , somewhat historically, putting authentication at top level is to not specify DID Documents as anything different. Included in that thing could be "how to authenticate" all of that matches well with this approach, you can re-use other types of protocols - whether somethin gis being resolved from DID Resolver... or URL Resolver, it just works. ✪
Drummond Reed: Dave is making the point that authentication of a DID subject is special enough that it should be elevated to a top-level branch. ✪
Dave Longley: I think in this conversation "DID auth" is generic. ✪
Markus Sabadello: I'm very comfortable with this approach, authentication branch should be limited to DID Auth - concrete protocol. Dave was talking about something more generic, just subject, not DID owner. I don't think authentication branch should be restricted. ✪
Dave Longley: It's not restricted to a particular protocol but is specific to authenticating the DID entity. ✪
Drummond Reed: If we say in the spec, "This is for authentication for DID Subjects", that accomodates the different protocols that could be used to do that, then I do believe in what Dave and Manu have been saying... DID Auth is special. ✪
Drummond Reed: It's not just because some forms of it won't have endpoints... let's say OpenID sees DIDs take off, if they want to do a profile of OpenID DIDAuth, then what I'm hearing is "Ok, then you're defining something, type/protocol that belongs in that authentication branch. ✪
Markus Sabadello: Maybe OpenID could use what's in authentication branch. ✪
Dave Longley: I agree that it could go both ways, this would be the place to put something if you HAVE to do a new OpenID protocol. ✪
Drummond Reed: Then why wouldn't we just use a service description... back full circle. ✪
Sam Smith: I think we don't know the answer yet because we haven't walked through OpenID yet. There are many iterations of this, let's not try to solve all of those problems yet, let's agree that "authentication" meets needs of tree and graph based model and we need auth and key reference and a type field that specifies protocol and now we can move on to specific protocols. ✪
Drummond Reed: There are two things 1) This is a DID Auth protocol, and 2) it does not have a separate endpoint. ✪
Dave Longley: And when we say "DID auth protocol" we mean, it is for authenticating the entity identified BY THE DID. ✪
Drummond Reed: Any protocol that fits those items goes here - happy w/ that definition. ✪
Christopher Allen: I'm in general agreement with that... if OpenID wants to create a DID Method, that's the other way they can do things. Methods do have a certain ability to do things their own way -- if there is enough information in a DID Method, then you can proceed/reuse information. ✪
Christopher Allen: There are escape valves here. ✪
Drummond Reed: Anyone have any issues with this? ✪
Drummond Reed: Yes, now have a clear enough picture... will point back to this exercise of how hard it is for well meaning people to agree while staring at the same document. ✪
Manu Sporny: I was able to get David Chadwick as a spec editor and get the whole process working on his machine. He was able to do PRs and edit -- so you and I, Drummond, can go through the same process. [scribe assist by Dave Longley] ✪
Drummond Reed: Perfect. [scribe assist by Dave Longley] ✪
Manu Sporny: Ok, we'll do that. [scribe assist by Dave Longley] ✪
Manu Sporny: There are some sections that needs to come out, like the authorization section (did method specific). [scribe assist by Dave Longley] ✪
Dave Longley: (Or goes into a common optional spec) ✪
Drummond Reed: Ok, I'm happy. If you want to take what's there to get us to the next baseline and we start working against, I'm more than happy. Pull out what you need to comes out, put in what you know needs to go in. I'll be happy to engage at that point. And assign action items to me. [scribe assist by Dave Longley] ✪
Drummond Reed: Can't wait to get it done. [scribe assist by Dave Longley] ✪
Manu Sporny: I'll try to get the spec restructured and then you and me doing PRs against specific sections. [scribe assist by Dave Longley] ✪
Drummond Reed: CONGRATS and thank you everyone for persisting through to get to this point where we can get down to drafting. ✪