Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature/SDK-7 #25

Merged
merged 12 commits into from
Apr 25, 2024
Merged

feature/SDK-7 #25

merged 12 commits into from
Apr 25, 2024

Conversation

zoemaas
Copy link
Contributor

@zoemaas zoemaas commented Apr 3, 2024

No description provided.

@zoemaas zoemaas self-assigned this Apr 3, 2024
@zoemaas zoemaas requested a review from nklomp April 3, 2024 14:18
Copy link
Contributor

@nklomp nklomp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See remarks


export interface ICreateIdentifierOpts {}

export enum KeyType {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't introduce new key type enums. We already have TKeyType. If you need to restrict the current Enum, then use a Pick<>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TKeyType is an UnionType and Pick<> doesn't work with it and according what I've read so far, it doesn't work either with enums. In addition enums are completely different from UnionTypes and the process to extract a subset of keys from them is completely different. 😕 In the end I just had to use Extract<>.

options?: IKeyOpts
options?: {
methodSpecificId?: string // method specific id for import
secp256k1?: IKeyOpts | VerificationMethod
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rather see the word Key in there. So secp256k1Key. Also what is the reason for the union. The VerificiationMethod interface extends IKey, which makes the name poor BTW (should be changed). You could just as well have added the purposes property as an optional prop to the IKey interface

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the sake of consistency I just copied snippets from did-provider-ion. I cannot add anything to the IKey interface because it comes from @veramo/core, but I could make IKeyOpts extend it directly and keeping the required privateKeyHex property.

}

private assertedPurposes = (args: { keyType: KeyType; purposes: EbsiPublicKeyPurpose[] }) => {
if (args.purposes) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since purposes is required this expression would also be favored over the ones below and as it returns immediately, the rest of the function does nothing. IMO purposes should be optional. Also IMO the construct is a bit odd anyway. For EBSI you cannot say that for instance a Secp256k1 key can be used for an assertionMethod; so why would you allow that anyway. IMO this function should check whether the provided purposes are allowed for the specific key. And seperately a method should check when no purposes have been given (so undefined), then it should set the defaults.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes sense, broke it in two methods as suggested

throw Error(`Type ${options.type} not supported`)

if (args?.keyOpts && 'purposes' in args.keyOpts) {
keyManagerImportArgs.meta = { purposes: [...args.keyOpts.purposes] }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See remark about purposes. IMO there should always be purposes, as otherwise the keys have no meaning in the context of the DID

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refactored the method and added the purpose checks as requested in one of the previous remarks

packages/did-provider-ebsi/src/types.ts Show resolved Hide resolved
Copy link
Contributor

@nklomp nklomp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sew remarks

}
}

export interface ICreateIdentifierOpts {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this doing here? Should not be needed. Or at least properly list the actual options available

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed unused type

throw new Error(`Unsupported key type: ${key.type}`)
}
}
return this.setDefaultPurposes({ key, type })
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmzz this is rather ugly. An assert method setting defaults instead of sticking to assertions. Either rename the method slightly or adjust the implementation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally ugly 😞. Refactored: Separated assertion from setting defaults

@@ -43,5 +41,19 @@ export interface ICreateIdentifierArgs {
kms?: string
alias?: string
type?: EbsiDidSpecInfo
options?: IKeyOpts
options?: {
methodSpecificId?: string // method specific id for import
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually used? If so I am assuming for the r1 key and not the k1 key

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is existing code, it's an id that gets asserted and appended to did:ebsi. It seems to be allowing an external did to be imported. Not attached to any key. Removed.

Copy link
Contributor

@nklomp nklomp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, will merge

@nklomp nklomp merged commit 9192cb4 into develop Apr 25, 2024
0 of 2 checks passed
@nklomp nklomp deleted the feature/SDK-7 branch April 25, 2024 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants