jiebi/CodeConvo huggingface dataset:
Code change:
and . Switches to zlib instead of gzip encoding and adds the recommendation to use the best available compression.
I'm working on a TypeScript implementation of this spec, and have the encoding / decoding of the status list implemented. It seems to work based on the example in the spec and the example python scripts, with one slight difference. When I encode either the 1 or 2 bit example it will output one character difference , while mine outputs an . The decoding seems to work fine, and maybe this is a gzip thing, but I'm wondering if the examples use certain gzip features to get this output? I've adapted my implementation to use compression level 9 (default for python lib) and set the mtime to the same value The input byte array is the same as for the python implementation and the examples in the spec, so it's really something that is happening during the gzip encoding (the output byte array here is different) any idea what is going on here? The implementation and tests can be found here: URL
Seems to be a difference in the header - from the position I would assume the timestamp (even though you seem be setting it to the fixed value used in the examples in the draft)? There is also a header entry for the operating system - that would also be a very likely candidate for the difference. I will take a look at it when I am back from IIW. We were discussing switching from gzip to zlib (or deflate directly) for that reason - we don't really need these headers and most languages seem to support both gzip and zlib (which was our concern when we initially thought about this). Related Issue:
Thanks for testing! There is a header as well in zlib, but it's considerably smaller. The zlib header does not include a timestamp which makes it better for reproducible results and test vectors. I think we should also give a recommendation for the used compression level, I suspect either default or highest. It would be interesting if the underscore vanishes in zlib?
I changed the python implementation to use zlib with level 9 and did the same for your typescript implementation --> both resulted in the same: We should really change that imho (and also add the text to recommend compression level).
I'm a proponent of using zlib instead of gzip. As suggested in the other issue, we don't really need the other metadata. And the result is smaller as well :)

Related discussion:
text: ("7").  All bits of the byte array at a particular index are set to a status value. <del> The complete byte array is compressed using gZIP RFC1952. </del> <ins> The complete byte array is compressed using the "DEFLATE" RFC1951 compression method and stored using the "ZLIB" RFC1950 data format.  Implementations are RECOMMENDED to use the highest compression level available. </ins> <del> The result of the gZIP compression is then base64url-encoded, as </del> <ins> The result of the compression is then base64url-encoded, as </ins> defined in Section 2 of RFC7515. 4.2.
Code change:
This feedback comes from applying the Status List to an implementation of a general OAuth 2.x server issuing JWT Access Tokens. Such implementation will typically not keep record of any issued JWT Access Tokens (their claims, expiry, etc) until they need to be revoked due any reason, e.g. getting leaked or just being explicitly revoked by the client. In such cases the issuer considers the token as VALID when issuing the Status List but this state will not necessarily reflect the token's validity as per the JWT validation rules for claims like nbf or exp. This is important to point out so that the status list is not mistaken for an alternative to actually validating the referenced token's claim set.
NAME could you merge with main and add a line to the document history please
Not a member, cannot merge.
I meant sync, sry. But I can add the history on main also.
NAME Please review and merge if you approve
Looks good to me. It might be better positioned in a dedicated Verification Processing section once we have that but its good for now

Related discussion:
text: (bit size) to be able to describe the required Status Types for the application. <ins> The processing rules for JWT or CWT precede any evaluation of a referenced tokens status.  For example if a token is evaluated as being expired through the "exp" (Expiration Time) but also has a status of 0x00 ("VALID"), the token is considered expired. </ins> 6. 6.1.
Code change:
Adds access token as an example use-case for status list.
Aaron says that there are zero mentions of the term access token and proposes to mention JWT accesstokens as a possible usecase

Related discussion:
text: references a Status List Token.  Status Lists may be composed for expressing a range of Status Types.  This document defines basic Status Types for the most common use cases as well as an <del> extensibility mechanism for custom Status Types.  The Status List Token may be used by an issuer in the Issuer-Holder-Verifier model to express the status of verifiable credentials (Referenced Tokens) issued by an issuer. The following diagram depicts the basic conceptual relationship. </del> <ins> extensibility mechanism for custom Status Types. An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of RFC6749.  Token Introspection RFC7662 defines another way to determine the status of an issued access token, but it requires the party trying to validate an access tokens status to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation. Another possible use case for the Status List is to express the status of verifiable credentials (Referenced Tokens) issued by an issuer in the Issuer-Holder-Verifier model.  The following diagram depicts the basic conceptual relationship. </ins> 1.1.
Code change:
and
Payload and Statement seem to be used intermixed in the text. I tried to disambiguate the via "Statement payload". If that does not work, please provide a counter proposal. The term Claim sometimes seem to have meant Signed Statement and sometimes Transparent Statement. Using our interim terminology, that became a selection process for me. Please check, if I made the correct choice in all occurrences (sometimes I had to guess the intent). Consistent Capitalization was a mess. I hope I fixed most of that. Please check. There is still no consistent use of "Registry" vs. "log" vs. "ledger" vs. "Transparency Service", I think. Please check. Please check every use of the term "Evidence" and if an alternative expression could be used. Please check every occurrence of the term "guarantee" or "proof" and if an alternative expression could be used. Privacy Considerations and Security Considerations texts require significant improvement.
Here is my opinion: Registry refers to the facilities used to store and retrieve "Authenticated Statement Data" that has been submitted to a "Transparency Service" "operator". A Registry contains specific "Statements" which the Transparency service supports, as documented in their registration policies document. A Registry may employ different technologies needed to carry out its function to store and retrieve "Statements" that are permitted in the Registry, per the registration policies defined by the Transparency Service operator. The operator of a Transparency Service serves the role of Gatekeeper to ensure the integrity of the Registry data and services provided to access the Registry data. A Statement is contained in a message "Payload" exchanged between a Transparency Service API function and other parties, i.e. consumer inquiries and Notary submissions.
It would help to be able to read the document given the changes proposed here. But due to the make errors documented in I haven't yet succeeded in doing so. Does the build infrastructure automatically build documents for other branches? Or can someone else build and publish the document based on this branch?
Editor's version build via github actions for is located here: https://ietf-wg-URL
LGTM, thanks for finishing this off

