Workflow and details for signed-statement/issue

[SteveLasker]

Opening this issue to explore:

• Does /signed-statements/issue also register the newly signed statement, or return a signed statement to then be submitted via 2.1.2. Signed Statement Registration?
• What are the properties of a Signed Statement, when signed by the Transparency Service?
  • How does the TS represent it has signed on behalf of the service-authenticated user, meaning are we deferring the signing to be a root CA, where the service is maintaining identity documents for the user? Or, is there some on-behalf of flow?

[JAG-UK]

Currently the endpoint returns a Signed Statement, and then you have to send that along to the Register endpoint. While an all-in-one API seems attractive, it would also risk getting complex as parameters for each part of the operation are added and commingled. I'd suggest leaving it as it is for now.

How does the TS represent it has signed on behalf of the service-authenticated user,

Suggest we not over-specify this. Too many options and this isn't special compared to any other signing service, or an internal security server farm, or whatever. So where do we draw the line on showing this?