Clarification of JWT encoding

[David-Chadwick]

---

Preview | Diff

[OR13]

this is so great to see! I wonder if we might fully define these transformation functions, I would like to see them made explicit.

[TallTed]

@OR13 -- I suggest creating a new issue "to see [these transformation functions] made explicit".

[OR13]

My only real concern is: https://github.com/w3c/vc-data-model/pull/828/files#r740230917

This PR is excellent, and very much needed. thank you.

[David-Chadwick]

@brentzundel Thankyou for clarifying the position wrt normative statements. Given the importance of adding this clarification text to v1, it is more important to keep the changes without adding any new normative statements and issue this PR in v1.1. We can add normative statements in v2 if they are needed.

[TallTed]

@David-Chadwick -- This PR is showing merge conflicts. They appear to be pretty simple, and, I think, should be easily resolved.

[kdenhartog]

As discussed on the call we're going to remove the MAY to SHOULD change on line 3455 so that we can be certain that this text remains as a purely editorial change. I've labelled it as such since that's what was agreed to by the author of this PR.

[iherman]

The issue was discussed in a meeting on 2021-11-03

• no resolutions were taken

View the transcript

3.1. Clarification of JWT encoding (pr vc-data-model#828)

See github pull request vc-data-model#828.

David Chadwick: what i need to understand is what happens to the existing PR for v1.1 not in the text manu has pointed to..
… manu said that anything new will be exceedingly difficult. in that case, the outstanding PR needs to go in before the 9th of november. the other day, talking about the VC-HTTP-API working group, manu said there's no problem making changes in v1 through january..

Manu Sporny: let me try to explain. my understanding of the whole process has been changing every 2 days, because the process document doesn't outline everything that comes into play..
… we should merge in editorial things into 1.1 as soon as we can, which is almost immediately. these will go into the active working draft, so if people look at the editor's draft it'll be there. after january 14th, if those things are purely editorial, we will be able to publish those changes..
… we have to freeze things for the AC to review then. if it is truly editorial, then it will get in there. what we learned was about how difficult it was to get things into the document as the AC was reviewing..
… before, we decided 1.1 and 1.2 path, and then we decided not to have two branches. because there is only one path now, we cannot easily push out editorial changes into the space, until january 14th.
… we can merge editorial changes into the 1.1 branch, and once jan 14th hits, we can push it out as an editorial update and good to go.

David Chadwick: is 1.1 containing the normative changes in there from 1.2?.

Manu Sporny: yes.

David Chadwick: we should put in the changes this week then.

Brent Zundel: we can merge any PRs that are editorial and within scope of 1.1, we can merge into the v1.1 branch, and accumulate a body of editorial changes..
… the TR space recommendation that is currently under review, we're not gonna touch that..
… once the review period is over, regardless of the outcome, we will have the option of then merging the body of the editorial changes into the 1.1 branch. the work we're doing isn't going to be lost..
… the PRs in the queue to merge into 1.1, we can refine those and merge in them in, but the precise time they will be published into TR space will not happen until jan..

Kyle Den Hartog: with the intent of doing a V2 spec pretty soon after, we have to work through the chartering stuff. the intent of any of these substantive changes that are coming in is to have them fit into the pure view of the v2 scope. some of the more substantive changes we've been looking at, related to jwt work, we're talking about separating out the proof suites into separate documents about them specifically.

Kyle Den Hartog: so it could be useful to hold off on the jwt work, because we would want to see jwt into its own document. in that case it would make sense for those things to work together. while it's difficult for us to get stuff into 1.1, it's not the intent of the WG to stall the work, there's just a slight delay due to rechartering..

David Chadwick: that's fine, i don't mind a separate document for JWT next time around, but the situation we're in at the moment, is that the current JWT section in the spec lacks clarity, and the PR brings the clarity. in my opinion, it's imperative that those changes go in the 9th of november..
… the key aspects of that PR must go into the spec by the 9th of november. people have been saying there's a lack of clarity, and there's no reason for that not to be included except for slow responsiveness..
… i feel very strongly about this, because we're doing a disservice to the world community without the clarity.

Kyle Den Hartog: is this actually editorial?.

David Chadwick: the current spec doesn't say anything about how bearer credentials are dealt with. this PR clarifies what people can infer but may have inferred wrongly..

Manu Sporny: pull 828?.

Brent Zundel: yes.

David Chadwick: the one to do with JWT is the important one, which adds text.
… feedback from orie that this is really good.

Manu Sporny: just on the responsiveness, you raised the PR days ago, responses from ted and markus on the day. i retargeted the branch, there were merge conflicts. orie said it was good but don't merge, 2 days ago, esp. with the removal of nonce.

Manu Sporny: See latest commit diffs.

Manu Sporny: there is a change to normative language, like 3455, you're changing a MAY to a SHOULD.
… if you remove that line, i think it'd be editorial, and with that and merge conflicts fixed, we could see it in. please don't merge it before november 9th, but it's many hours of work for the editors. so either it's a normative change and that's problematic, or it's an editorial change and doesn't affect implementers..
… we do get this into the publication, in the editorial version, as soon as the merge conflicts are resolved, we can merge that into 1.1 so it's live on the editorial branch. once jan 14th hits, it'll go out in the live version and get the changes you want in the spec in there..

Brent Zundel: making an assertion and asking a response to you DavidC. i am asserting that further editorial changes will not be made to the document that is being reviewed by the AC. and having made that assertion, i must ask, in light of that, is it your intention to formally object to the document that is under review?.

David Chadwick: i'd like the changes in.

Brent Zundel: if that doesn't happen, would you formally object?.

David Chadwick: i will discuss with the people who have asked for the changes and see if it's acceptable or not. i was in the fortunate position of understanding the JWTs because i was part of the VC drafting process. but the majority of the people implementing do not have the background and knowledge..
… if they say they would like it in the document, i will object. it depends on what other stakeholders who have had problems figuring out exactly how to do it..

Brent Zundel: no one is saying we don't want these changes. it's about timing-wise.
… either we ask our editors to spend hours and hours of work to merge in the changes outstanding, or publish what we have already documented on the 9th, while continuing to refine your PR, and as soon as it's ready merge into the 1.1 branch. as soon as review period over, and candidate merged into the rec, we can take that candidate 1.1 branch and merge into the recommendation as needed..

David Chadwick: will the draft be visible to people?.

Brent Zundel: yes, it will be possible to point to people to a published document that we can say will be coming on jan 15th.

David Chadwick: are you saying that the pointer in the document which manu pointed us to, which is w3c recommendation 9th of november, 1.1, where it says latest editor's draft, that will have the PR in it for JWT once it's been agreed to. is that right?.

Brent Zundel: yes.

David Chadwick: so people will have that visible?.

Brent Zundel: yes, it won't be TR space.

David Chadwick: that may be acceptable.
… i just want people to know it's not hidden, because it's important that people can see it.

Brent Zundel: totally agreed, it's just about the timing & process.

David Chadwick: i don't want to give you hours of work, that's not fair. it's just sad that this wasn't done more quickly.

Brent Zundel: no disagreement.
… anything else?.

Kyle Den Hartog: when you're in conversations with these people who may object, the solution we've put forward, can you be sure to mention that the text going into v1.1 editor's draft will be there. i'll put a link before closing the PR so it's easier for people to find in the editor's draft in the intermediary..

David Chadwick: they will just need to see the v1.1, click the "latest editor's draft" and see it anyway. that's what brent said.

Manu Sporny: quick reminder, it came from "i'm representing..." it's problematic to potentially cross anti-trust boundaries at W3C. big companies have been known to hire small companies to pack a room, not saying you're doing that, but it's really that kind of behavior that's frowned upon at w3c. these people can jump on the issue tracker and provide the feedback to this group, and they should not be doing it through you.

Manu Sporny: it makes it difficult to have a direct conversation with people who have the issue...

[iherman]

The issue was discussed in a meeting on 2021-11-03

• no resolutions were taken

View the transcript

4.3. Clarification of JWT encoding (pr vc-data-model#828)

See github pull request vc-data-model#828.

Brent Zundel: david's PR, 828, you're welcome to walk us through this set of changes.

David Chadwick: i don't see the same text i saw when manu said it...the MAY/SHOULD is not visible to me.

Brent Zundel: sharing my screen. on 3455, we have may going to should.

David Chadwick: this is the only one that is still contentious. i didn't think this was a normative change from the implementation perspective, therefore there's no mandatory requirement. ted, are you available to comment on this?.
… it was the fact that changing a MAY to a SHOULD, is that a normative change? it doesn't affect implementors.

Ted Thibodeau Jr.: it is a normative change but does not make an implementation of the MAY non-compliant..
… it is normative, but does not force implementation change.

David Chadwick: so the real issue is: is this prohibited from the v1.1 editorial?.

Kyle Den Hartog: the precedent we've held throughout this WG is any change to normative text requires it to be a substantive change, based on my reading of the different classification of changes in the W3C process, so my preference is to leave it as a MAY for now, SHOULD later when it's easier.

Manu Sporny: the danger DavidC is that if we make that an editorial change, any W3C member can force us to put everything through a candidate correction, making all the editorial changes we've made under review, adding months to timeline.
… we should probably do MAY.
… we don't let any of the other PRs to touch normative language if they were editorial.
… it doesn't make a difference at that particular line, the rest of the stuff is very easy, we can merge it sooner than later.

David Chadwick: agreed, we will keep the normative text as-is.
… the other issue brought up by Orie, was removal of the nonce.
… there is no nonce as a JWT claim, it doesn't exist. there's no text anywhere in the spec.
… we put the nonce in the VP claim.

Brent Zundel: we are out of time.
… the text of this conversation will go into the PR.
… you need to have the conversation w/ Orie.

David Chadwick: already in the PR.

Brent Zundel: the process of determining this is still ongoing..
… Agree that changing may to should is probably not substantive, but don't know if we need to go down that road..
… MAY -> SHOULD is arguably not substantive, but we're not sure if we want to go down that road.

David Chadwick: yeah probably not.

Brent Zundel: Thanks to everyone that came, still have v1.1. issues.
… you're all fantastic bye.
… Hopefully we have a chance to look at that next time, thanks to wayne for scribing, see you next week..

---

[iherman]

The issue was discussed in a meeting on 2021-11-10

• no resolutions were taken

View the transcript

3.4. Clarification of JWT encoding (pr vc-data-model#828)

See github pull request vc-data-model#828.

David Chadwick: The last time we discussed, I understood -- 2 changes, remove the SHOULD believing that wasn't normative..
… Last meeting we discussed that perhaps it was, we go back to MAY.
… TallTed said there were issues in merging, but not substantive, changes to latest version should work there..
… There is no such thing as a nonce, it's not a claim in JWT, it's a property of the VP, if you want the nonce, you'd move it down into VP claim..
… I just need Orie to agree that that's the right way to agree to nonce..

Dave Longley: https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes (https://openid.net/specs/openid-connect-core-1_0.html#ClaimsContents) <-- OIDC uses "nonce" as a JWT claim ... maybe that should be referenced for the JWT case.

Manu Sporny: https://www.iana.org/assignments/jwt/jwt.xml <-- nonce exists here.

Brent Zundel: suggested we keep the nonce, and then describe nonce more fully later for all the cases it is present.

Manu Sporny: nonce is defined in OIDC as a valid claim name so we can use it.
… I think we should add a sentence to described it.
… The nonce is there to prevent replay attacks.

[David-Chadwick]

This PR is showing merge conflicts. They appear to be pretty simple, and, I think, should be easily resolved.

@TallTed - some are, which I have made, and some are not. The latter appear to be changes between this PR and v1.1 that concern JWTs that are part of this PR. They should be incorporated into this PR so as to include all the changes to the JWT description that need to be made

The nonce has been re-inserted along with an explanatory sentence

[David-Chadwick]

As discussed on the call we're going to remove the MAY to SHOULD change on line 3455 so that we can be certain that this text remains as a purely editorial change. I've labelled it as such since that's what was agreed to by the author of this PR.

@kdenhartog This has now been done.

[msporny]

Only one remaining normative change. Once that's fixed, this is ready to be merged.

[kdenhartog]

I've gone and resolved the merge conflict at the request of @David-Chadwick. I made my best effort to align the text with my understanding of what has been agreed to at this point, but there were some instances where the conflicts were related to the text still in the process of being discussed. Can we get the reviewers (@peacekeeper @TallTed @brentzundel @OR13 @msporny) as well as the author (@David-Chadwick) to take a look at this again when they have the time to just to make sure I didn't accidentally change something incorrectly.

[OR13]

Saddly, I agree that we can't call this change editorial:

https://github.com/w3c/vc-data-model/pull/828/files#r749558939

I really, really, wish we could fix this, but IMO its not a good move to do it in this change set, and without clearer code review from JWT implementers.

cc @selfissued

[kdenhartog]

Can you clarify why a vast majority of the "verifiable" terms are being removed?

[OR13]

probably because its not actually the same type... in JWT land, jwt.payload.vc.issuanceDate is maybe not required if the 'instead of' path is taken... leading to type ambiguity if the term verifiable credential is used to refer to the vc payload... the jwt.payload.vc is in fact not verifiable... only the jwt (the outer container that includes it) make sit verifiable.

[OR13]

this is in line with the langauge we use as well:

credential: JSON with an @context that contains all required fields except for proof
-> issue ->
verifiable credential <JWT or LD Proof>

[OR13]

if issuanceDate is a required attribute of a verifiable credential (thats what the spec says today)...then removing it destroys interoperability and conformance.... calling the thing that might not have that property the same as the thing that has to have that property is problematic.

[msporny]

if issuanceDate is a required attribute of a verifiable credential (thats what the spec says today)...then removing it destroys interoperability and conformance

Yes, and (removing issuer and issuanceDate and all other JWT-encoded properties) was exactly this was suggested on the call yesterday, which tells me that the entire VC-JWT ecosystem is not interoperable today.

[OR13]

IMO, this change should be accepted, since vc is obviously not a verifiable credential under the current normative text... its possibly also not a credential under the current text, but this is a step in the right direction. We should not be standing in the way of a "more truthful" editorial refinement.

[David-Chadwick]

Can we all agree that a credential that is produced from all the different flavours of VCs (JWT with/without duplication, LD-Proofs of different types, ZKPs etc) after the proof has been removed will all be identical? This is what we have already said in PR #808 that has been merged.
This explains to @kdenhartog why verifiable credential has been replaced by credential in a lot of the text, since credential is talking about the same data structure regardless of the proof format. Whereas talking about verifiable credential leads to ambiguity and misunderstanding since a VC in different proof formats will contain different data elements.
Thus a credential must have an issuer property. But a VC need not have it (if it is a JWT with duplication removed). Thus to answer @msporny, we have other edits that are needed to change occurrences of verifiable credential to credential since the current text is fundamentally wrong. (And we all know why this is. To refresh your memory, it was because originally we all thought that all VCs would have a proof property and would all be identical apart from the proof property. But this was a false assumption based on the fact that the JWT encoding had not yet been specified).

[TallTed]

Suggested change

	claim names MUST be used instead of, or in addition to, their respective standard
	claim names MUST be used, instead of or in addition to, their respective standard

[TallTed]

@David-Chadwick -- You marked this resolved, and said that such marking meant you had applied my suggested change. This change was not applied. I am applying it now in a new PR.

[OR13]

@David-Chadwick I don't think we can necessarily agree to what you wrote without making substantive changes to the spec.

but i think we agree in spirit.

Verifiable Credential

required fields:

• @context
• type
• issuer
• issuanceDate
• credentialSubject

(note that id is not required)

Later in: https://w3c.github.io/vc-data-model/#proofs-signatures

It says:

At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.

An external proof is one that wraps an expression of this data model, such as a JSON Web Token, which is elaborated on in Section § 6.3.1 JSON Web Token.

It does not say that an "external proof" proof is applied to a "verifiable credential" it says that an"external proof" is applied to a credential, and that is what makes a credential a verifiable credential....

I interpret that as "Verifiable Credentials ALWAYS have an external or embedded proof", and by implication, "Credentials" NEVER have an "external" or "embedded" proof.

then later this happens:

jwt.payload.vc

required fields: ???

IMO, jwt.payload.vc is not a verifiable credential IF it does not contain the required verifiable credential fields that the specification defines OR it does not have an "external" or "embedded" proof.

And the language referring to "instead of" is a normative dirty bomb... making it impossible to provide a safe mapping between unambiguous JSON types for either Verifiable Credential or Credential (which as far as I can tell is never defined with MUST statements, meaning it has no required fields).

The JSON in vc is not and cannot ever be a verifiable credential, under the current language... Because of what this section says about external proofs: https://w3c.github.io/vc-data-model/#proofs-signatures

A JWT can be a VC, but a jwt.payload.vc is a credential.... since it does not contain an embedded proof, and is not the external proof.... if by referring to jwt.payload.vc we always actually mean jwt... then yeah, the JWT is a verifiable credential... and again, if all I hand over is JSON part... no its not a verifiable credential... imagine handing someone sub and saying its verifiable sub but not providing any proof.... clearly sub by itself is not verifiable... you need the external proof (header and signature) to make it verifiable....

If the spec defined credential AND verifiable credential AND their relationship better... this would all be much easier to explain.

I think changing verifiable credential to credential means MUST statements about verifiable credential (such as "external" or "embedded" proofs) are no longer relevant to conformant implementations.

However, it would appear that we do need to make these changes, since the current language is clearly broken in many ways, and needs to be fixed, and this PR is a step in the right direction IMO... I am just not sure how far we are allowed to step.

Coming back to the original question:

Can we all agree that a credential that is produced from all the different flavours of VCs (JWT with/without duplication, LD-Proofs of different types, ZKPs etc) after the proof has been removed will all be identical?

credential IS NOT produced, it is consumed by issuance, and an embedded or external proof is added to it, which leads to a verifiable credential which is produced by issuance.

credential might be recoverable or produced by verification of a verifiable credential...

We sadly can't agree that credential is recoverable from verifiable credential IF we allow "instead of + data type conversion"... we can agree that credential is recoverable from verifiable credential IF we forbid "instead of and ignore data type conversion".

In other words:

credential:json -> issuer consume -> select proof ("embedded" or "external") -> issuer produce -> verifiable credential

It is ALWAYS possible for credential to be recovered IF and ONLY IF, we preserve all its properties as the JSON that they were before signing, and assign jwt.payload.vc = credential and we call the JWT a verifiable credential, and its payload.vc a credential.

It is SOMETIMES possible for credential to be recovered IF a lossless bi-directional mapping exists between all "instead of" properties AND jwt.payload.vc = credential (with properties removed / moved up a level and renamed) and we call the JWT a verifiable credential, and its payload.vc a credential.

It is NEVER possible for a credential to be recovered IF a lossless bi-directional mapping DOES NOT exist between all "instead of" properties" AND jwt.payload.vc = credential (with properties removed / moved up a level and renamed)...

issuanceDate is a required property of both credential and verifiable credential... (https://w3c.github.io/vc-data-model/#issuance-date) ... and yet, there exist XML Date Times that cannot be directionally mapped to unix time stamps without loss of information... QED.

I would argue that the correct things to do here are:

1. define credential in JSON Schema
2. define credential with external proof in JSON Schema
3. define credential with embedded proof in JSON Schema
4. define vc-jwt as credential with external proof in JSON Schema
5. define vc-ld as credential with embedded proof in JSON Schema
6. define verifiable credential as oneOf vc-jwt and vc-ld
7. define jwt.payload.vc as of type credential with external proof and NOT vc-ld as credential with embedded proof.
8. forbid "instead of" and retain "in addition to".

Consider forbidding XML Date Time strings that cannot be losslessly bi-directionally converted to unix time stamps.
Consider renaming payload.vc to payload.credential.
Consider renaming payload.vp to payload.presentation.

I don't think we can fix all these in this PR, but we should stop referring to the value of the key jwt.payload.vc as a verifiable credential, because it is not one when considered by itself... it should be referred to as a credential with external proof, it only becomes a verifiable credential when its part of a decoded JWT and you have the external proof... thats painfully confusing, and should be fixed by not using the same word for 2 different data types...

Be especially aware that the current Microsoft verifiable credentials implementation uses "instead of" and NOT "in addition to"...

I would strongly discourage anyone from using VC-JWT in production given the current issues, but I am hopeful these issues can be fixed in the future.

However, if you are interested in getting a head start on vc-jwt interop, checkout this work item at DIF:

https://identity.foundation/JWS-Test-Suite/#implementations

[TallTed]

@OR13 -- You've drawn a distinction between the classes "Verifiable Credential" and "Credential". I think this is the wrong distinction. I think that the classes "Verifiable Credential" and "[Unverifiable] Credential" (where "[Unverifiable]" is usually left unstated) are disjoint subclasses of, and together comprise the totality of, the class "Credential". This is definitely confusing, and I fear there will be a great many changes, hopefully all Editorial, because of this, but I think that is probably the rigorous, and therefore correct, thing to do. (The changes I speak of are primarily putting "Unverifiable Credential" in place of "Credential" wherever the subclass is intended, but there may be follow-on changes needed.)

I interpret that as "Verifiable Credentials ALWAYS have an external or embedded proof", and by implication, "Credentials" NEVER have an "external" or "embedded" proof.

-- therefore changes to --

"Verifiable Credentials ALWAYS have an external or embedded proof", and by implication, "Credentials" MAY have an "external" or "embedded" proof, while "Unverifiable Credentials" NEVER have an "external" nor "embedded" proof.

[OR13]

You've drawn a distinction between the classes "Verifiable Credential" and "Credential". I think this is the wrong distinction.

I am just restating what the spec says today:

At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.

https://w3c.github.io/vc-data-model/#proofs-signatures

But I agree with this part very strongly:

"Verifiable Credentials ALWAYS have an external or embedded proof", and by implication, "Credentials" MAY have an "external" or "embedded" proof, while "Unverifiable Credentials" NEVER have an "external" nor "embedded" proof.

[msporny]

I would strongly discourage anyone from using VC-JWT in production given the current issues, but I am hopeful these issues can be fixed in the future.

I cannot agree more strongly with this statement. I've been saying that for years... yes, it can be fixed, but people have been promising to do that for years as well (and yet, it keeps not happening).

Anyway, we'll deal with this in the VC 2.0 work, if it's not formally objected into oblivion. :P

[David-Chadwick]

@OR13 "I don't think we can necessarily agree to what you wrote without making substantive changes to the spec. but i think we agree in spirit."
I agree that substantive changes are needed to the text in order to make it 100% crystal clear and unambiguous to everyone. From my decades or work in producing standards I have learnt that standards are like code: different parts are written by different people, and they are full of bugs, many of which are known about but the time and effort to fix them was not deemed to be worth the cost involved, whilst others are not known about until someone discovers them. I think the VC spec is like this. We have known about many bugs since before it was published but we decided that publishing on time was more important than fixing the bugs (cost/benefit decision). Other bugs are only becoming apparent now (to some of us at least).
We have to take a pragmatic view on how to resolve this. So I propose:

1. A full fix is done for v2, which unfortunately will be more than a year from now.
2. In the interim (between now and January 22) we do as many editorial changes as possible to help alleviate the problems that you have excellently identified above, and perhaps add footnotes (or in the implementation guide) detailing the bugs that will be fixed in v2 (We have a precedent here with the date/time stamps that are described in v1.). In addition, with the new example (non-normative) formats that @msporny has been producing, we produce "best practice" examples for JWT that we believe will accord with the v2 specification (by removing duplicates) and not conflict with the v1.1 specification.

[David-Chadwick]

@OR13 "especially aware that the current Microsoft verifiable credentials implementation uses "instead of" and NOT "in addition to"..."
Our implementation also uses "instead of". This is the correct approach.
I raised this issue at the OIDC SIOP meeting yesterday, and they said that the rules for JWT processing in OIDC are that if claims are duplicated and have different values then the entire JWT is rejected. Thus using "in addition to" raises the distinct possibility that the JWTs will be rejected because of mistakes in duplication even if these are unavoidable, for example, the iat claim and issuanceDate property not being equal due to leap seconds.

[David-Chadwick]

@TallTed I disagree with your credential classification. Credential is the superclass. A verifiable credential is a subclass of credential and is a credential with a proof property. Therefore a currently unverifiable credential i.e. a credential without a proof property is still a credential and cannot be differentiated from it, whereas a verifiable credential can be differentiated as it is a specialisation and has a proof property. If you are implying that we should introduce the class of object "never verifiable credential" to be a subclass of credential that can never have a proof property added to it, then I reject this notion. It has no place in the VC standard and we should not introduce it.

[TallTed]

[@David-Chadwick] @TallTed I disagree with your credential classification. Credential is the superclass.

That's what I said. You do not appear to disagree with me.

[@David-Chadwick] If you are implying that we should introduce the class of object "never verifiable credential" to be a subclass of credential that can never have a proof property added to it, then I reject this notion. It has no place in the VC standard and we should not introduce it.

Indeed, we should not introduce this notion, and I wish you had not done so here! Having reread my writings above, I don't see how anything I wrote could be construed this way!

In bastardized (ETA: and incomplete; there are many attributes of these, and possibly other entities, which would need to be present for this to be complete; the snippet below is purely to clarify my understanding of vc:Credential vs vc:VerifiableCredential vs vc:UnverifiableCredential) Turtle:

PREFIX vc: <https://github.com/w3c/vc-data-model/ontology/#>  
# I don't remember if a VC ontology exists yet, nor where it is, 
# but this should communicate well enough for this discussion

vc:VerifiableCredential   rdf:type             rdfs:class ;
                          rdfs:subClassOf      vc:Credential ;
                          vc:hasProofProperty  "True"^^Boolean .

vc:UnverifiableCredential rdf:type             rdfs:class ;
                          rdfs:subClassOf      vc:Credential ;
                          vc:hasProofProperty  "False"^^Boolean .

vc:Credential             rdf:type             rdfs:class ;
                          vc:hasProofProperty  "Indeterminate"^^Schrödinger .

Perhaps that's clearer?

[kdenhartog]

Can we all agree that a credential that is produced from all the different flavours of VCs (JWT with/without duplication, LD-Proofs of different types, ZKPs etc) after the proof has been removed will all be identical? This is what we have already said in PR #808 that has been merged.

Yup, that's in line with what I was thinking we were doing as well and I agree with this.

Slight correction after reading through @OR13 post.

credential IS NOT produced, it is consumed by issuance, and an embedded or external proof is added to it, which leads to a verifiable credential which is produced by issuance.

This aligns with what I agree with and I glossed over the response to quickly to realize that nuance.

And we all know why this is. To refresh your memory, it was because originally we all thought that all VCs would have a proof property and would all be identical apart from the proof property. But this was a false assumption based on the fact that the JWT encoding had not yet been specified

Yeah, this is why I raised the question is because when reading it we say the credential in JWT format and it made me think "wait, is this implying the full JWT is a 'credential' or is this just referring to the payload portion". If the intent of this change was to refer only to the JWT format payload, then I agree that these should be set to credential, but that wasn't clear to me while reading it hence raising the question.

I think the difference here is we're aligned at the 10,000 foot view, but the text may be leading us to different conclusions for implementations as @OR13 points out which means we may need to be more thorough in the updates we're making to the text here. If this means that we need to make normative statements then so be it, and so I think the best we can do is raise warnings in the text to call this out similar to what I did for the termsOfUse term.

I'm concerned about the idea of trying to overly lead people in a particular direction at this point while the group has a limited number of people participating because I don't want V1.1 changes to lead us in one direction and then revert course when we get to V2 work and more people start attending. If we can avoid that in your second option mentioned above @David-Chadwick I'd be alright doing option 2, but my preference would be to go with option 1 just because I think that's more likely to lead us to a robust long term outcome.

[David-Chadwick]

@kdenhartog. I agree that it is important that we all agree on the principles. My original wording about credential was quickly written, here is a more precise version for us to agree to.

• a credential that is produced from the validation routines of all the different flavours of VCs that were created from it (JWT with/without duplication, LD-Proofs of different types, ZKPs etc) after the proof has been validated and removed will all be identical.
• The process of converting a credential to a verifiable credential and back to a credential needs to be deterministic, lossless and repeatable (an infinite number of times), even if the verifiable credential is structured differently each time.
  Other principles that have been copied from @OR13's message:
• "Verifiable Credentials ALWAYS have an external or embedded proof"
• "jwt.payload.vc is not a verifiable credential". The complete JWT is the verifiable credential.
  Then one of my own
• jwt.payload.vc is not a credential. It is a component of a JWT verifiable credential. It is currently an un-named data structure in the VC recommendation. (It is an intermediate data structure formed during the process of creating a JWT verifiable credential from a credential and currently how this is formed and what it contains is ambiguously specified, which is leading to much of the discussions in this PR)

[David-Chadwick]

@TallTed . It all depends upon how you define the superclass credential. I would not include the hasProofProperty attribute. Rather I would say something like

credential
has attributes: id, type, @context, issuanceDate....

verifiable credential
subclass of credential
has attribute: proof

and then we dont need an unverifiableCredential class.

[edited by @TallTed to add appropriate codefences]

[David-Chadwick]

@TallTed

"Note. In" is not equivalent to "Note: In", even if you disagree with the <i> which sets the note apart. (I think there's some CSS magic <p class="note"> or similar that would be more appropriate, but I don't remember for sure what it is.) I would VERY much appreciate you not marking my comments or suggested changes as RESOLVED when they ABSOLUTELY ARE NOT!"

[Note: I have edited the above quote, codefencing the HTML tags here which were codefenced in my original but not in what I'm guessing @David-Chadwick copied-and-pasted. -- @TallTed]

Your changes are agreed to, which is why I marked it as resolved. I tried to commit your changes using my browser but every time I do this for your comments I get an error invalid email address. I dont know if this means your address is invalid or mine. But I have committed other people's changes OK, so is there something wrong with your email address?
Kind regards
David

[OR13]

This change should be accepted for the reasons I gave in https://github.com/w3c/vc-data-model/pull/828/files#r753698782

[OR13]

This change should be accepted for the reasons I gave in https://github.com/w3c/vc-data-model/pull/828/files#r753698782

[OR13]

@msporny please re-review this PR and suggest any concrete changes you require for it to be accepted.

[TallTed]

[@David-Chadwick] > "Note. In" is not equivalent to "Note: In", even if you disagree with the <i> which sets the note apart. (I think there's some CSS magic <p class="note"> or similar that would be more appropriate, but I don't remember for sure what it is.) I would VERY much appreciate you not marking my comments or suggested changes as RESOLVED when they ABSOLUTELY ARE NOT!"

[Note: I have edited the above quote, codefencing the HTML tags here which were codefenced in my original but not in what I'm guessing @David-Chadwick copied-and-pasted. -- @TallTed]

Your changes are agreed to, which is why I marked it as resolved.

Please understand: If you apply my suggestion manually, but you don't explicitly acknowledge my suggestion and note that you've applied it in commit xyz, I get no notice of your agreement nor of your manual application of my suggested change, which I do need, because it is then necessary for me to manually review that commit to confirm that my suggestion was applied as intended, and not misunderstood nor accidentally misapplied, both of which have happened in the past.

When/if you want to mark as "resolved" a future suggestion that you have applied or will be applying manually, please first make the change in your branch/fork/whatever, and second make a comment in reply to the suggestion with a link to the relevant commit such that we may review and confirm that the suggestion has been applied as intended, and third -- after the suggester comments to confirm that the commit accurately addressed the suggestion -- mark the suggestion, "resolved."

I tried to commit your changes using my browser but every time I do this for your comments I get an error invalid email address. I dont know if this means your address is invalid or mine. But I have committed other people's changes OK, so is there something wrong with your email address?

To the best of my knowledge, you are the only person who receives this email address error. I receive innumerable email notices from GitHub, so I'm pretty sure there's no issue with my email address. If you will provide the complete error message you're receiving, along with any context of that message, I will review them, and may then be able to determine what's actually wrong, such that you or I or whomever else is appropriate may correct it.

[TallTed]

and then we dont need an unverifiableCredential class.

Your descriptions don't eliminate the existence of the unverifiableCredential class; they only eliminate its explicit naming and description.

This would be more complete and more accurate --

credential
has attributes: id, type, @context, issuanceDate....

verifiableCredential
subclass of credential
has attribute: proof

unverifiableCredential
subclass of credential
does not have attribute: proof

First thing, verifiable credential and similar space-broken entities in your writings should generally not be space-broken; they should be joined in whatever way is appropriate to the language in use, which might be an underscore, or a hyphen, or camelCase, or PascalCase, or something else.

This does not say anything about the ability (nor inability) to convert an unverifiableCredential (which might perhaps be better named nonVerifiableCredential) to a verifiableCredential. It implies that the former might be made into the latter by the addition (and the latter might be made into the former by the removal) of a proof attribute.

[David-Chadwick]

@TallTed " If you will provide the complete error message you're receiving," I did copy you the exact error message I received. It was followed by "please try again" or similar, but this leads to exactly the same outcome. So then I have to revert to using my local copy and pushing a change up to GitHub, which is obviously more time consuming and error prone that trying to make the change using my browser.

[TallTed]

[@David-Chadwick] @TallTed " If you will provide the complete error message you're receiving," I did copy you the exact error message I received. It was followed by "please try again" or similar, but this leads to exactly the same outcome. So then I have to revert to using my local copy and pushing a change up to GitHub, which is obviously more time consuming and error prone that trying to make the change using my browser.

I am not trying to make your life more difficult nor drive you to more time consuming or error prone activities, though these seem to be side-effects of trying to patch what I see as bugs in your PRs. My request for the details of the error is intended to help enable you to use the faster and less error prone paths to applying my change requests/suggestions.

I have to revert to using my local copy and pushing a change up to GitHub

This local copy is why I need you to explicitly indicate your acceptance of a suggestion, and to provide a link to the commit, on GitHub -- because otherwise there is no indication of the acceptance of my suggestion, nor the commit which applies it, until you've pushed your changes up, which has typically been some while after you've marked my suggestion as "resolved".

I have doubts that the complete error message is contained within this --

[@David-Chadwick] I tried to commit your changes using my browser but every time I do this for your comments I get an error invalid email address. I dont know if this means your address is invalid or mine.

-- and certainly, this --

[@David-Chadwick] "please try again" or similar

-- is not "the complete error you received" -- which is made plain by the "or similar"!

Possibly you might need to review system and/or application logs, or look into your browser's developer views, to see the error which the browser is receiving which it might be reducing to "invalid email address". This might lead to reporting a bug against the browser, or against GitHub, or something else in the mix.

What browser are you using? Any chance you might try using another to take the same steps? (fwiw, I have been primarily using Chrome on macOS for some years without issue against GitHub. If you have not, I would suggest trying -- in no particular order -- Chrome, Safari, Firefox, Opera, and/or [if on Windows] Edge.)

[David-Chadwick]

@TallTed. @OR13 and myself have decided to write a JWT Implementation Guidelines that will include details of the transformations of all the credential properties to claims. Would you still like a new issue to be created?

[TallTed]

@David-Chadwick /cc @OR13 -- The suggested issue was to track making the referenced transformation functions explicit. If that effort is being tracked some other way, that's fine with me. I just didn't want @OR13's request to be lost.