2.2.1 Issue Signed Statement.

[roywill]

Are we asserting that the authentication identity to the end point is the identity to sign the content with? I think we need to clarify that this can be completely different. I do question why we need to specify a validFrom date?

[JAG-UK]

Are we asserting that the authentication identity to the end point is the identity to sign the content with?

This should be clarified/specified indeed.

Given the context of this endpoint being environments that can't sign their own Statements, the credential can't be 1:1 equivalent to an Issuer at a deep technical/cryptographic level. Therefore some logic has to be applied in the endpoint to convert the authenticated API client into a SCITT Issuer.

Given that, it seems reasonable to leave it fairly open, for example by adding:

"

• The Transparency Service SHOULD use a different Issuer identity for each different API client
• The Transparency Service SHOULD use the same Issuer identity for every call made by the same API client
  "

This language is slightly sloppy but YKWIM.

[SteveLasker]

The example in https://ietf-wg-scitt.github.io/draft-ietf-scitt-scrapi/draft-ietf-scitt-scrapi.html#section-2.2.1 should be updated to not be a W3C credential

[achamayou]

I have proposed in #53 that we drop this endpoint altogether, and stay focused on interoperability of the Transparency Service itself, which can be composed with any number of signing mechanisms, local or remote.