3C/ Standard Interfaces for DID Create/Update/Deactivate
Standard Interfaces for DID Create/Update/Deactivate
Tuesday 3C
Convener: Markus Sabadello
Notes-taker(s): Jovan Shandro
Tags for the session - technology discussed/ideas considered:
DID, specification, DID operations
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
There is an attempt to specify abstract interfaces if you want to Create/Update/Deactivate a did that could be implemented for all did methods.
The idea of this specification is to provide a standard with the same assumptions as with resolution. It should be in an abstract level, meaning it should specify the inputs and outputs of creating/updating/deactivating a did but not how it should be implemented.
There are many differences on how the operations of different did methods work, so it is still a question whether this standard will work for all did methods at the current state.
Two greatest architectural questions that have come in the way:
How should key management be handled: where are keys created, how are they handled etc?
The concept of internal state or longer running jobs
Regarding key management, in the current early draft there is a section which describes 3 possible way to handle key management:
Internal secret mode: The service itself generates keys and either stores them or returns them to the client. The disadvantage is that the service has to be highly trusted. This mode could make sense if you run the service yourself.
External secret mode: Key management is handled by some kind of externally hosted wallet that the service can call (e.g hardware wallet).
Client-managed secret mode: The client that makes use of the registrar service would first create the keys and then call the different functions of the service. This would mean back and forth communication between server and client (e.g server sends sign request, client signs etc.).
Regarding the internal state concept, write operations could sometimes take some states to complete, so there could be an internal state machine keeping track of the states until the operation is complete e.g when you say you want to create a did, the create method might not directly return the did, but there might be multiple steps and a bit of back and forth communication between client and registrar and the client will need to take some more action.
The next step would be to see if the current specification is generic enough (can it be applied to all did methods).
Regarding future changes: It is sure that one such generic specification will be able to work for all did methods, the question is if it is too generic, then is it useful?
Links:
