The rules for obtaining the issuer metadata needs to be extended to cope with paths as well. I suggest to use the text from URL
The following example is already supported ... NAME is this what you had in mind, or is there anything missing? In that case, we could add an example that makes it more visible that this use case is supported.
URL needs to be URL have a look at URL
Ok, makes sense. Will create a PR to fix that.


NAME can we merge this now?
Try to find a new term.
Introduce and use the term "unsecured payload" instead of payload or credential to refer to the input JSON document. We cannot use payload because it would lead to confusion since the payload of the SD-JWT might not even contain all the claims and only the hashes.


I'm not sure whether we really need a comprehensive description of the issuer-holder-verifier model. I think what is needed is a description why JWT is not suitable and why SD-JWT is to motivate VC-SD-JWT. Note: we also have a duplication of term definitions between intro and terminology section
lgtm now


This just fixes typos and references.
This just fixes typos and references. No review required at this stage.


Only minor editorial changes such as typos.
Only minor editorial changes such as typos -> no peer-review required at this stage.


Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?


first pass, will cover other sections later
I approve of the content in this PR. (I would use the GitHub "Approve" function, but it appears that I may need write or contributor access to the repository to be able to do so. Could that be added for me?)
These changes are all worthwhile improvements.


Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.


In this PR, I generalized the examples: Right now, there is a lot of repetition in the code for each of the three examples. With more examples (W3C VC) and more example code (claims merging) to come, things will get more complicated. I therefore moved the examples into a separate directory as YAML files. I used YAML, because this means that we can store all data required for each example as separate JSON documents in one YAML file (JSON is a subset of YAML). The code can now be called with a YAML file as the input and will run the demo for the example defined in the file. This will make it easier for us to add more examples in the future. Also in this pull request: Cleaned up the code to produce just one example each time - there is no need to calculate all examples when only one is used in each run Cleaned up the code to produce both the CLI output and the spec examples from the same set of data to avoid repetitions This means that placeholders in URL are now strictly named as follows: , where refers to the identifier of the data produced in the example run (see file). Fix for example output: serialized SVC was not shown, but serialized SD-JWT twice Renamed to (not sure what was meant to say) Fix for norandomness: RNG was seeded to static value even when no_randomness was not used
Yes, it was in my backlog, thanx. This first proposal was to get all the examples in a single shot, we can add a CLI parameter, I'll have a look for that This means that placeholders in URL are now strictly named as follows: example-{exampleid}-{artifactid}, where artifactid refers to the identifier of the data produced in the example run (see sdjwt file). Thank you, I wanted to make a proposal for this, you did it My bad it was "selected example" but artifacts is better anyway OK!


addresses Issue
NAME considering the last OOP refactor on the python code and the revision of Brian probably it would be easier to close this PR and starting a new one on top of the current master branch, the changes in the code and in the text are very trivial
NAME ok, please do a PR directly to this branch :)


Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT


PR for URL
Done, and also cleaned up the intro slightly (repeating 'document' is superfluous there).


added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged


reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.


Addresses Issue
I also revisited the security recommendations for the salt and made some smaller changes there.
user has 2 SD-JWTs from the same issuer, same blinded claim names can be used to correlate the user. advice to have a fresh blinded claim name for each credential.
Instead of opening a new issue from our conversation this morning - here is the excerpt & suggestion from the document we discussed: First off, maybe it's informational or maybe it's specified - issuers should not include "secrets" in claim labels. If a label for something is actually a secret, it should be treated as such. That said, I get that this scenario must be addressed. Sensitive predicates or graduated disclosure contexts can benefit from this capability. It seems to me that the most useful and easy algorithm to implement is to use the same hash algorithm + salt for the node value to blind the label where: SALTED LABEL = HASHALGO(LABEL + SALT) Of course, this assumes that specific guidance is included for best practice salt generation (fresh entropy gathering for each attribute block salt, sufficient bits of entropy, etc.) for strong cryptographic outcomes. In this representation, the salted hash of the label's value ("name") "9-J2445ap91..." can be addressed directly by the digest "h" value in compact form: Side-note: Informative statements that recommend large sd-jwt claim sets should be 'broken down' into much smaller sets, or individual claims, then wrapped and sealed as a JWP may be better than including too many claims in an sd-jwt.
Right now, it is RECOMMENDED that a random string is chosen for the blinded claim name. HMAC(salt, claim-name) and HASHALGO(LABEL + SALT) would be fine as well, but there's more room for errors, especially as holders/verifiers might expect a specific format and then reject an SD-JWT when, e.g., the issuer chose a wrong encoding or similar. I don't see a real advantage of using HMAC/HASHALGO for the blinded claim name. I therefore propose to stick with the current recommendation. We should stress that a fresh random value must be chosen for each claim in each issued credential.
NAME it's not super clear to me how: would alleviate your concerns here: "but there's more room for errors, especially as holders/verifiers might expect a specific format and then reject an SD-JWT when, e.g., the issuer chose a wrong encoding or similar" Maybe I'm missing something obvious but I don't see much difference in how holders & verifiers would treat these various approaches. They still have to reconcile with the encoding and/or hashing algorithms expressed in the security envelope.
My point was about the selection of the blinded clame name (or 'placeholder claim name' as it is called in the current draft). We have two options on the table: Select a random string as the placeholder Select the placeholder as some function of the original claim name (the label in your proposal) and the salt What I wanted to express is that I think option 1 is better. From a security perspective, both are equivalent. There is no need to choose the placeholder claim name in a particular way, we just need to ensure that it does not leak information about the original claim name. Just numbering all placeholder claim names would be fine as well (as long as the numbering does not reveal anything, e.g., the position of the original claim in the list of claims.) But for option 2, I see two drawbacks: We need to explain more, in particular how to assemble the input for the function, similar to the discussion we had about the hidden claim values. For example, we need to define how the original claim name and the salt are concatenated such that there can be no prefix collisions. A verifier receiving an SD-JWT with blinded claim names according to option 2 may be tempted to (needlessly) check that the claim name was created in a particular way by recalculating the hash. If the issuer has made a mistake when calculating the hash or the verifier makes a mistake, this check will fail. Since such a check is not needed, it would be better if we don't set this trap in the first place. I see no advantages of option 2 over option 1, so I propose to go for option 1.
I see, thanks for explaining that. I'm fine with option 1 if the goal is to reduce cognitive complexity for the application developers - it makes sense.
PR and PR
I agree with these changes, but it really made me think that we need to clarify various options we have introduced how claims in SD-JWT can be represented as it is becoming a bit hard to follow.. issue filed


addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR


I think we need a section summarizing what kind of claims SD-JWT can consist of... claims in SD-JWT can all be selectively disclosable claims, or can also include always-disclosed claims claim names in SD-JWT can all be blinded, or can include non-blinded claim names claim structure can be simple or complex and claims in the complex structure can be blinded/not-blinded and disclosable/not-disclosable same claim names can appear within multiple complex claim structures and can be blinded/not-blinded and disclosable/not-disclosable...


Added an option to do pairwise SD-JWTs to prevent Verifier/Verifier linkability Original feedback. Please re-write section 8.2 in the light of the above suggestions.


Fixing the "release" in the sense of a defined term as "SD-JWT Release"
We have fixed the term and definitions but a few still appear in the main text. We need to fix them as well, hopefully before the first individual draft is uploaded. So, s/signatures called releases/signatures called SD-JWT Releases/ s/SD-JWTs and releases/SD-JWTs and SD-JWT Releases/ s/Verifying a Release/Verifying a SD-JWT Release/
Fixed with PR


Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM


Add Justin to Acknowledgements (he suggested the array for _sd in sid…e meeting) and fix the commas + and in that list of names


As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity


for add a bit more context/background to the intro about the indented general applicability of SD-JWT and the relation to JWT and the OAuth WG


More explicitly state that SD-JWTs have to be signed asymmetrically (no MAC and no ) One item out of John Mattsson's review: URL Thanks for the review John. I've tried to reply to the comments inline below. MUST be signed using the Issuer's private key" in sec 5.2 .) but I think you're right that it should be explicit. I assume it would be a claim. Is there something that suggests otherwise to you? That "HOLDER-PUBLIC-KEY" only shows up in section 4.3 , which is supposed to be a somewhat abstract discussion about it. And I think it's separate from SD-CLAIMS and NON-SD-CLAIMS there to call attention to it. But not to suggest that it's not a claim. More generally (as sec 5.2.3. Holder Public Key Claim tries to describe) the specific way that holder public key binding is established by the issuer and represented in the JWT is out of scope. A "cnf" claim is used in examples for what it's worth. But the specific details of a holder public key binding claim are left to applications using or profiling SD-JWT. the hash input so as to make it infeasible to "reverse" the hash value by enumerating potential claim name/values into the hash function. Correspondingly a salt value is included in the disclosure structure directly alongside a claim name and value. I think using the word secret to talk about salt values would be problematic and potentially confusing. The salt values of undisclosed claims need to be hidden from parties to whom the claim isn't being disclosed. But the salts are sent from the issuer to the holder. And salts of disclosed claims are sent from the holder to the verifier. That's different from a typical secret (as I think of a secret anyway). We can look to add text or clarify text about not revealing salt values to unintended parties. that the "Issuer MUST ensure that a new salt value is chosen for each claim" and a "new salt MUST be chosen for each claim" in section 8.4 . I think that's what you mean by salts being independent of each other? Sec 8.5 has a 128-bit minimum length as RECOMMENDED. As I recall, there was some desire to allow for shorter salts when used with a more computationally expensive digest function and the RECOMMENDED would allow for that situation by basically saying to use at least 128 unless you have a good reason to do otherwise and understand the implications. I think "key" or "secret" are definitely not the right name and would be more prone to mislead or confuse. It's a random value that's included in the hash input (that otherwise has a more predictable value space) to make it infeasible to guess/confirm the claim name and value from the hash value. And ensure that the hash output will vary when hashing the same claim name/value more than once. disclosure structure (containing the claim name & value as well as the salt) is hashed and the digest value is placed in the "sd" claim of the signed JWT. Each (signed via inclusion in the JWT) digest value is an integrity check on, and reference to, the corresponding disclosure. Length extension attacks aren't applicable to this kind of use of the hash value. Any change to the disclosure content breaks the integrity check and any change to the hash value breaks the signature. Cheers, 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._


A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated) for issue
While looking at this I noticed URL only allows hash algs from the registry. URL removed the JOSE HMAC stuff but also removed allowing the hash alg to be "a value defined in another specification and/or profile of this specification" which I thought we wanted to have - for Christian's type use cases and extensibility in general. This isn't the right place for a discussion but wanted to note it somewhere before our call.
I think we intentionally removed “a value defined in another specification and/or profile of this specification” Because using that would require a separate profile and not just defining an identifier.
from this PR URL


Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.


This PR outlines security targets of SD-JWT. when merged it will replace PR and close issue .


When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL


Addresses issue . enveloping in a single signed JWT more than one Combined Format for Presentation without a Holder Binding JWT.


Fixes Issue
Thanks NAME I think the two folks should be acknowledged and the small change around the claim incorporated. Then I think this should be merged and we should publish a -04 as basically a bug fix. The issue NAME URL found kinda undermines the whole point of SD-JWT and we should have a published version out that fixes that.
When decoys are used (_sd members not corresponding to a disclosure are added) the says to I imagine this is not intended and the holder should ignore missing disclosures instead? Same in
Actually the following in doesn't make sense to me at all since the whole point is to selectively not release disclosures.
Good point/catch Filip. I think the intent was to say that if a disclosure is found that isn't referenced by a _sd hash value, that should be a rejection. But the language got turned around somewhat. I think anyway. It needs to be fixed or clarified regardless though.
Processing by the Holder: This seems fine to me. In the context, "the digests" refers to "the digests of the Disclosures". If there is a Disclosure that hashes to a digest not found in any _sd array, the SD-JWT is invalid. Maybe we can clarify by modifying this to: Verification by the Verifier: This is wrong and should read "If no such Disclosure can be found, the digests MUST be ignored." Thanks for bringing this up, Filip!
Don't we then also need something at the end of Verification by the Verifier - that makes sure all of the provided disclosures match a digest in the payload and reject if that is not the case or am I missing something here?
That would force the Holder to act correctly, but would it provide any benefit beyond that?
The changes above are included in PR - please review NAME NAME
PR merged


This fixes Issue . The main change is to better describe in which role the adversary acts.
does this one need a doc history entry... ?


To fix Issue , I found that removing Example 2b is the best way to go. I tried to fixate the nonces used in the examples despite decoys being generated in one of the examples, but that got quite messy and introduces a lot of unsafe code paths into the python code. An alternative would be to manage the example manually, but that is a source for errors, so let's not do that.
The decoy concept is intuitive enough that a separate example isn't needed, I think. And per the separate example that has a completely different set of digests might cause confusion. So removing 2b seems like a good course of action. The change is larger than I'd have expected. Are all the other file changes due to regenerating examples? I think so but it caught my attention. And it seems like and this will be difficult to resolve. But maybe you've already considered that.
Why remove an entire example, if we can add a text clarifying that "Example 2b uses the same data as 2a, but because even for the same claim values, different nonces are used, not just the decoys but all digests are different from those in 2a"?
That was my initial approach, but with that change there's really not that much value to the example: It just shows a bunch of digests, where the number of digests is higher than it was previously. The fact that the digests are different can be confusing for readers at worst and the example is not very helpful at best.
So instead of showing the decoy digests in the examples you propose to list them seperately and not show a complete example with decoy digests?
We agreed on our call to generate a snippet of markdown code to explicitly list the decoy digests to improve the explanation.
I updated the python script and the spec to show the decoy digests: URL
Other than the little nit about the the text that says the decoys in the example are about the address, this looks pretty good.
Do you want to mention something in the doc history?
Good point, done!
NAME Can you please review this?
states that it was created using data from , but adding decoy values. I'd expect its param to be a superset of example 2a's, but it's not the case. Am I missing something?
Example 2b includes different nonces than Example 2a. We try to use deterministic random numbers to generate the examples, but in this case, due to the order in which the decoys and regular salts are created, this approach does not produce the same nonces for the same "real" disclosures.
PR was merged


Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm


to
I think the first paragraph mixes Issuer with Verifier. Old: New:
Thanks for catching that. We'll fix.


