Base context v1 missing sec: mapping in RsaSignature2018 "@context"

[kuzdogan]

I've been looking into the base context and a minor PossibleErratum caught my attention. In the "@context" of RsaSignature2018 property the shorthand sec: is used several times, but the definition is not given, as in other properties.

RsaSignature2018:

"RsaSignature2018": {
      "@id": "https://w3id.org/security#RsaSignature2018",
      "@context": {
        "@version": 1.1,
        "@protected": true,

        "challenge": "sec:challenge",
        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
-->     "domain": "sec:domain",
        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
-->     "jws": "sec:jws",
        "nonce": "sec:nonce",
        "proofPurpose": {
          "@id": "sec:proofPurpose",
          "@type": "@vocab",
          "@context": {
            "@version": 1.1,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "sec": "https://w3id.org/security#",

            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
          }
        },
-->     "proofValue": "sec:proofValue",
        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
      }
    }

whereas in EcdsaSecp256r1Signature2019 for example

    "EcdsaSecp256r1Signature2019": {
      "@id": "https://w3id.org/security#EcdsaSecp256r1Signature2019",
      "@context": {
        "@version": 1.1,
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "sec": "https://w3id.org/security#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",

        "challenge": "sec:challenge",
        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
        "domain": "sec:domain",
        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
        "jws": "sec:jws",
        "nonce": "sec:nonce",
        "proofPurpose": {
          "@id": "sec:proofPurpose",
          "@type": "@vocab",
          "@context": {
            "@version": 1.1,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "sec": "https://w3id.org/security#",

            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
          }
        },
        "proofValue": "sec:proofValue",
        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
      }
    }
...

[brentzundel]

I agree this is a correction that needs to be made to the security vocabulary. @OR13 @msporny @tplooker I believe you are the owners of the security vocab work item at the CCG.
We will close this issue as soon as it has been picked up by the security vocab folks.

[msporny]

this is a correction that needs to be made to the security vocabulary.

Hrm, no, not in the security vocabulary... the bug is in the VC JSON-LD Context -- good catch @kuzdogan!

This means that RsaSignature2018 is completely broken in the 2018 Verifiable Credentials context... which tells me that no one is using that particular cryptosuite for VCs. :)

I'll note that the Ed25519Signature2018 definition doesn't have the same problem.

Changing this would be a substantive change... we will have to note that RsaSignature2018 MUST NOT be used with the 2018 VC suite. We will then have to fix this in the new VC context.

@kuzdogan -- how did you find this bug? Did a library throw an error on you? I'm wondering if a signature would still be generated (with a different set of base URLs for where sec: isn't defined. So, all implementations should still do the same thing... and signatures should still be safe, it's just that the URLs aren't what we'd expect them to be if we were to put them through a reasoner of some kind.

[kuzdogan]

@msporny Nope, I found it by chance while I was working on my prototype VC application.

Not sure if this is what you mean, but the application generates a VC with BbsBlsSignature2020, which is not included in the default VC context. If I were to remove the BBS context from the document @context array, I don't get any errors but the proof node is generated as follows:

"proof": {
    "type": "sec:BbsBlsSignature2020",
    "http://purl.org/dc/terms/created": {
      "type": "http://www.w3.org/2001/XMLSchema#dateTime",
      "@value": "2021-05-10T15:40:52Z"
    },
    "https://w3id.org/security#proofPurpose": {
      "id": "https://w3id.org/security#assertionMethod"
    },
    "https://w3id.org/security#proofValue": "ijhBesgKIvFhvQOnWQzfqKQ3JuS41L0vWe8L1kUXZr1tm7gAXfLdvK39EURw46a3GPvWuifz/AY2X7exULXN9KbTzisGClkDu5pccIk85MdDsEQyHJnIxOnTB7n+BYqLwdcPDsvV3U70oinM2KfV/Q==",
    "https://w3id.org/security#verificationMethod": {
      "id": "did:example:489398593#test"
    }
  }

Whereas with the complete context it is:

  "proof": {
    "type": "BbsBlsSignature2020",
    "created": "2021-05-10T15:41:18Z",
    "proofPurpose": "assertionMethod",
    "proofValue": "jDbEQx7M6q01qYEXyQ4tTZvyAJSwG51GYRpXdI3xCQWM4vul0fE4MxE83HTsu2fNVUPFxJye1VKwkG3JSstrPNpSrFdkOVQQJhUadaBx74QQYmRqkZSAsocSWpCO4DlYWhy3uX20CzFzGmznKvKPAg==",
    "verificationMethod": "did:example:489398593#test"
  }

