jiebi/CodeConvo huggingface dataset:
Code change:
The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix

Related discussion:
text: Upon receiving a Referenced Token, a Relying Party MUST first perform the validation of the Referenced Token - e.g., checking for expected <del> attributes, valid signature, expiration time.  As this is out of scope of this document, this validation is not be described here, but is expected to be done according to the format of the Referenced Token. </del> <ins> attributes, valid signature, expiration time.  The processing rules for JWT or CWT precede any evaluation of a Referenced Token's 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.  As this is out of scope of this document, this validation is not be described here, but is expected to be done according to the format of the Referenced Token. </ins> If this validation was not successful, the Referenced Token MUST be rejected.  If the validation was successful, the Relying Party MUST
Code change:
The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix

Related discussion:
text: 14.5. <ins> This specification establishes the IANA "Status Types" registry for Status List values.  The registry records the a human readable label, the bit representation and a common description for it. 14.5.1. Status Type Name: Status Type Description: Status Type value: Change Controller: Specification Document(s): 14.5.2. Status Type Name: VALID Status Type Description: The status of the Referenced Token is valid, correct or legal. Status Type value: "0x00" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: INVALID Status Type Description: The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled. Status Type value: "0x01" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: SUSPENDED Status Type Description: The status of the Referenced Token is temporarily invalid, hanging, debarred from privilege.  This state is reversible. Status Type value: "0x02" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_3 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x03" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_14 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x0E" Change Controller: IETF Specification Document(s): status-types of this specification Status Type Name: APPLICATION_SPECIFIC_15 Status Type Description: The status of the Referenced Token is implicitly given by the particular use case and the meaning of this value is known out-of-band. Status Type value: "0x0F" Change Controller: IETF Specification Document(s): referenced-token-jose of this specification 14.6. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.
Code change:
The spec creates a registry and claim for status mechanisms and 1 specific mechanism, the status list. We should adjust the introduction to reflect those changes.

Related discussion:
text: resolvable endpoint.  The roles of the Issuer (of the Referenced Token), the Status Issuer and the Status Provider may be fulfilled by the same entity.  If not further specified, the term Issuer may refer <del> to an entity acting for all three roles. </del> <ins> to an entity acting for all three roles.  This document describes how an Issuer references a Status List Token and how a Relying Party fetches and validates Status Lists. </ins> <del> The following diagram depicts the relationship between the artifacts: </del> <ins> The following diagram depicts the relationship between the involved roles (Relying Party is equivalent to Verifier of SD-JWT.VC): 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 extensibility mechanism for custom Status Types. </ins> <del> The Referenced Token is referenced by the Status List, which described the status of the Referenced Token.  The Status List is embedded and secured within a Status List Token. </del> <ins> Furthermore, the document defines an extension point that enables other specifications to describe additional status mechanisms and creates an IANA registry. </ins> 1.1. <ins> 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 SD-JWT.VC. 1.2. </ins> Revocation mechanisms are an essential part for most identity ecosystems.  In the past, revocation of X.509 TLS certificates has been proven difficult.  Traditional certificate revocation lists
Code change:
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change

Related discussion:
text: "aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of <del> Referenced Token.  See section batch-fetching for further detail. </del> <ins> Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the JSON representation of the Status List:
Code change:
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change

Related discussion:
text: "aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this <del> type of Referenced Token.  See section batch-fetching for further detail. </del> <ins> type of Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the CBOR representation of the Status List in Hex:
Code change:
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change

Related discussion:
text: The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID, or via a VICAL extension for <del> ISO mDoc / mDL. </del> <ins> ISO mDoc / mDL.  If the Issuer is an OAuth Authorization Server according to RFC6749, it is RECOMMENDED to use "status_list_aggregation_endpoint" for its metadata defined by RFC8414. </ins> The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.
Code change:
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change

