Verifiable Claims WG - JWT Task Force -- 19 Nov 2018

<scribe> scribe: dmitriz

<manu> scribenick: dmitriz

stonematt: This is a taskforce type call with regards to JWTs and the VC data model
... can somebody give us the current state of the union of this work?
... and then we'll work through the various open issues and PRs
... I'll watch the time carefully, and reserve the last 15 mins for summary and next steps

<manu> PR for JWT addition is here - https://github.com/w3c/vc-data-model/pull/267

stonematt: unless there are other topics we want to put on the list, that's the agenda for today

<manu> Comparison is here: https://docs.google.com/spreadsheets/d/1WJ1pOH6zmZacuWgoAVfIHLI9Q1EPXbScY44w2gqv9vo/edit

<manu> +1 to going into the call like that

<manu> I'd like Oliver to do some background first before we begin

stonematt: ok, can somebody give the current State of Union?

State of JWTs in VCs

Oliver: ok, I can talk about that PR 267, to provide a data model for JWTs
... we have a couple of issues. the first one is - should we use JSON-LD, especially with regard to @context
... also, should we use ZKPs with the JWT data model
... and there is also some discussion around - should VC be at the top level, or should it go one level deeper (into the JWT claims: etc)
... the most important one, I think, is how to deal with ZKPs

<Zakim> manu, you wanted to discuss some high level requirements going in -- "looks and acts like a JWT", "doesn't break JSON-LD expression", "do not require JSON-LD processing", etc.

manu: I just want to talk about some requirements, going in, from the JWT perpective
... at a high level, this is what I'm reading between the lines as a requirement
... 1) whatever solution we come up with has to look like and act like a JWT. 2) We don't want to break JSON-LD processing, so there should be a clear separation of concerns
... I believe folks looking at JWT stuff would prefer to have zero JSON-LD processing, and could potentially hardcode against data structures provided
... the good news is that, based on what Oliver has put forward, there are straightforward ways we could achieve all of this
... so the call today is mostly to nail down the high level direction we're going with
... and lock in high-level decisions we need to make

dlongley: one of the requirements I'd like us to have is - whatever path we end up taking with JWTs,
... the verification needed for whatever we pull out of JWTs would be the same as verifications pulled out of any other encoding model

<Zakim> dmitriz, you wanted to talk about COSE and CWTs

<dlongley> dmitriz: I wanted to ask at the beginning of the call -- should we also discuss COSE and CWTs as a potential alternative to JWT?

<manu> +1 to talk about COSE / CWT / ZKP as (things we should consider)

<dlongley> dmitriz: The idea being -- that this was brought up on the mailing list previously, much of the security industry, especially the browser industry is moving away from JWTs and towards CWTs, and the authors of JWT specs are moving towards CWTs and they view it as the next iteration having learned from mistakes of JOSE days.

<dlongley> dmitriz: Should we "skate to where the puck is going"?

Oliver: I think it's not JWT over COSE or something like that
... the spec, how it reads now, is that we could have multiple representations, including JWT and CWT
... no reason not to support all

<Zakim> manu, you wanted to mention another high level requirement - COSE / CWT / ZKP

manu: I want to talk about two things, one is the high level reqs around this discussion, and the second one is about those other encodings like COSE etc
... so, there's two levels around VC architecture, a separation of concerns
... one is - how do you represent a cryptographic proof via the data model
... [er, wait] one is the VC data model itself, and two is - how do you wrap the crypto proof around it

<dlongley> layers!

manu: so, the VC data model is - who the credential is about, the various claims (ageOver, hasDriversLicense) and so on. and then, separately, is - how do we wrap signatures and proofs around that
... so, if we can accept that, that we have interoperable libraries for working with VCs, then we can wrap the data model in a variety of ways
... for example, JWTs, CWTs, ZKPs, LD-PRoofs
... so if we do the layering properly, we should be able to achieve all these cryptographic encodings, without all the arguments
... in my mind, it's pretty clear how we can achieve that, but there's the issue of coming to consensus about the details etc

