jiebi/CodeConvo huggingface dataset:
Code change:
From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Related discussion:
text: 10.11. <del> Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the </del> <ins> RFC8725 describes the use of explicit typing as one mechanism to prevent confusion attacks (described in RFC8725) in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially subject to such confusion attacks, so in the absence of other techniques, it is RECOMMENDED that application profiles of SD-JWT specify an explicit type by including the </ins> header parameter when the SD-JWT is issued, and for Verifiers to check this value. <del> When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.  The definition of </del> <ins> When explicit typing using the header is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD- JWT.  The definition of </ins> in Section 4.1.9 of RFC7515 recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the header parameter. <ins> Use of the content type header parameter to indicate the content type of the SD- JWT payload can also be used to distinguish different types of JSON objects, or different kinds of JWT Claim Sets. </ins> 11. The privacy principles of ISO.29100 should be adhered to.
Code change:
From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Related discussion:
text: We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, Dale Bowie, David Bakker, David <del> Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Michael B.  Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Waite, Dick Hardt, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Michael B. Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> Special appreciation is extended to Martin Thomson, who wielded his considerable intellect and influence to change a single occurrence of
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: explicit_typing for more details. It is the Issuer who decides which claims are selectively disclosable <del> and which are not.  End-User claims MAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case.  See sd-validity-claims for </del> <ins> by the Holder and which are not.  Claims MAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case.  See sd-validity-claims for </ins> considerations on making validity-controlling claims such as selectively disclosable.
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: MUST be used. <del> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </del> <ins> This claim value is a case-sensitive string with the hash algorithm identifier.  The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </ins> To promote interoperability, implementations MUST support the
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: 4.3.2. <del> The Verifier MUST ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key.  For example, if the SD-JWT contains a </del> <ins> Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it belongs to.  See key_binding_security for security considerations. If the Verifier requires Key Binding, the Verifier MUST ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key.  For example, if the SD-JWT contains a </ins> value with a member, the Verifier would parse the provided JWK and use it to verify the Key Binding JWT. <del> Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it belongs to.  See key_binding_security for security considerations. </del> <ins> Details of the Validation process are defined in verifier_verification. </ins> 5.
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: Holder about having received a complete set of Disclosures.  That is, for some digest values in the Issuer-signed JWT (which are not decoy digests) there may be no corresponding Disclosures, for example, if <del> the message from the Issuer was truncated. It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed. </del> <ins> the message from the Issuer was truncated.  It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the user when needed. </ins> 7.2.
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: implicitly pressure Verifiers into collusion by incentivizing participation in their larger ecosystem.  Deployers of SD-JWT must be aware of these potential power dynamics, mitigate them as much as <del> possible, and/or make the risks transparent to the End-User. </del> <ins> possible, and/or make the risks transparent to the user. </ins> Contrary to that, Issuer/Verifier unlinkability with an honest Verifier can generally be achieved.  However, a callback from the
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: 10.2. <del> Wherever End-User data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national </del> <ins> Wherever user data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national </ins> identity service.  For example, in OpenID Connect OpenID.Core, signed ID Tokens can be stored by Relying Parties.  In the case of SD-JWT, Holders have to store SD-JWTs, and Issuers and Verifiers may decide to do so as well. Not surprisingly, a leak of such data risks revealing private data of <del> End-Users to third parties.  Signed End-User data, the authenticity of which can be easily verified by third parties, further exacerbates the risk.  As discussed in key_binding_security, leaked SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys.  Altogether, leaked SD-JWT credentials may have a high monetary value on black markets. </del> <ins> users to third parties.  Signed user data, the authenticity of which can be easily verified by third parties, further exacerbates the risk.  As discussed in key_binding_security, leaked SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys. </ins> Due to these risks, systems implementing SD-JWT SHOULD be designed to minimize the amount of data that is stored.  All involved parties
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: Holders SHOULD store SD-JWTs only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the private Key Binding key.  Decentralized storage of data, e.g., on <del> End-User devices, SHOULD be preferred for End-User credentials over </del> <ins> user devices, SHOULD be preferred for user credentials over </ins> centralized storage.  Expired SD-JWTs SHOULD be deleted as soon as possible. After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT or the respective Disclosures if they contain privacy-sensitive data. It may be sufficient to store the result of the verification and any <del> End-User data that is needed for the application. </del> <ins> user data that is needed for the application. </ins> 10.3. If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the <del> End-User's personal data or correlate the information with previous uses of the same SD-JWT. </del> <ins> user's personal data or correlate the information with previous uses of the same SD-JWT. </ins> Usually, transport protocols for issuance and presentation of credentials are designed to protect the confidentiality of the
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: any encryption mechanism. Implementers MUST ensure that the transport protocol provides <del> confidentiality if the privacy of End-User data or correlation attacks by passive observers are a concern. </del> <ins> confidentiality if the privacy of user data or correlation attacks by passive observers are a concern. </ins> To encrypt the SD-JWT when transmitted over an insecure channel, implementers MAY use JSON Web Encryption (JWE) RFC7516 by nesting the
Code change:
should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"

Related discussion:
text: the existence of particular claims) can be a side-channel disclosing information about otherwise undisclosed claims.  In particular, if a claim in an SD-JWT is present only if a certain condition is met <del> (e.g., a membership number is only contained if the End-User is a member of a group), the Issuer SHOULD add decoy digests when the condition is not met. </del> <ins> (e.g., a membership number is only contained if the user is a member of a group), the Issuer SHOULD add decoy digests when the condition is not met. </ins> Decoy digests increase the size of the SD-JWT.  The number of decoy digests (or whether to use them at all) is a trade-off between the <del> size of the SD-JWT and the privacy of the End-User's data. </del> <ins> size of the SD-JWT and the privacy of the user's data. </ins> 10.5.
Code change:
No good nit goes unaccepted
In Section 4.1.1 Hash Function Claim it's stated that: I've seen this reference and similar phrasing in other recent specifications and it's never indicated whether these values are case-sensitive or not. Perhaps this is fault of RFC 6920 not being explicit on the matter, but being vague here creates interop issues; I've already witnessed one regarding this very claim. Should these values be considered case-sensitive or not?
I guess it doesn't say so explicitly but the intent is absolutely that the values be considered case-sensitive. We can maybe add a brief statement to that effect.
adds one sentence indicating case-sensitivity.
Excellent, thank you!
Just for clarification, are sha-256 and SHA-256 different claim?
yes, sha-256 and SHA-256 are different
Good Thank you :)
assuming my small nit gets accepted

Related discussion:
text: MUST be used. <del> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </del> <ins> This claim value is a case-sensitive string with the hash algorithm identifier.  The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </ins> To promote interoperability, implementations MUST support the
Code change:
Issue and . Describing the concept of holder binding and giving minimum directions on: find pubKey in SD-JWT Sign SD-JWT-R using privKey bound to a pubKey in SD-JWT but leaving details to the profiles and implementations.

Related discussion:
text: case, the mechanisms defined in this document can be used for many other use cases as well. <del> Note: so far agreed to define holder binding (user's public key contained inside an SD-JWT) as an option.  It is not mandatory since holder binding is use case specific and orthogonal to the general mechanism of selective disclosure defined here. </del> <ins> This document also describes holder binding, or the concept of binding SD-JWT to a key material controlled by the subject of SD-JWT, which is optional to implement. </ins> 1.1.
Code change:
Issue and . Describing the concept of holder binding and giving minimum directions on: find pubKey in SD-JWT Sign SD-JWT-R using privKey bound to a pubKey in SD-JWT but leaving details to the profiles and implementations.

Related discussion:
text: 4.3. <ins> Some use-cases MAY require holder binding. Information about the key material controlled by the holder MUST be communicated in SD-JWT.  How the public key is included in SD-JWT is out of scope of this document.  It can be passed by value or by reference.  Examples in this document use Claim to include raw public key by value in SD-JWT. Holder MUST sign SD-JWT-R using the private key associated with the public key included in SD-JWT. Verifier MUST verify that the signature on SD-JWT-R using the public key information in SD-JWT. 4.4. </ins> A verifier checks that The detailed algorithm is described below.
Code change:
In some use cases of SD-JWT, the key for what we currently call Holder Binding may not be bound to a holder (but, for example, to a device). We should therefore consider renaming Holder Binding to Key Binding.
PRs have been merged
The spec currently does not contain a reference for RFC 7519 (JWT), which it clearly needs to. It also uses RFC 7515 (JWS) as the citation for JWT in several place, which is incorrect. Please add a RFC 7519 (JWT) reference and cite it the first time that the term JSON Web Token (JWT) is used in the body of the spec (but not in the abstract). And look at the current uses of RFC 7515 and correct those that should be RFC 7519.

Related discussion:
text: 1. <del> The JSON-based content of signed JSON Web Token documents as defined in RFC7515 is secured against modification using digital signatures. A consumer of a JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving a JWT can read all contents of the document. </del> <ins> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </ins> A common use case is that the signed document represents a user's identity credential, created by an issuer.  The issuer includes the
Code change:
In some use cases of SD-JWT, the key for what we currently call Holder Binding may not be bound to a holder (but, for example, to a device). We should therefore consider renaming Holder Binding to Key Binding.
PRs have been merged
The spec currently does not contain a reference for RFC 7519 (JWT), which it clearly needs to. It also uses RFC 7515 (JWS) as the citation for JWT in several place, which is incorrect. Please add a RFC 7519 (JWT) reference and cite it the first time that the term JSON Web Token (JWT) is used in the body of the spec (but not in the abstract). And look at the current uses of RFC 7515 and correct those that should be RFC 7519.

Related discussion:
text: algorithm is used, i.e., the document is not signed. <del> In any case, the result is encoded as described in RFC7515 (here for </del> <ins> In any case, the result is encoded as described in RFC7519 (here for </ins> Example 1): (Line breaks for presentation only.)
Code change:
feat: Minimum length of the salt feat: weak hash algorithms to not use
mh ... we already have in Section
NAME I commited your suggestion I'm not sure that the normative language could be used in the considerations but it's good anyway to me, it's intellegibile :)

Related discussion:
text: 7.3. <ins> The length of the randomly-generated portion of the salt MUST be at least 128 bits. 7.4. </ins> For the security of this scheme, the hash function is required to have the following property.  Given a claim value, a salt, and the resulting hash, it is hard to find a second salt value so that equals the hash. <del> 7.4. </del> <ins> Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. 7.5. </ins> TBD
Code change:
changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Related discussion:
text: parameters for the <del> response header defined by RFC6750, which the resource server can use to explicitly communicate to the client the required authentication strength or recentness. </del> <ins> authentication scheme challenge defined by RFC6750, which the resource server can use to explicitly communicate to the client the required authentication strength or recentness. </ins> The client can use that information to reach back to the authorization server with an authorization request specifying the