[clehner]

I confirm this bug.

Here is a verifiable credential using RsaSignature2018, generated using Spruce's ssi library [Edit: this library will longer generate a verifiable credential like this, as it will detect and error on the unexpected RDF terms per this issue]:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "type": [
    "VerifiableCredential"
  ],
  "credentialSubject": {
    "id": "urn:uuid:b622372b-98d0-4245-8a9d-466e3ffb3a24"
  },
  "issuer": "did:web:demo.spruceid.com:2021:05:10:example-rsa",
  "issuanceDate": "2021-05-10T17:16:06.902Z",
  "proof": {
    "type": "RsaSignature2018",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:web:demo.spruceid.com:2021:05:10:example-rsa#key",
    "created": "2021-05-10T17:16:06.902Z",
    "jws": "eyJhbGciOiJSUzI1NiIsImtpZCI6InJzYTIwNDgtMjAyMC0wOC0yNSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..CQoDN2RkrJt1K6lieVoxe5WFUd4BdbHT9H78dbVa-sNYKhHqXTXm5kFh6c6EYm5pIXM1ttkpgK6B1gmsSluquPm8Jo2NnbiH6YjubEOWAcDryr2pFfr3321w5NZjG-qcpFAWpUyx5hMQyBcZOG0Lob8P6sxULTIO1kxrX0i95snuzRU9KnqbdLfVkgqmiJQc7lSW1WGduQ29y0COrEVw9BoLzrvcGCwCaG1OYtCrOA58TC8yQM1W5Eq8-Ry16cbeUAqJZ8wPO2TTl1GKYiJQyNbuRJjncbCxF4ZvBx1ijUrBj7geXH09LnaED3SeSumspGxXphIwvzQD2nNqGerK6g"
  }
}

N-Quads:

_:c14n0 <http://purl.org/dc/terms/created> "2021-05-10T17:16:06.902Z"^^<xsd:dateTime> _:c14n1 .
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#RsaSignature2018> _:c14n1 .
_:c14n0 <sec:jws> "eyJhbGciOiJSUzI1NiIsImtpZCI6InJzYTIwNDgtMjAyMC0wOC0yNSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..CQoDN2RkrJt1K6lieVoxe5WFUd4BdbHT9H78dbVa-sNYKhHqXTXm5kFh6c6EYm5pIXM1ttkpgK6B1gmsSluquPm8Jo2NnbiH6YjubEOWAcDryr2pFfr3321w5NZjG-qcpFAWpUyx5hMQyBcZOG0Lob8P6sxULTIO1kxrX0i95snuzRU9KnqbdLfVkgqmiJQc7lSW1WGduQ29y0COrEVw9BoLzrvcGCwCaG1OYtCrOA58TC8yQM1W5Eq8-Ry16cbeUAqJZ8wPO2TTl1GKYiJQyNbuRJjncbCxF4ZvBx1ijUrBj7geXH09LnaED3SeSumspGxXphIwvzQD2nNqGerK6g" _:c14n1 .
_:c14n0 <sec:proofPurpose> <https://w3id.org/security#assertionMethod> _:c14n1 .
_:c14n0 <sec:verificationMethod> <did:web:demo.spruceid.com:2021:05:10:example-rsa#key> _:c14n1 .
_:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
_:c14n2 <https://w3id.org/security#proof> _:c14n1 .
_:c14n2 <https://www.w3.org/2018/credentials#credentialSubject> <urn:uuid:b622372b-98d0-4245-8a9d-466e3ffb3a24> .
_:c14n2 <https://www.w3.org/2018/credentials#issuanceDate> "2021-05-10T17:16:06.902Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
_:c14n2 <https://www.w3.org/2018/credentials#issuer> <did:web:demo.spruceid.com:2021:05:10:example-rsa> .

N-Quads (VC only):

_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
_:c14n0 <https://www.w3.org/2018/credentials#credentialSubject> <urn:uuid:b622372b-98d0-4245-8a9d-466e3ffb3a24> .
_:c14n0 <https://www.w3.org/2018/credentials#issuanceDate> "2021-05-10T17:16:06.902Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
_:c14n0 <https://www.w3.org/2018/credentials#issuer> <did:web:demo.spruceid.com:2021:05:10:example-rsa> .

N-Quads (proof only, without JWS):

_:c14n0 <http://purl.org/dc/terms/created> "2021-05-10T17:16:06.902Z"^^<xsd:dateTime> .
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#RsaSignature2018> .
_:c14n0 <sec:proofPurpose> <https://w3id.org/security#assertionMethod> .
_:c14n0 <sec:verificationMethod> <did:web:demo.spruceid.com:2021:05:10:example-rsa#key> .

On JSON-LD Playground

Credential with context adjustment

Here is a verifiable credential simpler to the above but with the sec prefix definition added to the local context, to make the terms expand to the expected IRIs (Edit: the "xsd" mapping, used in the "created" property, is still missing. So this credential is still invalid. More info: #884 (comment)):

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    {
      "sec": "https://w3id.org/security#"
    }
  ],
  "type": [
    "VerifiableCredential"
  ],
  "credentialSubject": {
    "id": "urn:uuid:d58dcd4a-8602-47c8-90b4-a12d250af1be"
  },
  "issuer": "did:web:demo.spruceid.com:2021:05:10:example-rsa",
  "issuanceDate": "2021-05-10T18:01:16.244Z",
  "proof": {
    "type": "RsaSignature2018",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:web:demo.spruceid.com:2021:05:10:example-rsa#key",
    "created": "2021-05-10T18:01:16.244Z",
    "jws": "eyJhbGciOiJSUzI1NiIsImtpZCI6InJzYTIwNDgtMjAyMC0wOC0yNSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..IM4BYrQ-1UIalVY35N9QaxNl4SXmvyniuWCMX1lGAd2O4wwqTd2TP3hZLjw4q_6rfqrCdhsk0fLdu3jfF1-RIaldZ_LdrqDyDSqSYlEGGn2XbUGFeFAwotRIW0Ay0ljah-FjRi62C487tgkbtP-S2Cr1yUNxZi6ZoGFqahEtUlDuFu0qIOTW4qtu_-w1JUEyr1FIN2Nfzt-F5dGst6WlieaizJHsS78pNnjZYRdI5jHig-gEUku7lA7yjivLsrLyQ_SOG0DgATkdR-vVWf8voxBiXL-ifMygCL7xyZduNpMfm5ADw2myhHKbDeT4EGKw1uMkV97ADVxknobsZUdTiQ"
  }
}

N-Quads:

_:c14n0 <http://purl.org/dc/terms/created> "2021-05-10T18:01:16.244Z"^^<xsd:dateTime> _:c14n2 .
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#RsaSignature2018> _:c14n2 .
_:c14n0 <https://w3id.org/security#jws> "eyJhbGciOiJSUzI1NiIsImtpZCI6InJzYTIwNDgtMjAyMC0wOC0yNSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..IM4BYrQ-1UIalVY35N9QaxNl4SXmvyniuWCMX1lGAd2O4wwqTd2TP3hZLjw4q_6rfqrCdhsk0fLdu3jfF1-RIaldZ_LdrqDyDSqSYlEGGn2XbUGFeFAwotRIW0Ay0ljah-FjRi62C487tgkbtP-S2Cr1yUNxZi6ZoGFqahEtUlDuFu0qIOTW4qtu_-w1JUEyr1FIN2Nfzt-F5dGst6WlieaizJHsS78pNnjZYRdI5jHig-gEUku7lA7yjivLsrLyQ_SOG0DgATkdR-vVWf8voxBiXL-ifMygCL7xyZduNpMfm5ADw2myhHKbDeT4EGKw1uMkV97ADVxknobsZUdTiQ" _:c14n2 .
_:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> _:c14n2 .
_:c14n0 <https://w3id.org/security#verificationMethod> <did:web:demo.spruceid.com:2021:05:10:example-rsa#key> _:c14n2 .
_:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
_:c14n1 <https://w3id.org/security#proof> _:c14n2 .
_:c14n1 <https://www.w3.org/2018/credentials#credentialSubject> <urn:uuid:d58dcd4a-8602-47c8-90b4-a12d250af1be> .
_:c14n1 <https://www.w3.org/2018/credentials#issuanceDate> "2021-05-10T18:01:16.244Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
_:c14n1 <https://www.w3.org/2018/credentials#issuer> <did:web:demo.spruceid.com:2021:05:10:example-rsa> .

