Kaliya Young: Sure thanks so I just wanted to share again we've got the I’m working with New Logic in Thailand to produce the APAC digital identity unconference we just changed the venue but it's still happening and I think it's going to be really fantastic lots of interest from people around the region so if you have staff in the region or know. ✪

Kaliya Young: Folks working in the region that could. ✪

Kaliya Young: Connect up with the broader community that would be great to share it with them I'll put the link in the chat and also in mid-march I'm producing the thoughtful Biometrics Workshop to support uncommon conversations about this slightly controversial technology and would invite identity people who are interested in engaging in that conversation to join so I'll post both those links and of course as usual. ✪

Kaliya Young: IIW has registration open. ✪

Kaliya Young: Now April 18 to 20th in the Computer History Museum in Mountain View thank you. ✪

Kaliya Young: https://www.apacdigitalid.org/ ✪

Kaliya Young: https://www.thoughtfulbiometrics.org/ ✪

Kaliya Young: https://internetidentityworkshop.com/ ✪

Markus Sabadello: Can you hear me yes alright then I will try to show my screen. ✪

Markus Sabadello: Is that working. ✪

Markus Sabadello: It's okay fantastic so yeah thanks Harrison thanks for the for the invitation I'm Markus I'm one of the co-editors of the did core specification and the did resolution specification which I can talk about a little bit now how long should this Harrison how much how much time should I. ✪

Markus Sabadello: Okay so I try to have prepared this in a way where I'm not not starting from scratch right so not not going to explain all the foundations of dids and did documents I assume everybody knows most of that everybody probably knows that did resolution is the process of taking a did and getting the did document associated with the dids so I’m not going to explain all of this in. ✪

Markus Sabadello: Detail but I thought I'm going to start with just ✪

Markus Sabadello: Some some motivation to remind ourselves how how important and how fundamental did solution really is because it happens essentially all the time right if we do anything with verifiabler credentials or chapi or didcomm or open id connect it's always did resolution there's always a need to discover the did document to discover metadata about the subject that's identified. ✪

Markus Sabadello: By the dids so here are some common examples that. ✪

Markus Sabadello: Probably everyone here is familiar with but just as some inspiration in them in a verifiable credential if we want to verify the proof of a verifiable credential we need to resolve the issue did to look up the issue as public key if we perform some kind of did auth flow did auth interaction whether it's based on chapi or didcomm or open id connect there is always some kind of challenge response pattern and. ✪

Markus Sabadello: There's some kind of signature signed by someone who's identified by a did. ✪

Markus Sabadello: So I can we need to resolve the did and of course we also need to resolve dids for discovering somebody's didcomm end point or decentralized web node or some other kind of service it's a really very fundamental function and because of that there are also a lot of implementations out there right this is just a very small subset of implementations that somehow implement the did resolution. ✪

Markus Sabadello: Process there's the dif. ✪

Markus Sabadello: Universal resolver which is a resolver that can be run as a service and then there are several libraries veramo did kit Hyperledger Aries typescript resolve so there are resolvers implementations of did resolution they come in different forms and different languages and sometimes they are Standalone components and sometimes did resolution is built into something else so there's a lot of. ✪

Markus Sabadello: Variety and quite a lot of implenmentations. ✪

Markus Sabadello: Because dids and did resolution are so fundamental to other things how is this defined right now so how do we know how did resolution works and the answer is there's a little bit of content in the did core specification which as we know as a w3c recommendation it has an entire section about resolution. ✪

Markus Sabadello: And it also has a. ✪

Markus Sabadello: Section about the the identifier of course which talks a little bit about did parameters so these are some things that we have in the did core specification that have to do with with did resolution there's a definition of some functions resolve function resource representation the referencing functions and these functions specify what is the input and what is the output. ✪

Markus Sabadello: So for example. ✪

Markus Sabadello: If we resolve a did then there's really the did as one input and resolution options as another input and then as an output we get the did document but then we also get two types of metadata did resolution metadata did document metadata and some of that is also defined in in did core already so this is already a standard it defines some resolution option called accept. ✪