<dlongley> +1 i think that's the goal

manu: so, to ask the question more specifically: is that the goal we want to strive towards?

pelle: that would be beneficial.
... but my question is - so what is the VC exactly? what's the part that should be inter-operable

Oliver: I agree with manu's idea of a layered approach
... I see it similar to what we have with the DID spec, where we have a common data model we can use

<dlongley> +1 it's exactly like the DID spec ... the details for DID methods are abstracted away from DID Documents.

Oliver: but that's not necessarily how it's implemented in each individual method
... so yes, I just want to make sure we know exactly which parts we're standardizing, as part of this data model

stonematt: is that maybe a fine-tuned discussion for the next 15 mins?
... how do we differentiate these two layers, the document itself, and then the crypto wrapper around it?

manu: are you asking, we could start getting into proposals to achieve those high level goals?

<Zakim> manu, you wanted to suggest something

stonematt: yeah, are we at a consensus enough that we can start solving the problem?

manu: hopefully, everybody has been able to read Oliver's PR

<manu> https://github.com/w3c/vc-data-model/pull/267

manu: Oliver, I'm trying to express what I think you're trying to achieve, hopefully
... so, there are potentially two paths we can take, with that proposal
... fundamentally, what you're trying to achieve is - an expression, at the high level, that looks like a JWT
... there's some other questions, do we include the @context at the high level, how do we map from JSON-LD claims to JWT-like things (iss:, aud:, so on)
... I think that's what you're trying to do, these mappings from the JSON-LD verifiable claim properties to JWT properties
... and that is certainly a technically feasible approach
... but I don't think there is a clear separation of layers there
... so it'll lead to a lot of spec thrashing betwen W3C and IETF layers
... instead, I propose we rip the JSON-LD part out, at the top level
... instead, I propose we introduce a new top-level JWT claim

<manu> { JWT_stuff ... verifiable_credential: { VC_DATA_MODEL_GOES_HERE } ... JWT_stuff }

manu: so, your JWT ends up looking like a JWT, but with one extra property
... so we preserve the separation of concerns, the mappings can be clean, etc
... that way we don't need to sync W3C and IETF registries
... and avoid spec mgmt delays and slowdowns

<manu> { JWT_stuff ... verifiable_presentation: { VC_DATA_MODEL_GOES_HERE } ... JWT_stuff }

manu: So, the VC presentation follows the same form
... (we also add 'verifiable_presentation' to the JWT registry as well)
... so there's no JSON-LD processing at the top level, we can stuff the existing claim right into a JWT
... and that's where the @context belongs as well (in the verifiable_credentials: property)
... we've been working with the JSON-LD processing group, on a way to have it so that you don't need any JSON-LD processing at all
... basically, how can we treat these linked data objects like plain JSON
... one of those techniques is something called "sealed contexts"
... the upshot is - if you format it a certain way, you don't need to do any processing or canonicalization
... so, it achieves clear layering - between a JWT and the VC layer
... gets rid of necessity to process JSON-LD, /and/ it does not break the actual json-ld underneath
... I'm hand-waving a tiny bit, there's a couple of other corner cases and concerns, but that's the overall idea
... so what I'm hoping that proposal does, is that it makes the extension to the JWT IANA registry very minimal,
... makes the final data model used by apps able to be used by shared data libraries
... removes the need for having a JSON-LD processor if you don't need one
... and the approach is translatable to CWTs, CL Signatures, and any other crypto wrapper formats
... does this make sense to folks?

oliver: the main concern that we have, that we want to leverage
... is that we can reuse the JWS part of JOSE
... for the presentation of creds, and for the issuance of credentials
... is that included in your proposal?

manu: yes, that doesn't change
... it looks and acts like a JWT in all respects

<manu> Analysis of features: https://docs.google.com/spreadsheets/d/1WJ1pOH6zmZacuWgoAVfIHLI9Q1EPXbScY44w2gqv9vo/edit

