Open frankhinek opened 5 months ago
Output from the call today:
BearerDid
BearerDid
BearerDid
includes a function getSigner
that returns an object/instance with sign()
and verify()
methods that can be used to sign messages, credentials, or arbitrary data. The object/instance returns also has algorithm
and keyId
properties that are needed for header properties when creating JWS and JWE. By default, if getSigner
is called with no arguments it uses the first verification method found in the DID Document's assertionMethod
property. It can optionally be called with a methodId
argument to select a specific verification method from the DID document.{
uri: "did:method:123",
document: {}, // DID Document
metadata: {
published: boolean
// method specific properties
},
// Instance of `KeyManager` that holds keys for the DID
keyManager,
// Returns a Signer with `sign()` and `verify()` methods and `algorithm` and `keyId` properties
getSigner: (params?: { methodId?: string }) => Signer;
// Returns a `PortableDid` with the properties described above.
export: () => PortableDid;
}
PortableDid
{
uri: "did:method:123",
document: {}, // DID Document
metadata: {
published: boolean
// method specific properties
}
// Optional and would be empty if `AwsKeyManager` since keys can't be exported
privateKeys: [{...jwk}]
}
Delete / eliminate the DID method fromKeyManager()
. It was introduced to solve an issue for a PFI partner that is now better solved by import()
.
Delete / eliminate the DID method specific functions toKeys
or toPortableDid
. It has been replaced by the export()
function on the BearerDid
instance.
Rename load()
/ fromKeys
/ fromPortableDid
to DidMethod.import()
import()
must optionally accept a key manager (e.g., AwsKeyManager
or LocalKeyManager
)
just Did
= the string and has Did.parse()
Any thoughts on calling fromPortableDid
and toPortableDid
importBearerDid
and export
respectively?
Thought it might make sense given that it is a port able did! No biggie if not. Just staring at did.BearerDIDFromPortableDID
and/or did<method>.BearerDIDFromPortableDID
and thinking "damn.. that's a long function name"
While they are verbose, I do appreciate the symmetry of fromPortableDid()
and toPortableDid()
to make it clear that these methods are involved in converting back and forth between PortableDid
.
Something about importBearerDid
and export
makes it less clear that the two complement each other. It also exposes the developer to having to understand what a BearerDid
is right away, which is also true of toPortableDid()
/fromPortableDid()
.
IMHO importBearerDid
reads as "importing a BearerDid" -- but then a developer must provide a PortableDid
as input, which might be slightly confusing for some.
If you do want to change, what about:
Did<method>.import()
: Function that is DID-method specific and transforms a PortableDid
to a BearerDid
:
KeyManager
OR if no KeyManager
is given, instantiating a new LocalKeyManager
and importing the private keysdid.export()
: A BearerDid
instance/object function that transforms a BearerDid
to a PortableDid
:
PortableDid
object can be imported by the DID method's import()
function either using the same SDK or an SDK implemented in a different languageThese two methods enable the round-trip conversion of DID types, ensuring that DID material & metadata can be transformed between runtime and portable formats, thereby enabling interoperability between the various Web5 SDKs.
If the method is DidJwk.import()
and did.export()
it ought to be pretty obvious what's being exported and imported. If we wanted to be a bit more verbose we could make that DidJwk.importDid()
and did.exportDid()
but not sure if thats necessary.
All that being said...
It seems regardless of the language that it should be did<method>.fromPortableDID()
or did<method>.import()
rather than trying to attach BearerDIDFromPortableDID()
to a generic BearerDID
or DID
.
Context
The W3C DID Core specification contains guidance for the data structure to be returned by the
resolve
anddereference
functions:Additionally, there draft community report that a new W3C WG is being started to finalize:
No such guidance exists for other DID registration operations such as
create
,update
, anddeactivate
. The closest is a draft DIF spec that one of the W3C DID Core editors started:Current State of SDKs
At present, the shape of result returned by
create
implementations vary widely by SDK:It is expected and a positive that each SDK takes a slightly different approach to implementation due to idiomatic differences. However, it would be beneficial to have some general consistency on what is returned when a new DID is created, and for those DID methods that support it, updated or deactivated.
Proposal for
Did
object returned bycreate()
orupdate()
Proposal for
DidMethod.create()
DidMethod.create()
a local key manager that stores keys in-memory will be used for key generation using a default algorithm (e.g.,Ed25519
)verificationMethods
that specify additional verification methods to add to the DID document.services
which will be an array ofDidService
objects.Did
object or instance (depending on the SDK) that hasuri
,didDocument
,keyManager
, andmetadata
properties along with a convenience functiongetSigner()
that returns a signer that cansign()
andverify()
arbitrary data.Pseudo type definition for simple methods like DID JWK:
Type definition for a more complex method like DID DHT:
DidMethod.fromKeys()
Did
object ascreate()
.DidMethod.fromKeyManager()
keyManager
.DidMethod.toKeys()
After either
create()
orfromKeys()
returns aDid
object/instance, a developer can transform (or "export") the DID back to aPortableDid
.