Markus Sabadello: It defines some. ✪

Markus Sabadello: Resolution metadata called content type and error and some did document metadata about the did document when was it created when was it updated and and so on and then as I said there is also some did parameters did parameters are part of a did URL if we have a not just the did but a did URL with a path and the query string and and fragment. ✪

Markus Sabadello: And did core also defines. ✪

Markus Sabadello: Defines the syntax of that and then defines some of these did paramters. ✪

Markus Sabadello: Now what. ✪

Markus Sabadello: Did core did core standards doesn't Define it doesn't actually Define how this is really implemented in did core these things are related to did resolution or defined in an abstract way they are abstract interfaces with some abstract data structures but the did core specification doesn't Define for example a concrete algorithm if we look at this example. ✪

Markus Sabadello: Here it says did:ex:1234. ✪

Markus Sabadello: And then there's a parameter called service then did core defines that there is this parameter called service and it defines a little bit what it means but did core doesn't Define how you actually the reference this if you reference is what exactly happens what exactly is the is the output and also here for example if we have a fragment so that's missing in did core. ✪

Markus Sabadello: Another thing that's missing is. ✪

Markus Sabadello: Concrete representations or data formats for the did resolution results and the did URL dereferencing results with all this metadata right in did core we we specify representations and how to express a did document but we don't really Define a data format or representation or serialization of these other things that the metadata so this is also just mentioned in an in an abstract way but. ✪

Markus Sabadello: Not is not really defined how. ✪

Markus Sabadello: How to implement it or what that looks like then what's also not in in did core is some how you can invoke a resolver how you can call a resolver so it doesn't Define a binding over HTTP or over did comm over some other protocol that's because did resolution is an is an abstract function right it's not one it's not one single protocol as we have it in DNS. ✪

Markus Sabadello: For example in DNS. ✪

Markus Sabadello: There are DNS servers and their clients and there's a well-defined client-server protocol and did resolution is different because it's an abstract function and did core doesn't actually Define how you can invoke or how you can call a resolver so some of these things are. ✪

Markus Sabadello: Being addressed or. ✪

Markus Sabadello: We have been trying to fill in some of these missing pieces some of these missing links in did resolution specification which is a draft Community draft document it’s a work item in CCG it's not a final specification but it's trying to to add some of these missing missing pieces for example that if it tries to Define more concrete algorithms so if you. ✪

Markus Sabadello: Resolve a did if you dereference. ✪

Markus Sabadello: A did URL then what exactly happens and here just some some examples from from a some exemplary pieces of of those algorithms for example here it says determine if the did method of the input did is supported by the did resolver and if not the data resolver must return the following result so you can see here that. ✪

Markus Sabadello: The fact that there is did resolution metadata and did document and did document metadata that's already in did core and this error property that's also defined in did core and the meaning of these things is also defined in did core but did core doesn't actually you know provide an a concrete instructions what happens when right if then else if the input is in a certain way then there is all about. ✪

Markus Sabadello: A dereferencer should behave in a ✪

Markus Sabadello: Certain way and produce a certain output here’s another example if the did URL contains a parameter called service and the and maybe a parameter called relative ref then the fact that these parameters exist and what they mean that is in did core but did core doesn't tell us how to actually process them and what the concrete outcome is if you dereference them and some other things like what happens if you have fragments. ✪

Markus Sabadello: And and what errors are returned. ✪

Markus Sabadello: And so on so did resolution is trying to fill in these more concrete algorithms and instructions it also defines data format of the entire did resolution result and did URL dereferencing results so in did core we only Define representations of the did document but the other things did resolution metadata did document metadata. ✪

Markus Sabadello: In did core only defines. ✪

Markus Sabadello: In an abstract in an abstract way but it doesn't Define how you can represent the whole thing in Json or json-ld I mean it's kind of obvious right if you if you look at it it seems very straightforward and obvious anyway but still it's probably something that should be explicitly defined. ✪

Markus Sabadello: Another thing that's in did resolution specification is an HTTP binding or HTTPS binding how can you call a resolver if that resolver is exposed as an as an HTTP endpoint. ✪

Markus Sabadello: And here again it’s important to point out that that this is not like DNS right where did resolution doesn't have to happen by calling a remote service right so sometimes sometimes people look at the Universal resolver for example that's that's a relatively well-known project but this Universal resolver project at DIF is run as a service as a remote endpoint. ✪

Markus Sabadello: And if you can call over an HTTP. ✪

Markus Sabadello: Binding but it's important to point out that did resolution is this is just one way how did resolution can work right did resolution can also just be an entirely local process where you don't have to rely on any external service but still in some cases it can be useful to have a binding or in this case an HTTP interface to a. ✪

Markus Sabadello: Resolver and that's also one thing that. ✪

Markus Sabadello: We've been working on in the did resolution specification you can see some some examples here it's it looks relatively straightforward you basically it basically says that you can execute HTTP get request and you're passing the did and then you get back the did resolution result the did document plus the metadata and. ✪

Markus Sabadello: The headers. ✪

Markus Sabadello: Play a certain role so you can use HTTP headers and you can also pass additional parameters over the over HTTP in the in the URL and and and this binding tries to map that basically tries to map this http. ✪

Markus Sabadello: API to the abstract resolution and de-referencing functions that are in the did core specification and even though this looks relatively simple there are some there are some details that are not so straightforward so for example in in did core there is a difference between resolving a did and dereferencing a did URLl. ✪

Markus Sabadello: And one question is. ✪

Markus Sabadello: If over HTTP if these two functions should be if those two functions can be exposed at a single HTTP endpoint or if you maybe want two different HTTP endpoints one for resolving and one for dereferencing and how exactly do you pass the resolution options how exactly do you get back the the metadata to you map do you map the. ✪

Markus Sabadello: Options that you have on the did resoluatoin. ✪

Markus Sabadello: Level do you map those to http headers or do you just send them in an HTTP body so there's some some details that are. ✪

Markus Sabadello: Not as straightforward as it as it seems but anyway this is also one of the things that we've been trying to work on in did resolution specification one more thing there's some sections a little bit of content about architecture so again keeping in mind that did resolution implementations come in different forms sometimes did resolution is just a local library. ✪

Markus Sabadello: Sometimes it's a remote service sometimes you have a hybrid architectures where maybe you're running a did resolve locally and it can resolve certain did methods locally but if you can use a remote resolver as a fallback for did methods that you cannot resolve locally and then there are always a lot of questions about how you can trust the resolver and how. ✪

Markus Sabadello: How a client can verify if you get back the. ✪

Markus Sabadello: Correct result so there's a section also that tries to discuss some of these some of these architectural or or the topology how do different local and remote components. ✪

Markus Sabadello: Talk to each other. ✪

Markus Sabadello: And I don't know should I just keep going or are there any any questions so far. ✪

Markus Sabadello: Okay so so this so far has been on overview of what's in the different specifications did core and did resolution how does how those can relate and complement each other and now I have a few slides about since this is called the current state of did resolution I have a few slides about some interesting topics that we've seen in the last few weeks. ✪

Markus Sabadello: And last few months. ✪

Markus Sabadello: What we are learning about did resolution or what people in the community have been have been doing with with these did resolution interfaces and so for example we've seen a lot of extensions a lot of new ideas for resolution options for did parameters for metadata properties and error codes. ✪

Markus Sabadello: And here's a list of some of these extensions that there are not in did core and not in the did resolutions specification but that have been defined Elsewhere for example the parameter called initial state where you can pass on information to a resolver about the initial content of the did document there is a parameter called. ✪

Markus Sabadello: Transform keys where you can. ✪

Markus Sabadello: Instruct the resolver to convert the public key representations in the did document let's say between an ed25519 verification key 2018 you could convert it to a ed25549 verification key 2020 or to an adjacent web key so this is a something that a resolver could could perform if it supports. ✪

Markus Sabadello: Some of these extensions. ✪

