Closed OR13 closed 2 years ago
@kimdhamilton I've received some feedback from security folks that this is not a good idea... There was even suggestion that a digital wallet should not allow self attested credential issuance (which I don't agree with).
My intention was to focus on refining the higher order APIs and reduce the potential for abuse by exposing / endorsing lower level ones...
Here is a related article: https://thehackernews.com/2022/02/microsoft-warns-of-ice-phishing-threat.html
Basically, we don't want to expose interfaces that might be used to confuse a holder into accidentally signing data that could have been handled in a safer way with a higher order interface.
Yes, this is what I suspected; just want to make sure we have it documented. Thanks!
focus on refining the higher order APIs
This feels limiting and difficult to maintain for me.. Okay now there is an interface called "Issue" which I supposed is one of those higher order APIs. But how can we anticipate all potential future things we may want to sign? We would always have to change the wallet API just because there's something new we want to sign, no?
But yes I understand there's a tradeoff between flexibility and security/phishing concerns.
WebKMS also seems to have a generic signing function: https://w3c-ccg.github.io/webkms/#sign-options-code-lt-string-gt-code-
@peacekeeper yes, I suspect that raw signing will be supported by many lower level interfaces including webkms or other enterprise kms.
I would be happy to add some text that pointed folks who were interested in "raw signatures" to the appropriate specs.
thanks for the cleanup! Wondering why we're removing sign/verify raw though? Is the idea to move that somewhere?