the wallet finding the user claims in the credential

[Sakurann]

when the user-related claims attested claims are top-level, how does the wallet knows which claims are about the user vs metadata claims vs status related claims? One could say, first validate and remove all metadata claims, than validate and remove all status related claims, and what is left is the claims about the users, but that is not always realistic. for example, issuer put aud, and wallet is not expecting it, how does it know aud is not a claim about the user? or there are multiple mechanisms to express status, when the wallet supports only one of those, how does the wallet know that claim is not a user claim. it would be a bad UX if the wallet accidentally displays those claims to the user.
the suggestion would be to have a top-level claims claim where the issuer puts the claims it is attesting about the user/subject, so that the wallets/verifiers can know clearly, which are the claims about the user.
cc @dangodb

[bc-pi]

Maybe that top-level claim could be called credentialSubject...

More seriously though I think this is something that's just kinda inherent to JWT in general and while there are potential issues there as you describe there are also things in place to help. https://datatracker.ietf.org/doc/html/rfc7519#section-4 says to ignore claims not understood (aud is defined and registered so needs to be understood btw) and vct with something like prospective SD-JWT VC Type Metadata and/or OID4VCI's credential issuer metadata give tools to "understand" claims in a given context.

[awoie]

This issue raises a point that we discussed a while ago, essentially having all metadata-related claims in the header. What about having a dedicated metadata claim instead of having a dedicated claims claim?

[awoie]

Also what metadata are you interested in? Or are you including things like status/iat/nbf/cnf as metadata?

[Sakurann]

I am not necessarily arguing to put metadata in the header - that would probably make it harder to leverage the existing JWT libraries. and for the sake of this point, I am calling metadata anything that is not a claim about the holder/subject.

I mean, nothing stops implementations from using "claims" JWT claim on top of what is currently defined in sd-jwt vc draft, but I worry that that would result in non-interoperable implementations, defining "claims" parameter seems like a non-brainer that could help with interoperability here..

[awoie]

Would it make sense to instead put dedicated VC metadata that is SD-JWT VC instance (not vct) specific into a dedicated metadata claim instead? This way, existing JWT claims can be used.

[danielfett]

This can be solved with metadata. In particular, the wallet can check if there is display metadata associated with a certain claim or not. We should add a sentence explaining how that works to the metadata spec as soon as the display metadata was added, see #236