Markus Sabadello: A few new error codes have been proposed method not supported that's not in did core but it seems useful for a resolver to to indicate if it doesn't support a certain method now internal error not allowed method not allowed verification type invalid public key so I've seen several proposals and and developments where a did resolver could be considered a. ✪

Markus Sabadello: Point of where policies can be enforced and where some kind of validation can happen how you could configure did resolver in a way that it enforces certain policies where it can accept or reject certain requests or certain things or certain did methods depending on depending on policies of depending on properties of those dids and did methods you could. ✪

Markus Sabadello: For example automatically. ✪

Markus Sabadello: Return an error if a weak public key is detected in the did document right so the resolver could result the did and then it could check all the public keys in the did document and if those are considered weak or if a duplicate key has been detected it could be considered an error or a warning or a did resolver could automatically validate. ✪

Markus Sabadello: If the did document. ✪

Markus Sabadello: Conforms to the specification and if it's if it's missing something there or if JSON LD context is missing or if an ID value is invalid and then the resolver could also indicate that performs some some validation. ✪

Markus Sabadello: Yes that's the that has to do with with this section here did resolution architectures there there is a section about this in the did solution specification maybe looking at that that last diagram here where you have a client the client calls a local resolver using some library and then that local resolver maybe calls a remote resolver over an HTTP binding. ✪

Markus Sabadello: And then how can the. ✪

Markus Sabadello: Client be sure that that the resolver returns the correct data and they're really at least two sub-questions or subtopics that the first topic is does the resolver actually retrieve the correct did document according to the did method the second question is does the did resolver actually return that same did document or does the did resolver manipulate the did documents what the different. ✪

Markus Sabadello: Threat models and different attacks. ✪

Markus Sabadello: That can be considered what you mentioned that the did resolver could sign the the result and return that to the client that's one something that can certainly be done but that is also mentioned in the in the specification but it's always important to be aware of what does that protect from and what does it not protect from right so if the did resolver signs the result then. ✪

Markus Sabadello: It doesn't solve. ✪

Markus Sabadello: The problem of a potentially malicious did resolver right so you that maybe prevent some man in the middle attack or something like that where a client could verify that the resolution result has been signed by the resolved and it hasn't been manipulated since then but your but that doesn't really solve the problem of is it really the right did document for the for the did right so that's a separate question and there are some considerations about. ✪

Markus Sabadello: That as well you could query multiple resolvers and. ✪

Markus Sabadello: Compare the results or you could include in the did resolution metadata you could include some State proofs or some kind of method specific proof information which then the client could independently verify but that that's what this section is for to discuss and consider some of these topics that come with different resolution architectures. ✪

Markus Sabadello: Yes that that is certainly possible the resolves can sign the result and then the client knows or can verify that the result indeed comes from that from that resolver but it doesn't solve the issue of of a compromised resolver if the resolver itself is compromised then it could return a bad did document and sign the bad did document and then the client knows that that the result comes indeed. ✪

Markus Sabadello: From that resolver but the client still doesn't know if it's been. ✪

Markus Sabadello: If the resolve itself is compromised or or not. ✪

Dmitri Zagidulin: Markus do you mind if I jump in and add a comment. ✪

Dmitri Zagidulin: I think the Sandy helpful thing to think about with regards to resolver is that it is you must always consider a trusted back-end architecture so your concern is correct but I think you're thinking of the resolver more as an external as an external component it is regardless of how its deployed it is very much an internal trusted component so you have. ✪

Dmitri Zagidulin: To use the same. ✪

Dmitri Zagidulin: Techniques that you usually use to secure other trust that internal microservices whether it's just IP filtering whether you’re adding like OAuth2 authentication HTTP signatures all of those techniques go but it is definitely a trusted component thanks. ✪

Dmitri Zagidulin: Yeah exactly exactly. ✪

Markus Sabadello: Right so that the best scenario is probably where you where the resolver is just a local library right so where it's not even an a remote service that's that's probably best also from a perspective of decentralization if the resolver is up running locally and second best is probably if the if you use a remote resolver that that you control or that that yourself hosting. ✪

