3 ms·
that explains a lot but also how would this even work? every solution that relies on generic did s would have to implement all supported methods? or is every me
by jFriedensreich 5y ago
that explains a lot but also how would this even work? every solution that relies on generic did s would have to implement all supported methods? or is every method an incompatible namespace in which case what is even the point of did? i really don't get it...
- dwaite 5y agoTL;DR it remains to be seen if DIDs create more problems than they solve. I think you got it correctly. "DID" is basically a qualifier for identifiers which can have metadata resolved about them using 'some mechanism', and there are 100+ mechanisms (DID methods). These all have varying technical and non-technical differentiating factors, partially described in the DID Rubrick https://w3c.github.io/did-rubric/ https://w3c.github.io/did-rubric/ . DID methods will not have consistent features nor will the metadata resolved by them consistently meet your data requirements, so you will be limited both in terms of methods you can accept for your use case, and DIDs you can accept within that. One if the base ideas is that it puts users in control of their identity by "owning" a DID, presumably with a lot of local software assistance. This is likely not a single DID, both for interoperability and privacy reasons. It is also likely the DID will be "controlled" by others in some cases - e.g. if a employer or bank accepts DIDs as an authentication system, they will want to be able to guarantee the authentication meets their standards/regulatory requirements.