Thanks, editorial comments taken.
Whether this format is JWT or JWT-like, the considerations in the still apply. Please consider adding a claim. cc NAME
Explicit typing via the header can and should be done by specific applications or types of SD-JWT. But this SD-JWT draft is defining the general JWT-like construct and explicit typing of the generic thing isn't particularly useful or meaningful.
The The next draft will have a media type and structured suffix that can help with specific applications or types of SD-JWT doing explicit typing FWIW URL
I would be open to adding one sentence in the draft saying "applications of SD-JWT SHOULD be explicitly typed". I agree there cannot be only one type for all SD-JWTs.
I'm not quite sure where to add that one sentence. And a bit more context might be needed with it. I'll see what I can figure out. Maybe a small section like 3.11 in rfc8725. But (helpful) suggestions/ideas would be welcome in the meantime.
Add this sentence at the end of 5.1: The header parameter is RECOMMENDED, see Sec. 5.1.4 for more details. And as a new Sec. 5.1.4, "Explicit Typing": A commonly seen attack is for one kind of JWT to be confused for another. Both regular JWTs as well as SD-JWTs are vulnerable to confusion attacks. To prevent these attacks, it is RECOMMENDED to specify an explicit type by including the header parameter when the token is issued, and for Verifiers to check this value. The relevant token's content type can be used, e.g. , but often a more application-specific value is preferred. See Sec. 3.11 of RFC 8725 for more details.
Thanks NAME I took some inspiration from you words in creating PR .
merged PR to close this one
Thanks for preparing this! LGTM, just two small editorial comments.


Honestly, I'm not sure about this one. But I said I'd put together a PR for with an update to the title and some qualifying text. So this is that PR as something to discuss anyway. At least these few sentences took me an embarrassingly long time to write :/


RIPEMD-160 is usable, but not its predecessors. For this reason this PR removes RIPEMD-160 from the list of the weak algs by saying that only -160 predecessors must not be used.
Thank you!


Text looks good but it's going to clash with the array spec work URL
It's a small change, we can sort that out when merging either.
Now that is allowed at multiple locations in the JSON document, including recursively, I would expect Sec. 5.1.2 to define explicitly where the claim should appear. Once at the top of the document? Can it also appear alongside claims located deeper in the document? Also, please change the section heading from "hash function" to "hash algorithm", for consistency.
Thank you! The intention is that there is only one at the top level. We will clarify.
Concur with NAME
+1


changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.


This solves Issue by moving away from an example that wasn't ideal anyway (it encoded a different bytestring for the value Möbius). The Disclosure JSON should be:
"it shows as is there any way to change that..? (this is not the change introduced in this PR)" on the text in the doc at URL "A different way to encode the umlaut (two dots &; placed over the letter):" Originally posted by NAME in URL
Not sure why this broke now. I created a PR because the example wasn't ideal anyway: URL
I just noticed that the PR does not fully solve the problem. We have the same problem somewhere else as well: !
it's seems to have been an issue at least back to -01 URL and/or -02 URL (so basically since inception). I'm sure we could fight with the tool chain to fix it. But at what cost? I'm inclined to just reword that "The two representations... " part to make the issue go away. Which I did with this 48efde35a81ca3520eb30ceea6c43d62e8cd96f8 update to URL
PR merged


I've seen the "new" title from 332ded8faf20d528c5c05e04cebed28aab1a0d33 a few times in context now and it is really awkward.
yup, that updated intro and abstract text stays
as long as the intro text itself stays as we updated it, this makes sense to me.


I noticed that the consolidation of SD-JWT terminology in c6a27373dee13cc7c3f70a8b7fd374e62306f5a0 introduced a mistake in the "Enveloping" section title by including the word "Presentation" while the section talks about enveloping either issued or presented SD-JWTs. While fixing that, I decided to remove the SHOULD recommending the use of an unregistered claim name . I also tried to align the example enveloping payload a bit with a move minimal set of claims similar to those used in key binding. I realize I probably should have just fixed the section title and not expanded the scope of the changes. But there I was and these few little changes were so inviting... See it here: URL


update: agreed to replace SD-JWT VC example with PID. agreed to have only one sd-jwt vc example, so this will also address and
The and the editor's draft didn't get generated - URL 404s
fixed - thank you, Brian!
NAME Binding design and the usage of biometrics data is based on your original PR 210. Shall we replace 4a example with this one? But if you don’t see the need for this example anymore, I am not going to die on this hill.
Thinking about this just a little more NAME does this warrant a doc history bullet? Something like: Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework The history is nice to have and I often use it as a starting place when making "what's changed from last time" type slides for f2f meetings.
I'm just gonna add the doc history to keep things moving here... and done w/ 08d70d2fbfcb1afce5e2d088cb97934b91ce83a1
relevant section in the editor's copy preview: URL should anyone want to take a look before the coming soon merge NAME NAME @ etc
I think this is ready to merge (for real this time). It's kinda awkward process and numbers wise with Dr. out. And peppelinux is still listed as requesting changes but I think his comments were addressed. But I think it's good to go. Approved with two pendings suggestioni/change request and a general comment that's not relevant for the revision but Just informative


as additional explanation in the draft for see it here URL
in this PR might be replaced with depending on how PR goes.
Thanks, LGTM, just one editorial comment.


replaces , addressing issue I also cleaned up example structure, so that it is the same and uses the same language across multiple examples.


first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.


URL
I was wondering if there might be a mistake in the encoding of the address given in example 4: The documentation says: I assume this should be ? It looks like the claims where added to the list on error and there is a missing hash. I would expect to see some additional disclosure elements for postal_code, ... (each with a nonce) similar to instead.
Thanks for catching that! There is definitely a mistake in Example 4a. But it looks like the problem has to do with decoy digests in that example. The decoys listed at URL got pulled from the wrong place and so don't match up with the other example content, which includes the address claim Disclosure you've pointed. That all makes parts of that Example 4a problematic and hard to follow. I think it'd be best addressed by not including decoys in Example 4a. This is related: URL FWIW
PR aims to fix this. A preview from that PR of that example: URL and specifically the Disclosure for address: URL
Thanks for the quick response! That looks much better. I was expecting the address to be passed in a way that allows the selective disclosure of single items (e.g., only the post code). Maybe you can add an additional comment which of the three options in 5.7 every example uses (here 5.7.1). To me, having three options in 5.7 makes it unnecessarily complicated. and 5.7.3 are basically the same when you would allow having non-selectively disclosable items in this as well. If that would be the case, this could probably also handle all cases 5.7.2 would be used for.
Thanks for reporting this and NAME thanks for the quick fix! NAME The options in 5.7 are meant to show what is possible with SD-JWT and are not meant to restrict or define how can be encoded. It is up to the issuer to decide for each claim whether it should be SD or not. Options 1-3 just show some of the possible results. I'm not sure I'm following what you mean by "having non-selectively disclosable items in this as well". Could you give an example?
I created this PR to ensure that our wording around the options is clear in that the options are non-normative and not exhaustive: URL
I was wondering, if 5.7.1 would allow to have non-selectively disclosable items in the address claim: This single definition could then cover all use cases of 5.7.1,5.7.2, and 5.7.3. But i see what you are up to (thanks for ). You do want to leave a maximum flexibility. However, i am a bit concerned of "creative" uses of what is technically possible and how to make sure to be able to parse/process all possible combinations in the openid4vp context.
Yes, this mixture is possible within the current specification. With the algorithm defined in Section 6.3 there is no need (for the Holder) to be aware of all possible combinations. (In other words, such assumptions should never be hard coded.) It is just the Issuer that has to make a decision on which pattern to use.
Sure, this should never be hard coded. However you need e.g., to come up with a user friendly way of displaying that kind of information in a wallet context. It is a challenge to find an intuitive/understandable way to inform the user which information will or can be disclosed and so on. But this is becoming way to off-topic ;) Thanks for your quick response!
URL merged
I don't know why but I think we should have more examples, but not going to go against these changes.


