Code change:
2.1. <ins> In cases where a signed statement is issued by one party and registered by another, there is a need to prove posession of key material and detect tampering while authenticating both parties. Typically a nonce would be chosen by the transparency service and the second party would sign over the nonce, when registering the first issuer's signed statement. In order to avoid interactivity and improve interoperability, document describes a non-exclusive, but mandatory to support, confirmation scheme In this scheme the verifier's challenge is a recent unix timestamp, the presenting party need not request this information from the transparency service. Here is an example key binding token that can be paired with the confirmation claim in a signed statement: When applying registration policies to signed statements with confirmation, the transparency service acts as a verifier, and performs the following checks: verify the integrity of the issuer's signed statement confirm the verified content meets the registration policy for the transparency service. verify the key binding token, using the confirmation claim in the verified issuer signed statement ensure the key binding token has a nonce that is a string representation of a recent unix timestamp The exact window of validity for proving possession is a configuration detail of the transparency service. unix timestamps are used so that only a losely synchronised notion of time need be assumed and there is no requirement to account for timezones If the confirmation key is stolen, the attacker can produce key binding tokens from that point forward in time.  In an interactive confirmation schema, the transparency service can force the confirmation key holder to produce a signature over a nonce that is not guessable, and this prevents certain attacks related to the duration of access to a signing capability and other timing details. However, the cost of coordinating with the transparency service, coupled with the purpose of registering with a transparency service (to obtain a receipt, proving a signed statement was acceptable at a point in time) justify specifying the recent timestamp nonce as a mandatory to implement context binding. In the case that a SCITT transparency service wants to support challenges (nonces) that are context binding, the transparency service can expose a "challenge token endpoint". This endpoint can process request paramters, and issuer a challenge token, that future regsitrations can use to bind to the original request.  This interaction model works well for scenarios where requirements for a given regsitration might change over time, but it is important for the registering party to commit to acceptable values at the time that a signed statement is registered.  These endpoints are optional to implement. 2.1.1. 2.1.1.1. 2.1.1.2. Header: "Content-Type: application/json" (Optional) Header: "Retry-After: <seconds>" Query: "?intention={todo}" Body: "{ "token": "JWT | SD-JWT | base64url( CWT | SD-CWT )>" }" 2.1.2. 2.1.2.1. Headers: "Content-Type: application/cose" Body: SCITT COSE_Sign1 message Note: that the challenge token MUST be present and integrity protected when submitting signed statements to this endpoint.  Note: this endpoint is a duplicate of "POST https://transparency.example/ entries" 2.2. </ins> All messages are sent as HTTP GET or POST requests. If the Transparency Service cannot process a client's request, it

Related discussion:
text: Strawman proposal for: URL PoC implementation here URL
Definite start in the right direction - I would say it is enough to get in and build on
general thumbs upLGTM After a chat with Richard Barnes, I think there are a few things happening with and key binding, that we should probably consider independently for scitt: Registration Policies that require fresh signatures from issuers. Registration Policies that require issuer's to commit to a recent tree head. Registration Policies that require additional context binding and a fresh signature from the issuer bound to special context. 1 and 2 are basically both about "time". If the Transparency Service does not trust the issuer to be honest about time, the transparency service can force the issuer to include a time commitment from the transparency service in their registration with binding to their confirmation public key. In the case the "nonce" is a timestamp, the TS rejects key binding tokens that are outside some window. In the case the "nonce" is a recent tree head, the TS rejects key binding tokens that are not to a tree head inside some window. In the case the "nonce" is a "challenge token", the nonce is some special context, the TS rejects key binding tokens that lack this special context. There is an opportunity to make the registration none interactive and one shot, assuming the following is acceptable: The key binding token nonce is a "recent timestamp / tree head" The transparency service rejects key binding tokens with nonces that are not "recent" There is an opportunity to make the registration interactive and context binding, assuming the following is acceptable: The transparency service includes specific context the issuer must commit to in their "challenge token". The issuer uses the challenge token as the nonce in their key binding token. The transparency service rejects key binding tokens with nonces that omit required context In this second case, imagine a "dynamic registration policy" Holder (Issuer) asks Verifier (Transparency Service) for a challenge token for a Customs Entry for 16056100.