manu: if there is agreement on this, we can turn all of these yellow items up there, into green checkboxes, for the JWT part of it
... the big question is, is there an assertion that we /shouldn't/ use JSON-LD in the 'verifiable_credential:' portion
... if anybody asserts that we shouldn't use @context in there, we can have that discussion

stonematt: that sounds like an important point of agreement
... can you ask it again to make sure everybody hears it, and we have no objections?

manu: would anyone object to the use of the JSON-LD @context parameter, inside the verifiable_credential or verifiable_presentation property in the JWT?

oliver: I'm not opposed to it, but I think it might be difficult for JWT implementations
... which would need to recognize json-ld?

manu: no, they can be completely oblivious
... the only thing the library will need to do is ensure the ordering of the URLs in the @context: field. that's it
... so like, it'll be @context: [ <url to VC context>, <extension 1>, <extension 2> ]
... in that exact order
... if you don't want to do JSON-LD processing at all, you just check the order of the array, and continue using the data as a plain JSON object
... to be clear, this hinges on a feature of JSON-LD 1.1
... that's still pending with the JSON-LD WG, but at least we at Digital Bazaar are going to include that in all of our implementations
... so this feature builds a bridge between linked data and "plain JSON" community

oliver: another question - your proposal was to introduce these two attributes at the top level?
... what should go /into/ those structures? also sub: and jti: etc?

manu: no, all those things stay at the top level of the JWT
... what goes into those two claims is exactly what we have in the VC spec right now
... for example, the Issuance Date will be repeated, as iat: at the top level, and as issuanceDate: (?) inside the payload

oliver: ok, I see the need for interop at this layer

pelle: can we not deal with that particular issue in a slightly better way?
... I am worried about repeating data
... to me, that's one of the biggest problems
... and would lead to bugs, I fear.
... I'd rather we not repeat things from the top level
... there has to be some mapping there, to reduce duplication

markus_sabadello: I want to say something related,
... my question is, in the JSON-LD VC embedded inside the JWT, could that still also have a crypto proof (like a JSON-LD Signature), /in addition/ to the JWT signature?
... should that even be allowed?

<manu> dmitriz: Completely understand Pelle's concern - would like to see intersection of terms that could be duplicated... familiar w/ both - there are not going to be more than 1-2 fields.

<manu> dmitriz: The semantics are slightly different, one has to do with semantics of actual web token, other has to do with semantics of certificate - not really duplication, would love to see list of properties.

stonematt: quick time check, we're 4-5 mins away from recommending next steps

<Zakim> manu, you wanted to suggest DRY - mapping JWT fields to VC fields. and to note that proof could be at JWT and JSON-LD level and to note that there may be 4-5, but that's it.

manu: couple of things, to respond to pelle's concern around duplication
... we could get around it: to put in the spec that the processing rules that /after/ the lib is done processing JWT verification, is to move those mapped fields into the VC data
... so, the lib would move the iss: / iat: and so on, into the VC object after processing
... the downside is that it complicates processing a little bit

<pelle> That would address my concern. I think that would be fine

manu: to address markus's concern - could there be a duplication of proofs
... yes, there could be. but that's fine
... you could have the Proof of Work type proofs on the JSON-LD level, and some of the simpler digital signatures on the JWT level
... it could get hairy if there is duplication of signatures between those two layers