In response to Issue : Changed some words to ensure that the examples are not understood as an exhaustive list of possible structures Added note on non-normativity of examples Removed the word Option in the section titles and the numbers to avoid the notion of an exhaustive list of options


-Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses


Added JWT claims registration requests to IANA (to fix issue ) URL
This was meant as a placeholder/reminder for JWT Claims Registration requests to IANA that would be needed eventually. The and claims should be registered. I'm not sure about to be honest, which is ironic b/c I'm supposed to know about such things (see the so-called experts ). But it's somewhat different than the other claims in the registry. But, I dunno, requesting registration is probably the way to go w/ .
I share your unsureness, and agree that requesting registration is the way to go. btw in the spec, we have a text registered claim, so if we decide not to register it, that text needs to be updated.
Wait... really, where?
PR has been merged.


based roughly on feedback from Anders to draft-ietf-oauth-selective-disclosure-jwt at URL


for and based largely on text suggested on list by Neil Madden
from this thread URL Neil Madden has suggested the following for "Choice of a Hash Algorithm" section. I think (with maybe some minor tweaks) the text works and it would also address issue .
Saying something about matching the strength of hash function and signature algorithm would probably be worthwhile. resulting from this thread URL / URL etc "... indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms."
How to actually write this in an appropriate way for a draft RFC feels kinda tricky though. JWE has some text about using that I was hopping to borrow from but the context is (unsurprisingly) different enough that using text straight from it doesn't quite work. Maybe adding a very general statement in would be sufficient.
At IETF 118 Tuesday meeting, Orie proposed locking the hash to the one committed to by the Issuer. Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden wrote: Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want. verification and processing rules (this one specifically ). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft. A more sophisticated version of this “attack” illustrates the need for prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use. And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: URL signature algorithm would probably be worthwhile. Furthermore, preimage resistance is not a sufficient property to ensure section-11.5 along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”. We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversible. Can you perhaps suggest some text? Or could we just replace “preimage resistant” with “irreversible” in that text in 11.5? And maybe qualify that text a bit more too with something like “infeasible to calculate the salt and claim value (or any portion thereof) that results in a particular digest”. current venue. And as the end of the draft’s intro states, “this specification aims to be easy to implement and to leverage established and widely used data formats and cryptographic algorithms” which is why a regular old secure hash function is being used - SHA-256 specifically and as the default, which I believe is completely suitable for the purpose. It seems like some tightening up or changes around the approach provided for hash algorithm agility might be in order. But I think the overall salted hash based approach is okay/appropriate/sufficient. “inclusion in the [...] registry alone does not indicate a hash algorithm's suitability for use in SD-JWT” after attempting to describe what makes a hash algorithm suitable for use with SD-JWT. We wanted to allow for some hash algorithm agility but really didn’t want to create yet another hash algorithm registry. That "Named Information Hash Algorithm Registry" isn’t an ideal fit but was the best one we were able to find. Pointing to that registry and having the associated security considerations seemed like a reasonably reasonable approach. originally) and I’m very reluctant to make any such statements that venture into legal territory. model implies/assumes that an Issuer issues a token with no idea of where it’ll be presented and having a shared symmetric key seemed really weird in that situation. Also had to explain why or how a shared symmetric key would work in that situation too. That said, there’s been some talk about loosening that restriction - largely around the same reasoning on deniability that you cite - I guess your comment here should be taken as supportive of that prospective change? hard-wired set of claims/constraints enforced/required by verifiers is appropriate and necessary even when selective disclosure isn’t at play. It’s how regular JWT works (or should work) in practice already. And don’t think it harms future evolution because any new security constraints would necessarily need updates all around because they won’t be understood otherwise. The 11.8 section could perhaps be stronger in saying that claims controlling the validity of the token shouldn’t be made selectively disclosable. But what exactly constitutes such a claim is actually rather murky and there are undoubtedly exceptions like you point out with “aud”. And I know some have expressed the need/desire to have key/holder binding type claims (such as “cnf” but not only that) be made selectively disclosable for privacy reasons. I also don’t think a new registry would really help the situation. At this level we're describing a generic mechanism and don’t necessarily even have a list of all claims that could be interpreted as constraints in a particular context or application. Note, for example though, that URL does say that certain claims must be included directly and not made selectively disclosable. Which leads back to ultimately needing that requirement that Verifiers ensure that all the claims they deem necessary are present (in the clear or disclosed) when checking the validity and accepting the token. It’s not meant to preclude that kind of thing (and reading it again, I don’t think it does preclude it). But rather to just say that whatever the Verifier’s requirements on key binding are have to be based on its policy and not on the content of the token (some of which could be manipulated by the holder). A Verifier’s policy could, as you describe, afford different levels of access based on different security characteristics of the presented token/credential. Or the Verifier’s requirements could, for example, say that for credential type A, Key Binding is always required, while for credentials of type B, it is only required when the credential was issued by an issuer that is known to issue credentials supporting Key Binding. 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.
Hi Brian, Apologies for the late reply. I think we’re closing in on agreement here. Comments and some wording suggestions inline below. How about the following? — To ensure privacy of claims that are not being selectively disclosed in a given presentation, the hash function MUST ensure that it is infeasible to calculate the salt and claim name and value (or any portion thereof) that results in a particular digest. This implies the hash function MUST be preimage resistant, but should also not allow an observer to infer any partial information about the undisclosed content. In the terminology of cryptographic commitment schemes, the hash function MUST be computationally hiding. The hash function MUST be second-preimage resistant. For any salt and claim value pair, it is infeasible to find a different salt and claim value pair that result in the same digest. The hash function SHOULD also be collision resistant. Although not essential to the anticipated uses of SD-JWT, without collision resistance an Issuer may be able to find multiple disclosures that have the same hash value. The signature over the SD-JWT would not then commit the Issuer to the contents of the JWT, which is surprising. Where this is a concern, the collision resistance of the hash function SHOULD match the collision resistance of the hash function used by the signature scheme. For example, use of the ES512 signature algorithm would require a disclosure hash function with at least 256-bit collision resistance, such as SHA-512. — (I’d like to add an informational reference defining these terms, but I can’t find a good one - even the NIST/FIPS standards seem to just take terms like “collision resistance” for granted, so maybe we can too?) The current wording of section 11.6 says: “Verifiers MUST NOT take into account […] whether Key Binding data is present in the SD-JWT or not[…]” While 11.8 says: "Verifiers therefore MUST ensure that all claims they deem necessary for checking the validity of the SD-JWT are present (or disclosed, respectively) before checking the validity and accepting the SD-JWT" I think these constraints do rule out the migration path that I described. I don’t see how a service could incrementally and securely roll-out support for Key Binding (for example) over time—starting from a base ecosystem that isn’t using Key Binding. Either they would have to suddenly require Key Binding, and therefore start rejecting clients that haven’t updated yet, or they may have the situation where a stolen key-bound SD-JWT can be treated as a simple bearer token by not selectively-disclosing the cnf claim. Concretely, I think these phrases and section 8.4 should be removed/re-written. How about the following: — An Issuer MUST NOT allow any security-critical claim to be selectively disclosable. The exact list of “security-critical” claims will depend on the application, and SHOULD be listed by any application-specific profile of SD-JWT. The following is a list of standard claim names that SHOULD be considered as security-critical by any SD-JWT Issuer: “iss” (Issuer) “aud” (Audience), although issuers may want to allow individual entries in the array to be selectively-disclosable “exp” (Expiration Time) “nbf” (Not Before) “iat” (Issued At) “jti” (JWT ID) In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively disclosable. Best wishes, Neil
I’ve had a look through this new draft and I have some comments and questions. Some of which are similar to comments I already raised [1], but haven’t been addressed. Are we concerned about Holders and Issuers colluding? For example, now that claim names are blinded an Issuer can add the same claim multiple times with different, potentially contradictory, values and then the Holder can selectively release one disclosure to one Verifier and a completely different one to another Verifier. This seems problematic at least, that the “same” credential could be interpreted differently by different parties. A more sophisticated version of this “attack” illustrates the need for collision resistance in the hash function, not just preimage resistance as stated in the draft (and already raised by me in [1]). If the hash is not CR then a malicious Issuer can find colliding [salt, key, value] triplets that have the same hash value, give one to the Holder and then later claim that they actually signed the other one. (This is not just theoretical, similar attacks have been used to create fraudulent SSL certificates [2]). This also indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms. Furthermore, preimage resistance is not a sufficient property to ensure confidentiality of withheld claims. Preimage resistance holds if the attacker cannot recover the exact input that produced a given hash value, but it doesn’t preclude the attacker being able to recover partial information about that value. For example, consider the hash function H(x) = SHA-256(x) is concatenation). This hash function when applied to SD-JWT is preimage resistant (assuming the salt is strong), but leaks the last 10 bytes of the claim value. The appropriate security definition for SD-JWT is some form of cryptographic commitment scheme [3], with the associated security notions of hiding and binding. Honestly, I still think that this WG is not an appropriate venue for this kind of novel (in the OAuth world) cryptographic scheme and external review by experts would be helpful. All of this suggests that simply referring the the IANA hash function registry is not sufficient, as probably most of the entries there are not actually suitable for use in SD-JWT for one reason or another. Some other comments: The original JWT RFC [4] has this to say about the order of encryption and signatures: signatures over encrypted text are not considered valid in many jurisdictions. Presumably the same argument holds about signatures over blinded values? That should perhaps be noted at least. The draft repeatedly says that a symmetric signature algorithm (MAC) must not be used. Perhaps I’m missing something here, but why not? It doesn’t seem like it compromises any of the intended security properties. Use of a symmetric MAC may also limit the privacy impacts on users as it provides some measure of deniability (similar to that mentioned in section 12.1), as any Verifier in possession of the secret key could also have produced any claims that are subsequently leaked, allowing the user to deny that they were produced by the supposed Issuer. (This deniability property holds even without subsequent leaking of old signing keys). The security considerations about salt entropy should probably reference RFC 4086 (BCP 106) or something more up to date (maybe RFC 8937 too). I think section 11.8 about selectively disclosing contraints on the use of a SD-JWT is completely inadequate and will almost certainly lead to attacks. Requiring Verifiers to hard-wire the set of constraints they enforce is likely to be damaging to future evolution of the standard as new security constraints are added. It would seem especially problematic to allow selective disclosure of a “cnf” claim for example, and yet nothing forbids it and the history of JWT usage suggests that anything not forbidden will at some point happen (and even some things that are forbidden). I suggest establishing a registry of claims that are really usage constraints and forbidding issuers from allowing anything in that list to be selectively-disclosed. (There are perhaps some exceptions here, e.g. “aud” is a constraint in this sense but it probably does make sense for it to be selectively disclosed, but only on a per-array-item basis: that way a Holder cannot remove the constraint entirely but can still hide other “recipients”). On a related note, section 11.6 says that to avoid this kind of attack, Verifiers MUST NOT take into account whether a Key Binding is present or not to decide whether to require Key Binding. This seems to preclude Verifiers that can handle different levels of access with different security requirements and is the sort of requirement that makes it near impossible to incrementally evolve tougher security requirements over time. It effectively becomes an all-or-nothing switch that will have the likely effect of making the use of Key Binding less attractive. Security hardening should be the easy path if we want to see it adopted. Best wishes, Neil [1]: URL [2]: URL [3]: URL


for
"The security considerations about salt entropy should probably reference RFC 4086 (BCP 106) or something more up to date (maybe RFC 8937 too)." resulting from this thread URL / URL Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden wrote: Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want. verification and processing rules (this one specifically ). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft. A more sophisticated version of this “attack” illustrates the need for prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use. And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: URL signature algorithm would probably be worthwhile. Furthermore, preimage resistance is not a sufficient property to ensure section-11.5 along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”. We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversible. Can you perhaps suggest some text? Or could we just replace “preimage resistant” with “irreversible” in that text in 11.5? And maybe qualify that text a bit more too with something like “infeasible to calculate the salt and claim value (or any portion thereof) that results in a particular digest”. current venue. And as the end of the draft’s intro states, “this specification aims to be easy to implement and to leverage established and widely used data formats and cryptographic algorithms” which is why a regular old secure hash function is being used - SHA-256 specifically and as the default, which I believe is completely suitable for the purpose. It seems like some tightening up or changes around the approach provided for hash algorithm agility might be in order. But I think the overall salted hash based approach is okay/appropriate/sufficient. “inclusion in the [...] registry alone does not indicate a hash algorithm's suitability for use in SD-JWT” after attempting to describe what makes a hash algorithm suitable for use with SD-JWT. We wanted to allow for some hash algorithm agility but really didn’t want to create yet another hash algorithm registry. That "Named Information Hash Algorithm Registry" isn’t an ideal fit but was the best one we were able to find. Pointing to that registry and having the associated security considerations seemed like a reasonably reasonable approach. originally) and I’m very reluctant to make any such statements that venture into legal territory. model implies/assumes that an Issuer issues a token with no idea of where it’ll be presented and having a shared symmetric key seemed really weird in that situation. Also had to explain why or how a shared symmetric key would work in that situation too. That said, there’s been some talk about loosening that restriction - largely around the same reasoning on deniability that you cite - I guess your comment here should be taken as supportive of that prospective change? hard-wired set of claims/constraints enforced/required by verifiers is appropriate and necessary even when selective disclosure isn’t at play. It’s how regular JWT works (or should work) in practice already. And don’t think it harms future evolution because any new security constraints would necessarily need updates all around because they won’t be understood otherwise. The 11.8 section could perhaps be stronger in saying that claims controlling the validity of the token shouldn’t be made selectively disclosable. But what exactly constitutes such a claim is actually rather murky and there are undoubtedly exceptions like you point out with “aud”. And I know some have expressed the need/desire to have key/holder binding type claims (such as “cnf” but not only that) be made selectively disclosable for privacy reasons. I also don’t think a new registry would really help the situation. At this level we're describing a generic mechanism and don’t necessarily even have a list of all claims that could be interpreted as constraints in a particular context or application. Note, for example though, that URL does say that certain claims must be included directly and not made selectively disclosable. Which leads back to ultimately needing that requirement that Verifiers ensure that all the claims they deem necessary are present (in the clear or disclosed) when checking the validity and accepting the token. It’s not meant to preclude that kind of thing (and reading it again, I don’t think it does preclude it). But rather to just say that whatever the Verifier’s requirements on key binding are have to be based on its policy and not on the content of the token (some of which could be manipulated by the holder). A Verifier’s policy could, as you describe, afford different levels of access based on different security characteristics of the presented token/credential. Or the Verifier’s requirements could, for example, say that for credential type A, Key Binding is always required, while for credentials of type B, it is only required when the credential was issued by an issuer that is known to issue credentials supporting Key Binding. 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.
I’ve had a look through this new draft and I have some comments and questions. Some of which are similar to comments I already raised [1], but haven’t been addressed. Are we concerned about Holders and Issuers colluding? For example, now that claim names are blinded an Issuer can add the same claim multiple times with different, potentially contradictory, values and then the Holder can selectively release one disclosure to one Verifier and a completely different one to another Verifier. This seems problematic at least, that the “same” credential could be interpreted differently by different parties. A more sophisticated version of this “attack” illustrates the need for collision resistance in the hash function, not just preimage resistance as stated in the draft (and already raised by me in [1]). If the hash is not CR then a malicious Issuer can find colliding [salt, key, value] triplets that have the same hash value, give one to the Holder and then later claim that they actually signed the other one. (This is not just theoretical, similar attacks have been used to create fraudulent SSL certificates [2]). This also indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms. Furthermore, preimage resistance is not a sufficient property to ensure confidentiality of withheld claims. Preimage resistance holds if the attacker cannot recover the exact input that produced a given hash value, but it doesn’t preclude the attacker being able to recover partial information about that value. For example, consider the hash function H(x) = SHA-256(x) is concatenation). This hash function when applied to SD-JWT is preimage resistant (assuming the salt is strong), but leaks the last 10 bytes of the claim value. The appropriate security definition for SD-JWT is some form of cryptographic commitment scheme [3], with the associated security notions of hiding and binding. Honestly, I still think that this WG is not an appropriate venue for this kind of novel (in the OAuth world) cryptographic scheme and external review by experts would be helpful. All of this suggests that simply referring the the IANA hash function registry is not sufficient, as probably most of the entries there are not actually suitable for use in SD-JWT for one reason or another. Some other comments: The original JWT RFC [4] has this to say about the order of encryption and signatures: signatures over encrypted text are not considered valid in many jurisdictions. Presumably the same argument holds about signatures over blinded values? That should perhaps be noted at least. The draft repeatedly says that a symmetric signature algorithm (MAC) must not be used. Perhaps I’m missing something here, but why not? It doesn’t seem like it compromises any of the intended security properties. Use of a symmetric MAC may also limit the privacy impacts on users as it provides some measure of deniability (similar to that mentioned in section 12.1), as any Verifier in possession of the secret key could also have produced any claims that are subsequently leaked, allowing the user to deny that they were produced by the supposed Issuer. (This deniability property holds even without subsequent leaking of old signing keys). The security considerations about salt entropy should probably reference RFC 4086 (BCP 106) or something more up to date (maybe RFC 8937 too). I think section 11.8 about selectively disclosing contraints on the use of a SD-JWT is completely inadequate and will almost certainly lead to attacks. Requiring Verifiers to hard-wire the set of constraints they enforce is likely to be damaging to future evolution of the standard as new security constraints are added. It would seem especially problematic to allow selective disclosure of a “cnf” claim for example, and yet nothing forbids it and the history of JWT usage suggests that anything not forbidden will at some point happen (and even some things that are forbidden). I suggest establishing a registry of claims that are really usage constraints and forbidding issuers from allowing anything in that list to be selectively-disclosed. (There are perhaps some exceptions here, e.g. “aud” is a constraint in this sense but it probably does make sense for it to be selectively disclosed, but only on a per-array-item basis: that way a Holder cannot remove the constraint entirely but can still hide other “recipients”). On a related note, section 11.6 says that to avoid this kind of attack, Verifiers MUST NOT take into account whether a Key Binding is present or not to decide whether to require Key Binding. This seems to preclude Verifiers that can handle different levels of access with different security requirements and is the sort of requirement that makes it near impossible to incrementally evolve tougher security requirements over time. It effectively becomes an all-or-nothing switch that will have the likely effect of making the use of Key Binding less attractive. Security hardening should be the easy path if we want to see it adopted. Best wishes, Neil [1]: URL [2]: URL [3]: URL


