pimotte
commented
5 years ago As I see it, there could be two kind of references:
- Identifiers/pure references, which serve as an id of some sort to do a lookup. It seems likely these would be just strings.
- References with semantic meaning. I.e. embedding a signature in a reference. In this case it might be a string or an object. It would also be important that whatever encoding we use, we can send it over the line.
Altering the current behaviour to encode objects by JSON.stringify and base64 allows both use cases. The encoding and decoding is then something we can facilitate in disciple-core. Any semantic extraction needs to be done in the connector. In case we specifically want to disallow the second use case, I would replace the HMAC by a hash (as suggested in #10)
bkaptijn
The implementation is able to create links with a HMAC hash of claimdata. This can only be used when connectors return non string references. There is no functionality implemented within discipl core that actually uses such hashes! This all seems ill set up at the moment.
1) it may be better having connectors create proofs as references 2) connectors could then use their own types of proofs than hmac references 3) connectors can verify these proofs themselves
note that connectors can use other connectors so we could create connectors that add functionality to all others...
So the idea is to hand off this functionality to platform specific connectors. This probably will make supporting different kinds of verifiable credentials more easy.