Markus Sabadello: And relying on a third party resolver. ✪

Markus Sabadello: Of course comes with some security and Trust risks but. ✪

Markus Sabadello: Yep good input thank you last comment I will make just about these architectures is that like I said we think of remote resolver with an HTTP interface just as one possible way how you how resolution Works ideally resolution is just a local process but there can also be other protocols and other binding so for example. ✪

Markus Sabadello: We've also. ✪

Markus Sabadello: Specified at didcomm binding so you can also call a resolver over did comm then you have all the security and Trust benefits that you have maybe in in did comm including mutually authenticated communication based on dids themselves so you can use that also for communicating between resolvers okay but the point that I wanted to make here on this slide is just some some. ✪

Markus Sabadello: Innovation that that we’ve been. ✪

Markus Sabadello: Seeing recently on in terms of new parameters options error codes functionality that a resolver can perform we’ve already heard today about this recent proposal by checked and some others I think that was also discussed on the ccg call recently about the linked resources specification with some proposed did parameters. ✪

Markus Sabadello: That can be included in a did URL in this case to to identify a schema a resource with a certain name and type and so this is also did URL dereferencing right so did resolution and did URL dereferencing are really extensible mechanisms. ✪

Markus Sabadello: That can have where new functionality and new potential behavior and outputs can be can be added and the trick or the ambition of the did resolution specification is to provide some framework or some generic algorithm that is pluggable and extensible where anyone can any use case or any did method. ✪

Markus Sabadello: Or any application. ✪

Markus Sabadello: Can come up with their own ways of using did URLs right so that we can add new functionality here's another example we see in the work that's happening on decentralized web nodes this is especially interesting I think because here's an example of a did URL where one of the did parameters service is already defined in did core whereas this one is an. ✪

Markus Sabadello: Extension that as far as I know. ✪

Markus Sabadello: Is defined by a decentralized web modes and so service is a parameter that selects the service endpoint from the did document and clear resistant something that's applied to the decentralized web node that you find at that service so here's an interesting way of using did URLs where part of the dereferencing logic involves that the did document. ✪

Markus Sabadello: And another part of the logic involves the. ✪

Markus Sabadello: Service that you select from the did document it's also interesting to mention that some of these parameters some of the dereferencing logic tends to be did method specific it only works with some did methods and whereas some of these parameters are did method independent that work with all did methods so there's a lot of logic and interesting functionality. ✪

Markus Sabadello: That can be done. ✪

Markus Sabadello: Here's some more examples of. ✪

Markus Sabadello: Some recent developments in in the area of did resolution some did methods did:keri and did:self and version 2 of the did:ebsi. ✪

Markus Sabadello: What all of them have in common is that it's not so easy to resolve the did unless you have some additional information so for example this did:self or did:ebsi version 2 in this case the method specific identifier is a JW key jwk thumbprint so that means you cannot resolve this to a did document unless you already. ✪

Markus Sabadello: Have the did document and some other information. ✪

Markus Sabadello: We've been discussing this on different calls and different communities because this this feels really strange right we are used to we're used to the idea that if we have a did we can immediately resolve it we just go to to a web server or to a block chain or to some API and we we retrieve the did document for the did whereas here the dids require some additional information so you. ✪

Markus Sabadello: Basically already need the did document in. ✪

Markus Sabadello: Order to be able to resolve the did document that sounds really strange but I think it it actually fits into the framework I think it's totally legitimate to do these things it just means that when you call the resolver you have to pass the did plus additional resolution options right and that's then depends on the did method but it still fits into the overall overall framework of dids and. ✪

Markus Sabadello: The same is true for did:keri. ✪

Markus Sabadello: So keri is getting something that's getting a lot of attention to key event receipt infrastructure a new innovative way of managing keys and and in this in this technology you have an identifier and there's also not immediately immediately a way to resolve it you need you typically need something. ✪

Markus Sabadello: Called an oobi. ✪

Markus Sabadello: And introduction which lets you discover Witnesses and Watchers I'm not an expert on keri but but also here the identifier is not enough and so you need to Define some additional parameters and additional options in order to be able to resolve it so I think this is also quite. ✪