Related discussion:
text: 14.6. <ins> This specification requests registration of the following value in the IANA "OAuth Authorization Server Metadata" registry IANA.OAuth.Params established by RFC8414. Metadata Name: status_list_aggregation_endpoint Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management. Change Controller: IETF Reference: aggregation of this specification 14.7. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.
Code change:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Related discussion:
text: "aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of <del> Referenced Token.  See section batch-fetching for further detail. </del> <ins> Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the JSON representation of the Status List:
Code change:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Related discussion:
text: "aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this <del> type of Referenced Token.  See section batch-fetching for further detail. </del> <ins> type of Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the CBOR representation of the Status List in Hex:
Code change:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Related discussion:
text: If the Relying Party does not send an Accept Header, the response type is assumed to be known implicit or out-of-band. <ins> A successful response that contains a Status List Token MUST use an HTTP status code in the 2xx range. A response MAY also choose to redirect the client to another URI using a HTTP status code in the 3xx range, which clients SHOULD follow.  A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). </ins> The following are non-normative examples for a request and response for a Status List Token with type "application/statuslist+jwt":
Code change:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Related discussion:
text: The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID, or via a VICAL extension for <del> ISO mDoc / mDL. </del> <ins> ISO mDoc / mDL.  If the Issuer is an OAuth Authorization Server according to RFC6749, it is RECOMMENDED to use "status_list_aggregation_endpoint" for its metadata defined by RFC8414. </ins> The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.
Code change:
Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.

Related discussion:
text: 14.6. <ins> This specification requests registration of the following value in the IANA "OAuth Authorization Server Metadata" registry IANA.OAuth.Params established by RFC8414. Metadata Name: status_list_aggregation_endpoint Metadata Description: URL of the Authorization Server aggregating OAuth Token Status List URLs for token status management. Change Controller: IETF Reference: aggregation of this specification 14.7. </ins> This section requests registration of the following media types RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.
Code change:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Related discussion:
text: The HTTP response SHOULD use gzip Content-Encoding as defined in RFC9110. <ins> If caching-related HTTP headers are present in the HTTP response, Relying Parties SHOULD prioritize the exp and ttl claims within the Status List Token over the HTTP headers for determining caching behavior. </ins> 8.3. Upon receiving a Referenced Token, a Relying Party MUST first perform
Code change:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Related discussion:
text: 11. <ins> The Status List as defined in status-list only exists in cryptographically secured containers which allows checking the integrity and origin without relying on other aspects like transport security (e.g., the web PKI). </ins> 11.1. Implementers should be particularly careful for the correct parsing
Code change:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Related discussion:
text: 11.3. <del> When Relying Parties fetch the Status List, they need to be aware of its up-to-date status.  The 'ttl' (time-to-live) claim in the Status List Token provides one mechanism for setting a maximum cache time for the fetched data.  This property permits distribution of a Status List to a CDN or other distribution mechanism while giving guidance to consumers of the Status List on how often they need to fetch a fresh copy of the Status List even if that Status List is not expired. </del> <ins> When fetching a Status List Token, Relying Parties must carefully evaluate how long a Status List is cached for.  Collectively the "iat", "exp" and "ttl" claims when present in a Status List Token communicate how long a Status List should be cached and should be considered valid for.  The following diagram illustrates the relationship between these claims and how they are designed to influence caching. It is essential to understand the distinct purposes of the "ttl" and "exp" claims.  The "ttl" claim represents a duration to be interpreted relative to the time the Status List is fetched, indicating when a new version of the Status List may be available. In contrast, the "exp" claim specifies an absolute timestamp, marking the point in time when the Status List expires and MUST NOT be relied upon any longer.  Together, these claims provide guidance on when to check for updates ("ttl" claim) and when the Status List must be refreshed or replaced ("exp" claim). </ins> 12.
Code change:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Related discussion:
text: status mechanism method member and a reference to the specification that defines it. <ins> JWT Status Mechanism Methods are registered by Specification Required [RFC5226] after a three-week review period on the jwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register JWT Status Mechanism Method: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.2.1. Status Method Value:
Code change:
We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL

Related discussion:
text: status mechanism method member and a reference to the specification that defines it. <ins> CWT Status Mechanism Methods are registered by Specification Required [RFC5226] after a three-week review period on the cwt-reg- review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register CWT Status Mechanism Method: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.4.1. Status Method Value: