Conversation
| } | ||
|
|
||
| export interface DIDResolver { | ||
| resolveDID?: (did: UCAN.DID) => Await<Result<DIDKey, DIDResolutionError>> |
There was a problem hiding this comment.
For the long term, I bristle a bit seeing the only thing that a UCAN.DID can resolve to is a single DIDKey.
What if we had
resolveDID<DidMethod>?: (did: UCAN.DID<DidMethod>) => Await<Result<DIDResolution<DidMethod>, DIDResolutionError>>
and
type SingleKeypairDidDocument<ID extends UCAN.DID> = {
id: ID,
/** https://www.w3.org/TR/did-core/#also-known-as */
alsoKnownAs: DIDKey
}
type DidResolution<ID> =
| KeyAliasDidDocument<ID>
I like that return type because it's a subset of actual did doc type
There was a problem hiding this comment.
alternatively could have resolveDID -> resolveDIDKey.
I like that it gets nowhere near 'did resolution' nor reinforces the (IMO footgun) assumption that a DID will always cleanly resolve to a single default keypair.
There was a problem hiding this comment.
some more on did resolution result https://w3c-ccg.github.io/did-resolution/#did-resolution-result
There was a problem hiding this comment.
There was a problem hiding this comment.
You are right resolveDID is misleading name, this is not a function to resolve a DID document but rather to resolve a key. I'll rename both interface and a function.
| describe('signing principal', () => { | ||
| const { Signer } = Lib | ||
|
|
||
| /** @type {Lib.Signer.EdSigner} */ |
There was a problem hiding this comment.
Is this type assertion doin anything? I'm not sure what line it asserts about given the newline before and after
| export const access = async ( | ||
| invocation, | ||
| { canIssue = isSelfIssued, principal, resolve = unavailable, capability } | ||
| export const access = async (invocation, { capability, ...config }) => |
There was a problem hiding this comment.
I think a human readable js doc explaining when/why to use this could be helpful. In general, I like short names like these packages use, but we also frequently re-use those names across modules/files, and there are a lot of objects whose property names come from the intersection of several types, and those properties sometimes come from exports like this via a glob import.
wdyt of jsdoc human readable explanation here?
wdyt of something like an eslint rule that requires human readable explainers for exported functions?
2 participants
Implements embedded key resolution non did:key principals as per https://github.com/web3-storage/specs/blob/main/w3-account.md#update