See
I have trouble explaining why scanning a QR code is dangerous to initialize authentication flows to gain access because sometimes it is less dangerous. When using a device which is close proximity to the second device and forcing this through a protocol, the danger is reduced. I think introducing a new wording context would help (especially if this was used in the corresponding protocols, for example FIDO2 passkeys) Near device A device which is in close proximity to the second device and uses a protocol which forces a close proximity communication channel for the authentication steps. Cross device A device which communicates to a separate device and uses a protocol which does not force proximity to the second device. Then it would be easy to explain attacks and mitigations: Using a near device communication, the attack X is not possible etc. Not sure this is the right place to add this, but it would help I think.
That's and interesting idea. To me it is more about cross-device protocol properties. Some of them have strong proximity assurance properties, and some don't. Perhaps terminology like "proximity verified cross-device flows" or "proximity enforced cross device flows" vs "proximity-less cross device flows" works better? It is also somewhat protocol neutral.
I like these two: "proximity enforced cross device flows" vs "proximity-less cross device flows"
Let me think about how to work that terminology into the text at the right places.


The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.


Added user education as an explicit mitigation ()
Based on discussions with UX researchers at royal Holloway University and the latest requirements from the Payment Service Directive 3, user education does provide benefits in aggregate and should e considered as an additional mitigation (either as part of the UX section, or as its own section).
Small additions/changes, otherwise looks good to me.


Incorporating feedback based on
Follows . (CC NAME User Experience (extension) During potentially dangerous operations (e.g., reading the QR code on the Authorizing Device), advise users to verify the trustworthiness of the source, for instance by checking that the connection is protected through TLS or by verifying that the URL really belongs to the Authorization Server. In particular, when activating the camera to read the QR code on the Authorizing Device, the activity could also display a warning message advising users to only scan QR codes displayed on a specific website. Limitations: those already reported in the mitigation
After discussing with Daniel, this is very close to the recommendations on user education. We will review that addition and incorporate the recommendation to add warning messages when scanning a QR code, if it is not sufficiently clear already.


Added "Request Initiation Verification" as an additional mitigation based on issue
Follows . (CC NAME OTP Verification In the User-Transferred Session Data Pattern and Backchannel-Transferred Session Pattern, before authorizing the attempt, the Authorizing Device could display an OTP to be inserted back in the Initiating Device. In case the QR code or the push notification was generated without the users' consent, they would not have performed any action on the Initiating Device, and therefore they would not know where to insert the OTP they received. Limitations: Attackers could deceive users into revealing the OTP through other means (e.g., via email) and use it to finalize the authorization process; the additional step could reduce the usability level of the protocol. Effect on attacks (Table 1): .
Discussed with Daniel and proposal is to include as an additional mitigation and position this as part of the user authentication (i.e. not a protocol extension). It makes it harder to scale attacks, as the attacker has to find a way to recover the PIN as well.
Fix typo on "Authorization Device"


I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.


Included use cases for OTP, e-mail, SMS confirmation, step-up authentication and registration. Also see and


I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.


Added option for redirecting to the web. Notes: Re-using the PAR response - feels strange to have the "request_uri" parameter as the redirect URI - is that OK? Added and example of redirecting to the web. Not entirely sure how control gets passed back to the "native" app/client or how much detail we should provide.
I see the problem with the current text. In PAR, the response is a which represents the PAR request itself: The client is expected to then start an authorization request and put the value in the query string parameter: So the text in this section should instead be:


Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types


Issue Add normative requirement for device binding of auth session and require the authorization server to enforce it.
Should we prohibit the auth_session from moving off-device to avoid resumption of the session on another device (avoid risks of session theft or session take-over).
auth_session is expected to be device bound
Discussion Add statement that authorization sessions are device bounds. Make it Normative in spec.
Resolved in


Removed the need for the new ash claim by inverting the way in which binding works by putting responsibility for maintaining the binding on the authorization server (see issue ).
I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the authsession value to the the public key from the DPoP proof and checks the binding whenever the client sends the authsession. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value). URL URL
Suggestion: also require a unique DPoP key per session to avoid risks around session binding.
Completed in
Looks good


Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go. Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)


Addressing Issue I did not add anything explicit to the Security Considerations section and instead mentioned the potential security exposure in the text on User Experience
First item to add is guidance on limited input devices.
NAME I recall we discussed this, but unable to recall the details of the concern on what guidance we had in mind.
Notes from editor's call: "Not recommended to use this with challenges that require significant user experience challenges, for example entering a password on a TV screen with an on-screen keyboard." Security consideration around the differences between exposure of credentials on a TV screen in a room vs the risk of a cross-device flow We don't want to discourage the possibility of using this flow with a passkey on a TV remote control "If you're on a limited input device, and the authentication method the user must pass requires significant user interaction, e.g. entering a password, then you shouldn't use this method; use the device flow instead."
Completed in


Clarifying the text to make it clear that there are two ways in which phishing attacks may be facilitated by this specification. (see issue ) cc NAME
Maybe I misunderstand this section, but it sounds like only one way to do phishing is described, though the section starts by saying "there are two ways."
NAME Thank you for the new text.


Sec. 6.1 (in particular the example), what is the meaning of a response with an access token, a refresh token as well as an authsession, what is the client expected to do? How should it use the authsession?
The auth_session should be cached by the client in case it is needed for the stepu-up authentication flow as described in the Appendix (section A.7).


Clarify that the binding is not done through cryptographic means but rather through association by the authorization server since the binding is only between the client and the authorizations server. See issue cc NAME , NAME
Since RFC 9449 does not specify how "additional" parameters can be bound, please say explicitly that (presumably) this is a claim within the DPoP proof JWT named "auth_session".
It is not a new claim in the DPoP proof, because that would imply the binding happens from the client, not the AS. Brian's suggestion was to require the AS to do the binding, in which case it's internal and not part of the spec.
So can you please fine tune the language in 9.6.1. At least this reader understands the word "binding" when used in this context as cryptographic binding, and this is obviously not what you want. Maybe use "associate" instead.
Fixed by .


Added use cases. We may want to refine these, or move them into a non-normative section later.


parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details


Added a section in the security considerations to address topic raised by
Comment from Kelly: A.2.(D) I think AS in domain A at least SHOULD authenticate to AS in domain B. We have it as a MUST.
Perhaps this can be done in the security considerations.


Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL


Removes a duplicated section from the introduction
Feedback from Brian Campbell: Section 2 repeats itself with the text "A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange. The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B. The client in domain A may be a resource server, or it may be the authorization server itself." occurring twice.


Replaces examples and add response examples
Feedback from Brian Campbell Seeing curl commands in the examples is sort of unexpected. Typically these kinds of drafts try to show the "on the wire" HTTP message -something like this [URL] for example or this [URL] or [URL] etc


Fixes RFC7523 reference (was RFC7521)
Feedback from Brian Campbell The reference in the first sentence of [URL] would be 7523 rather than 7521 (I got rather confused reading that paragraph :-) ).


See
Feedback from Brian Campbell This requirement for the audience [URL] is already a requirement of [URL] (3rd bullet) and also [URL] (also 3rd bullet). But the way it's listed here makes it sound like an additional thing. It might be worthwhile to use the bullet here to be more specific about the aud value (it's been a bit of an interop pain point w/ JWT client auth fwiw) and say that it has to be the token endpoint or AS issuer identifier.


and minor other little fixes to fix issues , , an editor's draft preview of these changes here: URL
says this: However, if the authorization grant is a JWT (which it always should be, but see for details), then defines the grant type of the request to be: The other implication of this is that the only way to distinguish the type of JWT assertion is in the JWT itself, which can be done using the field in the JWT header.
Per is an "identifier [...] for the representation of the issued security token" and I think it's admittedly a bit odd but perfectly reasonable to use the URN of the grant type that the token is intended for as the value conveying the representation that token.
With that said however, I do kinda think that'd it be better to limit to JWT authz grant only (a la ) and not tie the issuedtokentype to the grant type.
My point was more about the grant type of the request as described by RFC7523. access token request as defined in of the OAuth Assertion Framework ] with the following specific parameter values and encodings. So if the request contains a JWT, then the grant type value has to be . Which means according to Section 2.4.3 of this spec the issuedtokentype "SHOULD" be , which is silly. So my proposal is to remove the "and SHOULD be passed into the assertion request" part, so that issuedtokentype can be a value that makes sense, and use as the grant type. As I said in the original comment, the implication is then that the JWT header itself would need to include something that indicates the type of JWT it is, otherwise all token exchange requests look the same.
I might argue that it's not actually silly but I won't b/c it'll be moot as PR addresses this with the removal of the "issuedtokentype parameter in the response indicates the type and SHOULD be passed into the assertion request" URL
issuedtokentype (a required parameter of a token exchange response URL) is missing from the example response at URL
NAME can you prepare a PR with an updated example?
example would be fixed by PR
Feedback from Brian Campbell Conceptually having "flexibility for authorization servers to change format and content" sounds nice but I can't help but wonder if that flexibility is actually useful and if this document wouldn't be better served and more straightforward using just JWT authz grants from 7523 (rather than being abstract about using 7521 and the very brief mention of SAML w/out a 7522 ref).
I agree that limiting the authorization grant format to JWT is useful. In fact you've almost already done that by adding the validation to the processing rules here: URL
As discussed in the meeting with the editors and Aaron, we will make the use of JWT explicit.
PR would limit the authorization grant format to RFC7523 JWT


