Add new RFC, design of "Sign Transaction" protocol -- perhaps Indy specific

[swcurran]

A common use case on Indy is the need for a Transaction Author that is not an Endorser to prepare a transaction for the ledger, pass it to an Endorser for a signature and on receipt, execute the transaction. This is explored in this HackMD document, in this presentation (https://docs.google.com/presentation/d/1bF_Su5m-kfFxcFL7xVlzPAEo3isnQrkqP4T2s3mMB2Y/edit?usp=sharing) and was discussed in this Aries WG Call ("Please Sign This" item).

Several questions are open about this:

• Should this be an "Indy Only" protocol that deals specifically with Indy issues?
  • If not Indy specific, perhaps the first cut should be, to deal with this specific case.
• The structure of the current (as I write this) HackMD document is not (IMHO) quite right. It should be closer to the "Issue Credential V2" approach of an attachment and a format/handler in the message for how to handle the attachment. Suggest reworking the message formats accordingly
  • This approach would allow building an initial Indy-specific way to do this, while remaining open to other options.
• There are sometimes needs to have n of m signatures on a transactions -- e.g. send the message out to 5 (m) entities and once 3 (n) have been returned, send a "nevermind" to the other 2 (m-n) and complete the protocol
  • When handling multi-signatures, specific transactions that are being signed apply the signatures in format-specific ways. For example, Indy has a specific way of handling that.
• The Admin interface for this protocol needs to be defined.
  • How is the process initiated? How does an Endorser/signer controller get notified of the request and respond?
• The specific transactions that need to be endorsed are handled in ACA-Py today -- ledger transactions to create DIDs, Schema, Cred Defs, RevReg and RevRegEntries. How do we inject this endorser process into those existing flows?
• How does the agent that needs an endorser know who to send the request to?
  • How does it establish a connection with the Endorser on startup?
  • How does it know the connection to use on restart?
  • Is a startup option defined to notify the agent that it has to do these things?

This task is to come up with a sufficient design for this feature that we can implement.

[swcurran]

@ianco -- the idea here is that you work on the design. You may also get to implement, but we've had others that might be able to do the implementation -- perhaps a dev from @jadhavajay 's team at AyanWorks.

[ianco]

Who is responsible for accepting the TAA? Is it the transaction author or the endorser? (Or both?)

[swcurran]

The transaction author. Slowly now.. TAA -- "Transaction Author Agreement"

[swcurran]

:-)

[ianco]

I suggest to leverage a couple of existing rfc's:

• Signed attachments: https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0017-attachments#signing-attachments
• Question/Answer: https://github.com/hyperledger/aries-rfcs/tree/master/features/0113-question-answer
• Goal Codes: https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0519-goal-codes

The basic signing protocol is:

• I create a message with an attachment that I want signed, and a request that says "Please sign for this reason (goal code) and return by (date)"
  • For Indy transactions the TAA acceptance is just part of the attachment, this protocol doesn't need to worry about it
  • We could specify a signature type, or determine the required signature type based on the attachment type
• I send this message to however many endorsers I have configured (assume each has an existing connection)
• The endorser can:
  • Return a message with the signed attachment
  • Return a status of "won't sign" or "can't sign" (with a reason)
  • Ignore the signing request
• If I don't get a response within (some timeframe) I can re-send the same request (same thread id)
  • As an endorser if I get a duplicate request I can just return the same response again, I don't necessarily need to track a history of what I've signed
• Requester will potentially receive multiple signatures, it's up to them to collate them in to a single transaction to write to the ledger
• If the requester receives enough signatures (e.g. sends to "m" endorsers but only needs "n" signatures (m>n)) then either:
  • send a "forget about it" message to the remaining endorsers
  • or just ignore subsequent responses

[ianco]

How this fits into existing protocols:

Protocols that write to the ledger (public did, schema, cred def, revocation registry) need to incorporate the above signing protocol. The aca-py agent will need to be configured with either (a) an endorser DID, or (b) a (list of) endorser connection(s) who can sign transactions.

For aca-py's with an endorser did, they can just write to the ledger.

Otherwise, once the ledger transaction is prepared for the above protocols and is ready to write to the ledger, it will be written to a persistent queue and sent to each endorser. (aca-py will need to know how many signatures are required and what endorsers are available. Endorsers obviously need to support the signing protocol.)

As endorser responses are received (signatures or non-signatures) they are collated against the transaction (in the persistent queue) and once enough transactions are received the transaction is written to the ledger. Subsequent responses can be ignored. The initiating protocol (public did, schema, credential definition, revocation registry) may need to be continued.

