jiebi/CodeConvo huggingface dataset:
Optional parameters: n/a <del> Encoding considerations: binary; </del> <ins> Encoding considerations: See status-list-token-cwt of this specification </ins> <del> Security considerations: See (#Security) of [ this specification ] </del> <ins> Security considerations: See Security of this specification </ins> Interoperability considerations: n/a <del> Published specification: [ this specification ] </del> <ins> Published specification: this specification </ins> <del> Applications that use this media type: Applications using [ this specification ] for updated status information of tokens </del> <ins> Applications that use this media type: Applications using this specification for updated status information of tokens </ins> Fragment identifier considerations: n/a <del> Additional information: File extension(s): n/a Macintosh file type code(s): n/a </del> <ins> Additional information: n/a </ins> Person & email address to contact for further information: Paul Bastian, paul.bastian@posteo.de
SD-JWT-based Verifiable Credentials SD-JWT.VC introduce the usage of Status List in Section 3.2.2.2.  The "status" object uses the same <del> encoding as a JWT as defined in referenced-token-jwt. </del> <ins> encoding as a JWT as defined in referenced-token-jose. </ins> The following is a non-normative example for a Referenced Token in SD-JWT-VC serialized form as received from an Issuer:
"status_list" (status list): REQUIRED when the status list mechanism defined in this specification is used.  It has the same definition as the "status_list" claim in referenced-token- <del> jwt but MUST be encoded as a "StatusListInfo" CBOR structure </del> <ins> jose but MUST be encoded as a "StatusListInfo" CBOR structure </ins> with the following fields: "idx": REQUIRED.  Same definition as "idx" claim in <del> referenced-token-jwt. </del> <ins> referenced-token-jose. </ins> "uri": REQUIRED.  Same definition as "uri" claim in <del> referenced-token-jwt. </del> <ins> referenced-token-jose. </ins> Application of additional restrictions and policy are at the discretion of the verifying party.
The following is the CBOR Annotated Hex output of the example above: <del> 6.4. The Referenced Token MUST be encoded as a "COSE_Sign1" or "COSE_Sign" CBOR structure as defined in "CBOR Object Signing and Encryption (COSE)" RFC9052. It is required to encode the status mechanisms referred to in the Referenced Token using the "Status" CBOR structure defined in referenced-token-cwt. </del> <ins> ISO mdoc ISO.mdoc may utilize the Status List mechanism by introducing the "status" parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2.  The "status" parameter uses the same encoding as a CWT as defined in referenced-token-cose. </ins> It is RECOMMENDED to use "status" for the label of the field that contains the "Status" CBOR structure.
Application of additional restrictions and policy are at the discretion of the verifying party. <del> The following is a non-normative example for a decoded payload of a Referenced Token: </del> <ins> The following is a non-normative example for an IssuerAuth as specified in ISO mDL (also referred to as signed MSO) in Hex: </ins> <del> TBD: example </del> <ins> The following is the CBOR Diagnostic Notation of the example above: </ins> 7.
Check for the existence of a "status" claim, check for the existence of a "status_list" claim within the "status" claim and validate that the content of "status_list" adheres to the rules <del> defined in referenced-token-jwt for JWTs and referenced-token-cwt for CWTs.  This step can be overruled if defined within the </del> <ins> defined in referenced-token-jose for JWTs and referenced-token- cose for CWTs.  This step can be overruled if defined within the </ins> Referenced Token Format natively Resolve the Status List from the provided URI
The claim value object MUST contain a "lst" (list) attribute with a string based value that represents the status values for all the <del> tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </del> <ins> tokens it conveys statuses for.  The value MUST be computed using the algorithm described in jwt-status-list-claim-encoding. 3.2.2. Each status of a Referenced Token MUST be represented with a bit size of 1,2,4, or 8.  Therefore up to 2,4,16, or 256 statuses for a Referenced Token, depending on the bit-size, are possible.  This limitation is intended to limit bit manipulation necessary to a single byte for every operation and thus keeping implementations simpler and less error prone. The overall status list is encoded as a byte array.  Depending on the "bit-size" each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1).  The status of each Referenced Token is identified using an index that maps to one or more specific bits within the byte array.  The index starts counting at 0 and ends with "size" - 1(being the last valid entry).  The bits within an array are counted from least significant bit "0" to the most significant bit ("7").  All bits of the byte array at a particular index are set to a status value. The complete byte array is compressed using gZIP RFC1952. The result of the gZIP compression is then encoded as base64 encoding as defined in Section 4 of RFC4648 and stored as a string. Example of a byte representing 8 statuses (1-bit status list) with indices 0,1,2,3,4,5,6,7 (1 byte): Example of a more complex status list of length 12 using 2 bit statuses (3 bytes): </ins> 3.3.
List.  Each Referenced Token is allocated an index during issuance that represents its position within this bit array.  The value of the bit(s) at this index correspond to the Referenced Token's status.  A <del> Status List may either be provided via HTTPS or be signed and embedded into a Status List Token, whereas this document defines its representations in JWT and CWT.  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.  The document also defines how an issuer of a Referenced Token references a Status List (Token). </del> <ins> Status List may either be provided via HTTPS or be protected within a Status List Token by cryptographic signature or MAC, whereas this document defines its representations in JWT and CWT.  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.  The document also defines how an issuer of a Referenced Token references a Status List (Token). </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
The JWT MAY contain other claims. <del> The JWT MUST be digitally signed using an asymmetric cryptographic algorithm.  Relying parties MUST reject the JWT if it is using a Message Authentication Code (MAC) algorithm.  Relying parties MUST reject JWTs with an invalid signature. </del> <ins> The JWT MUST be secured using a cryptographic signature or MAC algorithm.  Relying Parties MUST reject JWTs with an invalid signature. </ins> Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519. Application of additional restrictions and policy are at the <del> discretion of the verifying party. </del> <ins> discretion of the Relying Party. </ins> The following is a non-normative example for a Status List Token in JWT format:
The CWT MAY contain other claims. <del> The CWT MUST be digitally signed using an asymmetric cryptographic algorithm.  Relying parties MUST reject the CWT if it is using a Message Authentication Code (MAC) algorithm.  Relying parties MUST reject CWTs with an invalid signature. </del> <ins> The CWT MUST be secured using a cryptographic signature or MAC algorithm.  Relying Parties MUST reject CWTs with an invalid signature. </ins> Relying parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" RFC8392. Application of additional restrictions and policy are at the <del> discretion of the verifying party. </del> <ins> discretion of the Relying Party. </ins> The following is a non-normative example for a Status List Token in CWT format in Hex:
7. <del> This document defines potential statuses of Referenced Tokens as Status Type values.  If the Status List contains more than one bit per token (as defined by "bits" in the Status List), then the whole value of bits MUST describe one value.  A Status List can not represent multiple statuses per Referenced Token. The registry in this document describes the basic Status Type values required for the most common use cases.  Additional values may defined for particular use cases. </del> <ins> This document defines statuses of Referenced Tokens as Status Type values.  A status describes the state, mode, condition or stage of an entity that is represented by the Referenced Token. A Status List can not represent multiple statuses per Referenced Token.  If the Status List contains more than one bit per token (as defined by "bits" in the Status List), then the whole value of bits MUST describe one value.  Status Types MUST have a numeric value between 0 and 255 for their representation in the Status List.  The issuer of the Status List MUST choose an adequate "bits" (bit size) to be able to describe the required Status Types for its application. </ins> 7.1. <del> A status describes the state, mode, condition or stage of an entity that is described by the Status List.  Status Types MUST be numeric values between 0 and 255.  Status types described by this specification comprise: </del> <ins> This document creates a registry in iana-status-types that includes the most common Status Type values.  Additional values may defined for particular use cases.  Status Types described by this document comprise: 0x00 - "VALID" - The status of the Referenced Token is valid, correct or legal. 0x01 - "INVALID" - The status of the Referenced Token is revoked, annulled, taken back, recalled or cancelled. 0x02 - "SUSPENDED" - The status of the Referenced Token is temporarily invalid, hanging, debarred from privilege.  This state is reversible. </ins> <del> 0x00 - "VALID" - The status of the Token is valid, correct or legal. </del> <ins> 0x03 - "APPLICATION_SPECIFIC_3" - 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. </ins> <del> 0x01 - "INVALID" - The status of the Token is revoked, annulled, taken back, recalled or cancelled.  This state is irreversible. </del> <ins> 0x0E - "APPLICATION_SPECIFIC_14" - 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. </ins> <del> 0x02 - "SUSPENDED" - The status of the Token is temporarily invalid, hanging, debarred from privilege.  This state is reversible. </del> <ins> 0x0F - "APPLICATION_SPECIFIC_15" - 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. </ins> The Status Issuer MUST choose an adequate "bits" (bit size) to be able to describe the required Status Types for the application.
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
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.
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
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 3.1.1. </del> <ins> 4.1.1. </ins> The following rules apply to validating the "status" (status) claim The claim value MUST be a valid JSON object. The claim value object MUST contain a "typ" (type) attribute with <del> a string based value that represents the type of status list </del> <ins> a string based value that represents the type of Status List </ins> referenced.  The value MUST be equal to that of the "typ" <del> attribute in the "status_list" claim for the referenced status list. </del> <ins> attribute in the "status_list" claim for the referenced Status List. </ins> The claim value object MUST contain an "idx" (index) attribute with a numberic based value that represents the index to check for <del> status information in the status list for the current JWT.  The </del> <ins> status information in the Status List for the current JWT.  The </ins> value of this attribute MUST be a non-negative number, containing a value of zero or greater.  Refer to xx for details on the validation procedure. The claim value object MUST contain a "uri" attribute with a <del> string based value that identifies the status list containing the </del> <ins> string based value that identifies the Status List containing the </ins> status information for the JWT.  The value of this attribute MUST be a uri conforming to <del> 3.2. </del> <ins> 4.2. </ins> <del> The following rules apply to validating a JWT based status list. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating a JWT based Status List Token.  Application of additional restrictions and policy are at the </ins> discretion of the verifying party. The JWT MUST contain an "iss" (issuer) claim that contains a
The claim value object MUST contain a "typ" (type) attribute with a string based value that represents the type of status list referenced.  The value MUST be equal to that of the "typ" <del> attribute in the "status" claim for the token who's status is being validated. </del> <ins> attribute in the "status" claim for the Referenced Token who's status is being validated. </ins> The claim value object MUST contain a "lst" (list) attribute with a string based value that represents the status values for all the <del> tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </del> <ins> Referenced Tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </ins> <del> 3.3. </del> <ins> 4.3. </ins> This document formally defines the "revocation-list" status list type which applies the following additional validation rules beyond those <del> described in jwt-format-and-processing and jwt-status-list-format- and-processing. </del> <ins> described in jwt-referenced-token and jwt-status-list-format-and- processing. </ins> The "uri" attribute contained within a JWT using the "status" claim MUST be an HTTPS based URL that when resolved via an HTTPS GET
TODO add more <del> 4. </del> <ins> 5. </ins> <del> 4.1. </del> <ins> 5.1. </ins> TODO elaborate on risks of incorrect parsing/decoding leading to erroneuos status data <del> 4.2. </del> <ins> 5.2. </ins> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data <del> 4.3. </del> <ins> 5.3. </ins> TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section <del> 4.4. </del> <ins> 5.4. </ins> TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture <del> 5. </del> <ins> 6. </ins> <del> 5.1. </del> <ins> 6.1. </ins> TODO elaborate on herd privacy, size of the status list <del> 5.2. </del> <ins> 6.2. </ins> TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list <del> 5.3. </del> <ins> 6.3. </ins> TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO
are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms <del> 5.4. </del> <ins> 6.4. </ins> <del> TODO elaborate on issuers generating unique status lists per JWT token that do not offer herd privacy </del> <ins> TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy </ins> <del> 5.5. </del> <ins> 6.5. </ins> TODO elaborate on increased privacy if the status list is hosted by a <del> third party instead of the issuer reducing tracking possiblities </del> <ins> third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider?  An entity that hosts the Status List as a resource for potential verifiers.  The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. </ins> <del> 6. </del> <ins> 7. </ins> This document has no IANA actions.
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.
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.
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":