You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: