OB 3.0: Select required and recommended proof methods

[amiller-ims]

OB 2.0 and CLR 1.0 use Signed and Hosted Verification. OB 3.0 and CLR 2.0 will drop Signed and Hosted Verification, and replace it with proof methods as defined in the VC Data Model (and other places).

Hopefully this issue can be used to hold a conversation about proof methods that will inform the certification requirements and implementation guides for both OB 3.0 and CLR 1.0.

[amiller-ims]

Found this tracking issue in vc-data-model:

w3c/vc-data-model#863

We loosened the restrictions so that BBS+ would be an option w/o violating the specification (and we couldn't say much more without jumping the shark on our VCWG 1.0 or VCWG 1.1 Maintenance Charter). I think the VCWG 2.0 work is designed to finally get us to more concrete language, as long as the IETF CFRG work happens on a timeline that's aligned with the VCWG 2.0 charter lifetime.

I also saw these references to BBS+ in the SRI International review:

Note, these recommendations will not affect if a government client uses BBS+ signatures. They cannot unless NIST standardizes BBS+.

and

BBS+ signatures are not standardized by NIST and are unlikely to be standardized by NIST since they rely on elliptic curves with bilinear pairings.

I don't know how the IETF and NIST are related. Does one act before the other?

But it feels like BBS+ (and possibly other ZKP) are not ready to be required in an IMS specification.

[amiller-ims]

Linked Data Cryptographic Suite Registry, December 2020

[amiller-ims]

One of the things Hosted verification does is refresh the credential. In the vc-data-model, that falls to the refresh service. Here is a discussion about the refresh service that brings up valid concerns to be considered if/when we define how the refresh service works for OB 3.0/CLR 2.0.

[amiller-ims]

@justinpitcher @danblickensderfer @roverwolf - Please correct any mistakes and tag Dmitri and Phil if you have their GitHub handles

Notes from 2/3/22 meeting with invited expert Dmitri Zagidulin

• Other implementations of VC use JWT, LD-Proof, or both (no best practice)
• The VC Data Model v1.1 for proofs is flexible in that switching to new proof methods in the future should not be a breaking change
• Both JWT and LD-Proof can use the same signature schemes
• DZ recommends sticking to the 3 schemes recommended by SRI International: RSA, ECDSA, and EdDSA
• DZ noted that IMS and IMS members that implement OB 2.0 and CLR 1.0 should not write their own implementation of a signature scheme
• DZ noted that there are libraries available that implement all 3 schemes
  • Implementers who's main coding language does not have a library are creating microservices in a coding language that does have a library
• JSON Web Token (JWT) proofs may be more easily implemented for folks migrating from OB 2.0 and CLR 1.0, but have two draw-backs:
  • Signed credentials are approximately 30% larger than the source JSON
  • VC Data Model 1.1 does not explain how to serialize a signed VC that contains other signed VCs (i.e. a CLR). Note this was solved in CLR 1.0 by adding a property to the Clr class called signedAssertions. But since this is not described in VC Data Model 1.1, it's a safe bet that no existing VC services would know what to do with this.
• DZ recommends allowing more than 1 proof ("proof": [proof1, proof2]) for two use cases:
  • If someone invents a quantum computer and everyone decides to switch to a new signature scheme, existing VCs can be reissued with the new signature tacked on allowing verifiers to use the old scheme until they are ready to use the new scheme
  • Similarly, if multiple proofs are attached, a wider variety of verifiers will be able to verify the credential
• We did not talk about proof methods that use blockchain.

Ref: Cryptography Review of W3C Verifiable Credentials Data Model (VCDM) and Decentralized Identifiers (DIDs) Standards and
Cryptography Implementation Recommendations, Nick Genise and David Balenson, SRI International, October 15, 2021

[longpd]

@justinpitcher @danblickensderfer @roverwolf - Please correct any mistakes and tag Dmitri and Phil if you have their GitHub handles
My GitHub handle is @longpd

Notes from 2/3/22 meeting with invited expert Dmitri Zagidulin

* Other implementations of VC use JWT, LD-Proof, or both (no best practice)

* The VC Data Model v1.1 for proofs is flexible in that switching to new proof methods in the future should not be a breaking change

* Both JWT and LD-Proof can use the same signature schemes

* DZ recommends sticking to the 3 schemes recommended by [SRI International](https://docs.google.com/document/d/1EdCBSACtlBv2DxNZM67qi9F15Iv5uWOW/edit#): RSA, ECDSA, and EdDSA

The Edwards curve scheme is not currently a NIST recommendation, but it is among the Recommendations for Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters, Draft NIST Special Publication 800-186, and is expected to be accepted by NIST in the near future when used with the EdDSA165 digital signature scheme in FIPS 186-5

* DZ noted that IMS and IMS members that implement OB 2.0 and CLR 1.0 should not write their own implementation of a signature scheme

* DZ noted that there are libraries available that implement all 3 schemes
  
 * Implementers who's main coding language does not have a library are creating microservices in a coding language that does have a library

* JSON Web Token (JWT) proofs may be more easily implemented for folks migrating from OB 2.0 and CLR 1.0, but have two draw-backs:
  
  * Signed credentials are approximately 30% larger than the source JSON

Note: this is a linear increase per signature. Therefore, with a CLR where the intention is for individual assertions are signed as VCs, the size increase of the overall CLR can be considerable.
* JWS signatures do now support the concept of proof chains
* JWS approach has an issue with not specifying where the JWS should be placed

  * VC Data Model 1.1 does not explain how to serialize a signed VC that contains other signed VCs (i.e. a CLR). Note this was solved in CLR 1.0 by adding a property to the Clr class called `signedAssertions`. But since this is not described in VC Data Model 1.1, it's a safe bet that no existing VC services would know what to do with this.

* DZ recommends allowing more than 1 proof (`"proof": [proof1, proof2]`) for two use cases:
  
  * If someone invents a quantum computer and everyone decides to switch to a new signature scheme, existing VCs can be reissued with the new signature tacked on allowing verifiers to use the old scheme until they are ready to use the new scheme

  * Similarly, if multiple proofs are attached, a wider variety of verifiers will be able to verify the credential

Multi-sig use cases might be expected for jointly issued credentials, e.g., in a course accepted from another university as credit toward the second university's degree program might be signed by the original issuer and the institution including this course toward the awarded terminal degree.
There are various other real-world possibilities, including the supporting the function of a notary public, which might offer third-party review of an issued credential where the original issuer may be unfamiliar and a professional association or accreditation entity might examine an issued credential based and assess its compliance with US-based standards.

* We did not talk about proof methods that use blockchain.

Ref: Cryptography Review of W3C Verifiable Credentials Data Model (VCDM) and Decentralized Identifiers (DIDs) Standards and Cryptography Implementation Recommendations, Nick Genise and David Balenson, SRI International, October 15, 2021

[amiller-ims]

During the call I said there was some disagreement whether nested signatures with JWT was possible. It turns out it is documented and there is an example. The example is of a VP, but the process can be applied to a VC like CLR. And there is a thread in the [email protected] discussing future work to reduce the size of JWTs of large credentials.

Those of you that are familiar with a signed CLR 1.0 will immediately recognize the decoded example.

[amiller-ims]

I propose that the project group recommend these 3 proof methods. And I propose the project group select 1 for certification testing.

Linked Data Proofs

• JSON Web Signature 2020 - This suite supports cryptographic agility (i.e. you can use several different algorithms). I proposed recommending PS256 (or requiring PS256 if this suite is chosen for conformance testing).
• Ed25519 Signature 2020

JWT Proof

• RSA-SHA256 (RS256) - This is the same signature method used for Signed Verification in OB 2.0

[martyr280]

We should also consider CBOR given it's proliferation in the EU https://test.webpki.org/csf-lab/home Given the current conversations in VC-API I am concerned they will not support JWT but I have not been following the VC workgroup close enough to speak authoritatively. I put this forward with the caveat we are using JWTs and embedded JWTs in a current implementation.

[amiller-ims]

It looks like CBOR Signature Format (CSF) is an alternative to JWT. Is that because CSF results in smaller payloads than JWT?

CSF is not mentioned in VC1.1. That's not a reason to exclude it from consideration, but it does change the conversation.

[amiller-ims]

@martyr280 Is there a blockchain Linked Data Proof method we should consider?

[martyr280]

TBD on payload size, but that would be the intent.

[martyr280]

There's also active discussion on JWS encryption compression https://www.iana.org/assignments/jose/jose.xhtml#web-encryption-compression-algorithms not sure if it's necessary to be a part of it but I think should be a consideration in an implementation guide.

[longpd]

Marty: CBOR is extremely efficient at compressing binary data. We should find out how/if CBOR can be leveraged in the context of VC-API. The question that Andy has asked us is to consider 3 proof methods, select 1 for certification testing. Which JWT are you using, JSON Web Signature 2020 or JWT Proof - RSA-SHA256 (RS256)?

…

On Feb 10, 2022, at 5:08 PM, Marty Reed ***@***.***> wrote: We should also consider CBOR given it's proliferation in the EU https://test.webpki.org/csf-lab/home <https://test.webpki.org/csf-lab/home> Given the current conversations in VC-API I am concerned they will not support JWT but I have not been following the VC workgroup close enough to speak authoritatively. I put this forward with the caveat we are using JWTs and embedded JWTs in a current implementation. — Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYBFE3WXFDXVSNMDC6V6LU2QZMHANCNFSM5NG44W6Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.

[martyr280]

we're using JWT RS512

[amiller-ims]

CBOR-LD does a great job of compressing JSON-LD for storing in a database or as an API payload.

But I don't think there is an external proof format (e.g. VC-JWT is an external proof format) that uses CBOR instead of JSON. There is a CBOR Web Token, but I could not find a spec or standards track effort to normatively define a CBOR Web Token Proof method.

We could define one, but there is little evidence others will use it.

Please let me know if you find evidence that CBOR Web Token Proof is being worked on.

[amiller-ims]

Leaving this here so I don't lose track of it: https://medium.com/transmute-techtalk/linked-data-proofs-vs-jose-why-not-both-1594393418cc

[amiller-ims]

As of today, vc-wg-charter is aiming to create test suites for 3 proof types: Data Integrity Ed25519, Data Integrity BBS+, and JSON Web Token (an external proof type).

The charter language used to talk about normatively defining concrete serializations. I'm not sure if creating test suites implies normative language or not.

[amiller-ims]

Closing. Only VC-JWT is normative. See #365 for next step.

[dmitrizagidulin]

@amiller-ims - Can you say a little more? Why was 'Only VC-JWT is normative' decided?

[amiller-ims]

@dmitrizagidulin - Only VC-JWT is concretely defined normatively in VC Data Model 1.1. Other Linked Data Proofs are defined in proposed recommendations (on a standards track, but not yet an approved standard) or community group reports (not on a standards track). The OB 3.0 spec can refer to those as informative documents (e.g. in an implementation guide). But IMS standards policy prevents us from requiring (using normative language) their content. Mostly to avoid churn.

There are two options at least:

• OB 3.0 and CLR 2.0 could define other proofs concretely and normatively (e.g. define a ImsSignatureSuite based off of a proposed recommendation or community group report), but that seems like a lot of work and may push us well past our charter timeframe.
• OB 3.0 and CLR 2.0 could probably (we've never done this) "lock" in a reference to a very specific version of the proposed recommendation or community group report. For example, "Ed25519 Signature 2020, 26 July 2021". But I personally worry the maintainers may not maintain "old" versions of these documents over the lifespan of OB 3.0 and CLR 2.0.

I'd welcome other ideas.

[amiller-ims]

BTW, it is important that the OB 3.0 and CLR 2.0 specs not prevent the use of other proofs so that implementers can experiment.

The next major release of OB 3.0 and CLR 2.0 will likely be 12 to 18 months after they are released. That will put them right in line with VC 2.0 which will normatively define additional proofs.

[msporny]

For example, "Ed25519 Signature 2020, 26 July 2021".

FWIW, this signature suite is being rolled into a US-wide production deployment in retail as we speak -- 152K+ locations, 50M people per day... so it's highly likely that we'll have no choice but to define it normatively (somewhere) and support it long term. Going w/ VC-JWT limits you in a variety of ways:

1. VC-JWTs are badly defined in the VCDM spec, and we're finding lots of interop issues w/ it in the current environment, so much so that it's an area of focus in the VC 2.0 WG
2. VC-JWTs have no clear path to digitally signed QR Code display (important for offline/disconnected in-person presentation)
3. VC-JWTs do not support selective disclosure, a new data format is required for that (VC-JWPs); selective disclosure for Data Integrity (was: Linked Data Signatures) has been demonstrated for years and will be standardized (most likely well before VC-JWPs are).

[kayaelle]

It's also worth noting that VC wallets in the education space are favoring Ed25519 Signature 2020 so Open Badge issuing platforms that wish to integrate with VC wallets will likely be adopting this too.

[amiller-ims]

so it's highly likely that we'll have no choice but to define it normatively (somewhere) and support it long term.

That's awesome! I'll keep a close watch on that, but please let IMS know when that happens.

[msporny]

That's awesome! I'll keep a close watch on that, but please let IMS know when that happens.

The implementation and binary format is locked down (and has been for over a year):

https://github.com/digitalbazaar/ed25519-signature-2020

The spec does exist here, but is horribly out of date: https://w3c-ccg.github.io/lds-ed25519-2020/

That spec is an input document to the VC2WG, which is expected to begin work over the summer and we expect a conformance test suite to exist by late summer (remember, this work has been going on for over 8+ years, so we already have lots of incubation and implementation feedback done).

We can let you know when the spec hits Candidate Recommendation, which would be at least one signal that you can probably lock yourself into the spec at that point.

[justinpitcher]

Reopening based on conversation.

[martyr280]

I propose reference to either an existing proof registry https://w3c-ccg.github.io/vc-extension-registry/ or given IMS Global policy create an IMS Proof Registry. This then solves for the ever evolving signature space.

[msporny]

I propose reference to either an existing proof registry https://w3c-ccg.github.io/vc-extension-registry/

As one of the maintainers of the above registry -- I'm sad to say that it's out of date. Everyone is waiting for a bit of a registry reshuffle w/ the upcoming VC2WG wrt. cryptosuites and registries. This should give you an idea of where the work is headed in the next couple of months:

See the "Securing Verifiable Credentials (SVC) 1.0" section for a list of cryptosuites that are in scope:

https://w3c.github.io/vc-wg-charter/#deliverables

Those will end up in a VC2WG registry.

or given IMS Global policy create an IMS Proof Registry. This then solves for the ever evolving signature space.

Note that the VC2WG is planning to maintain registries related to the cryptosuites, see the "Registries" deliverable here:

https://w3c.github.io/vc-wg-charter/#deliverables

If it would help, I could make a pass at updating the vc-extension-registry with the currently known cryptosuites... but those are likely to change location in the next couple of months.

[martyr280]

@msporny that would be helpful to move our discussion along, @amiller-ims how does this hit you?

[ottonomy]

As an issuer platform, we would like to use the Ed25519 suite to sign credentials, as we find some wallets we want to integrate with are supporting this proof method.

In terms of writing the spec, we're aware that there are several proof methods at various stages of maturity and adoption. But we'll actually need to decide:

• In order to be a certified issuer, what are the options for proof formats that you MUST be able to support in order to produce a credential as part of the certification process? Are there others that you MAY support?
• In order to be a certified host or verifier (however these roles shake out that consume credentials), what are the required proof formats that you MUST support as part of the certification process?

It may make sense to allow JWT as an option; I would like to see Ed25519 as an option, and there may be other proof methods that other members might suggest. It is good to keep the list tight in terms of what options we make required, to keep implementation costs low, but we should determine from the implementing members what proof methods they need to support for their use cases, hope for some decent alignment, and have a lightweight enough mechanism to be able to add more to the list without a huge heavy list in the future.

[amiller-ims]

Just finished an internal discussion and I am pleased to say we will include Ed25519 linked data proof in the spec and will reference either https://github.com/digitalbazaar/ed25519-signature-2020 or https://w3c-ccg.github.io/lds-ed25519-2020/ (whichever is more likely to appear in https://w3c-ccg.github.io/vc-extension-registry/) as a normative reference.

The feedback you all provided really helped me make the case and IMS is strongly in favor of helping this move forward. Thank you!

[martyr280]

recommend referencing https://w3c-ccg.github.io/vc-extension-registry/ as this is pending PR to update to the latest ed25519-2020 spec

[longpd]

I concur with the pointer to W3C’s vc-extension registry. I think it helpful to reference a group that has multiple and diverse stakeholders seeking to use crypto suites that include business, gov, and education issuers. And +1 for the choice of the Ed25519 suite as one of the required linked data crypto options. Cheers, Phil Phillip Long, Ph.D.,Open Software Fellow Concentric Sky e: ***@***.*** ***@***.***> https://concentricsky.com/ <https://concentricsky.com/> —

…

On Mar 30, 2022, at 10:59 AM, Marty Reed ***@***.*** ***@***.***>> wrote: recommend referencing https://w3c-ccg.github.io/vc-extension-registry/ <https://w3c-ccg.github.io/vc-extension-registry/> as this is pending PR to update to the latest ed25519-2020 spec — Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYBFBUONWBBWTDALG4G7DVCRT67ANCNFSM5NG44W6Q>. You are receiving this because you were mentioned.