If not enough responses are received within (timeframe) then the transaction is timed out and the initiating protocol may need to be errored out and rolled back.

[ianco]

aca-py API needs to be enhanced to:

• Configure endorser connections (connections are setup separately but need to be flagged as endorsers)
• Configure signing requirements for public did, schema, credential definition, revocation registry
  • May need to be generic to allow for future protocols and signatures for non-Indy transactions?
• Need to review protocols for public did, schema, credential definition, revocation registry to see where the ledger writes fit in, and how to make the protocol continue or roll back after the signing protocol is completed
• Add api to view status of signature-requests-in-progress and potentially trigger a "signature request re-send" or "cancel" of the calling protocol

[swcurran]

Thoughts on the three comments:

• I didn't at first get the need for the Q&A protocol, but I think you mean to use it as the implemented protocol, attachment and goal-codes are decorators that will be used for the protocol.
• I think there will have to be some post processing of the Indy ledger transactions to insert the signatures in the appropriate way in the transaction. It's definitely possible, even for multi-sig transactions, as the Sovrin NetOps team was doing that for transactions. Indy transactions have a section that need to be signed, and a section that holds the signature, all in JSON.
• Why call out a "persistent queue" vs. just calling a child protocol (or multiple) as part of the flow? Couldn't the Q&A protocol simply be called as needed? Not that I'm saying that shouldn't be done that way -- just looking for clarification on why.
• The "I'm an endorser" configuration is going to be interesting. I think we can detect is a DID to which we've connected is an Endorser (if it is an Indy DID) now, although it's not clear that just being an Endorser DID implies it is the endorser DID I use. I think the logic of what Endorser to use needs to come from the Controller. Perhaps the Controller needs to say "MyDID= Endorser=" on the necessary admin requests, and ACA-Py is responsible for establishing a connection with the Endorser (if not present already) and then interacting with the Endorser. The "MyDID" part may be redundant as they are in the messages to be signed, but might be easier to include vs. having to extract from the transactions to be executed.
• Note that I think the Endorser side of the protocol has to be built up and is different from the Author part of it, which is defined here.

[swcurran]

One more thought. I question using Q&A for this vs. having another protocol. At minimum we'll want to update Q&A to reflect how it will be used. But I'm guessing that doing this will not be as easy as just implementing Q&A (as defined now) and adding decorators.

[ajile-in]

Hi @swcurran, we have identified a developer from our team who can contribute to this development with @ianco . He will join the regular ACA-Pug calls to get in sync.

[swcurran]

Thanks @jadhavajay ! We talked about this on our internal sprint review todau. Ian is going to do some more refinements to the docs and perhaps do a WIP/Draft PR that does a little bit of the work, but leaves the heavylifting.

@ianco I'd say once you have things finalized, do a new Issue that has the (as best we know it) solution defined and we'll close this issue. The implementation will start from there, and the conversation on that issue will be about implementation details vs. the design itself.

[swcurran]

Also - let's decide what RFC update is needed -- if we are going to use Q&A and we need to add details to it or if this will be a new PR.

Oh and one more thing. Do keep in mind the Aries Toolbox part of this so that we can see if we can make that happen.

[ianco]

Hackmd doc is updated: https://hackmd.io/5LzMhfsMQBevB5V2tKz4hA?view

[ianco]

@jadhavajay @swcurran I've been updating the hackmd doc with my thoughts around the design, can we schedule a call early next week to discuss? Monday is a holiday here so sometime from Tuesday onwards ... I'm in Victoria BC (Pacific Time) but am flexible to do an early morning or an evening call.

[ajile-in]

Sorry for the late reply on this @ianco. Yes, we can schedule a call to discuss. Please suggest if this week is still good for you.

[ajile-in]

CC: @HarshMultani & @ankita-p17

[swcurran]

Perhaps we can cover on the ACA-Pug meeting today?

[ajile-in]

I think we can.

[pstuermlinger]

Are you planning to let the endorser optionally write the completely signed transactions to the ledger itself, instead of returning it back to the TA?
In our use case (TA without internet access, privileged Endorser) this would be a great enhancement.

[swcurran]

Not on the plan right now. How about adding at least an issue about that -- ideally a PR :-).

Thanks!

[HarshMultani]

Hi @swcurran @pstuermlinger.

Yes, there is an issue about that. And it should be done in some days
#1031