Drop 'Issue Statement' endpoint and related considerations

[achamayou]

An 'Issue Statement' endpoint is not necessary, nor helpful to implement a transparency service, and it is unclear why it has been added as an optional endpoint.

SCITT services should be able to compose with arbitrary signing services that produce signed statements in the correct format.

Aside from separating concerns and making the document more concise, this helps make the authentication posture consistent (see #52).

[SteveLasker]

Being able to create a signed statement is an important security and usability workflow to SCITT.
I do agree a single transparency service should not sign their own statements prior to registration. However, another remote signing service could implement the API, which issue #56 covers.

[achamayou]

Being able to create a signed statement is an important security and usability workflow to SCITT. I do agree a single transparency service should not sign their own statements prior to registration. However, another remote signing service could implement the API, which issue #56 covers.

I am confused by this, my sense so far was that SCRAPI was "the API of a TS". As an implementer, or as a user, a TS is "a service that implements SCRAPI".

If I understand correctly, #56 says "SCRAPI is actually the set of all APIs that might be useful in the context of SCITT, likely (hopefully even) implemented by multiple services". Is that right?

Assuming I have got this right, I don't know that the current signing endpoint is a good thing to have, because:

1. If the bar for having an endpoint is all important workflows, then surely there ought to be a verification endpoint?
2. The specification doesn't say much more than "there is a way to get a COSE Sign1 over unspecified payloads". Is the issuer the same as for Transparent Statements? Is key discovery the same too? I struggle to see what interoperability value this endpoint provides.

I think it would be more coherent to specify only endpoints that we expect a TS to implement and where the specification provides interoperability value (i.e. format definitions, field semantics etc).

[SteveLasker]

This is a good point, as while it is important to ease and standardize a means to create signed statements, it may be beyond the scope of SCRAPI.
Let's discuss this in the next meeting.