Drummond Reed: Good discussion on the list, let's use that as the starting point for this discussion ✪
Drummond Reed: The goal of these calls is to drive toward closure of these calls - next stable version that we're implementing to. I'm hoping we won't need these calls beyond January. ✪
Drummond Reed: We're implementing a prototype of DKMS, highly dependent on DIDs. ✪
Drummond Reed: We have a delivery deadline mid-march... we'd really like to be implementing against a stable DID spec. Just providing input - really good to drive this toward closure this month if possible. ✪
Drummond Reed: Any other overall perspectives on progress of spec, priorities of call? ✪
Manu Sporny: Under a deadline in mid-February as well. [scribe assist by Drummond Reed] ✪
Manu Sporny: We may need to have even more frequent meetings to get the next version of the spec closed. [scribe assist by Drummond Reed] ✪
Manu Sporny: Seeing some level of agreement in the mailing list threads, but we need to go faster. [scribe assist by Drummond Reed] ✪
Joe Andrieu: Just an early heads up wrt to schedule stuff. It looks like the spring RWoT will be the first week of March (6th,7th,8th) ✪
Joe Andrieu: Talking about schedule, next RWoT is March 6th-8th. ✪
Drummond Reed: That overlaps with DC Blockchain summit. ✪
Adrian Gropper: Link to the DC Blockchain Summit, please... ✪
Markus Sabadello: Regarding schedule - reaffirm my interest to work on universal resolver - as soon as there is a stable version, we can upgrade that project. ✪
Drummond Reed: Any other broader comments before we dive in? ✪
Topic: Biometric Authentication
Mike Lodder: Manu, if you could send me biometric stuff that you're using as a reference to better understand that, that would be helpful. ✪
Mike Lodder: You've just made me more nervous, or it's a bad idea in general, tech isn't ready yet - post it into chat, that would be helpful. ✪
Pelle Brændgaard: Also wanted to just point out that I don't think we need biometrics for daily usage - I think it would be helpful, if we can't complete, what's the most important thing we need to get ready right now - rather than spec out all biometrics stuff -- spec out what we need for interop. ✪
Pelle Brændgaard: Then let spec be open for implementation of biometrics - so we have a limit, so we don't make this a never ending thing where we need to discuss things forever and ever. I dont' think there's that much needed for most basic parts we're talking about. ✪
Pelle Brændgaard: There may be scope stuff that we disagree on. ✪
Drummond Reed: I missed most of the opening explanation of biometrics that manu gave on biometric template option... so, suggest that we start there - short description of that... use case and need for it? Is it a type of key, is it not a type of key? How urgent is it to have that in the spec? ✪
Manu Sporny: First point - Digital Bazaar is not asking for a biometric option to be spec'd out. However they would like to make sure it is considered at this point so it's clear where it would eventually go in the spec. [scribe assist by Drummond Reed] ✪
Manu Sporny: Explains that the biometric authentication being discussed is not a key, but a method of authentication. [scribe assist by Drummond Reed] ✪
Manu Sporny: The state of the art in biometrics has moved far beyond the earlier non-rotatable version. [scribe assist by Drummond Reed] ✪
Manu Sporny: Public key crypto is still a stronger form of authentication than biometrics. [scribe assist by Drummond Reed] ✪
Manu Sporny: You would not want to use biometrics for high-value auth transactions [scribe assist by Drummond Reed] ✪
Manu Sporny: To use this method, you first need to create a biometric template. All of them are proprietary today. [scribe assist by Drummond Reed] ✪
Manu Sporny: The template can be very simple, like an integer, or more complex, like a complex hash. [scribe assist by Drummond Reed] ✪
Manu Sporny: Once you have the template you put it on a biometric server, which is a system that you control, vs. one controlled by others. [scribe assist by Drummond Reed] ✪
Manu Sporny: Then if you can generate a biometric match against that system, that system can authenticate you. But it's privacy preserving because the biometric template stays under your control. [scribe assist by Drummond Reed] ✪
Manu Sporny: The biometric server can keep any number of biometric templates of different kinds in order to provide multiple biometric auth factors. [scribe assist by Drummond Reed] ✪
Manu Sporny: There are standard protocols for these kinds of biometric server matching approaches, such as IEEE BOPS. [scribe assist by Drummond Reed] ✪
Manu Sporny: It's clear that such a template is not key material, but just used for matching. [scribe assist by Drummond Reed] ✪
Adrian Gropper: I understand what you mean by biometric server / authentication server - to be an endpoint, authorization server that HIE of One represents... you control authorization server - or biometrics as you put it. Why isn't this biometric server just and endpoint in the DID Document? ✪
Adrian Gropper: Asked manu why isn't the biometric server not just an endpoint in the DID document? [scribe assist by Drummond Reed] ✪
Manu Sporny: It could be modeled that way, i.e., one of the service endpoints could be a biometric server using a specific biometric auth protocol. [scribe assist by Drummond Reed] ✪
Manu Sporny: The basic idea is that application and purpose are important to consider. [scribe assist by Drummond Reed] ✪
Manu Sporny: If we were to break out biometric authentication into a list of services, it would just recreate the same kind of authentication we are trying to solve in DID documents. [scribe assist by Drummond Reed] ✪
Drummond Reed: If one takes the perspective that the primary problem we're trying to solve with DID Document is key discovery - one could argue that you don't need to talk about biometrics (do it in service fields). This is an alternative perspective on scope here, emphasis on problem we're solving. ✪
Drummond Reed: I'm a huge supporter of what Manu just described - biometric authentication service is being provided by eyeRespond, Sovrin stewards - implementing Thai Fishing Fleet workers and Myanmar refugees. working with iRespond on privacy respecting aspects of it. ✪
Drummond Reed: The way we've been planning on doing it is discovery of iRespond as service endpoint and mechanism to deal w/ iRespond as a service. ✪
Adrian Gropper: Did not understand how manu's explanation of the use of a biometric server was privacy respecting. [scribe assist by Drummond Reed] ✪
Adrian Gropper: I did not understand, from the privacy perspective, manu's explanation of why template has anything to do w/ DID document as opposed to being negotiated w/ whoever is doing authentication out of band. I don't necessarily need explanation, this is very relevant to what we care about at HIE of One - we do want the endpoint to the authorization server to be considred a personal/private store. It's relevant that we have another use case for authentication that needs to be aligned, but didn't want to take up any more time. There are scope that need to be negotiated between various groups. ✪
Adrian Gropper: I don't understand why template is any different from that? ✪
Nathan George: +1 To agropper's comments on the scope creep inherent in trying to more fully model authorization ✪
Manu Sporny: Is hearing the arguments that DID docs are about public key discovery, but not agreeing. [scribe assist by Drummond Reed] ✪
Manu Sporny: The thing that the biometrics discussion highlights is that one of the important things that we are trying to do with keys is authentication. [scribe assist by Drummond Reed] ✪
Manu Sporny: It would be nice if we could log into a website using the material in a DID document [scribe assist by Drummond Reed] ✪
Manu Sporny: What we are trying to standardize is this universal way to do authentication [scribe assist by Drummond Reed] ✪
Manu Sporny: If the scope is broadened to include something like biometrics, as one more form of proof. Keys are just one mechanism. [scribe assist by Drummond Reed] ✪
Manu Sporny: Thinking about only keys is the wrong way to think about it. [scribe assist by Drummond Reed] ✪
Manu Sporny: All we need to do is one minor twist to the DID documents to support these other mechanisms. [scribe assist by Drummond Reed] ✪
Manu Sporny: The sticking point appears to be whether the scope is just public key management or whether it should include other auth mechanisms. [scribe assist by Drummond Reed] ✪
Nathan George: There is a subtle distinction on how we're thinking about authentication - may reveal difference in design. A more general authentication mechanism might leak information, misleads user to determine what they're getting, more of an authorization case instead of a more authentication sense. Verification of non-transferrable posession of a secret, the biometric template functions as a key. ✪
Nathan George: There is a subtle distinction about using biometrics for authentication/authorization, which in turn depends on a key on the biometric server. So that's why it's something that goes into the array of keys. [scribe assist by Drummond Reed] ✪
Drummond Reed: ...Nathan is worried about leaking privacy information in a DID document if it enables biometric authentication. ✪
Nathan George: What you're doing is relying on possession of hardware device - a lot like a public key in that case, if they've secured it properly. One of the keys that goes in the array. If we start to imply that the intent is baked into the key - person consumed DID, only after they've authenticated - defer authorization out of DID, we need to selectively disclose information - bare minimum required for authentication, in flat "key" array, we have enough for authentication piece - put everything else into a service endpoint. It's generic information about raw biometrics (correlatable), which wouldn't be good, we should avoid. ✪
Joe Andrieu: Standardizing authentication through extensible mechanisms doesn't mean every method needs to define all of that stuff - even if some methods are not involved. ✪
Nathan George: But it would prevent you from accepting these foreign DIDs if you don't understand the more full concept, no? ✪
Joe Andrieu: I think we should be able to find authenticatoin details in a DID document regardless of which DID Method is being used. Maybe most methods don't use biometrics. ✪
Joe Andrieu: It also means maybe you outlined the value of indirection in a spec about authentication, but we don't have a good model on when you'd prevent access in a model here. I need to have a filter somewhere where I can stop you from getting some data. ✪
Joe Andrieu: That feels like a rathole - indirection is probably the better way to handle it. ✪
Nathan George: Use case example: in the future a template scheme is discovered to be flawed, so you only want to disclose the information to parties that have an existing relationship ✪
Nathan George: (It is fair to point out that a key derivation scheme, or a bad one, could have similar issues) ✪
Topic: DID Spec Scope?
Drummond Reed: I think this is a good discussion - I get the value of biometrics discussion, but actual scope difference between DID Document being public key discover and service endpoint discovery - you may want to do authentication some other way. Authentication/authorization is some other field? What's the scope of the DID Document? Provide any kind of authentication proof material? Or public service endpoint discovery? ✪
Drummond Reed: What is the scope here? Any form of authentication material? Or just keys only? ✪
Pelle Brændgaard: I think that's a good way of decisioning this, but we should be open for all kinds of stuff in the future. What we need right now is public key to verify different kinds of data ✪
Drummond Reed: +1 To the primary use case being "public keys" ✪
Pelle Brændgaard: I don't necessarily think that that needs to be an official requirement of DID spec - some kinds of authentication methods, I'm fine with that... I'm also fine w/ keys. If we accept that primary use case is public keys, we don't have to have to spec out what's in DID spec, we could do that in a separate spec... how do you get a public key for a particular purpose? I need to get public key for DID doc, but I think we can do everything that Manu wants w/o stopping public key part of it as long as we accept that it's essentially a container. ✪
Pelle Brændgaard: If you want to do something w/ biometrics, by all means put it in "authentication", but we don't have to go into any details about that. ✪
Joe Andrieu: +1 To extensibility in light of the primary use today as public keys ✪
Pelle Brændgaard: For drummonds point - if there are two particular things that DID Document is good at we can standardize that, we don't need to dive into details on stuff like biometrics, but provide space for it... don't want that to stop us from getting public key stuff done. ✪
Drummond Reed: +1 To not limiting the DID document to just pubic key and service discovery. ✪
Sam Smith: This discussion is interesting, I'm having a hard time figuring out where to jump in. It's clear that there is a divide here, what I'm hearing is a desire for DID Documents to be a source of more than just minimalist metadata to bootstrap decentralized identifier. ✪
Sam Smith: I get the argument, for a little bit of extra work, we can add more functionality where we can't terminate because every little bit gets us more - but it adds to discussion wrt. are we doing it the right way. It's starting to get to where I don't know what the DID document is for. ✪
Sam Smith: I thought it was so we could bootstrap control over public/private key pair to DID... now we're talking about authenticating other data, not just the DID itself. I don't think that ends. Now we don't have to specify all those other use cases, every protocol for every other authentication mechanism. ✪
Sam Smith: Who controls the DID, who controls metadata, anything more than that is a lot of extra work. It's not necessary to bootstrap into all those things we need to do. Who owns the DID, how is that DID controlled, it's a service endpoint that's not essential to the DID Document. ✪
Drummond Reed: +1 To the scope of the DID document being what is "essential to a DID document" ✪
Nathan George: +1 To samsmith. If we can bootstrap with that much we can figure the rest out. ✪
Topic: DID Document Extensibility
Markus Sabadello: Not a cryptographer or biometrics, should DID document be primarily about public key discovery or support broader set of authentication material. I like extensibility, so would support what Manu's suggesting, have option for extensibility, if people want to publish that, we shouldn't prohibit that even if we increase correlation/reduce privacy (possibly) ✪
Markus Sabadello: Publishing public keys is main objective, we should not restrict it to it... may want to publish verifiable credentials in DID document, so why not biometric template. ✪
Manu Sporny: Wanted to underscore that everyone wants to do public key discovery. And Digital Bazaar is not suggesting in any way that it not important. [scribe assist by Drummond Reed] ✪
Manu Sporny: But at the same time we should not put off other authentication options. [scribe assist by Drummond Reed] ✪
Joe Andrieu: I need to run. Thanks. This is good work, folks. ✪
Manu Sporny: If we can say where other type of authentication material would go in the DID document, that would provide the extensibility that Markus spoke to. [scribe assist by Drummond Reed] ✪
Manu Sporny: So methods or applications that don't need other forms of authentication don't have to use them. [scribe assist by Drummond Reed] ✪
Manu Sporny: Would broaden "DID documents are about public key and service endpoint discovery" to "DID documents are about discovery, period". [scribe assist by Drummond Reed] ✪
Manu Sporny: That includes publication of all types of discovery info, potentially even public credentials. [scribe assist by Drummond Reed] ✪
Adrian Gropper: +1 To Manu : DID documents are about discovery ✪
Markus Sabadello: +1 To broader concept of discovery ✪
Manu Sporny: We would put biometric auth details out of scope for the DID spec itself, but leave a place for it. [scribe assist by Drummond Reed] ✪
Sam Smith: Authentication of what? Did owner or something else ✪
Drummond Reed: I think we're getting clarity around difference between DID Documents being around public key discovery and service endpoint discovery, and it being about discovery in general. ✪
Drummond Reed: You will have one architecture w/ the narrower scope and a different architecture with the broader one. ✪
Adrian Gropper: We can assume that institutions will index DID documents. ✪
Drummond Reed: If we could solve one and only one thing w/ DID documents, keys and service discovery - it's hard to argue against extensibility - one approach to take is extensibility - use JSON-LD? For thing that I'm claiming is essential, public key discovery, service discovery - here are data structures to do that. ✪
Drummond Reed: The third thing - here's how you do other forms of discovery - here are specific branches/vocabs for at least two other things, biometric authentication services, so we can say here's how you extend it - here's how you extend it. ✪
Drummond Reed: Any such extensions are out of scope - proposal, would love to get feedback on that. ✪
Markus Sabadello: That sounds good to me - how to describe key service endpoints - possible to extend that - w/ other branches. ✪
Pelle Brændgaard: I'm in agreement with Drummonds suggestions ✪
Markus Sabadello: If the data model is RDF/JSON-LD, you have open world assumption anyway - add attributes/predicates to that data model anyway. It doesn't make sense to have extensible graph model and then tell people they can't use the extensibility. ✪
Drummond Reed: +1 To Markus' point that if we have a specific extensibility model, we can all use it ✪
Nathan George: I was going to add - semantics of whether we call it key wrt. data linkages that comes from an external system - what do I have to check to see if its the actual person - practical interop of that is what I want to preserve. As long as we can preseve that, we're good. ✪
Nathan George: I want to make sure that if I get a DID, I can check to make sure who that is. ✪
Topic: Fundamental DID Architecture
Drummond Reed: This crystalizes the fundamental architecture of what we're after - it puts a solid stake in the ground to get to the extensibility model we want. If there is agreement about that, there could be branches of the DID Document that we are going to define. ✪
Drummond Reed: Here's what we're defining for bootstrap functionality - first we're defining how we're doing public key discovery - branch for doing that - and how you do service discovery. ✪
Drummond Reed: There is a difference in the emphasis in public key discovery - authentication being something you want to do, other thing that came up on the thread -- authentication and encryption - if you pay attention to one w/o the other, you're missing the point... keys are not just for authentication.... public key management, hope I'm not just carrying that perspective, that was the problem that public key crypto solved. ✪
Drummond Reed: So, if we can focus on architecture - public key discovery, then service discovery - if we want to go about it in that way - how do we get to a proposal on public key management piece - service endpoint piece, then have proposals on other two, spec and wrap text on it, finish this month. ✪
Manu Sporny: If we are agreed on an open world data model, then the spec is inherently extensible. That question has come up many times in terms of what is required in the spec, and the need for naive JSON support. [scribe assist by Drummond Reed] ✪
Manu Sporny: Would like to avoid the extensibility debate. [scribe assist by Drummond Reed] ✪
Manu Sporny: RE Drummond's proposal to standardize specific branches, Manu agrees that service discovery is one of the branches. [scribe assist by Drummond Reed] ✪
Manu Sporny: But the question of public key discovery is not clear. [scribe assist by Drummond Reed] ✪
Manu Sporny: If it about public key discovery, then it's about an array of keys. If it's about purposes like auth and encryption, then we have two different branches. [scribe assist by Drummond Reed] ✪
Manu Sporny: The concrete proposal that Manu is making is to pick apart the concrete proposals on the mailing list, and decide on the basis of that narrower scope how best to handle the problem. [scribe assist by Drummond Reed] ✪
Pelle Brændgaard: About extensibility - I don't think it has to be anything particularly complex - it's a data object, we specify for areas that we are standardizing, we have a type, purpose, this could be used for something that can be updated in the future, otherwise anything that you can put in the DID document, go a head. ✪
Pelle Brændgaard: If I want to go in and authenticate something from Sovrin, I can get public key data, I can get service endpoints, that's all we need. Put LinkedIn names, we're doing that already in proto DID, no need for specific formal bit on extensibility - put anything you want for your particular method, it can be JSOn-LD, if you don't want it use something else. ✪
Manu Sporny: Has a word of warning about "use anything for extensibility" [scribe assist by Drummond Reed] ✪
Pelle Brændgaard: The only point is that we don't need to worry about it right now. We can deal with that elsewhere ✪
Manu Sporny: The problem of semantic conflict is going to rear its head if we follow a "laisse faire" approach to extensibility. [scribe assist by Drummond Reed] ✪
Manu Sporny: This is the problem that RDF & JSON-LD solves. [scribe assist by Drummond Reed] ✪
Drummond Reed: Drummond is on the queue to talk about the previous discussion about support for naive JSON. ✪
Drummond Reed: I do agree that we want to specify the extensibility model clearly... want to point everyone back to a conversation at W3C TPAC - is it possible to specify the core branches are understandable to naieve JSON developers? ✪
Drummond Reed: To deal w/ that issue, simple DID Document parsers, we should adopt that same approach. ✪
Drummond Reed: I do agree w/ Manu's point - if we're going to talk about structure of branches, one thing we should do is -- service endpoint branch, let's get proposals up there, define that and close on it as quickly as it can. We have already identified that there are interactions w/ those endpoints and keys. ✪
Drummond Reed: Service endpoint may need to reference key. ✪
Drummond Reed: I think we're down to this question - is it key management first and auth/encrypt purposes, or is it organized by purpose? Keys in different branches of the graph? There is no a-priori argument - no pure logical argument you can make for those decisions. ✪
Drummond Reed: Let's use the list, any mechanism that we can to close these issues. ✪
Drummond Reed: We've made a fair amount of progress, will try to summarize to email list... ✪
Pelle Brændgaard: Sorry have to run to another meeting ✪
Manu Sporny: Sees a potential clear compromise between the two worldviews. It is for one group to set up a keys array, and other to set up an authentication and encryption branches. [scribe assist by Drummond Reed] ✪
Manu Sporny: The downside is that actually doing discovery is more complex for developers. [scribe assist by Drummond Reed] ✪
Manu Sporny: This may also have security vulnerabilities. [scribe assist by Drummond Reed] ✪
Manu Sporny: If all else fails, we could end up deciding on that. [scribe assist by Drummond Reed] ✪
Drummond Reed: Ok, with that, take discussion to mailing list then take rest of discussion to mailing list. ✪