jiebi/CodeConvo huggingface dataset:
The value of "id" might be found the "iss" or "sub" claims if they are present in the protected header or payload. <del> "resolve = (id: string, accept: content_type = 'application/ did+json') => idDocument (of content type application/did+json).  " </del> For example: <del> "did:example:123 " </del> Might resolve to: <del> "{ "id": "did:example:123", "verificationMethod": [{ "id": "#key-42", "type": "JsonWebkey", "controller": "did:example:123", "publicKeyJwk": { "kty": "EC", "crv": "P-384", "alg": "ES384", "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh_Udu2ObLer3cKFBCaAHY1svmbPV69bP3RH", "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYHIwGBnN5rd8QWykAprstPdxx4U0uScvDcYd" } }] } " </del> Editor note, we might wish to eliminate this intermediate identity document content type, by treating it as an alterative encoding of "application/jwk-set+json" or "application/cose-key-set".
See also draft-ietf-cose-cwt-claims-in-headers [1]. <del> "dereference = (id: string, accept: content_type = 'application/ jwk+json') => publicKeyJwk (of content type application/jwk+json).  " </del> For example, when DIDs are used: <del> "did:example:123#key-42 " </del> Might dereference to: <del> "{ "kty": "EC", "crv": "P-384", "alg": "ES384", "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh_Udu2ObLer3cKFBCaAHY1svmbPV69bP3RH", "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYHIwGBnN5rd8QWykAprstPdxx4U0uScvDcYd" } " </del> 5.1.2. Many Issuers issue Signed Statements about different Artifacts under
Transparency Services.  To register a Signed Statement, the Transparency Service performs the following steps: <del> Issuer Key Discovery The Transparency Service MUST perform DID resolution of the Issuer's key and store evidence of the lookup. This step may require that the service retrieves the Issuer DID in real-time, or relies on retrieving cached resolution. Signature verification The Transparency Service MUST verify the signature of the Signed Statement, as described in RFC 9360, using the signature algorithm and verification key of the Issuer DID document. Signed Statement validation The Transparency Service MUST check that the Signed Statement includes a Statement payload and the protected headers listed above.  The Transparency Service MAY additionally verify the Statement payload format and content. </del> <ins> The Transparency Service MUST perform DID resolution of the Issuer's key and store evidence of the lookup.  This step may require that the service retrieves the Issuer DID in real-time, or relies on retrieving cached resolution. </ins> <del> Apply Registration Policy For named policies, the Transparency Service MUST check that the required Registration info attributes are present in the headers and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and may use information contained in the attributes of named policies. </del> <ins> The Transparency Service MUST verify the signature of the Signed Statement, as described in RFC 9360, using the signature algorithm and verification key of the Issuer DID document. </ins> <del> Register the Signed Statement to the append-only log. Return the Transparent Statement, which includes the Receipt. </del> <ins> The Transparency Service MUST check that the Signed Statement includes a Statement payload and the protected headers listed above.  The Transparency Service MAY additionally verify the Statement payload format and content. For named policies, the Transparency Service MUST check that the required Registration info attributes are present in the headers and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and may use information contained in the attributes of named policies. Register the Signed Statement to the append-only log Return the Transparent Statement, which includes the Receipt </ins> Details about generating Receipts are described in Receipt. The last two steps may be shared between a batch of Signed Statements
ts_identifier: The DID of the Transparency Service that issued the Receipt.  Verifiers MAY use this DID as a key discovery mechanism to verify the Receipt; in this case the verification is the same <del> as for Signed Statment and the signer MAY include the "kid" header parameter.  Verifiers MUST support the "did:web" method, all other methods are optional. </del> <ins> as for Signed Statement and the signer MAY include the "kid" header parameter.  Verifiers MUST support the "did:web" method, all other methods are optional. </ins> We also introduce the following requirements for the COSE signature of the Merkle Root: The SCITT version header MUST be included and its value match the <del> "version" field of the Receipt stucture. </del> <ins> "version" field of the Receipt structure. </ins> The DID of issuer header (like in Signed Statements) MUST be included and its value match the "ts_identifier" field of the
Transparency Services.  To register a Signed Statement, the service performs the following steps: <del> Client authentication.  This is implementation-specific and MAY be unrelated to the Issuer identity.  Signed Statements may be registered by a different party than their Issuer. Issuer identification.  The Transparency Service MUST store evidence of the DID resolution for the Issuer protected header of the Envelope and the resolved key manifest at the time of Registration for auditing.  This MAY require that the service resolves the Issuer DID and record the resulting document, or rely on a cache of recent resolutions. Envelope signature verification, as described in COSE signature, using the signature algorithm and verification key of the Issuer DID document. </del> <ins> This is implementation-specific and MAY be unrelated to the Issuer identity.  Signed Statements may be registered by a different party than their Issuer. </ins> <del> Envelope validation.  The service MUST check that the Envelope includes a Statement payload and the protected headers listed above.  The service MAY additionally verify the Statement payload format and content. Apply Registration Policy: for named policies, the Transparency Service must check that the required Registration info attributes are present in the Envelope and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and MAY use information contained in the attributes of named policies. </del> <ins> The Transparency Service MUST store evidence of the DID resolution for the Issuer protected header of the Envelope and the resolved key manifest at the time of Registration for auditing.  This MAY require that the service resolves the Issuer DID and record the resulting document, or rely on a cache of recent resolutions. As described in COSE signature, using the signature algorithm and verification key of the Issuer DID document The service MUST check that the Envelope includes a Statement payload and the protected headers listed above The service MAY additionally verify the Statement payload format and content. for named policies, the Transparency Service must check that the required Registration info attributes are present in the Envelope and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and MAY use information contained in the attributes of named policies. </ins> Commit (register) the new Signed Statement to the Registry <del> Sign and return the Receipt. </del> <ins> Sign and return the Receipt </ins> The last two steps MAY be shared between a batch of Signed Statements recorded in the Registry.
Statement passed its Registration Policy and was recorded appropriately. <del> Conversely, a corrupt Transparency Service may 1. refuse or delay the Registration of Signed Statements, 2. register Signed Statements that do not pass its Registration Policy (e.g., Signed Statement with Issuer identities and signatures that do not verify), 3. issue verifiable Receipts for Signed Statements that do not match its Registry, or 4. refuse access to its Registry (e.g., to Auditors, possibly after storage loss). </del> <ins> Conversely, a corrupt Transparency Service may refuse or delay the Registration of Signed Statements, register Signed Statements that do not pass its Registration Policy (e.g., Signed Statement with Issuer identities and signatures that do not verify), issue verifiable Receipts for Signed Statements that do not match its Registry, or refuse access to its Registry (e.g., to Auditors, possibly after storage loss). </ins> An Auditor granted (partial) access to a Registry and to a collection of disputed Receipts will be able to replay it, detect any invalid
by enforcing the following complementary security guarantees: Statements made by Issuers about supply chain Artifacts must be <del> identifiable, authentic, and non-repudiable; </del> <ins> identifiable, authentic, and non-repudiable </ins> <del> such Statements must be registered on a secure append-only Log, so </del> <ins> Such Statements must be registered on a secure append-only Log, so </ins> that their provenance and history can be independently and <del> consistently audited; </del> <ins> consistently audited </ins> Issuers can efficiently prove to any other party the Registration of their Signed Statements; verifying this proof ensures that the Issuer is consistent and non-equivocal when producing Signed <del> Statements. </del> <ins> Statements </ins> The first guarantee is achieved by requiring Issuers to sign their Statements and associated metadata using a distributed public key
JSON encoding. Registration Policy info (label: "TBD", temporary: "393"): A map <del> of additional attributes to help enforce Registration Policies. </del> <ins> containing key/value pairs set by the Issuer which are sealed on Registration and non-opaque to the Transparency Service.  The key/ value pair semantics are specified by each Issuer or are specific to the Issuer and Feed tuple.  Examples include: the sequence number of signed statements on a feed, Issuer metadata, or a reference to other transparent statements (e.g., augments, replaces, new-version, CPE-for). </ins> Key ID (label: "4"): Key ID, as a bytestring.
service MAY enforce its own Registration Policies for authorizing entities to register their Signed Statements to the append-only Log. Some Transparency Services may also enforce authorization policies <del> limiting who can write, read and audit specific Feeds or the full </del> <ins> limiting who can write, read and audit specific Subjects or the full </ins> registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is
the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed Statements what Artifact it is referring to.  This information is <del> stored in the Feed header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. </del> <ins> stored in the Subject header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. </ins> 5.1.3. <del> Besides Issuer, Feed and kid, the only other mandatory metadata in a Signed Statement is the type of the Payload, indicated in the "cty" </del> <ins> Besides Issuer, Subject and kid, the only other mandatory metadata in a Signed Statement is the type of the Payload, indicated in the "cty" </ins> (content type) Envelope header.  However, this set of mandatory metadata is not sufficient to express many important Registration Policies.  For example, a Registry may only allow a Signed Statement
Beyond the trusted components, Transparency Services may operate additional endpoints for auditing, for instance to query for the history of Signed Statements registered by a given Issuer via a <del> certain Feed.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints, except if it is necessary to compute a Registry </del> <ins> certain Subject.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Registry in auditing endpoints, except if it is necessary to compute a Registry </ins> consistency proofs.  Other evidence to support the correctness and completeness of the audit response MUST be computed from the Registry.
Identifier DID-CORE) of the signer, as a string. "did:web:example.com" is an example of a DID. <del> Feed (label: "TBD", temporary: "392"): The Issuer's name for the Artifact, as a string. </del> <ins> Subject (label: "TBD", temporary: "392"): The Subject to which the Statement refers, as a bytestring, chosen by the Issuer. </ins> Content type (label: "3"): Media type of payload, as a string. For example, "application/spdx+json" is the media type of SDPX in JSON encoding. Registration Policy info (label: "TBD", temporary: "393"): A map <del> of additional attributes to help enforce Registration Policies. </del> <ins> containing key/value pairs set by the Issuer which are sealed on Registration and non-opaque to the Transparency Service.  The key/ value pair semantics are specified by each Issuer or are specific to the Issuer and Feed tuple.  Examples include: the sequence number of signed statements on a feed, Issuer metadata, or a reference to other transparent statements (e.g., augments, replaces, new-version, CPE-for). </ins> Key ID (label: "4"): Key ID, as a bytestring.
return which service the Transparent Statement is registered on. In some scenarios, the Verifier already expects a specific Issuer and <del> Feed for the Transparent Statement, while in other cases they are not known in advance and can be an output of validation.  Verifiers MAY be configured to re-verify the Issuer's signature locally, but this requires a fresh resolution of the Issuer's DID, which MAY fail if the DID Document is not available or if the statement's signing key has been revoked.  Otherwise, the Verifier trusts the validation done by the Transparency Service during Registration. </del> <ins> Subject for the Transparent Statement, while in other cases they are not known in advance and can be an output of validation.  Verifiers MAY be configured to re-verify the Issuer's signature locally, but this requires a fresh resolution of the Issuer's DID, which MAY fail if the DID Document is not available or if the statement's signing key has been revoked.  Otherwise, the Verifier trusts the validation done by the Transparency Service during Registration. </ins> Some Verifiers MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency
The interoperability guaranteed by the Transparency Services is enabled via core components (architectural constituents).  Many of the data elements processed by the core components are based on the <del> Concise Signing and Encryption (COSE) standard specified in RFC9052, </del> <ins> CBOR Signing and Encryption (COSE) standard specified in RFC9052, </ins> which is used to produce Signed Statements about Artifacts and to build and maintain a Merkle tree that functions as an Append-only Log for corresponding Signed Statements.
the data elements processed by the core components are based on the CBOR Signing and Encryption (COSE) standard specified in RFC9052, which is used to produce Signed Statements about Artifacts and to <del> build and maintain a Merkle tree that functions as an Append-only Log for corresponding Signed Statements. </del> <ins> build and maintain an Append-only Log for corresponding Signed Statements. </ins> 1.1.
as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service <del> identity and the agility parameters for the Merkle Tree Proof.  Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle-tree- proofs. </del> <ins> identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle- tree-proofs. </ins> This section describes at a high level, the three main roles and associated processes in SCITT: Issuers and the Signed Statement
other variants.  The Transparency Service is only required to support concise Receipts (i.e., whose size grows at most logarithmically in the number of entries in the Append-only Log) that can be encoded as <del> a COSE Signed Merkle Tree Proof. </del> <ins> a Signed Inclusion Proof. </ins> It is possible to offer multiple signature algorithms for the COSE <del> signature of receipts' Signed Merkle Tree, or to change the signing algorithm at later points.  However, the Merkle Tree algorithm (including its internal hash function) cannot easily be changed without breaking the consistency of the Append-only Log.  It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency. </del> <ins> signature of receipts' Signed Inclusion Proofs, or to change the signing algorithm at later points.  However, the verifiable data structure cannot easily be changed without breaking the consistency of the Append-only Log.  It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency. </ins> 5.2.3.1.
6.4. When a Signed Statement is registered by a Transparency Service a <del> Transparent Statement is created.  This Transparent Statement consists of the Signed Statement and a Receipt.  Receipts are based on COSE Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree- proofs) with an additional wrapper structure that adds the following information: </del> <ins> Receipt becomes available.  When a Receipt is included in a Signed Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree-proofs). Receipts protected headers have additional mandatory fields: : The "crit" header (id: 2) MUST be included and all SCITT- specific headers (version, DID of Transparency Service and Registration Policy) MUST be marked critical </ins>
Before checking a Transparent Statement, the Verifier must be configured with one or more identities of trusted Transparency <del> Services.  If more than one service is configured, the Verifier MUST return which service the Transparent Statement is registered on. In some scenarios, the Verifier already expects a specific Issuer and Subject for the Transparent Statement, while in other cases they are not known in advance and can be an output of validation.  Verifiers MAY be configured to re-verify the Issuer's signature locally, but this requires a fresh resolution of the Issuer's DID, which MAY fail if the DID document is not available or if the Statement's signing key has been revoked.  Otherwise, the Verifier trusts the validation done by the Transparency Service during Registration. </del> <ins> Services. Verifiers MAY be configured to re-verify the Issuer's Signed Statment locally, but this requires a fresh resolution of the Issuer's verificaton keys, which MAY fail if the key has been revoked. </ins> Some Verifiers MAY decide to locally re-apply some or all of the Registration Policies, if they have limited trust in the Transparency Services.  In addition, Verifiers MAY apply arbitrary validation <del> policies after the signature and Receipt have been checked.  Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. </del> <ins> policies after the Transparent Statement has been verified and validated.  Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state. </ins> Verifiers MAY offer options to store or share the Receipt of the Transparent Statement for auditing the Transparency Services in case
This may involve registering the same Signed Statements at different Transparency Services, each with their own purpose and Registration <del> Policy.  This may also involve attaching multiple Receipts to the same Signed Statements, each Receipt endorsing the Issuer signature and a subset of prior Receipts, and each Transparency Service verifying prior Receipts as part of their Registration Policy. For example, a supplier may provide a complete, authoritative Transparency Service for its Signed Statements, whereas a Verifiers's Transparency Service may collect different kinds of Signed Statements to ensure complete auditing for a specific use case, and possibly require additional reviews before registering some of these Signed </del> <ins> Policy. This may also involve attaching multiple Receipts to the same Signed </ins> Statements. <del> An independent entities (security companies) may Issue statements of quality about different artifacts on their own Transparency Service. Verifiers choose which independent entities they trust, just as entities choose different security companies today. </del> <ins> For example, a software producer of a supply chain artifact might rely on multiple independent software producers operating transparency services for their upstream artifacts.  Downstream producers benefit from upstream producers providing higher transparency regarding their artifacts. </ins> 8.
5.2.2. <ins> The Transparency Service records its configuration in the Append-Only Log using Transparent Statements with distinguished media type "application/scitt-configuration". The registration policy for statements with the media type suffix ("+<format>" is implementation-specific.  The implementation SHOULD document them, for example defining the Issuers authorized to register configuration Signed Statements. The Transparency Service is configured by the last Transparent Statement of this type.  The Transparency Service MUST register a Signed Statement that defines its initial configuration before registering any other Signed Statement.  The Transparency Service MAY register an additional Signed Statement that updates its configuration. The Transparency Service provides an endpoint that returns the Transparent Statement that describes its current configuration. The configuration "reg_info" SHOULD include a secure version number and a timestamp. The sample configuration payload uses the CDDL 5.2.3. </ins> Authorization is needed prior to registration of Signed Statements to ensure completeness of an audit.  A Transparency Service that registers valid Signed Statement offered by anonymous Issuers would
specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users. <ins> A provider of a Transparency Service indicates what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy by issuing and registering configuration statements. </ins> As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As defined in RFC6024, "A trust anchor represents an authoritative