<dlongley> again, that would be the same approach taken with the DID spec (if fields aren't "native" in your DID Document on a ledger, but can be computed, you add them to the DID Document returned by a resolver)

manu: we can address that by saying "the issuer cannot create two signatures, they either do it at the JWT level or at the VC level, but not both"
... lastly, what Dmitri metnioned, it's probably not 1-2 duplicate fields, it'll probably more like 4-5

stonematt: I'm gonna freeze the queue for the moment, then next steps

oliver: can we solve the duplication issue by introducing another context?
... that describes (in case of JWTs) the claims?

manu: at the topmost level?

oliver: no, on the VC level

+1 to having a context potentially map between JWT and LD claims

manu: I have some thoughts on that

<dlongley> won't get the same simple interop if we add a different `@context` -- it's a big switch statement

<dlongley> in applications.

<dlongley> (in applications that don't do JSON-LD processing)

stonematt: ok, so let's spend a couple mins on agreeing on our phrasing of these proposals, and whether the PR linked above reflects it accurately
... what are the points of agreements, and what should we do to the PR to reflect it? (or make a new PR)

oliver: we still have disagreement with redundant fields, between the two layers?
... I think that still needs to be solved. We /do/ have agreement that we can use JWT signatures to prove ownership / presentation, to use them as a proof
... or still use the proofs in the proof: section of the VC to do ZKP proofs and so on

<Zakim> manu, you wanted to changes to current PR.

manu: at a high level, that PR is not quite what we just discussed
... I'm still unclear on where there's agreement/disagreement on the duplication issue
... I think most of the text of that PR can be pulled over
... trying to figure out if it would be better to do a counter-PR
... as something concrete, to take into account pelle's and oliver's feedbacks etc
... so I can try to do another PR, and see what people think?
... see if that raises any more objections
... alternatively, Oliver, if you feel like you understand the proposal, you can modify the PR to reflect that?

stonematt: I think it might be useful to try to state where we had points of agreement (cause we had several)
... along the lines of: @context belongs in the VC payload inside a JWT.
... there are new properties proposed at the JWT top level that represent claims and presentations
... and lastly, the VC processor can do some transformations/mappings to reduce duplication
... are those the right 3 points, and can we end up with a PR that reprsents that?

manu: oliver, if you want to take the lead on that, totally fine, if not, I know what to write

oliver: I would be fine with those points, the question is how to reduce duplication

manu: we can add a section that talks about post-processing rules. After processing of the JWT, the processor takes needed fields and puts them into the VC payload
... so, the VC itself will be missing the issuer, issued date, digital signature proofs (that could be made on the JWT level).

<dlongley> "missing" or it can be "overwritten" ... as the "signing process" might copy to a JWT and then sign.

manu: that way, no duplication

<markus_sabadello> +1 especially proofs shouldn't be duplicated on JWT and JSON-LD level

<dlongley> +1 to matt

stonematt: *summarizes, rephrases as pre-processor transformation and post-processor transformation*

oliver: I'm in favor of those post-processing rules, to prevent duplication. if we find the info at the JWT level, we should not expect it to also be at the VC level (it'll be mapped into there, instead)
... and that the proof should never be duplicated on both levels

<dlongley> btw ... LD-proofs uses JWS detached signatures (for those that didn't know)

<manu> Oliver: What I can do is to extend the PR by integrating all of the stuff that we talked about today.

<manu> dmitriz: I want to go back to "it would be great that if there was a JWS signature at the outer level, it shouldn't expect proof at VC layer".

<manu> dmitriz: If that's true, it ignores all of the more PoW and ZKPs that will have to be in the payload and not the JWT itself.

oliver: right, to avoid confusion.
... if you have the more complicated PoW proof inside the payload, you shouldn't then need the JWS sig

pelle: I hope this isn't controversial - could we maybe instead of having proof as a requirement of the VC data model, maybe have that be an implementation-level decision?
... so that the actual VC data model does not have the concept of a proof
... thereby simplifying the VC model

manu: I think we're waiting on a PR to make the proof optional. Going a further step and taking proof entirely /out/ of the data model would be problematic
... that said, if it's optional, the JWT stuff can just be standalone, without the proof on the VC level
... you can say, if the issuer is expressing the proof as a JWT, it MUST NOT express the proof inside the vC
... as an alternative, you can take a much more hardline stance and say "the vc MUST NOT have a 'proof' field in the VC". and that's much more drastic

<Zakim> manu, you wanted to note that proof is not a requirement (waiting on @nage for that PR)

stonematt: we're at the end of our time
... oliver, you can update the PR to reflect on the points of agreement
... that last point (about proofs in the VC) can be discussed in the next iteration

oliver: ok, I have the next steps

- DRAFT -

Verifiable Claims WG - JWT Task Force

19 Nov 2018

Attendees

Contents

State of JWTs in VCs

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output