feature/SPRIND-84 #255
feature/SPRIND-84 #255
Conversation
| } | ||
|
|
||
| private async registerCryptoServiceCallback(platformCallback: RegisterCryptoServiceCallbackArgs): Promise<RegisterCryptoServiceCallbackResult> { | ||
| CryptoServiceJS.register(platformCallback); |
There was a problem hiding this comment.
Please do not expose this function in the SDK. We have a jwt-service that should be used
There was a problem hiding this comment.
Removed the function from the SDK. As far as I can understand, the default service should be used. Is that correct? Does it make sense to keep the verifyJwt() function exposed?
There was a problem hiding this comment.
We have a plugin that does JWTs/JWS. So that should be leveraged to sign JWTs, as it has integrated support for all the identifier types we support (X509, DIDs, JWKs, kids etc).
The verify function is also exposed in the OIDF client. Depending on whether that function is doing more than a regular JWT check it makes sense to delegate it to the OIDF client. IF not then it could also use the JWT exposed CompactJwt/Jwe verify function from the SDK.
What would be nice if you have the option to have a callback. But then it should not be exposed as a method, but as a constructor argument to the plugin. Then you could do something like:
If callback is set on the plugin, delegate to the respective function of the callback. If not then delegate to the JWT service of the SDK
There was a problem hiding this comment.
Added the verifyJwt() and signJwt functions using @sphereon/ssi-sdk-ext.jwt-service. Still cannot make it work properly because the CryptoService.register(...) function from the OIDF client is ignoring the input. I'm checking it with @jcmelati
There was a problem hiding this comment.
Added the verifyJwt() and signJwt() functions using @sphereon/ssi-sdk-ext.jwt-service. Still cannot make it work properly because the second parameter of the verifyJwt function (context). I get a compilation error which I'm not sure how to fix.
|
At the moment the underlying library does not provide an implementation of a default callback, so I've created one for testing and I'm passing it to the constructor of the plugin |
No description provided.