N-Quads (VC only):

_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
_:c14n0 <https://www.w3.org/2018/credentials#credentialSubject> <urn:uuid:d58dcd4a-8602-47c8-90b4-a12d250af1be> .
_:c14n0 <https://www.w3.org/2018/credentials#issuanceDate> "2021-05-10T18:01:16.244Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
_:c14n0 <https://www.w3.org/2018/credentials#issuer> <did:web:demo.spruceid.com:2021:05:10:example-rsa> .

N-Quads (proof only, without JWS):

_:c14n0 <http://purl.org/dc/terms/created> "2021-05-10T18:01:16.244Z"^^<xsd:dateTime> .
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#RsaSignature2018> .
_:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> .
_:c14n0 <https://w3id.org/security#verificationMethod> <did:web:demo.spruceid.com:2021:05:10:example-rsa#key> .

On JSON-LD Playground

[peacekeeper]

which tells me that no one is using that particular cryptosuite for VCs. :)

I think one possible reason why this hasn't been detected sooner might be that during creation and verification of the RsaSignature2018 proof, you never actually serialize the entire VC (including the proof) to N-Quads as it is shown above in a few examples.

You serialize the "proof options" separately from the "VC without the proof".

An implementation might serialize the "VC without the proof" using the https://www.w3.org/2018/credentials/v1 context, and it might serialize the "proof options" using the https://w3id.org/security/v2 context. Yes this would be a buggy implementation, but it's not inconceivable that the various CCG specs and discussions could be interpreted this way.

In such an implementation, the resulting proof would actually be correct, even though the VC as a whole would be invalid JSON-LD because of the missing terms.

[clehner]

during creation and verification of the RsaSignature2018 proof, you never actually serialize the entire VC (including the proof) to N-Quads as it is shown above in a few examples.

This is correct. I've updated the examples I wrote to add the N-Quads for VC only and proof only.

For serializing the proof options, Spruce/ssi's implementation merges the local context from the linked data document (VC without proof) into the proof object. So it still uses the compact IRIs in this case. If https://w3id.org/security/v2 was used instead, that would result in the correct expanded IRIs: On JSON-LD Playground

[kdenhartog]

I've optted to relabel this to a v2 issue that won't be addressed by this because of the reasons stated in this comment: #778 (comment)

[iherman]

The issue was discussed in a meeting on 2022-08-03

• no resolutions were taken

View the transcript

6.9. Base context v1 missing sec: mapping in RsaSignature2018 "@context" (issue vc-data-model#778)

See github issue vc-data-model#778.

Brent Zundel: Not sure what this means.

Manu Sporny: This deals with the base context... let's keep it in the data model since that's where the context is..

Orie Steele: +1 to keeping it, and then removing it..

Brent Zundel: Any opposition to keeping it in the core data model?.

Oliver Terbu: Is this about the data integrity suite - RSA in particular?.
… If so maybe would fit in Data Integrity.

Orie Steele: I think there is a series of context-specific changes, like Mike Jones mentioned earlier..
… Since that file is currently in the core data model repo, I think it's fine to leave issues in the core repo to say will keep or leave items from the core data model context..
… This particular one I think we are definitely removing, and probably need to find in the data integrity repo at some point..
… But I'm just guessing....
… I suggest we leave issues that are requesting changes to the v1 context in the VC data repo until the change can be addressed by the WG..

[msporny]

Listing specific Data Integrity cryptosuites have been removed from the v2 context and are going to be replaced with DataIntegrityProof. This issue is no longer relevant since the v2 context will not specifically list RsaSignature2018. Marking as pending close.

[brentzundel]

No comments since marked pending close, closing

[fabrii]

Hello!

I recently ran into a problem related to this. We are using verifiable-credentials-java (backend) and vc.js (frontend/mobile).
Both libraries handle this situation differently, and the canonicalization produced does not match. This means, as of now, that there is no interoperability between java and javascript for RsaSignature2018.

This type of error can be hard to diagnose, specially to newcomers as me.

Also:

• RsaSignature2018 is used many times in https://www.w3.org/TR/vc-data-model/, and there is no warning of this.
• In our case, we have no possibility of changing the keys types away from RSA.
• Currently, there are not JsonWebSignature2020 javascript implementations that support RSA.

I believe that a consensus/workaround should be made explicit in the spec, so we can have interoperability across all implementations.

Thanks