search

hyperledger / aries-rfcs

Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions
https://hyperledger.github.io/aries-rfcs/
Apache License 2.0
326 stars 217 forks source link

Signatures in Indy and JWS's in RFC 0017 - work together? #555

Open swcurran opened 4 years ago

swcurran commented 4 years ago

We want to create an RFC to sign attachments using RFC 0017 (attachments decorator), which calls for the use of JWS's. We want to then use that protocol to allow a Sovrin Txn Author to send an Indy ledger transaction to a Sovrin Endorser to sign. Can the use of JWS in RFC 0017 support that use case, or does there have to be Indy-specific/non-JWS handling done to get the correct signature? @kdenhartog @TelegramSam @dhh1128 do you know?

We're assuming that after we get the signature and DID (kid from the JWS), we'd have to add to the non-signed part of the transaction and that's OK. It's just the use of JWS in general that we're not sure of.

swcurran commented 4 years ago

@ianco @jadhavajay FYI

dhh1128 commented 4 years ago

I think we'd have to add JWS support within indy-node -- but otherwise I don't see any reason why this could not be done.

kdenhartog commented 4 years ago

Yeah last I remember Indy-node had it's own indy specific support for serializing transactions to get bytes and then signing those bytes. If the goal is to do as described, then I'd think adding support for JWS to indy-node would be the best path. Otherwise we'd need the attachment protocol to support the indy serialization format in the protocol and have a way of specifying how the signature would be passed.

swcurran commented 4 years ago

I really don't want to get into change in indy-node. I was expecting to use the format that indy-node expects.

Alternatively, we can just create a separate protocol for Indy, but I was hoping it was possible to use existing functionality. We'll have to do that everytime we need a signature for an app that we can't control.

Since we can't control what signature scheme is needed for a given use case, is there a need for a way to allow support for different signature types just like we do with different verifiable credential types in the VC Exchange protocols?