Markus Sabadello: Interesting to have the new ways of innovative did methods. ✪

Markus Sabadello: And I'm almost done here is the third slide that yes as we work on did resolution we are encountering again some maybe not so not so easy topics from that we already had in the did working groups on uncertainties unanswered questions maybe around different representations and media types there. ✪

Markus Sabadello: Was a. ✪

Markus Sabadello: Github issue where a media type of Manu opened a I think about on the did core specification about how to handle media types for example in the in the did Web method so what we're seeing here is. ✪

Markus Sabadello: If you resolve a did. ✪

Markus Sabadello: Web identifier then typically the resolution process looks like this where you retrieve a. ✪

Markus Sabadello: Document called did.json over HTTP and then in many cases this will be on the HTTP level this will be returned as application/json but it includes @ context sorry this is wrong this @ context is wrong this should actually be the standard the standard did core context but anyway you get back a did document in json-ld form with an. ✪

Markus Sabadello: Application/json header but then this is not. ✪

Markus Sabadello: Really one of the media types defined in the did core specification which defines these media types so there's a. ✪

Markus Sabadello: Little challenge here I wonder if maybe the did resolution work can make some of these easier but but anyway also something to be. ✪

Markus Sabadello: Aware of and then last slide so what's now the current state of this did resolution as I said it’s a work item in the ccg it's a draft Community report like I said it covers some algorithm some data format some extensions some architectural considerations it is definitely. ✪

Markus Sabadello: Not done so. ✪

Markus Sabadello: It needs more work it probably some things need to be added some things need to be fixed there are 45 open issues. ✪

Markus Sabadello: There is also the test Suite so we contributed that a few months ago a did resolution test Suite which is different from the did test Suite right so there's a did test suite that test the did core specification and the idea of the did resolution test Suite is to test the did resolutions specification there is some overlap but it's really. ✪

Markus Sabadello: A little bit different with this you can. ✪

Markus Sabadello: Test a resolver endpoint and see if it behaves correctly. ✪

Markus Sabadello: Yeah just that the last thing this is really the last thing how there is now a proposed Charter for the next did working group and that says that the working group will begin working toward a specification for did resolution and did URL dereferencing so that's a place where this work can hopefully continue. ✪

Markus Sabadello: That's it thank you and yes more questions. ✪

Ryan Grant: Hi Markus thank you very much I have a question it seems there are different requirements for different resolver deployment architectures so how could the did resolution specification prioritize between on the one hand Clarity of specification for a simple architecture as may be required to move the did working group past a privately threatened formal objection versus convenience features. ✪

Ryan Grant: For certain network reliant architectures. ✪

Markus Sabadello: I think I don't think the did resolution specification should have a lot of requirements that depend on on the architecture I think everything that it. ✪

Markus Sabadello: It says and mentions about for example the algorithm how are how is the did URL processed when there are certain error codes returned how is the metadata being used I don't think this has much to do with the architecture doesn't make much of a difference if it's an entirely local resolver or it's a remote resolver there is a section about these architectures. ✪

Markus Sabadello: The did resolution specification but those sections ✪

Markus Sabadello: Don't really change the behavior or the algorithms or their requirements of how how did resolution really works it just adds on security considerations and Architectural considerations and it's not finished right so if you actually look at the document you will see a lot of open open issues and and ideas that still have to be. ✪

Markus Sabadello: Completed but I'm. ✪

Markus Sabadello: Not sure exactly what you mean about preventing formal objections too can you specify. ✪

Ryan Grant: Sure I think one of the ways that the did working group could could move forward as discussed at TPAC would be to focus on did resolution and the threatened formal objection that I referred to was the prior formal objections and and that they would be repeated if there was not a did method chosen but. ✪

Ryan Grant: There is not consensus on choosing a did method so I was asking what kind of the minimal set of. ✪

Ryan Grant: Of clarity of specification would be in for instance does does did resolution spec need to choose an example architecture that it answers certain questions for in order to dissolve the formal objections. ✪

