peacekeeper
commented
2 years ago Good idea.. I agree getting this supported by Browser APIs would be a good thing. The idea is that this spec basically follows the same approach as DID Resolution, where we define abstract interfaces with inputs and outputs that can be implemented by local SDKs, or browser APIs, or an HTTP(S) binding or DIDComm binding etc. Of course a "local" implementation is always preferable over a "remote" one.
There can also be hybrid architectures, similar to DID Resolution, where e.g. a brower implements 1-2 common DID methods (like did:key), but is also able to connect to a remote Universal Registrar service for more exotic DID methods that it doesn't support natively.
Regarding "addMethodDriver", that definitely makes sense. I'm not sure if that would belong directly into this specification, or into something bigger. E.g. we recently had some discussion about specifying a "community browser extension and abstract wallet architecture" (see https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md#meeting---31-january-2022---1400-et-recording), where various extensions including support for additional DID methods could be plugged in.
Thinking about where I see this going, I think one of the clear places I could see this getting implemented would be as a Browser API since DIDs have been standardized at W3C. However, one thing that's certain is that browser vendors won't want to support every did method under the sun so I'm thinking it would be useful for us to define a method to polyfill a method into the browser so that the standard interface APIs could be used by them. Then browser vendors would only need to implement 1 or 2 did methods by default with the additional option that a new method can be added into the browser very easily while also converging their usage in a meaninful way like this spec does.
What's your thoughts on adding a addMethodDriver operation in a way that would allow for the create API to call those methods using the polyfill?