when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant


Issue
Can you give an example where this is relevant? With excluding private claims we make sure all claims are uniquely identifiable across all parties of the three-party-model.
claims we make sure all claims are uniquely identifiable across all parties of the three-party-model. I dont believe this PR discourages public claims it simply reflects that there are bunch of scenarios where VC ecosystems what to interoperate on claims that are perhaps not general enough to register as public claims.
Please merge


Status Provider should be either 4th party or issuer (not verifier).
Merging this since multiple approvals.
lgtm, thank you!


Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.


alternative to based on NAME 's comment "I can't help but wonder if it'd make sense to have the spec be only about SD-JWT VCs and treat the plain JWT VC as just a special case of an SD-JWT with no selectively disclosable claims." no changes to the basic structure. simple clarifications what to do when there are no selectively disclosable claims ie no claim and no Disclosures. Might need some more details but this is how it might look like. (cc NAME NAME linked to rendered preview
Generally, I really like this approach! Some examples could be useful for key binding with JWT (no disclosures)
I'd expect the typ for both to have +jwt if that were really the case. There is another draft up for multiple suffixes. URL Is it simple enough to support now?
should this be titled ? I think this should be changed as well as the title before merging to make sure we are calling out that this covering SD-JWTs and JWTs
Yes. Will make a change once we have a decision whether PR or this one is the way to go…
What is the position of this specification? From my understanding it defines a VC with JWT claims it defines a profile for the JWT claims it defines a profile for securing the VC There's an open discussion between the sd-jwt and JWS protection. Relevant discussion has been started URL - sd-jwt introduces an encoding that becomes incompatible with JWS in the limit where selective disclosure is not used. In other words, it introduces a first-order phase transition. Let's see how this topic resolves. IMO, the data model and securing mechanisms should support both sd-jwt and JWS.
I do like this approach, but I am a bit concerned that even in the 'no disclosures' case, we'll have the trailing tilde in the issuance and presentation (when no KB is present). A JWT is not a special case of an SD-JWT for this reason.
I agree with the concern.
IMHO keeping the trailing tilde is preferable as it keeps the model consistent.
from what I am sensing, there seems to be a lot of preference towards the approach in this PR over , partially because it is simpler and gives one credential format and not two (consolidation, yay!), with one major discussion point being a ~ after a JWT VC when it is issued. a bit of the context... this trailing ~ is the result of the decision being taken in SD-JWT spec to better align the issuance and presentation formats, (URL does it, and it has not been merged yet). One option is to keep issuance and presentation formats separate in SD-JWT (as-is) so that there is no ~ when (SD-)JWT VC is issued. but that is not that clean from a pure SD-JWT processing perspective is I think the opinion of its authors (NAME NAME so the question is really what to do with a trailing ~ when there is no SD in SD-JWT based VC.
should be good to merge once NAME takes a look and approves
I'm ok with this direction. I personally don't like the trailing tilde but we can fix that in another PR. I'll open an issue in the repository.
Merging this PR since a lot of approvals and no objections.
approving but will create an issue to address trailing tilde.I approve this approach over as, the specification is much cleaner I expect implementations to be much cleaner I don't see confusion with trailing tilde, because typ is not jwt but sd-jwt most interop profiles will require SD support anywayI prefer URL since I find its description of what we're achieving more natural / less surprising. But I can live with this description as well, provided the distracting "with JSON Claims" language is removed.


Replace "Three-Party-Model" with "Issuer-Holder-Verifier Model"
There are lots of things that could be described as a three-party model (including classic OAuth where this work is aspiring for adoption). The use of "Three-Party-Model" in this document strikes me as somewhat presumptuous and potentially misleading or confusing. Could we instead use "Issuer-Holder-Verifier Model"?
I agree, since there must be always a trusted third party in the model, like a trust anchor or its intermediate
I typically refer to this model as "decentralized identity" or "verifiable credentials applications/solutions/ecosystems", I would be fine with "digital credentials applications/solutions/ecosystems".
I'm suggesting only to replace the 5 or 6 usages of "Three-Party-Model" with "Issuer-Holder-Verifier Model".
That would work for me and I understand that Three-Party-Model is confusing since other architectures also involve 3 parties.
I'm ok with using "Issuer-Holder-Verifier Model".
It seems that this issue is ready for a PR.
is that PR
thanks, lgtm


As NAME has aptly pointed out, 'the "with JSON payloads" wording is clunky and redundant.'
lgtmI see no reason to have the "with JSON payloads" in the title


I worry about collisions and confusion with (and with ) - those of us that work with this stuff will likely understand the difference, but there is probably a better descriptor we could use than for this reason. Maybe specifying "schema" or "schemaName" or "sn" (for nice short form) would be more useful here
NAME there is a conversation on renaming type claim in Issue URL which should be a separate PR if we agree on an alternative claim name..
lgtm after we applied NAME suggestion


I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm


We currently have two section describing verification by Verifiers. This commit consolidates both sections. Importantly, this commit fixes the description of the key binding check to ensure that removing a KB JWT from the presentation does not allow circumventing KB.
thank you! great improvement.


URL
I found several minor issues here: The spec has the following headlines: 4.2.2 Claims Comparing this to RFC7519 JWT these should be: JOSE Header JWT Claims Set Also, in 4.2.2.1 type claim is never explained. This should be added to the Terminology. Its also missing a link to the Annex A.1.
Additionally, headline 4.2.2.1 would better fit saying "New JWT Claims"?


Add reference to Security Considerations in SD-JWT
E.g.: SSRF with Issuer URI


Added privacy considerations section from SD-JWT which provides a good foundation. ,
Currently, is not one of the selectively disclosable claims. This might be ok but it might have some privacy implications if a VC has multiple types. Let's assume the following: A VC with the types: driver's-license, age-over-18. If the holder discloses only the age, then based on the current specification, the verifier would also know that the age was disclosed from a DL which is probably unnecessary context info since all the verifier needs is to trust the issuer of the VC. Note, the issuer itself might also leak some contextual info as well, so the issue might not need to be mitigated or it might not be entirely possible anyways. Should we make selectively disclosable per array entry? Is this even supported by SD-JWT?
Closing this issue since SD-JWT doesn't support selectively disclosing array elements.
We might want to add something to privacy considerations about that.
FYI: There is a discussion about Selective Disclosure for array elements. URL
suggest to close as the type is a simple string now
NAME raised an issue with me that "if the type is always disclosed, what is the point of selective disclosure because the verifier will know what claims are in the credential". I think we should consider making type selectively disclosable.
I agree with Peter and I'm in favor of sd for type
What is the value of a VC without type information? Or let me put it the other way around. If the Verifier is supposed to be able to process a VC without knowing the type (which also means it can request the VC presentation without specifying the type), why do we need the type at all?
I was wondering about that point as well - what is revealed information worth without information about credential type (and corresponding trust framework).
It becomes valuable if all the verifier wants to know is a specific claim, e.g., , and trusts an issuer which could issue other credential types as well. The credential type can also make a difference, e.g., if somebody wants to know whether somebody has a driver's license but is not interested in the details.
My current assumption is that is the primary selection criteria for credentials in a presentation request (as identifier for a pre-defined bundle of claims associated with certain policies for enrollment and issuance). Based on that assumption, the Verifier always knows the type. So what would be the scenario to request a VC without knowing its type?
Having the type disclosable does not mean the user never shares it. If a verifier requests the type then the user can disclose it, no? The issues with both the and the is that they reveal what claims the user has, which is more than what is strictly required for a service. The privacy requirements from the Parliament, Council, and the Commission are strict. However, I cannot think of a scenario to justify type being disclosable. Arguments for: As NAME mentions, the verifier may require only a particular claim, e.g., age over 18, and should reasonable accept these from any trusted issuer without having to know what exact attestation type it came from. Some issuers may have multiple types that all contain the same attribute. And there are strong demands that the user should reveal only what is required for the service and absolutely nothing else (to the point where I am actively having to fight against people who want to put ZKP everywhere). Not revealing claim values is great; also hiding what claims you have is more privacy preserving. Arguments against: Beside from those already mentioned, you could question the privacy benefits. As long as the individual Issuer's signature is included, it is likely not that hard to guess what the particular attestation may contain, particularly if the Issuer only issues few attestations. In conclusion, given how there are no technical challenges to making type disclosable, and how the Verifier may just request a type and refuse to process a presented claim without type disclosed, I would argue for that the type MAY be disclosed.
The field is always disclosed, hence not revealing the only offers privacy if the same issuer with the same key offers multiple VCs that share the same claim name that is being requested. It seems like an unrealistic scenario that this is a privacy benefit. It seems to me the usecase would be merely a fillout help, where the verifier does not care about the origin of claims and handles those as self-attested
Let's create a PR and see how the spec will change and continue the discussion there.
Currently, the spec gives the following function: Given that, I don't think it can be selectively disclosed. We should close this issue.
We should add something to the privacy considerations section that explains the risk of leaking more context info from the type in certain use cases.


NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that


Type identifiers MUST be collision-resistant names as defined in RFC7515 Changed the example to a URI


This PR renames the claim to , as per the discussion in
I oppose against this change. I suggest to use 'vct' instead.
I'm good with . For the record, I think it's important to move away from , because URL uses the claim name, but with a different syntax. Keeping the naming conflict will inevitably lead to grief.
Naming is hard. Regarding dct: isn't it obvious for an internet standard that we refer to digital credentials?
Neither dct nor vct are intuitive for me, so I am pretty unsure. But between dct and vct, I would prefer dct. A term Verifiable credentials got enough feedback that it has strong too strong of an association to W3C VC-DATA-MODEL. And Digital credentials seems to be a term that is acceptable to generalize.
Why is "Verifiable Credential Type" (vct) not intuitive to you? This would match the current definition of . Isn't this what this claim is about? That is why I'm actually in favor of over , .
I meant that abbreviations are not intuitive to me. And "type" is a pretty JSON-LD specific construct AFAIK so I was hoping we could have a deeper discussion on whether it should be called "claimset" or something. If we are to move away from "type" claim name. on dct and vct, as I explained, I prefer something that is not associated to W3C VCDM and digital credentials seems to be pretty well understood.
If the color of the bikeshed is still open for debate, how about just for credential type?
I like 3-letter-names more than 2-letter-names for some reason. Also, is more accurate since the spec is about SD-JWT VCs => Verifiable Credentials. I'd be still in favor of for that reason.
is fine for me. Updated the PR accordingly.
is fine for me too. was just an off-hand idea
Merging this PR since a lot of approvals. We will have a larger conversation on what is inferred by the value in a separate issue.
I suggest to use 'vct'.LGTM. We should address NAME concern in a separate issue.This is an improvement.


This PR does the following: make verification that the public key of the Issuer-signed JWT belongs to the Issuer mandatory introduce methods to perform this verification based on JWT Issuer Metadata, X.509 Certificates and DIDs Potentially . Partially Out-of-scope: Renaming and moving JWT Issuer Metadata Section
Addressed all suggestions, please review again NAME
I had to rename the section. I think now it is more precise.
Show possible options like JWT Issuer Metadata, being a DID URL etc.
We introduced a new section that talks about different key discovery methods during the verification process in PR


This fixes Issue . Note that this removed the "exp" claim which I think we don't need to mention explicitly.
SD-JWT defines the KB-JWT header, SD-JWT-VC only refers to the claims. Is it necessary to reference to the SD-JWT spec for this?
We do refer to the Key Binding JWT: URL Is there anything else missing?
Closing this issue since got merged.
LGTM


This PR introduces the following changes: - - Fixed SAN Extension rule Removed all options for X509 except
NAME pls review again.
Fixed merge conflicts and reconciled with PR . Nothing new should have been introduced than what has been approved already. If NAME or NAME can approve again, then we can merge imo.
The section should be renamed to "Issuer-signed JWT verification key validation" since the section is about checking that the value corresponds to the key that signed the JWT. The process of obtaining it via different means is just the first step. We should also fix the language in the "Verification and Processing" section to say: instead of
Fixed by
The rules to obtain the verification key from X.509 should be changed to use the from the SAN extension instead of the (which does not exist). Furthermore, since can potentially start with a https scheme, the JWT Issuer Metadata rule should only be enforced if no x5* JWT header was set.
We also need to add JWT header.
Fixed by


This PR introduces the following changes: renamed JWT Issuer Metadata to JWT VC Issuer Metadata which - moved JWT VC Issuer Metadata to the end of the specification for editorial reasons
3 approvals, resolved merge conflicts, merging
Every entity in the OAuth/OpenID is potentially a JWT issuer, then I found the name of this endpoint misleading. Considering that this brand new specification defines a profile for SD JWT verifiable credentials, I'd propose to change the pathname to .well-known/vc-jwt-issuer
The idea is that the JWT Issuer could be used with any JWT, not necessarily VCs only.
NAME what do you think?
NAME is there a reason the JWT Issuer should not be used with something else than VCs?
There are well known endpoints like openid-configuration or openid-federation that publish entities metadata, including jwks Since this specs Is related to VC based on sd-jwt, this specs should not be in conflict to pre existing Oauth2/OpenID ecosystem SD-JWT-VC should define only the resources needed for the solution It defines
I'm ok with the proposed change. I anyway assume we will add VC issuance specific metadata in the future (it is not limited to key distribution).
I agree NAME Key attestation alone Is not enough, this endpoint deserves a proper identity with a specialized protocol metadata Also the verifiable attestations related to the entity may be available in it
To me this sounds reasonable. I will update the spec accordingly.
(As a record, I repeat my question I made elsewhere in the past.) Why is it necessary to introduce a new path, especially if the expected content is just like below (excerpt from "")? Isn't the JWS header parameter (RFC 7515 ) like below sufficient?
(For the record, I repeat my answer I gave on Slack and add more context) The jku header is not sufficient for the intended purpose. The purpose of the well-know endpoint is to establish a stable issuer identifier independent of the jwks location. This issuer identifier can be used in other structures to establish trust, e.g. it can be added to trusted lists (verifier end or trusted 3rd party). Additionally, it fits nicely with the other well-known locations, like openid-credential-issuer and oauth-authorization-server. So the issuer can distribute the role specific metadata in different location residing under the same issuer identifier. And not to forget, this well-known location also could work well with openid-federation. Moreover, any additional VC issuer metadata we will come across can be added to this endpoint. BTW: I think a dedicated issue would be the better place for this discussion.
I am actually in favor of . This mechanism is meant to be general enough to be used with not just a 'verifiable credential'. and I don't think anyone would think to use with ID Tokens and Access Tokens, UserInfo responses , etc. that are JWTs.
I understand your point NAME below my thoughts Why defining jwt-issuer for general purpose in a spec that's specialized for VC? Requirement: definition of a specs in IETF for general purpose JWT Issuer metadata (enabling client metadata, that today is only available in openid-federation...) I agree that jwt-vc-issuer semantically collides with credential-issuer, and we should not do collisions why we can't use .well-known/openid-federation? Federation entity discovery is required for the entities that builds trust chain according to the federation specs, nothing prevent to publish all the metadata of all thw "JWT-role" in a single metadata, that should not be signed if request (content-type) asks it in plain text I suggest to use to consolidate a unique way to publish all the metadata types and roles of an entity. coming back to the name change proposal. Why we use the term since the metadata contains also general capabilities not related to the issuance? in a more general purpose way, wouldn't it be a ? then the question: if that entity has more functionalities and roles, being at the same time a RP and a AS, how the metadata should be organized? We've resolved this issue in openid-federation, with the below schema, where a RP can be also a OP, AS, Client, credential-issuer and so on: URL
I'm a little embarrassed, but to be honest, I still don't understand the reasoning. "A stable issuer identifier" is represented by the claim, not by the URL of the well-known endpoint, isn't it? A possible reason for necessity of a well-known path I guess is "to make sure that the host identified by the issuer identifier actually exists and is accessible, by forcing JWT verifiers to access a path under the domain." An example with concrete values would be "to make sure that the host identified by the issuer identifier actually exists and is accessible, by forcing JWT verifiers to access a path () under the domain ()." It might be beneficial to define as the ultimate fallback general-purpose option for locating the public key required to verify the JWT's signature (not as the sole rule for every VC to follow), especially when it is challenging to reach a consensus on a single method within a limited timeframe among the following. starting with Others However, maybe I'm still missing something, sorry.
The well-known endpoint is indeed also a stable identifier. But it depends on a certain well-known location, i.e. different well-known locations are different identifiers. I'm looking for a stable identifier for the issuer that works across .well-known locations and is not bound to a certain key. That's pretty simple with well-known locations as the iss value can be extended by several different .well-known locations, but the identifier is still the same, right? So for example, the issuer could use the jwt-issuer mechanism share keys and (at the same time) be part of an OpenID Federation as shown in the following: /.well-known/jwt-issuer /.well-known/openid-federation The same issuer's URL could also at the same time used in an external data structure at the verifier or at a trusted 3rd party. Effect: I can establish trust in a certain issuer/entity/server that works across different roles/perspectives. I hope that explains better.
this would allow an entity to use different keys to sign ID Tokens, VCs, access tokens, etc.
my question is how to specify different capabilities for different metadata protocols? this is an example in oidc federation URL here we're saying, this is the wallet provider metadata, where multiple metadata/roles cohexists in a single .well-known how jwt-issuer endpoint achieves this?
If the JWS header indicates that the JWT is a VC (e.g. ), the following paths also can work. (defined in OID4VCI) (proposed by this issue) I'd like to understand why the generic name is chosen. The generic name is subject to interpretation where authorization servers, relying parties and any JWT-issuing systems should provide to expose their metadata (at least or ) as the last resort. What if one server behaves as both an authorization server and a credential issuer? Should the authorization server publish the same content at both and ? Should intermediate authorities and trust anchors of OIDC Federation also provide ? Such a conflict is what I'm (and ordinary server implementers will be) concerned about. The latest draft of "" defines and jwt-issuer metadata. If so, there is no reason to prevent adding the same metadata to OID4VCI as well. Basically, I believe the metadata should be added to OID4VCI regardless of the discussion about jwt-issuer.
Potentially fixed by
NAME raises an important question that we need to address, at least by giving guidance. I don't have a good answer to that at the moment. Besides that, I don't see a need to rename to .
NAME correct me if I'm wrong. I understand you prefer over , right? And whether the key data will be added to the is a different topic (that's how I read your last statement). Please conform.
We will need more discussions on that topic. Potentially at IETF 117. This means, we won't be able to resolve this issue for our individual draft 03.
We had a small discussion on this and I created a new issue so we can separate between the 2 discussions overlapping here (name of the endpoint and intended usage).
Regarding the path, I have been losing confidence in my own opinion. As an implementer who has implemented numerous OAuth/OIDC specifications and been leading development of Authlete that holds the most OpenID certifications in the world, my intuition told me "The path should be avoided due to possible conflicts with other specifications." However, I haven't received as much support for my opinion as I expected. For now, I will implement my OID4VCI implementation using the path. Please let me withdraw my opinion.
I agree the position of NAME while in the italian solution we're implementing openid-credential-issuer as metadata within the .well-known/openid-federation endpoint, according to OpenID Federation 1.0. This doesn't prevent to include also a jwt-issuer metadata type but there's the decision by our side to wait and the same time give evidence of our implementation to help the consolidation of the vc-jwt-issuer specs
NAME An off-topic question out of curiosity. If an authorization server / OpenID provider and a credential issuer are hosted on the same server, the payload of the entity configuration published at of the server contains the following, right?
Hey NAME I'm sure that you meant The answer Is yes, even if we have used a snake case like here URL It's still an initial draft without an official release, several editorials and implementation compromises needs to be resolved but the most of the work Is there, feelfree to open issue for discussion here URL
To make progress with this. Are folks comfortable with renaming "JWT Issuer Metadata"? And if so, would folks be fine with "SD-JWT VC Issuer Metadata" or "VC Issuer Metadata"? I like "VC Issuer Metadata" better because it is more future looking. What do folks think? cc NAME NAME NAME NAME NAME After we agreed on a new name I'd ask NAME to update PR .
Agree that "jwt-issuer" is too general and am in favor of a renaming.


This PR introduces the following changes: - Made all public key validation rules conditional Rejecting the SD-JWT VC if public key validation cannot be done
This harms interoperability, since some implementations will use DIDs and others will use . A more interoperable approach would be to drop and to always use DIDs. Those who want to use domain names and web servers can then still use . DIDs have always been designed as an abstraction layer for different types of resolvable identifiers. To build yet another layer of optionality, where DIDs are one option out of others, does not make much sense. Now you will have to deal with different metadata formats (JWT Issuer Metadata, and DID document). Similar arguments apply to the vs discussion. But I already know the response.. "Simple is a feature", and "DIDs have more boilerplate that is not needed", right? :)
NAME Let's have the discussion in . As long as we haven't resolved the discussion I keep the DO NOT MERGE label on it.
Let me try to update the PR.
NAME I made all rules now conditional from a verifier perspective. In this way a verifier is compliant if they don't support all rules but the SD-JWT VC would fail validation. Note, it is impossible for a verifier to support all rules that may be defined by ecosystems anyways. Are you ok with the updated language?
As a DID maximalist, I would personally prefer DIDs to be the only mechanism that is used whenever public keys are needed, instead of allowing more static public key mechanisms like "jwt-issuer" or "cnf". Unlike "jwt-issuer", DIDs support identifiers that are persistent, decentralized, and cryptographically verifiable. Unlike "cnf", DIDs support key rotation and other updates. And as I said above, with DIDs there would be only one syntax and one resolution mechanism and one metadata format, instead of multiple different ones that individual implementations may or may not support. But I also understand that for some communities, "keeping it simple" is more important than the above properties, so yes I'm fine with the language, thanks for the effort to update it!
While I understand your points, I think some of them are not true. DIDs may be decentralized, may support key rotations and may have other features. There are enough examples of DID methods that do not have those properties. Making DIDs mandatory would limit optionality. But also with DIDs the optionality in my view shifts just shifts a layer further down as there are many DID methods. Indeed allowing DIDs expands optionality by 200+ did methods, so this could indeed be a counterargument. "Cnf" isn't actually far away from DIDs, as the content can vary, there is a registry at IANA for supported methods, with different properties. In my view the cleanest approach for the keybinding would be to register a new cnf type "did" in this registry. But that's off topic in this PR. I'm fine to keep some optionality in the specification at the beginning and then see what is actually being used
True. :) But with "JWT Issuer Metadata" discovered from domain names you will never have the kind of decentralization, persistence, and cryptographic verifiability that DIDs can offer. Sounds interesting! But I agree off-topic. You can still restrict the DID methods you want to use in a specific application such as eIDAS2. For example, if you want to support 1. domain names, 2. plain public keys, and 3. EBSI, then: With the current approach in this specification: For 1. you need to support JWT Issuer Metadata (= a new format introduced by this spec). For 2. you need to support "cnf" and JWK (= a format that has been around for a long time). For 3. you need to support DID documents (= a format that has been around for a few years). Compare that to a DID-only approach: For 1. you need to support did:web (= DID document format) For 2. you need to support did:jwk (= DID document format) For 3. you need to support did:ebsi (= DID document format) You see what I mean? Yes with a DID-only approach you would still have a layer of optionality with regard to DID methods, but you'd only have that ONE layer of optionality instead of TWO layers of optionality, and you'd have a harmonized identifiers syntax and harmonized metadata format. But I understand there are communities that simply don't want to use DIDs, so I think this current PR is a good middle ground.
The current text is basically a normative requirement to support all DID resolution. Which is too much, even to the extent we want to allow for or support some DID usage. We need to revisit how this is phrased in the document and even how much (if any) is said. created from discussion in PR : B: "IMHO DIDs can be accounted/allowed for via the "Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above" criteria below and shouldn't receive 1st order treatment like this in the spec." O: "We added DIDs to make the spec useful also for the credential market that uses DIDs. For those people it is required to demonstrate how that can be done. I'm wondering how other folks are thinking about dropping DIDs from getting 1st order treatment. You are right, one can create another draft that just explains how to use DIDs with this spec." Originally posted by NAME in URL
It was definitely not the intend to support all DID methods and all kind of DID resolutions. We need to make DID support optional for verifiers and if they don't have support they won't be able to verify DID-based SD-JWT VCs which is fine.
I made a proposal here


also fix a typo or two for Issue
URL has "Combined Format for Presentation", which isn't used in SD-JWT anymore.
I assigned you NAME since you are one of the SD-JWT editor's.
Gotta start somewhere... hopefully I can handle this one. PR has proposed changes.


also add associated IANA registration request and fix up formatting etc in other IANA bits see it live URL
There are 2 parts of the draft discussing the path to issuer metadata: and I do believe the latter is the currently intended /.well-known mechanism, whereas the first section was probably not updated and would result in to resolve metadata. I guess this was an oversight in ?
Thanks for catching the inconsistency NAME and I believe you are correct that the latter is currently the intended mechanism for .well-known.
We might also want to use something other than "user" in the example path. It's not wrong exactly but maybe unnecessarily misleading or confusing.
endeavors to fix this (and a few other little things)
lgtm


Added terms and definitions section; made some changes data formats based on terms and definitions section -
I think we need to define what the following "things" are. What is the Verifiable Credential based on SD-JWTs? I believe it is the JWT that contains the s. It is not any of the combined formats. This means that the Verifiable Credential MAY NOT contain any disclosable claims, e.g., . Would you agree NAME NAME Daniel? The VC based on SD-JWT will have the media type . What is the Verifiable Presentation based on SD-JWTs? It makes sense to define that since the HB JWT has some specific requirements. It also makes sense because protocol developers will need to refer to one term when they exchange presentations or verifiable presentations between issuer holder verifier. Can we call the Combined Format for Issuance AND Presentation the Presentation based on SD-JWTs, and if there is HB, then it is a Verifiable Presentation? The VP based SD-JWT will have the media type altough I'm not sure if this makes sense. Wouldn't it better to have ? Any thoughts on that?
Also it is important to note that for OIDC4VP we use Verifiable Presentations in vptoken and we use Verifiable Credentials in OIDC4VCI in the credential response. It probably has the implication that for OIDC4VCI, we will put the VC based on SD-JWT into the credential response, or we define a format identifier for something else. Keep in mind we need to send the disclosures to the client as well. In that regards is the SD-JWT itself the SD-JWT-VC without disclosures, or is the combined format including disclosures the SD-JWT-VC? Or we follow the approach above and we return a combined presentation (no HB) in the credential response and define a credential identifier for that. It probably also means that we would put the VP based on SD-JWT into the OIDC4VP vptoken.
We (IDunion) put the combined presentation (+hb jwt) in the vp_token. What else would you expect?
That makes sense, so the VP based on SD-JWT is the combined format for presentation including HB JWT. Then, there is the question what would the OIDC4VCI credential response return? And what would be a format identifier? I know that this doesn't have to be answered in this spec but it helps with answering the terminology question.
Suggest we not overcomplicate things and say: what is returned in a VP Token in OID4VP is a combined Format for presentation with HB-JWT. what is returned in Credential Response in Credential Response in VCI is combined format for issuance. credential format identifier is 'vc+sd-jwt' for both. Terminology-wise, SD-JWT in the IETF spec is defined as an issuer signed JWS without disclosures. For this profile, the payload of SD-JWT, can be mapped back to a VCDM2.0
This is potentially fixed by PR


