-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify that vc
vp
claims do not include entire VC/VPs
#4
Comments
@Sakurann Unfortunately your initial assertion was not fully supported by the v1 specification, because the spec says "For backward compatibility with JWT processors, the following registered JWT claim names MUST be used instead of, or in addition to, their respective standard verifiable credential counterparts: " I initially tried to remove "in addition to" from v1.1 (which is effectively what you are suggesting) but eventually we decided against this for two reasons: |
Agree with @David-Chadwick ... However, if this issue is targeted at v2, we can start to argue over breaking changes... If we take the "instead of" path... We must define a lossy conversion process between the VC Data Model and JWT representations, and it must account for 100% of the VC Data Model features in v2. If we take the "in addition too" path, we must define a non lossy conversion process and normative requirements for using the "in addition too" components.... I think "instead of" sets the wrong tone for what a VC is... its not a JWT... JWTs are not the source of truth for the data model... in fact, JWTs are just 1 possible serialization of the data model, and we might want to make better room for JWPs or ZKP-CL, or LD Proofs... without the awkwardness with ended with in v1. If a proof format cannot represent the information an issuer wants to claim... we should not limit what an issuer can claim, we should be explicit about what you loose / gain by picking that proof format... Today, at a minimum, you loose leap seconds and any JSON components of the I would like to see VC Data Model 2.0 enable JWTs that have issuers that look as nice as LD Proofs... for example:
This would mean NOT taking the "instead of path"... it would mean taking the "in addition to" path. Which every path we take, we better be as consistent as possible for all properties... But we can decide to handle dates with "instead of" and all other properties with "in addition too"... I'm generally opposed to JWT representations that loose semantic information, and thats why we implemented the spec using the "in addition too" instead of "instead of"... also... by convention in JSON, any property not understood is ignored... so its safer to keep the data and ignore it, than try to translate or convert it. |
The issue was discussed in a meeting on 2021-12-01
View the transcript3.4. clarify that
|
short answer is that they do when you pick the |
I think you're saying that "[ |
@TallTed thats correct, I am addressing the title of this issue. In this implementation: https://github.com/transmute-industries/verifiable-credentials I chose the If you choose to implement the This is another reason why |
since this is v2 and we are allowed to make breaking changes... From the discussions, below seems to be an option that minimizes the need for mapping/transfrming between "vc-data-model" properties and existing registered JWT Claims while correctly uses existing registered JWT Claims enabling to reuse JWT libraries:
(focusing on the JWT body claims since there are issues for each of the JOSE header claims ( |
Under 1.1 rules, I think making the I am a strong -1 to "almost" |
Ah, that's interesting. In that case, would you define "vc" property similar to what I propose above or as something different?
Not sure I understand. what is "almost" application/credential+ld+json.. |
@Sakurann I think you have some typos in your message about the JWT claims. Specifically
|
An object that is conformant except without any properties that can map to a JWT.... aka the "instead of path". I am ok giving that content type a unique |
I'm going to mark this pending close, since AFAIK, its been overtaken in the latest draft, but I have filed #119 Which I think is a better place to follow up on managing v1 vs v2 compatibility. |
It seems to me that a better place to follow up on managing v1 vs v2 compatibility would be an issue with exactly that focus and title, rather than one asking whether to deprecate |
Marked pending close over 1 week ago, closing. |
vc
andvp
claims in the JWT encoding include only the properties such as@context
,credentialSubject
that do not have equivalent IANA registered JWT claims such asexpirationDate
,id
, etc.vc
andvp
claims do not include entire VC/VPs, which is not clear from the description below.Suggest to clarify the description to something like following (happy to do a PR):
The text was updated successfully, but these errors were encountered: