JWS vs JSON-LD

[cjbuchanan]

I keep hearing external complaints about the use of JWS vice JSON-LD. Hoping to start a discussion here regarding this interop issue.

[msporny]

There is a lot already documented here:

https://www.w3.org/TR/vc-imp-guide/#proof-formats

In the end, the Verifiable Credentials Working Group couldn't agree to be a single signature format and instead decided to be signature format agnostic, note that there were at least 2 choices, and allow the specification of more signature formats in the future. While the VC Data Model is agnostic to the signature format, it becomes necessary to understand which signature format(s) are expected to be used in a particular ecosystem.

[jmandel]

Hey Manu -- thanks for chiming in here!

it becomes necessary to understand which signature format(s) are expected to be used in a particular ecosystem

100%.

Chris, the quick story is that SMART Health Cards is using JWTs -- specifically JWS to represent signed and optionally JWE to represent encrypted credentials. There's a lot of history and some trade-offs here, but one quick point is that JWT compact serialization has a relatively low implementation overhead and is supported in a vast array of software libraries (see https://jwt.io/ for an example) which is a big help with rapid adoption.

The key here was to "pick something", and I wanted to pick simplest tool for the job. I know this could be the subject of debate, but I hope it won't be in this context (because I'm confident JWT will work, and I think "satisficing" is the right modus operandi if we're going to move this effort forward and deliver on the promise of consumer access and empowerment).

I should note that this discussion has been about JWS vs JSON-LD at the level of signatures; there's a similar discussion to be had about "Vanilla FHIR JSON" vs "FHIR JSON-LD" at clinical and identity data layer. There too, we've opted for the familiar and widely supported "vanilla" option, capturing claims in a fhirBundle that any FHIR parser can process.

[msporny]

I know this could be the subject of debate, but I hope it won't be in this context

Unfortunately, it will be, it always is... and it always starts out like this. :)

To put this in perspective, all of the successful live fire interop testing being done by DHS for government use cases (which has multiple funded organizations building real products for government customers) do not use JWTs, but rather Linked Data Signatures. The new privacy-preserving stuff (BBS+ Signatures) does not use JWTs because of limitations in JWTs. The JWT part of the VC spec is underspecified and problematic. In other words, while it is true that JWT has more library support... It's not the signature format that is being deployed in a variety of active and funded VC programs.

... and I'm sure that the second I hit the comment button, the Internet will be notified, and people will rush in to provide pro-JWT and pro-LD perspectives... and the cycle will start all over again, like it always does. :)

Best to focus on the core data model and punt the "how will it be signed" question down the road... let the market decide... no amount of debate has resulted in everyone being convinced one way or another.

[cjbuchanan]

I'm glad that JWS is in spec and that it is easy to adopt. However, the issue I was concerned about was interoperability with other portions of the VC ecosystem. I've not run across that method with respect to VCs before and I thought the W3C spec was (at least originally) pushing toward the JSON-LD format which was why most implementations selected it. However, there is inference there on my part and I hoped to learn something from the discussion. So far so good.

[msporny]

I'm glad that JWS is in spec and that it is easy to adopt.

I'd say it's easy to write an implementation that you have no idea if it conforms to the other implementations in the ecosystem. No one has really taken on the task of ensuring that all the JWT VCs work -- there's no exhaustive test suite for JWT-based VCs. To put that in context, there are interoperability tests suites that do test Linked Data Signature-based VCs... the latest being the VC HTTP API work.

the issue I was concerned about was interoperability with other portions of the VC ecosystem.

Yes, that's largely the problem -- JWT by itself is fine, but when it comes to VC libraries, JWT has very little ecosystem support.

I've not run across that method with respect to VCs before and I thought the W3C spec was (at least originally) pushing toward the JSON-LD format which was why most implementations selected it.

Yeah, there were politics at play here (like there is in any standards-setting process... I'm sure the VCI stuff has a healthy dose of politics, or will in time). :)

VCs require the use of the @context property, making all VCs valid JSON-LD documents, which is what give VCs global semantics and interoperability without having to hard code those global semantics. There were people in the group that really didn't like JSON-LD at all "It's too complicated, we don't need that complexity!" and so wanted us to state that they didn't have to use JSON-LD if they didn't want to, which is why the specification has language like:

Verifiable credentials and verifiable presentations MUST include a @context property.

... and then strangely follows up with language like:

Though this specification requires that a @context property be present, it is not required that the value of the @context property be processed using JSON-LD. This is to support processing using plain JSON libraries, such as those that might be used when the verifiable credential is encoded as a JWT. All libraries or processors MUST ensure that the order of the values in the @context property is what is expected for the specific application. Libraries or processors that support JSON-LD can process the @context property using full JSON-LD processing as expected.

That language allowed the JSON-only folks to avoid the use of JSON-LD processing in their VCs and hard-code their deployments against only the specific VCs they cared about. That's standards compromise for you... that group also insisted on JWTs for the reasons @jmandel outlines above ("JWTs have great library support!" (which is true... but avoids the fact that there are use cases that you can't accomplish via JWTs -- like cross-syntax digital signatures, CBOR-LD style compression so you can fit VCs in a compact <400 byte QRCode, support digital proof mechanisms like DLT anchoring and selective disclosure, etc.)... btw, some of those are all requirements that I expect the health card initiative to have.

All that said, everything is not all unicorns and rainbows with Linked Data Signatures -- they're not a global standard yet. Due to politics (again), the work to standardize Linked Data Signatures has met strong resistance from the JWT camp in the global standards setting organizations "Why do we need to reinvent the wheel!? We already have JWTs! We've made a huge investment in JWTs! Look at the library support!". To overcome that, the Linked Data Signatures folks have had to do a lot of (necessary) work around formalizing the mathematical proofs backing the canonicalization algorithms, getting field experience, etc... and that takes time, and meanwhile VCs are taking off faster than we had planned for so we're scrambling to get the global standards around Linked Data Security done. This is largely a formality at this point as the underlying technology has been stable for 5+ years. We expect the official Linked Data Security global standardization work to start and the W3C Chartering process to begin in Q2 2021. This also means that library support is trailing JWTs (because the technology is newer, it takes time for folks to build libraries).

If you were to look at VC libraries, though... the vast majority of them use Linked Data Signatures... and there is even a Linked Data Signatures cryptosuite that uses JWTs as the signing mechanism. So, if you want to use VCs and you want to move fast, Linked Data Signatures is probably your best bet.

... and as I said above -- this is my opinion, there are people that have very strong opinions about using JWTs and not JSON-LD or Linked Data Signatures, and I fully expect there to be disagreement on this point... which is why I said -- get the data model right for the health card stuff, people tend to do a good job of getting the basics right... squabbling over the signature mechanism is something the market will take care of in time. I realize the desire to move this stuff forward quickly due to the pandemic, and I expect funding agencies to bring the hammer down on this decision if it slows down the roll out.

[OR13]

https://github.com/w3c-ccg/lds-jws2020

I personally prefer Linked Data Proofs over VC-JWT, but we've built out support for both...

https://github.com/transmute-industries/vc.js/tree/master/packages/vc.js/src/vc-jwt https://github.com/transmute-industries/vc.js/tree/master/packages/vc.js/src/vc-ld

[OR13]

https://github.com/OR13/did-params-and-you/blob/master/__tests__/case-5-relative.jwk.test.js

This example is probably more reflective of ION did documents.

[DrHouston]

I would like to chime in here... I am not a developer but I am developing a solution. I am wondering what is being done to ensure that all VC's are compatable with ANY LEDGER. That humans who want to hold and control the information about themselves are able to do that and present it in a way that is readable and usable across sytems...

For example --- Aries framework is compatable with the Hyperledger Ursa correct? --> what is being done to ensure it is also compatable with Etherium? Bitcoin? Other permissioned blockchains who CHOOSSE to use the standards in development....? @msporny what is veres/digital baazar using, and how is it making this compatable? @OR13 - what about transmute, same question?

As a non technical founder who wants to be able to use this stuff for real world applications I really am having a hard time wrapping my head around this... are you all JSON-LD based? What's the deal with the JWT Stuff... (specifically this project: https://vaccinationcredential.org/ - https://github.com/smart-on-fhir/health-cards) is it compatable? As a physician and patient advocate I'd like to understand. It's also important for the public to understand.

How can any of these projects be self sovereign if there is no interoperability between projects...? Importantly regarding the 21st Century Cures act put out by HHS/ONC they are FORCING interoperability in healthcare... so this is critically important to get right- especially now... especially on the above project.

Re SSI and the VC specs...we cant build appliances (VC's and DID's) that only go into the plug outlets that we have to come install in your home (protocols that don't speak to eachother)...it's not practical... I'd like to understand so I can move forward... this is the question that has left me in gridlock for the past few months... would love some perspective...

[Identitywoman]

I feel the pain that Leah is expressing. There are several VCI options I wrote a paper about this - which is still in draft form but nearing completion. (feedback from folks is welcome)

It is worth clarifying for you Leah that picking the flavor of a Verifiable Credential - doesn't affect what ledger you might choose to anchor the DIDs for Issuers in.

There is another issue that is present that isn't named in Leah's comment but is sitting there in the confusion. The current proposed structure for VCI's implementation anchors the actual credential that is issued to an individual person to long form ION DIDs (Merkle tree rooted into bitcoin) so that any time the individual shares their credential - the DID is seen by the verifier and thus creates linkable set of presentations that if verifier collude the places a person shares their credential can be connected together. The ZKP choices provide ways to issue credentials to people and not leverage persistent linkable identifiers as their base. Maybe it makes sense to open another "issue" about this correlatability with ION did anchoring for credentials - but I thought it should be named in response to what Leah was saying.

[jmandel]

To be clear, the SMART Health Cards data model intentionally includes direct demographics-based identifiers intended to support correlation -- e.g., name, birth date, and phone number. This is to support matching the identity attributes in a Health Card with information known about the individual by a verifier. (There's a distinct issue #45 related to public visibility of long-form DIDs. As noted in that issue, there is no expectation that long-form DIDs will be anchored to any ledger; it's an option down the line, but not something the Health Cards specification requires or even supports today.)

[jmandel]

@DrHouston -- really appreciate your message here. As a fellow physician and technologist working to improve consumer access to healthcare data, I feel your pain! Our aim with the SMART Health Cards specification is to build a bridge between the ecosystem as it exists today (where ONC's certification rules are ensuring consistent adoption of the SMART on FHIR specification for all certified EHRs), and the ecosystem we want to see in the future (where consumers can not only access their data, but manage and re-share downstream when they explicitly choose, and without friction). We're taking deliberate, pragmatic steps to get there.

[DrHouston]

To be clear, the SMART Health Cards data model intentionally includes direct demographics-based identifiers intended to support correlation -- e.g., name, birth date, and phone number. This is to support matching the identity attributes in a Health Card with information known about the individual by a verifier. (There's a distinct issue #45 related to public visibility of long-form DIDs. As noted in that issue, there is no expectation that long-form DIDs will be anchored to any ledger; it's an option down the line, but not something the Health Cards specification requires or even supports today.)

Interesting - so phone number is the unique identifier along with name and DOB that will help to organize the data... I actually like this idea, but there are some people who constantly change that number... what are we doing for these people? are we creating a custody tracking chain link mechanism to ensure new numbers are anchored to old numbers? (same question for people who are using email and changing email)

And that paper is super helpful @Identitywoman - agree- maybe start a new thread... I have never done this, so don't want to muddy someone elses waters, but do want to have this convo and make this understandable for laypeple like me:) don't know how to do that, so please invite me when it is open and titled if you can...

@jmandel thanks for chiming in here. I am super interested in what you are doing - perhaps we can connect after I have had a chance to review and digest everything (taking longer than expected, but learning a lot.) Honestly the whole concept of "certified EHR's" annoys me.... physiciains used to have paper charts in their private offices... now they are forced to use only "certified" versions of doccumenting the PRIVATE conversations they are having with their patients... those "certified" systems are now sharing the patients PHI without the patient or physicians hard consent... this is not serving doctors or patients IMO, and it is a main reason healthcare is becoming increasingly complex and unecessarily expensive - this is the basis of my desire to become competent in this topic- it's now part of my hippocratic oath.

[jmandel]

Thanks! I am going to close this issue because it's drifting far from the original topic (and on that point: we're deferring new signature formats as an issue for future scope, since we need to stay focused to be successful with v1).

Please don't hesitate to open other issues -- or for more free-form discussion topics I'd recommend https://github.com/smart-on-fhir/health-cards/discussions.

[arztnh]

But remember that changing phone numbers or email is not the only issue here. We know from current COVID appointment scheduling apps that lots of people use the same phone number and associate it with multiple records, whether is my doing it for my wife, my aging parent, or my child, when I want the contact/follow-up to go to me and not them. So we need to be careful to NOT allow cell number and/or e-mail to be required as a UNIQUE key in any system like this. I have seen that already in some COVID scheduling apps.

[msporny]

(and on that point: we're deferring new signature formats as an issue for future scope, since we need to stay focused to be successful with v1).

hold up... what signature format was selected for v1... and who decided that?

[jmandel]

Given that we're building the connection + presentation flows on DID-SIOP, we already have a dependency on compact-form JWS signatures for our id_token values (Verifiable Presentations); the approach here is to re-use these choices when signing the claims within these presentations (the Health Card VCs themselves). https://smarthealth.cards documents these details including signature algorithms.

That said, let me emphasize:

• We're looking to VCI participants to share feedback based on their implementation work; we have at least four independent implementations at this point, and have not run into functional limitations
• If there are functional challenges, let's address in focused follow-up issues (this one has meandered)

[jpp9]

just want to add for folks here that VCI decided to adopt and promote SMART Health Cards Framework as the initial members believe that the framework offers the best chance at adoption in the US healthcare ecosystem with the speed and breadth necessary to address the pandemic.

[radamson]

To build on what Josh/JP have mentioned, the spec details have been discussed at previous FHIR meetings well before VCI brought together this broader coalition (I remember Josh hosted a session back in August). We want to encourage implementations to continue pressing forward and making progress, based on the current version, and make improvements based on those experiences.

[msporny]

Given that we're building the connection + presentation flows on DID-SIOP, we already have a dependency on compact-form JWS signatures for our id_token values (Verifiable Presentations); the approach here is to re-use these choices when signing the claims within these presentations (the Health Card VCs themselves). https://smarthealth.cards documents these details including signature algorithms.

These choices put the VCI initiative in an awkward position -- you're picking a set of technologies (essentially the Microsoft stack) that are non-interoperably different from what 8+ companies in the US DHS work have implemented (with a real test suite) to get to interop.

It's sounds like it's too late to provide guidance and VCI has picked a technology winner that's going to put it in a very awkward position when this stuff goes out into the market. I hope no one will be surprised when the solution doesn't integrate cleanly with many of the other vendors that have a multi-year lead on this particular project.

Apologies for being blunt; I'd rather provide feedback quickly and not waste anyone's time.

[jmandel]

Appreciate the feedback, and blunt is good. I do want to make sure I understand specifically what suggestions you're making; is this feedback specifically about VC signature formats or are you referring to a broader set of architectural choices (issuance protocols, presentation protocols, DID methods, etc)?

[msporny]

I'm referring to a broader set of architectural choices (issuance protocols, presentation protocols, DID methods, etc):

I've created a new issue to document the architectural choices: https://github.com/smart-on-fhir/health-cards/issues/59