This PR: adds relationship to other docs section - preview here: URL
One little nit on the text but otherwise looks okay (after the couple iterations by NAME and NAME thanks for those).
NAME pls approve if you are happy with the latest language, then we will merge the PR.
Data model in this document resembles to the ID Token data model as defined in OIDC (with the addition of cnf). On the other hand, the data model is trying to follow the W3C VC data model. What is the benefit of this data model over the W3C VC data model (except that the claim names are different and iss can be a URI, and not an object and that JSON-LD is not supported by the data model, which basically excludes some significant use cases such as Europass that are leveraging JSON-LD for internationalization, for example)?
It is simple, leverages all predefined JWT claims (including eKYC), and can be used by people familiar with the JWT model to also implement VCs - with SD-JWT also with selective disclosure capabilities. So it clearly gives an easy migration path from the federated to the issuer-holder-verifier model. We tested the idea with some projects and communities and it seems a lot of implementers like that. Regarding Europass and other JSON-LD-based credential schemes. There could be another spec defining how SD-JWT could be used with JSON-LD.
eKCY defines its own data model same as for ID Token. eKYC can be easily mapped to VCs. The only real difference is the name of the metadata claims (iss vs issuer, iat vs validFrom, etc.) But SD-JWT can be used with W3C VCs (bot as SD-JWT is and W3C VCs as they are).
eKYC defines an extension that can be used in any JWTish environment. Doesn't work with W3C VCs due to the split between subject related data (credentialSubject) and metadata (evidence). Ask Mark Haine. not sure what you mean. can you please explain.
We did some mapping in the past (it was some time ago, and I don't remember how far we got): Evidence in VCs is optional and the model and use of evidence for eKYC doesn't make a lot of sense since eKYC already defines the full data model. eKYC can be nicely modelled within the credential subject. There were discussions around re-using the model of eKYC for expressing different levels of verifications. Essentially it was something like: verifiable-attestation-URL is the VC data model e-kyc-verifiedclaims-2022-URL - is the JSON schema of the eKYC
Just had a chat with Alen about typing and want to share the conclusion. We think typing happens on the following levels: Payload of a (HTTPS) response - here, a processor needs to know how to process the object (blob). So on this level, the media types or should be used. JOSE header - on that level, the determines how the payload of the JWS shall be processed. fits on that level. It governs the format (SD-JWT, which implies JSON) and what claims MUST be present (e.g. and ). Those claims are related to security of and trust in the credential. They are not related to the further domain specific structure of the credential. In SD-JWT VC, we use the claim to determine the structure/schema beyond the basic structure determined by the JOSE header. A university credential, for example, will have different rules for the schema of the payload than a drivers license. NAME NAME NAME NAME NAME NAME NAME Please let us know, whether we are on the same page. If so, it might be beneficial to add some text along those lines to the draft.
on point 1, I think that is ruled by the underlying protocol - OID4VP/OID4VP define those ( and ) I do not think sd-jwt vc draft should say anything about that. on points 2 and 3, i think i agree
to answer the original question raised in the issue, the way VCDM 2.0 is going, it requires data model to be JSON-LD and processed according to JSON-LD rules, so things like will not be conformant. the value of VCDM IMO is defining the concept of a credential in a three party model: issued credential must contain the issuer, the subject, claims about the subject, metadata about the issuance of that credential (iat, exp, etc.) and optionally a cryptographic key. that's it. How to map it to the JWT claims is not the expertise of w3c vc wg nor is well-defined in the documents produced by that group. VCDM itself is silent about how to sign/process the I would absolutely not equate ID Token data model to a VC data model. VC data model needs one step to get to the ID Token usability which is defining how the concepts defined in VCDM are mapped to the JWT claims and how to sign/process that JWT claimset, which is what this sd-jwt vc draft attempts to do.
NAME I think we need to at least scope the media type definition in the spec as those definitions are related to the only, not request payload.
why it can't be left to the protocol? why it can't be ? just for example: URL
NAME the way VCDM 2.0 is going, it requires data model to be JSON-LD and processed according to JSON-LD rules, so things like NAME is in the payload, we put it to be conformant, but are not processing it will not be conformant. Please check the discussion in URL since the conclusion is different. NAME What do you understand under LD processing? (LD processing with VCs is used only by: data integrity proofs, selective disclosure that's been just defined, internationalisation, identity matching, some advanced querying) Since JWS is not using any of that, JWS protection mechanism is not affected by the -LD part. However, it enable use cases, that want to use the -LD (e.g., ELM v3) for internationalisation etc., to use it. When VCs are secured with JWS, LD processing is not performed. It MAY be performed, if use case requires it, in the post-processing (after the validation) or rendering phase. the value of VCDM IMO is defining the concept of a credential in a three party model: issued credential must contain the issuer, the subject, claims about the subject, metadata about the issuance of that credential (iat, exp, etc.) and optionally a cryptographic key. that's it. How to map it to the JWT claims is not the expertise of w3c vc wg nor is well-defined in the documents produced by that group. That's perfectly fine. W3C VCDM is focusing on the VCDM data model. Note that the current VCDM v2.0, without any JWT claim, is a valid JWT. VCDM itself is silent about how to sign/process the data model I think this is a good approach of the specification, since it defines a data model. Securing mechanism should be defined by specifications like JAdES which defines a profile for JSON-based AdES.
Reason is simple and it is following the basic architecture/design principles. Signature (e.g., JWS) defines the serialisation and with it the resulting type. JWS specification cannot and should not know anything about the protocol that will use it. When a protocol defines a profile or a set of supported elements, the protocol needs to ensure that the media type that's defined consistent with the elements it selected.
NAME Perhaps I did not explain well. This is the media type definition from the spec. It does not describe the context where the media type shall be used. So people might think this is a media type that should be used as content type of an HTTP response. I think we agree this is not the case. All I'm suggesting is to document the intended use in the JOSE header (and as format identifier in credential exchange protocols). Would you agree?
I don't agree that it is a good idea to take VCDM claims and use all of those to secure JWTs, because there are existing claims from JWT claims registry and existing implementations depend on those
NAME thank you for your feedback and I fully understand your concern. We need to put things into a context: most of those cases operate within closed systems where everything is well defined - data models, verification rules, etc. Within this context, I fully agree with you. Securing JSON-LD can be done today by JAdES (pure JWS, no JWT). I believe it is worth to read and reflect on it URL From my experience, the NAME is really processed (in most cases) outside of the verification scope/process. There are signatures that rely on the context, however, that's not relevant for JWS and this discussion. (In a brute-force scenario context can be embedded/inline and problem solved - size is the price to pay - not in the scope of this discussion) Since JWT specifies that all claims are optional, libraries should be able to process JWT tokens without any JWT claims (I know how it sounds). From experience, JWS/JWT libraries verify the signature, other verifications are performed manually. People could also argue that VCs are used. This direction won't lead to a solution. ID Token and eKYC define rules for the JWT claims when they are secured with JWS. I believe there are many other use cases that define profiles, rules, etc. In an open multi-use case system, there are additional challenges and we had a good discussion with Torsten on the topic where we identified several points that should be considered. It is worth reflecting on the designs of JWS JAdES linked data proofs VCDM v2 on their data model and serialisation. Back to my question: What is the real benefit of this data model over the W3C VC data model by looking at the situation objectively? (I'm also trying to find an answer to the question) With Torsten we had a very fruitful discussion. We need to reflect on several elements. Have a nice weekend!
NAME , I missed one point. Can you please elaborate on "take VCDM to secure JWT"? If my understanding is correct (sometimes is, sometimes isn't), it is JWS the one secures the payload (and it can be any JSON). JWT claims define contextual information: who, validity, about who, for whom. We should reflect on sigTst from JAdES. I'm personally not proposing to use VCDM to protect a JWT. VCDM and JWT are both protected by JWS.
As an example, iss and cnf are registered claim names for JWTs that are used to secure the VC. Existing RFCs are using those. Therefore it doesn't make sense to overwrite those by the w3c data model in my opinion
Thank you NAME I understand your view. If VC claims were registered, what would be the benefit of the data model over VCDM? Since I’m involved in projects that use VCDM (in JSON and JSON-LD) and also JWT I would really like to understand the objective benefits od the data model.
To resolve this issue, we will add a section on relationship to other documents and include a chapter on "VCDM".
This issue is ready for a PR.
Approved with a minor proposed improvment.


Clarify the optionality of the cnf claim (to
please see issue and note that the text in this PR has "This [cnf] claim MUST be present when cryptographic Key Binding is to be supported." Also note this PR isn't for issue and it was probably a mistake on my part to have suggested text there that touches two issues. But they were both on cnf so I did what I did [no pun intended]. This PR only attempts to clarify the optionality of the cnf claim for issue . There doesn't yet seem to be consensus on .
URL
NAME you probably made the comment while I was updating my original comment based on re-reading the PR. I still think it should remain "required when cryptographic binding is used"
what does this mean? you believe sd-jwt-vc should have more than one way to do cryptographic holder binding? or that many of the credentials will not use cryptographic holder binding?
No, I just mean SD-JWT VCs can be key bound, but they don't need to be. Therefore it is an optional feature.
I see, the difference here is that if key binding shall be used, then cnf must be used while the other formulation leaves more space?
If that's the intent, sounds more appropriate to me. just saying would lead to confusion that it is optional even when cryptographic binding is used.
I also like the proposed version more. The proposed language addresses which is based on developer feedback that were confused by the current language that uses REQUIRED if ... . So I think that OPTIONAL seems to solve that issue. IMO, it is also appropriate since we have the additional requirement in the paragraph that says MUST be present if cryptographic binding is required.
Sorry, I don't understand why more space is needed here? The less optionality in key binding, more interop. with the current PR, it would be ok to use a top level sub claim and put a DID there (instead of using URL). I think it is harmful for the interop, that SD-JWT VC is hoped to bring
I don't see that this optionality is allowed by the following?
I see your point. The proposed text opens a door for key binding without using the cnf claim. However, the new text is more initiative and we could add this constraint as an additional sentence or in the section on key binding
Okay, it is already present. Sorry I didn't recheck the changes. Lgtm then
I'm struggling to understand the disagreement/argument here. But I'm trying... The text for cnf in the PR has: which seems to me to clearly says that cnf is the required way to do key binding, if doing key binding. Especially the "This claim MUST be present when cryptographic Key Binding is to be supported" sentence. Would changing that sentence to "This claim is REQUIRED when cryptographic Key Binding is to be supported" help? Maybe I'm missing the point of contention but that and the current PR text and the current text in the draft all say the same thing - that cnf is the one and only way to do key binding in SD-JWT VC but b/c key binding isn't itself required, the claim also isn't required.
I thought that was better phrasing anyway so made the change w/ 9edae9d4aa1dc2b647c77029b7d415d384cded49
Seems great to me.
You're suggested pedantic wording is indeed better than what I'd had. Thanks. I've accepted it w/ c6b138036e035e6df2a2f983aa4cf8b183d39fc2
Not all VCs require key binding. For those, cnf should be made optional.
I've read the text in URL that says "REQUIRED when Cryptographic Key Binding is to be supported." as being optional or not required when key binding isn't needed. Perhaps we need to discuss and/or make things more clear?
Do you think we should also explain the OPTIONAL case or replace the REQUIRED with something else? CONDITIONAL is not a reserved word unfortunately.
I would propose to clarify this. From a quick reading this is not obviously optional and it does not match the other claims that only state REQUIRED/OPTIONAL without any conditions. As cryptographic binding is optional, I think this line should begin with "OPTIONAL. [...]"
URL attempts to do just that
thank you!lgtm, see my comment in the discussion.I like this version. CNF is more optional to me and having required as the first keyword seems less rightI'm generally fine with the change, but I think I want to be pedantic here and resolve the contradiction.


Add general SD-JWT VC Type Metadata framework based on NAME work: URL See preview here: URL
Yep, good point. I18N is definitely needed although I'm not too sure about name/description since those are intended for developers only, not for end-users. I'll create a ticket to consider I18N, and also discuss whether this is needed for dev-only fields. I18N is definitely something we should add to metadata but needed some PR to start with first.
We have 3 approvals and no new comments coming in after 2 weeks. I propose to merge this PR NAME NAME . PR was created 1 month ago.
We should define more clearly what a credential type (identified by the claim) actually means. The current description is a bit handwavy and that may be a sign that we have not yet defined the concept well. I think that there is a set of metadata usually associated with each SD-JWT VC type, for example Display information for the whole credential A schema for the JSON structure (may or may not be defined in JSON schema) Information about the claims, including Display information Type information Status information (self-attested vs. verified etc.) Maybe: What kind of binding is supported/usually used for this credential type Maybe: What issuers are allowed to issue this credential type Such metadata would help Wallets (e.g., for displaying the credential to the user) and Verifiers (e.g., for determining the status of claims). It would also help developers of Verifiers, as they would get structured information about the credential they can expect. The need for such metadata has been discussed in Issue and similar approaches have shown up in . The metadata may or may not be embedded into the credential itself, or provided externally. Assuming we allow for registered values (e.g., ), this metadata could go into the registry. It could also be distributed manually. But it can also be made discoverable, e.g., by providing it at a .well-known URI derived from the URL in . Here is a completely made-up example of what this metadata could look like: Important: This mechanism will not be format-agnostic, but defined only for SD-JWT VC for now. There are overlaps with mechanisms defined in HAIP, for example, and part of this issue here is to figure out what data should go where and to avoid duplications by getting the concept right. I think that the element defined for the credential issuer metadata in could be replaced by just a identifier (the metadata could be discovered from there, or retrieved from the registry).
Interesting point, I have the following approach to satisfy the requirement of having the credential metadata along with a credential: using openid federation a trust chain is needed to attests the cryptographic keys of the issuer to verify the credential. Within the trust chain the openidcredentialissuer metadata is provided. in the openidcredentialissuer metadata there are the display information for all the credential types. Then, using this approach, the credential doesn't need any metadata. Fed trust chain can be made available in a static form, within the credential jws/MSO headers Let's see other points: I would not use , because its value seems more close to the concept of issuance type. I would say set(, ). Also the name may semantically collide with all about status lists It would be up to the trust model and the credential metadata or trust marks or attestations. We cannot allow an italian PID provider to issue a Polish PID, then the domestic italian credential identifier must be linked with one or more italian credential issuers. This information must be made available according to the infrastructure of trust, where the issued credentials are not involved yet. During a discovery phase the user/holder knows which are the credential issuers, which credential types they offers to users. Generally this is made available in the openidcredential_metadata and must be granted by an accreditation body. That's why I mentioned trusted lists or federation trust marks or X.509 custom extentions (for strong stomachs) or federation metadata policy. Without openid federation I would have to find a solution and the credential metadata sounds resonable but I use federation and this requirement is already satisfied. Another point of interest is that the credential metadata should be issued by credential issuer and bound to the credential. I would change this sentence we have in the current text: because the metadata should be issued by credential issuers and be tamper proof, otherwise a bogus implementation would use a valid credential with a fake presentation of the claims that may swaps some value and change the interpretation of the data to a verifier. Let's imagine that Giuseppe Marco would be swapped to Marco Giuseppe and pass through a supervised verifier as Marco, while the credential is still valid and verified
I like the idea to define schema and display information in the context of the credential definition (in contrast to issuance protocol) as I believe this information should be consistent across issuers and needs to be available for verifier developers. I also believe some information could be useful at the level of individual credentials for visual customization in the wallet.
we may add: type of binding of the vc ,e.g. key-binding, claim-based-binding, none vct could be either URL linking to the resource directly or an identifier that links to e.g. an (ISO) specification to get the credential metdata IANA registry is probably not a good option versioning of the metadata protection against change e.g. put a hash of metadata in the vc It might be worth to consider reducing the credential format specific Issuer metadata defined in OpenID4VCI and define that in a credential format specific credential metadata resource: However, there will remain issuer-specific things e.g. cryptographic support that should stay in the Issuer Metadata. These would need to be defined in SD-JWT-VC.
Using the VC type metadata, one could also include an ecosystem-specific parameter that contains a that allows you to map to any data model one want. It would also allow automatic fetching and executing the transformation algorithm quite easily.
I prepared a first draft for the SD-JWT VC metadata. I wrote this as a separate draft for working on it, but of course we can consider integrating this into SD-JWT VC — whatever works best. I'm looking forward to your feedback. URL
NAME I like the document and think it's a great start. I think there's a lot more to do around JSON Schema, similar to the work we've put into . I'm happy to help here. Similarly, the display reminds me of , which could be a standalone thing. Perhaps the types document should be transformed to a 'hub' document?
For all these "human readable strings", please make sure to have an i18n story, and ideally reference PRECIS, or DisplayStrings, etc .


Updated terminology and other sections to clarify VCs and presentations can be repudiable or non-repudiable Minor typo fixed See preview here: URL
3 approvals, merging
The specification currently uses terms like public key validation and potentially other things when it comes to the verification of the KB-JWT. We should make sure there is no language that would prohibit the use of MAC authentication for KB-JWT and Issuer-signed JWT.
Currently blocked by SD-JWT: URL URL
NAME A few options we discussed on the editor's call today (cc NAME NAME ): not do anything in SD-JWT to enable this since SD-JWT just prohibits "symmetric algorithms". We could wait for an JOSE value specification to appear and to be registered in the IANA registry which states that the algorithm is not symmetric. One downside of this approach is that standard JOSE libs won't work today since the value is not supported. Note that technically one could implement this using standard if the key was agreed/derived using an ECDH/ConcatKDF schema. remove the normative statement completely from SD-JWT that prohibits "symmetric algorithms". change the normative statement to a SHOULD NOT use "symmetric algorithms" and explain in the SD-JWT security - considerations section where symmetric values are acceptable and when not. keep the MUST NOT statement in SD-JWT but add an "... unless" clause that explains where this could be useful, e.g., for hybrid schemes but this needs to be confirmed if this process is indeed hybrid and therefore the use case is covered.
I think is the cleanest approach, but may take more time for implementations, we will try to get some experience there. also doesn't sound bad to me.
I think I still lean towards preferring something like # 2 - just remove the explicit prohibition of symmetric algorithms from SD-JWT and not say much, if anything else about it in that spec. Let the layer above SD-JWT/JOSE (probably the presentation protocol) define how an HMAC key is agreed upon and use existing JWS HMAC algs and implementations. I.e., the verifier sends a public key in it's presentation request, which the generator uses in a key agreement with their private key to get a key that is then KDFd to produce an appropriate key for existing/established JWS HS256[384|512] algs. That layer is going to have to define much of that anyway so there's not much gain from pushing an ECDH-based MAC alg into JOSE/JWS (also note that defining and registering a new JOSE alg is far from a trivial exercise). And the prohibition of symmetric algorithms in SD-JWT makes sense from a particular perspective but is arguably just unnecessarily restrictive at the building block layer.
I would agree that removing the restriction is okay, as SD-JWT is an improvement of JWT and JWTs don't have this restriction. Do you think that ECDH-ES is an anti-pattern? It has been in JWA from the beginning and you could have the same arguments there?
I wouldn't take it that far. My comments/arguments here are really just in the context of the current state of JWS specs and existing library support.
NAME NAME if option 2 is our favorite options. Should the SD-JWT VC spec then say something about that? IMO, it would be good to say something in the security considerations at least.
I agree in general that since SD-JWT is a building block, being too restrictive there regarding symmetric algorithms is probably not necessary.
I don't object removing the restriction, I checked RFC7519 and there is no similar statement.
Definitely not opposed to saying something. But it might be challenging to say something that's actually meaningful/helpful.
URL removes the explicit prohibition on MAC from SD-JWT (which will be in the -08 draft-ietf-oauth-selective-disclosure-jwt)
Then, we need a PR that cleans up the language in this specification, so MAC is not going to be prohibited.


This PR includes the following: [x] Add schema type metadata [x] Add full schema type metadata examples [x] Describe base document for schema validation [x] Minor editorial fixes [x] Moved type metadata retrieval section for readability purposes [x] ~IANA considerations for , and ~ See preview here: URL Fixes URL
NAME NAME Do you think it makes sense to describe the base document for schema type metadata validation? For example, a verifier receiving an SD-JWT VC with Disclosures won't be able to validate the JSON schema against it before transforming the entire SD-JWT VC with Disclosures to expanded JSON document first.
NAME NAME Should we restrict schema to specific JSON schema versions?
I'm honestly not familiar with the intricacies of JSON schema. Is/are there a stable standard version(s) that can be referenced from a prospective RFC? The current content of the PR seems to have some normative statements but no reference. I'd think that's kind of a prerequisite to discussing version restrictions/requirements. A few minutes of looking around and I found this https://json-URL which at least suggests it's a bit messy. Any idea if/how other actual standards documents utilize JSON schema?
Well, statements like "MUST validate the Verifiable Credential against the provided JSON Schema document." probably need some more clarity about what part of the VC and at what stage of transformation/processing.
I suggest that we proceed with merging this PR nonetheless and have a separate discussion on JSON Schema versions in an issue.
Update: We don't need IANA registration for schema, schemauri and schemauri#integrity since type metadata is not a JWT.
NAME NAME Can you please check the examples I added.
I believe we will need to distinguish between presentation and issuance schemas -> see
I don't really speak JSON schema but it looks ok
Thanks a lot. I updated the PR. Will merge later on the editor's call.
Merging this since all comments were addressed.
Define how schemas can be included in type metadata. Requirement is that it should allow JSON schema.
left a couple of editorial remarks, but generally this looks good to me, thank you!


The first example in Section 6.1 shows a credential, not a type metadata document, but is not labelled as such. The example in question:


Two approvals, merging now.
The text currently says: It must by the Issuer's choice to support either x5c, jwt-vc metadata or both, this is also how HAIP defines it. Extending this thought, the Verifier has no means of understanding what the issuer supports, given that may be an HTTPS URI but no support is avaiblable for jwt-vc metadata. This is because is the best indicator but in Section 5 only described as RECOMMENDED. Proposal is that the Issuer may chose this and that the presence of in SD-JWT VC indicates jwt-vc metadata.
This is from HAIP: By following the HAIP text, I don't understand how an issuer can support both options in an SD-JWT VC? Can you give an example? Furthermore, DNS name is not a URI and strictly speaking is this not allowed as per SD-JWT VC where has to be a URI. For that reason, SD-JWT VC says that the value needs to be encoded using the dns URI scheme. I'm not saying SD-JWT VC should not be changed in that regards because I do see some potential for improvement and I think as well that an issuer might want to support both and that needs to be addressed. We should discuss ways how this can be achieved. But I don't think is appropriate for this to control whether a verifier fetches well-known or not. I would assume that a verifier will likely know which issuer ( value) to trust and also know if the issuer is part of some trust framework that supports well-known. If not, the verifier will have to try in the same way as they try other well-knowns. I don't see the need to connect the presence of with the presence of well-known if this is what you suggested. Furthermore, I believe your specific use cases is already supported by: using an HTTPS URI for the value hosting a well-known for that URI including a x5c header with a URI SAN entry that matches the value
I don't think using to indicate whether well-known is supported is a good solution. I don't think we need this indication for the reasons pointed out above. (we can discuss whether URI scheme is a good solution in general but this is a separate topic and whether we should not limit to be a URI)
NAME at least for using kid with openid federation is resonable, because that kid is resolved within a federation trust chain
I think there is nothing wrong with: using an HTTPS URI for the value hosting a well-known for that URI including a header with a URI SAN entry that matches the iss value adding to the header In that case, using the to indicate whether well-known is supported or not would not work because like NAME mentioned, apparently OpenID federation uses as well and I believe in that case, well-known is not required. Please correct me if I'm wrong. NAME Can you explain how OpenID federation resolves the ?
To be clear, the above is valid. To be clear, the above just means that using to control how the verifier has to resolve the key does not work because people using OpenID federation might not host a well-known endpoint but will also need a .
NAME sure, thank you for asking imagine the federation trust chain like an object, related to a subject (giuseppe, a trustable entity) linked to a trust anchor (a trusted party over all the others), wwhere in the middle we may have zero, one or more intermediaries between the subject (leaf) and trust anchor. the leaf's metadata can be overloaded by the statements within the chain, along the trust anchor. Therefore the jwks the leafs claims to use, and any other protocol specific metadata, can be dynamically overloaded within the trust chain, by applying the metadata policies. once the policies are applied, the resulting metadata is called final metadata and contains all the jwks related to an entity, for each protocol (since a federation entity configuration may have more than a single metadata creafted for a speicifc role, such as VCI, RP, OP and so on). using the final metadata, the kid is needed in the form of lookup parameter within the JWKs provided within the final metadata
the resolution of the kid is interesting we may have a discovery, using well known endpoints we may have a static trust chain, provided like a x.509 certificate chain
NAME To be even more clear, they might not host a SD-JWT VC Issuer Metadata well-known endpoint but they might host an OpenID Federation well-known endpoint.
Thank you for this elaboration! It means that in this case, you won't need SD-JWT VC Issuer Metadata well-known, right?
using federation the metadata must be signed and evaluated within the trust chain, therefore, yes, there are no direct dependencies with the SD-JWT VC Issuer Metadata well-known endpoint, even if these two can cohexist within the same entity.
I'm supportive of changing value requirements for the following reasons: using could be a bit misleading using to match against the SAN DNS value is error prone (some devs might forget to do and instead do ) and perhaps misleading if does not exist (although the domain exists). Perhaps an edge case but it might have security implications.
to chage the requirement to be not a URI but a string for cases when is a DNS SAN value? the point of in HAIP was that the issuer can use the same value in sd-jwt vc to support various key resolution mechanisms - web-based key resolution (.well-known/jwtvcissuer with or without openid federation) or x509. so I am supportive of keeping a URI in sd-jwt vc, but change the scheme to as opposed to regarding your points 2 and 3, for example, in HAIP, the idea was for the issuer to support both key resolution mechanisms, so the chance of devs forgetting doing is low, and the verifier supporting x509, would have to extract dns name from as part of validations steps, so I see your points, but still think the the benefits of the same with different key resolution mechanisms is strong.
I support this, see my reasoning here: URL
NAME and I chatted briefly and are leaning towards keeping the requirement on iss to be a URI while using an https scheme for both key resolution mechanisms.
NAME said she might have some suggested text or a PR along those lines
NAME I'm going to work on this tomorrow (hopefully) so if you have anything that might help in that effort, please comment or post it or whatever works.


for and hopefully/maybe too URL URL URL
NAME this work and URL were largely undertaken as a result of your questions/feedback
Select parts of a conversation from an encrypted messaging service copied here. Editorial liberties have been taken to extract the most relevant parts of the discussion and protect the identities of the participants. >- the first example is just user claims that are being secured >- the second example is user claims + metadata that is necessary to be added when signing the sd-jwt IMHO it would be worthwhile to expand the example in URL with some additions to URL to also show the content of the thing that needs a name.
Seems related to
I think the understanding of the spec could be further facilitated by adding an example of a SD-JWT VC after the verifier has processed the SD-JWT VC and (basically) has constructed a JWT representation for further processing in the application.
The new PID example in draft -02/-03 shows the JSON data for "further processing" after validation: URL Does that seem sufficient? Or perhaps a similar addition to the example used in the main body of the draft ()? Or something different/more?
I personally don't understand why this applies to the verifier: "has constructed a JWT representation for further processing in the application". However, NAME has this issue been addressed by the examples NAME provided? Then we can close it.


Update the anticipated media type registration request from to per the Dublin Accord (last slide of URL)


Remove the requirement to insert a .well-known part for vct URLs , ,
Dr. Fett, PhD: >Gentlemen, Some feedback I received (on top of the comments we already got in the issuers) makes me second-guess the choice to use a .well-known URL for the type metadata documents. In fact, RFC 5785 tells us that .well-known is mainly to be used for site-wide information or information about a specific host. that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. Brian Campbell, B.A.: >That feedback seems not wrong to me. We've got probably a lot of somewhat questionable uses of .well-known but type metadata is maybe less well suited than most. And less needed. >It could just point to the json document. Or we make up some convention. Or something with uri templates.
Relevant related issues: , ,
I believe that lifting the restriction is not preventing the use of .well-known; IMO there are two approaches provide the full link signal that the metadata is under the well-known However, metadata owner must be aware of the responsibility to take care of the versioning. As mentioned in , should there be a requirement to either use hash links or protect the remote content via vct#digest? Dr. Horvat, PhD
Maybe I'm missing something, but the change in PR should mostly solve this, I think. It now requires to provide the full URL to the metadata. (If someone wants to provide it under .well-known, that is their choice, but doesn't influence the requester at all). For versioning I filed a . Not sure about making #digest mandatory, but we should also discuss this separately.
digest mandatory, but we should also discuss this separately. -> if it's an external resource, it should be defined how it is protected
URL Is defining that if vct is an https:// it should check the metadata under the well known (at least the 2nd part of the text reads like this: Many registries are, and will be accessible via URLs, hence the metadata type is expressed via an URL; Adding or maintaining a .well-known might not fit in the existing API designs. Also note that .well-known has well-known issues with multi-tenancy. Most use cases will delegate the hosting of the information to registries. Also Questions: if schema is https, should the full URL be provided? (no ambiguity with .well-known, you can host schema on github, ...) metadata retrieval category re-consideration: 1) Fetch vct from a remote source: a) URL: HTTPS schema -> full URL that points to a schema b) URN: domain-defined URN that MUST be understood by the wallet; The URN method defines how to map the URN to URL and retrieve the data 2) Fetch vct the metadata locally a) local cache b) Signature (signed or unsigned header); Whether or not metadata is shared in the (un)protected header is defined by the signature format, hence out of scope of this document. 2b: point to consider for the OID4VP: should there be a flag: "archival mode" or similar, that would flag that the wallet needs to provide all the referenced content in an unprotected JWS header?
removes the requirement to insert .well-known (discussion in )
Type Metadata introduced new well-known URI /.well-known/vct/ in "6.3.1. From a URL in the vct" , but this is not reflected in appendix-A.3 Well-Known URI Registry. Additionally, using in sentence "Metadata can be retrieved from the URL URL, i.e., by inserting /.well-known/vct after the authority part of the URL." seems to me a little bit confusing as type is considered to refer to whole URI. Maybe use or (to include also query and fragment URI components)?
Thank you and yes, the registration request is missing and needs to be added. And that sentence could also be improved.
Although the use of .well-known for type metadata is being reconsidered
Current text: Since well-known only applies to HTTPS URLs, we should limit the section to HTTPS URLs although other URLs would be still possible, e.g., . Additionally, also the in is probably not correct since the type refers to the value itself which would not make sense to the full value here which would also include the scheme for instance. I suggest we update the title to "From an HTTPS URL in the claim" and update the language to something like this:


and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL


Pros: selective disclosure of types possible to increase privacy and to reduce contextual info more granular types possible issuers don't have to issue multiple credentials Cons: polymorphism always is a challenge, we that with no support in SD-JWT yet to selectively disclose array elements
After further discussions it seems that multiple types might cause difficulties with JSON schemas. If multiple types are required in the future (e.g. more implementer's feedback), we can update the specification. So, let's make a single string value.


I left some references open that will be addressed by other pull requests changing the surrounding text in order to avoid merge conflicts.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.
lgtm


I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.


Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.


In the rendered HTML, the entire algo appears in one paragraph. The mmark is probably broken and has to be fixed.
lgtm, thank you!


As agreed on the editor's call (5/23), the following ... should become ...
I'm still confused why we need this text at all. What people will basically get is "this spec deviates from the VCDM 2.0".


fix:
in the three-party model: An Issuer creates a Verifiable Credential for some End-User (Holder), who then presents this credential to multiple Verifiers. A Verifiable Credential might contain a large number of claims, but the Holder We should short this as suggested by NAME Originally posted by NAME in URL
Relates to