to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!


Remove initial underscore on for I do think this change is appropriate but think we should publish a -07 soon if we proceed with it.
It makes sense for to start with an underscore, since it is being inserted into a JSON object supplied by the caller and it needs to be something unlikely to conflict with an existing claim. The field appears in the key binding JWT, a format being defined by this document. So it can safely live without the underscore.
That's a fair point, I think.
I think the same argument also applies to . It's just a normal JWT claim, so it can be deconflicted using the usual registry process.
Really they are all just JWT claims and will be registered. The leading underscore isn't magical and doesn't exempt from registration. But it is a nicety to help avoid conflict, which is particularly relevant with where/how and are used. They both are in the issuer signed JWT where there is some potential for name conflicts with application supplied data (JWT's whole registered, public and private claims guidance is supposed to help here too but conflicts are still possible). For general clarity and consistency, I agree (I think anyway) with removing the initial underscore on . But is more similar to in usage/context and those two should keep their leading underscore.
To me the difference between and seems to be that is at the top level of the JWT claims, where we're used to dealing with . But can be down in the guts of the claims, which the JWT signer might have less control over. So I would go for , but and .
Registered claims (I'm a so-called DE on there so I have some familiarity) don't fully address conflicting names even at the top level with the possibility of the use of private claim names. More could be said about that registry and what it does and doesn't provide in practice but that'd be a digression... Anyway, that and show up in the content of issuer-signed JWT is my point of vew for keeping the underscore on both. Also for keeping those two similar to each other. Lastly note that and have been in the draft for many revisions (back to -02 I think) whereas was just introduced in -06. Changing at this point likely wouldn't impact implementations much but changing would.
I'd prefer to not see ANY public claim names that start with . It starts a convention which I would prefer not to see repeated.
In OpenID Connect, we decided that our "meta-claims" would start with underscore to visually distinguish them from normal claims. For instance, see the claims and in the registry at URL I support SD-JWT continuing to follow this convention and so would prefer that the leading underscore be kept for its meta-claims.
NAME What is the difference between "normal claims" and "meta-claims" here? And why did OpenID Connect go that way?
"Meta-claims" are claims about the structure of where actual claim values can be found - claim values that are not simply top-level members in the JWT Claims Set. They're road-signs saying where to go to get them - not the destinations themselves.
Thanks, that distinction makes sense. Applying that to SD-JWT, it seems directly applicable to , and sort of fits as well, since it tells you how to read the road-signs (to continue NAME metaphor). I'm OK with these keeping ``. But is not a road-sign, it's the main event. If you ignore or , you miss out on some claims, but nothing fundamental breaks. If you ignore , you're not enforcing the key security properties of the system. So I think the original issue here is still valid.
PR URL would remove the leading underscore on (and only there). Which is the original issue here.


In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.


adding SD-JWT claim Note: need to update the examples to include it once we agree this claim is needed (cc NAME )
We need to say in the checking algorithm that verifiers MUST check the alg and MUST only accept hash_algs they understand and deem secure.
information about the hash function should probably be included inside SD-JWT. Based on NAME 's comment to the PR URL
Yes, needed indeed. This and more details about hash formatting (how to transform inputs into byte arrays to be passed to the hash function).
The alternative is to use the same hash function as was used for the signature. This is done in OpenID Connect Core at URL in the definition (as well as in the definition. The language is:
You might want to use a different hash function to reduce the SD-JWT size (e.g., SHA-256 truncated to 128 bit), or decide on a stronger hash function with iteration to reduce the size of the salt (again, to minimize the size of the artefact). Bottom line, choosing the hash function independently might be useful.
As discussed in the call, if we allow different hashes to be used, we may want to make a recommendation that for simplicity an implementor may want to use the same hash algorithm to minimise implementation errors.
Assuming we're not going to use the trick that OpenID Connect uses to determine the hash algorithm implicitly, then I approve of this approach.


Clarify validation around no duplicate digests in the payload (directly or recursively) and no unused disclosures at the end of processing (to & )
SD-JWT validation processes should require that the validating party (Holder or Verifier) validate that the hash of each disclosure object appears in the Issuer JWT claims. If this validation is not performed, then the SD-JWT format is malleable, in the sense that arbitrary additional disclosure objects can be added beyond those that the issuer intended. This creates the opportunity for mischief, from bugs to covert channels. This is not a difficult property to enforce. The already has the validating party compute the lists of (1) hashes of disclosure objects and (2) disclosure hashes in the Issuer JWT. So the only additional step required is to check that (1) is a subset of (2).
That requirement that the hash of each disclosure must appear in the Issuer-singed JWT is in the current draft text - near the top of has "a Holder or a Verifier MUST ensure that ... all Disclosures are correct, i.e., their digests are referenced in the Issuer-signed JWT". Seems it could be made more explicit or clear? But it is there.
Ah, thanks, I had missed that. Even given that though: I would not call this property "correct". The only other place that property appears is in 11.2, so maybe it can just be dropped, and we can just say directly "All disclosures correspond to a hash value that appears in the Issuer JWT" Given recursive disclosure, though, even that's not really sufficient. A recursively disclosed claim does not in fact appear in the Issuer JWT -- you basically need to verify that it hash-chains into the Issuer JWT via a series of disclosures If we're going to eliminate recursive disclosure, I think the current text probably suffices (modulo "correct"). But if we're going to keep it, we need to elaborate the algorithm. Maybe it can be folded into the existing recursive algorithm as a termination condition. If you're adding the hashes inside disclosed values as you restore them, then if you get to the point where none of the claim hashes are in the set of disclosure hashes, then if the set of disclosure hashes is non-empty, the object is invalid.
Assuming here in this ticket at least that we are not going to eliminate recursive disclosure. The use of "correct" is indeed awkward and that whole bit of text could be improved. There's room for a lot of improvement there. I've always understood text like "referenced in the Issuer-signed JWT" as intending to mean included directly in that JWT but also included recursively. But being more explicit is probably worthwhile. I think it'd be sufficient to say somewhere something like "all disclosures must correspond to a hash value that appears (either directly or recursively) in the Issuer-signed JWT". That somewhere could be in place of the "all Disclosures are correct" text and/or a step in the validation steps near . To you earlier point - it's not a difficult property to enforce. Even with the recursion. A validating party needs to compute the lists of (1) hashes of the disclosure objects and has to look at (2) all disclosure hashes in the Issuer JWT (including by recursive inclusion). The only additional step is still just to check that (1) is a subset of (2). Which is basically just checking that there were no unused disclosures at the end of processing.
Agreed, if we can update the algorithm to reject if any hashes are left over, then that would fix this issue.
Great, I think we can update the the algorithm to reject if any disclosures are left over. It'd probably go near the check to ensure that no digest value is repeated in the whole of the SD-JWT - either in the payload directly or recursively in any disclosure (that check about duplicate digests needs a bit of improvement too). Also we should tidy up that text with "correct".
From the mailing list Hi Jacob, the intention was to cover the first case you listed. We should clarify this. -Daniel Am 20.10.23 um 15:02 schrieb Jacob Ward:
my 2 cents at/from URL
Also... um, wouldn't "More than one Disclosure have[ing] the same digest" imply a collision in the hash function? And therefore infeasible to actually happen. Agree that it should be clarified. Being precise with language around this stuff is tricky. But my understanding of the intent was to ensure that no digest value is repeated in the whole of the SD-JWT - either in the payload directly or recursively in any Disclosure. Because of the trickiness of language, I'm not sure if we disagree or not about the intent... 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.


which can be found at
I think the following change might be cleaner per in Jefferey's review. "9. Check that the Key Binding JWT is valid in all other respects, per [NAME and [NAME -> "9. Check that the Key Binding JWT is a valid JWT in all other respects, per [NAME and [NAME
Sure, that's done in 4442c3a06767498ee24154024d8dff987325b08f
While reviewing URL, I had to understand some of the SD-JWT verification algorithms. I noticed some issues, which I've listed here. I haven't filed individual issues yet because I'm not sure how you'll want to group them. Thanks to NAME for doing a first pass; any remaining mistakes are probably because I didn't take his advice. [x] This should follow URL by specifying "what serialization and serialization features are used". I see that 1.1. Feature Summary mentions the compact serialization, but that doesn't clearly say that this embedded JWT uses it.[x] "The claim name, or key, as it would be used in a regular JWT payload. The value MUST be a string." <- I assume the "value" is the key, and not the key's value in the JSON object? [x] Why is 128 bits only recommended and not required for the salt?[x] This should follow URL by specifying "what serialization and serialization features are used". I see that 1.1. Feature Summary mentions the compact serialization, but that doesn't clearly say that this embedded JWT uses it.[x] This mentions "bytes preceding the KB-JWT in the Presentation", but several other places mention "Key Binding is provided by means not defined in this specification", in which case the relevant bytes don't precede the KB-JWT. These should be consistent.[x] Are "Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that" and "The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT" accomplishing the same thing? [x] "Separate the SD-JWT" should cite an algorithm for doing that. I think it's "5. SD-JWT Data Formats" which implies it's just "split on '~'"? [x] "Ensure that a signing algorithm was used that was deemed secure" disclosure and then call a recursive element-processing-and-replacing function, but this isn't too bad. [x] "Remove all array elements for which the digest was not found" probably won't confuse anyone for long, but my first reading said that an array in the payload like [1, 2, 3] would wind up empty since no digests were found for the elements. [x] "Check that the SD-JWT is valid using claims such as nbf, iat, and exp" should say where those claims are defined and what part of which object they appear on. (URL, and the top level of the payload, not the header, right?) [x] The "required validity-controlling claim"s should probably be an input parameter to this algorithm. Possibly all the IANA-registered JWT claim handling should be passed in, or this algorithm should return all the claims for the caller to deal with.[x] "create a Key Binding JWT" <- refer to the section that says how to do this. [x] "Assemble the SD-JWT for Presentation" <- This should at least refer to "5. SD-JWT Data Formats" and possibly just write out the algorithm of "make an array of the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT, and join the array with '~'."[x] This is clearer that "Verifiers MUST ensure that" is accomplished by the steps in the following algorithm, but I don't like the redundant MUST. You can just say "Verifiers need to ensure that" and then leave the normative requirements to the algorithm. [x] "according to the Verifier's policy" should be an input parameter to this algorithm, that the verifier provides along with the bytes of the presentation. [x] "verify the Key Binding according to the method used" <- how? This might be URL, but you should cite the details. [x] "Determine the public key for the Holder" <- how? This might be the 'cnf' claim, but you should say so. [x] "Ensure that a signing algorithm was used that was deemed secure" <- as above, this should be an input parameter to this algorithm or computed from the public key. [x] "Validate the signature" <- again, cite how to do this. [x] "the typ of the Key Binding JWT" <- is that in the header or payload? (cite 5.3. Key Binding JWT and possibly URL) [x] "within an acceptable window." <- should be an input parameter [x] "validating nonce and aud claims" <- The instructions for doing this should be an input parameter to this algorithm. [x] "Check that the Key Binding JWT is valid in all other respects" should call a particular algorithm from the other specs that it cites.[x] Many of these should be normative. For example, base64url is used all over the normative parts of this specification, and it comes from [RFC7515] in this section.
Thanks for the review Jeffrey! I'm acknowledging it with this comment but also noting that there's a lot here so response/action will take some time.
1c1f165ab821dea5350f62225f103bdceff31532 one was an oversight and one was a tooling issue and oversight. I think that covers them tho.
Those other specs don't have algorithms that can be called nor do they have suitable sections to reference directly.
Some contributors want to leave open the option of a more computationally expensive hash with smaller salt values.
Yes and I've tried to remove any ambiguity there by just not using the word "value" with d015a3de2ae50623b4a294590fb2d0249e7d33b5
Per , "JWTs are always represented using the JWS Compact Serialization" the compact serialization is already specified.
That is for the claim in Key Binding JWT so isn't relevant elsewhere.
& Yeah, with 2a0e270f2e1dbfa9664bb5ce4989a2f6a1765217 I basically applied your suggestion to both places.
Yup 7d68d4ed9b91e49a0aa00254475bf7c116669dd6
Yes but I believe it's sufficiently clear in the context of the draft.
This draft is not structured such that it has input parameters to algorithms so suggestions to make something an input parameter to an algorithm are not actionable or practical.
e9acd5ed665b107776b6b41355680470cde89f2c
is a JOSE header. Will cite sec 5.3. where that's more explicit 64a4c4519668c7a63f1a0be215176657895fa0c8
That sentence starts with "If Key Binding is provided by means not defined in this specification," so there are not specific details to cite. mentions that other ways of proving Key Binding are possible. DPoP/rfc9449 is one possibility but not the only one. Nor a particularly likely one. At least not likely enough to warrant mention here.
The very next part of that sentence says "in the processed payload" and that's a non-exhaustive list of JWT claims for which a citation/reference isn't really needed.
I feel like it's sufficiently clear from context and shouldn't confuse anyone for too long.
Noted.
This draft intentionally doesn't prescribe how keys are distributed, identified, selected, trusted, etc. any more than JWT/JWS do (e.g. URL, URL, etc). A map from (issuer ID, key ID) pairs to public keys is one application but certainly not the only one.
referencing that 072a0605bcb62937e343aaa7812aa8ef86d8379f
That's a somewhat existential and loaded question but common usage of the word doesn't preclude it describing nested items and array elements. And this draft is not alone in that. In the intro it also says, '"Claims" here refers to both object properties (name-value pairs) as well as array elements.'

"create a Key Binding JWT" <- refer to the section that says how to do this. cbee5f8457f447574400377dc6f7c9fe7f1c3c18
a474e2b0b0ff7635af38c2ac95e70b40b2f82798 makes things a little more a bit more prescriptive about suggesting RFC7800 cnf/jwk be used to convey the Key Binding key and references that section from the "Verification by the Verifier" section.
Thank you so much, Brian! overall, agree with all the responses. I made few comments on the PR, but one thing to note here too: I think recommending claim per comment is inconsistent with a comment that says that "this draft intentionally doesn't prescribe how keys are distributed, identified, selected, trusted, etc. any more than JWT/JWS do. so I think recommending is redundant and using in examples is sufficient.
That latter comment was about (and in reply to a suggestion about) validating the signature on the Issuer-signed JWT and checking that the signing key belongs to this Issuer. While the former comment is about the holder's public key inside the Issuer-signed JWT itself. Different things so I don't believe there's really an inconsistency in my statements. Nor do I think that being a little more a bit more prescriptive and more clear about using RFC7800 cnf/jwk to convey the Key Binding key is redundant. Rather this review of a review seemed like a good opportunity to provide a little more clarity and guidance in an area the draft that could benefit from such.
one nit, otherwise looks good - thank you, Brian!


This addresses Issue . The rest of the text still refers to asymmetric signatures, but technically, an HMAC is now allowed.
The scope of this PR was intentionally to only remove the explicit prohibition on MAC. Not to explain how it might work or adjust other language about asymmetric signatures or private keys or similar. Just remove the explicit prohibition so that, should some deployment/ecosystem/jurisdiction need to MAC for whatever reason, it's not directly going against a normative must.


Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!


Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text


for issue URL
The layout of these section delineations seems off. There's an "Example 1" section header, but no other numbers. Some examples are top-level, some are subordinate. Is this intended?
Kinda. has additional examples with some of those other numbers. ! And a few places refer back to "Example 1" by name. This all could probably be tidied up though.
like it


would
It seems like it could be helpful to implementors, allowing them to quickly validate whether what they have is syntactically an SD-JWT or an SD-JWT with key binding. Something like:
The actual helpfulness of ABNF IMHO really depends on the readers familiarity with ABNF. I don't know that such familiarity is particularity prevalent. But, as long as it's correct, it doesn't hurt to include either. And while I'm not overly familiar with ABNF myself, I know enough to know that that isn't valid ABNF and doesn't quite correctly convey the SD-JWT constructs. I've endeavored to fix it up but am not 100% sure this is correct either: \ with a bit of help from https://author-URL
Looks good to me, thank you! Maybe a small improvement would be to introduce a name for disclosure?
That's a good improvement, thanks!
Looks good to me, and appears valid according to the .
(SD-JWT-KB part of the ABNF depends on another PR)
need to wait after is resolved to do a PR.
maybe add a KB-JWT line to be even more better? a la:
Not my religion, but happy to celebrate anyway.


More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key


Mr. Heenan suspects he should probably be listed in the SD-JWT acknowledgements section and I don't disagree


to
I was not completely sure either and that's why I posted only the issue and no PR first. I still think that in chapter 5. the extra mentions are confusing as the text and the ABNF are separating the SD-JWT and SD-JWT+KB formats. In contrast, similar explicit mention in the verification section is clarifying to me.
I wasn't sure when first looking at it and actually thing it's okay either way but have come to think it's more okay this way.
The distinguishing of SD-JWT from SD-JWT+KB is a good clarifying change in -09. Some extra mentions of KB-JWT still remain that could probably removed: In : >An SD-JWT without Disclosures and without a KB-JWT and >An SD-JWT with Disclosures and without a KB-JWT The "and without a KB-JWT" could be removed as there are separate examples for SD-JWT+KB and SD-JWT is now defined not to include KB-JWT.
Thanks NAME PR does exactly what you've suggested.
approved the PR () too.
I am not sure these are actually extraneous, but ok looks good


BTW NAME please do a quick PR adding yourself to the Acknowledgements section, if you;'d like.
Thanks NAME !


Acknowledge Martin Thomson for his contribution: URL
Open for one week. No approvals. No objections. One minor editorial change applied. Will continue to wait.
If this is this acceptable, I love it