Markus Sabadello: Well first first I don't think the did resolution specification should mention any specific did method so I know that there is a ongoing discussion whether or not a new did working group should standardized did methods and if yes which ones or no did Methods at all I consider that completely separate and independent from the did resolution specification the did resolution specification should. ✪

Markus Sabadello: Not mention any specific did method. ✪

Markus Sabadello: It should also not do anything or make any assumptions that would favor certain did methods or certain did method architectures when when I mentioned architectures here I meant not architectures of the did methods so it's not about did web versus a did key versus blockchain based. ✪

Markus Sabadello: Did method this is more. ✪

Markus Sabadello: About the architecture of the of the resolver right is the resolver hosted locally is the resolver hosted at an HTTP endpoint but this has nothing to do with with how the did method works and I think they should be completely neutral and not not do anything that that favors or makes any assumptions about how the did method itself works. ✪

Ryan Grant: If I could just tag on to perhaps clear up any misunderstanding I wasn't trying to bring that into into this specification the direction of my question was that this specification could become more important as one way to dissolve the roadblock in the did working group in a way that also. ✪

Ryan Grant: Satisfies other concerns about. ✪

Ryan Grant: Not picking did method winners and losers so if this did resolution specification was becoming more important then my question would be is it helpful to to pick a deployment architecture as an example implementation so that people who would otherwise formally object such as a prior formal. ✪

Ryan Grant: Objectors. ✪

Ryan Grant: See that it is clear what packets need to be sent over the wire to or not over the wire if we choose a different deployment architecture in order to fully. ✪

Ryan Grant: Result get a resolution from a did that’s all. ✪

Markus Sabadello: Yes I mean I think this is something that the specification could could discuss something that has a little bit of that already here in this section it does mention and illustrate with with diagram certain deployment architectures if you want then try to discuss a little bit what are the risks and potential threats of certain architecture so to. ✪

Markus Sabadello: I don't know maybe a maybe I can take the universal resolver as an example if you go to uniresolver.io that's a relatively well-known service in the community and a lot of people use that but you should not use that except for experimentation maybe because it is a. ✪

Markus Sabadello: Third party hosted. ✪

Markus Sabadello: Service that could be unreliable that could manipulate the results and so this kind of thing this this I think would be would be in scope to to discuss and describe a little bit these different architectures is is that what you mean or. ✪

Ryan Grant: Yeah I'm just asking questions about what this this specification could do to prioritize in a way that would make it a viable answer for for finishing it in the did working group and as as the current did working group charter specifies the proposed charter. ✪

David Chadwick: Yeah, well actually, I won’t be here next week. I’m traveling. But basically there is a draft and all we’re wanting to do is to standardize what the type would be. Because as you know, the verifiable credential allows any evidence to be specified of any type, and so we’d just like to standarize one type, which refers to the Open ID Foundation’s existing draft specification on identity assurance. So they’ve actually, there’s been a working group working for a year or more on how do you assure identity and what evidence do you need to assure identity? So we’ve got a whole standard on this and we’d what like to do it import it into verifiable credential by saying if you have this particular type of evidence, then it means you’re using the Open IDF standard for evidence. That’s essentially it, the new work item. ✪

David Chadwick: Yeah, what really interesting that came out of it actually is that when presenting evidence, they’re actually presenting a whole raft of evidence. So if you consider somebody’s name, their evidence might be “I took the name David Jones from the passport, and I took the name David Jones Smith from their driving license” and now you’ll see that you’ve got different evidence with different names because over time, someone might have changed their name or by deep pull or whatever. And so, there are two things that come out here - one is the evidence value, the evidence value is presented then not by the same as the actual value in the verifiable credential because of changes to them, and the second thing is that the evidence is somehow duplicating information in the verifiable credential such that if you were to do selective disclosure of the verifiable credential, but not selective disclosure of the evidence, you may actually be revealing evidence, information that you didn’t want to reveal in the selective disclosure. So that’s a really interesting thorny problem to discuss. ✪