Related discussion:
text: 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 Claims and the signer MAY include the "kid" header </del> <ins> as for Signed Statment and the signer MAY include the "kid" header </ins> parameter.  Verifiers MUST support the "did:web" method, all other methods are optional.
Code change:
and
Payload and Statement seem to be used intermixed in the text. I tried to disambiguate the via "Statement payload". If that does not work, please provide a counter proposal. The term Claim sometimes seem to have meant Signed Statement and sometimes Transparent Statement. Using our interim terminology, that became a selection process for me. Please check, if I made the correct choice in all occurrences (sometimes I had to guess the intent). Consistent Capitalization was a mess. I hope I fixed most of that. Please check. There is still no consistent use of "Registry" vs. "log" vs. "ledger" vs. "Transparency Service", I think. Please check. Please check every use of the term "Evidence" and if an alternative expression could be used. Please check every occurrence of the term "guarantee" or "proof" and if an alternative expression could be used. Privacy Considerations and Security Considerations texts require significant improvement.
Here is my opinion: Registry refers to the facilities used to store and retrieve "Authenticated Statement Data" that has been submitted to a "Transparency Service" "operator". A Registry contains specific "Statements" which the Transparency service supports, as documented in their registration policies document. A Registry may employ different technologies needed to carry out its function to store and retrieve "Statements" that are permitted in the Registry, per the registration policies defined by the Transparency Service operator. The operator of a Transparency Service serves the role of Gatekeeper to ensure the integrity of the Registry data and services provided to access the Registry data. A Statement is contained in a message "Payload" exchanged between a Transparency Service API function and other parties, i.e. consumer inquiries and Notary submissions.
It would help to be able to read the document given the changes proposed here. But due to the make errors documented in I haven't yet succeeded in doing so. Does the build infrastructure automatically build documents for other branches? Or can someone else build and publish the document based on this branch?
Editor's version build via github actions for is located here: https://ietf-wg-URL
LGTM, thanks for finishing this off

Related discussion:
text: The SCITT version header MUST be included and its value match the "version" field of the Receipt stucture. <del> The DID of issuer header (like in Signed Claims) MUST be included and its value match the "ts_identifier" field of the Receipt structure. </del> <ins> The DID of issuer header (like in Signed Statements) MUST be included and its value match the "ts_identifier" field of the Receipt structure. </ins> TS MAY include the Registration policy info header to indicate to verifiers what policies have been applied at the registration of <del> this claim. </del> <ins> this Statement. </ins> Since I-D.draft-steele-cose-merkle-tree-proofs uses optional headers, the "crit" header (id: 2) MUST be included and all SCITT-
Code change:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Related discussion:
text: 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".
Code change:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Related discussion:
text: 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
Code change:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Related discussion:
text: 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
Code change:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Related discussion:
text: 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
Code change:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Related discussion:
text: 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
Code change:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Related discussion:
text: [3] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/17 <ins> [4] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ issues/17 </ins>
Code change:
This PR is intended to update URL as the current version has broken codeblock formatting and no longer reflects the current state of the draft URL URL URL URL URL
I looked through the changes and they are fine. Thanks for fixing the over-long lines in the examples.

Related discussion:
text: 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
Code change:
Good clarification, with a few nits to reduce and clarify the text
All edits have been addressed. I believe this is ready for merging.
Thanks, NAME Sounds like we can address this suggestion separately and we can merge this as-is
For the next submission deadline, RegInfo needs more detail to convey it's purpose. Maybe... it may even need a new name, as RegInfo might not be limited to key/value pairs about registration policy?
LGTMI would prefer "The key/value pair semantics are application-specific, or even possibly specified by each Issuer for each of their Feed." but I am fine with both formulations. Thanks.

Related discussion:
text: 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.
Code change:
LGTM, Thanks, NAME the stakeholders to consumers looks like a great change. I don't know if we'd keep both, or replace. I'll merge this to keep moving forward. Also, thanks for the catch on CBOR

Related discussion:
text: <del> : organizations, stakeholders, and users involved in creating or </del> <ins> : organizations, consumers, and users involved in creating or </ins> attesting to supply chain artifacts, releasing authentic Statements to a definable set of peers
Code change:
LGTM, Thanks, NAME the stakeholders to consumers looks like a great change. I don't know if we'd keep both, or replace. I'll merge this to keep moving forward. Also, thanks for the catch on CBOR

Related discussion:
text: 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.
Code change:
This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:

Related discussion:
text: 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.