Generated DID not accepted by Gaia-X Compliance API

[markus-hentsch]

I tried the DID creator and the JSON it produced to verify the compliance process I described in the upcoming blog post about Gaia-X compliance credentials.

Input `config.yaml` (click to expand ...)

issuer: "did:web:gaia-x-testing.cloudandheat.com"
verification-methods:
    keys:
    - /path/to/cert.pem
    x509s:
    - https://gaia-x-testing.cloudandheat.com/.well-known/fullchain.pem

A `did.json` generated by scs-did-creator (click to expand ...)

{
"@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
],
"id": "did:web:gaia-x-testing.cloudandheat.com",
"verificationMethod": [
    {
        "@context": "https://w3c-ccg.github.io/lds-jws2020/contexts/v1/",
        "id": "did:web:gaia-x-testing.cloudandheat.com#JWK2020-RSA-0",
        "type": "JsonWebKey2020",
        "controller": "did:web:gaia-x-testing.cloudandheat.com",
        "publicKeyJwk": {
            "kty": "RSA",
            "kid": "1Cy1AxUdN648x2Xtnjc06tDIYhWimd5I6hu4E4rsC_o",
            "n": "5o8bBm98K1jaE7eEY_wCD0dXeeNktstgRfwX7h9uwypCquPDWVemIJYyuIdW_shm8Q9LJa7b6i7ktp7hGW3sBPbnsEmvCMY8FEmUNr3eVJYcyH6sihqqA1sglpKwIFwomTM-JIechmL99cAIQlGtaBJRzLedmdX75xu__5Jroj0Sl6oD7ApsT8tZPGZtBe3W0xZHNuYdlhEco_hRerKj2PGwpY0rGLggeAHsfZesRpJ8WtM1mmxi0jFIcWC61jKtmiVIMyLjRpGaiREGKPfd2Lz77guu7m1BJENebZwMPdNGzjP12h6J1c0CrQhUXzGE3D9p4A-wlrwupmwLf7RJVWv4zS3atY4F3TkWT2PoqLHV8Cq-A5h2E07KCinXIuJ15pdOEo_4WmNvK20H96c3XfJE1giPXRf4eR_CLFvly1RBAWK7t6pR2BueLmWSIzPlKlwTrZCZ6OgUYAtHBH0p3KDMnSU80ANXZOo9ZTBjAcqfdcR7x-gleOlX5Kt877RMKoYdVFSpbiQGooOMgMTSwpRIowhIFTNCFgCTnjpgFaQA6IIrpUQ30bG3vv6DQEcB6LHWBmDCmD_ytxHHQL-UwWU5jYomyBTFwWPiMOdt4G5rzJ7_ldsMHnjRGoDzvFg-90dJZ6Vbzo_W3V_HspdP3yE357I1_bYH9m5iOBkvlLk",
            "e": "AQAB"
        }
    },
    {
        "@context": "https://w3c-ccg.github.io/lds-jws2020/contexts/v1/",
        "id": "did:web:gaia-x-testing.cloudandheat.com#JWK2020-X509-1",
        "type": "JsonWebKey2020",
        "controller": "did:web:gaia-x-testing.cloudandheat.com",
        "publicKeyJwk": {
            "kty": "RSA",
            "kid": "1Cy1AxUdN648x2Xtnjc06tDIYhWimd5I6hu4E4rsC_o",
            "n": "5o8bBm98K1jaE7eEY_wCD0dXeeNktstgRfwX7h9uwypCquPDWVemIJYyuIdW_shm8Q9LJa7b6i7ktp7hGW3sBPbnsEmvCMY8FEmUNr3eVJYcyH6sihqqA1sglpKwIFwomTM-JIechmL99cAIQlGtaBJRzLedmdX75xu__5Jroj0Sl6oD7ApsT8tZPGZtBe3W0xZHNuYdlhEco_hRerKj2PGwpY0rGLggeAHsfZesRpJ8WtM1mmxi0jFIcWC61jKtmiVIMyLjRpGaiREGKPfd2Lz77guu7m1BJENebZwMPdNGzjP12h6J1c0CrQhUXzGE3D9p4A-wlrwupmwLf7RJVWv4zS3atY4F3TkWT2PoqLHV8Cq-A5h2E07KCinXIuJ15pdOEo_4WmNvK20H96c3XfJE1giPXRf4eR_CLFvly1RBAWK7t6pR2BueLmWSIzPlKlwTrZCZ6OgUYAtHBH0p3KDMnSU80ANXZOo9ZTBjAcqfdcR7x-gleOlX5Kt877RMKoYdVFSpbiQGooOMgMTSwpRIowhIFTNCFgCTnjpgFaQA6IIrpUQ30bG3vv6DQEcB6LHWBmDCmD_ytxHHQL-UwWU5jYomyBTFwWPiMOdt4G5rzJ7_ldsMHnjRGoDzvFg-90dJZ6Vbzo_W3V_HspdP3yE357I1_bYH9m5iOBkvlLk",
            "e": "AQAB",
            "x5u": "https://gaia-x-testing.cloudandheat.com/.well-known/fullchain.pem"
        }
    }
],
"assertionMethod": [
    "did:web:gaia-x-testing.cloudandheat.com#JWK2020-RSA-0",
    "did:web:gaia-x-testing.cloudandheat.com#JWK2020-X509-1"
]
}

The generated DID fails to work with the Compliance API of Gaia-X.

Missing x5u field for RSA type verificationMethod

I intuitively filled in both keys and x509s in the config.yaml.
This seems a misinterpretation on my side (keys is not necessary if x509s is specified because the public key is downloaded from the URL anyway).
This inevitably led to two verificationMethods being generated:

• did:web:gaia-x-testing.cloudandheat.com#JWK2020-RSA-0
• did:web:gaia-x-testing.cloudandheat.com#JWK2020-X509-1

The #JWK2020-RSA-0 one is missing the x5u field and is rejected by the Gaia-X Compliance API:

{"message":"The x5u parameter is expected to be set in the JWK for [object Object]","error":"Conflict","statusCode":409}

In all existing examples¹, the x5u field is always present and the JSON only contains one verificationMethod entry.
The Gaia-X DID documentation categorizes the x5u field as "should" but it seems mandatory nonetheless.
The alternative x5c is mentioned in the documentation as well but also rejected with the same error message.
I'm not entirely sure but this makes it seem like the Gaia-X Compliance API is not correctly following its own standards.

Having generated the #JWK2020-RSA-* type by accident (from keys: in the YAML) I'm wondering if that type is actually useful to have in scs-did-creator if it is not accepted by the Gaia-X API at all.
On the other hand, maybe the API is just misbehaving currently as noted above.

Nonetheless, omitting the keys: input will result in a single entry with the correct x5u field but leads to the next problem (see below).

Missing alg field

Even when only using the x509s input and generating a single verificationMethod that does include the x5u field, it is still rejected by the Gaia-X Compliance API:

{"message":"Could not confirm X509 public key with certificate chain.\"alg\" argument is required when \"jwk.alg\" is not present","error":"Conflict","statusCode":409}

The existing examples¹ also include this field.
Although RFC7517 categorizes this field as optional, Gaia-X seems to mandate it.
I have not found any mentioning this in the Gaia-X documentation and its referenced standards yet hinting at this restriction.

Adding the alg field by hand makes the DID being accepted by the Gaia-X Compliance API.

Summary

• the #JWK2020-RSA-* type (resulting from keys: config entries) is rejected by the Gaia-X Compliance API due to the missing x5u field; hence it's usefulness is debatable but maybe this is an issue with Gaia-X's API implementation
• (contrary to its documentation) the Gaia-X Compliance API does not accept the x5c field as a replacement for x5u
  • currently scs-did-creator supports generating this type but it can't be used
• the alg field of publicKeyJwk is missing but mandated by the Gaia-X Compliance API

Footnotes

1. examples of existing DIDs are the DID JSON template of gaia-x-101 and the did.json hosted at Gaia-X Lab referenced as did:web:registration.lab.gaia-x.eu:v1#X509-JWK2020 when receiving a signed LRN VC from the Registration API ↩ ↩²

[anjastrunk]

solved via #3

[markus-hentsch]

solved via #3

I observed the issues reported above on 3a0a0d8 which already had #3 merged.

Reopening.

[markus-hentsch]

Iff the alg parameter calculation for certificates is added (I locally added some code inspired by gaia-x-101 for testing), according to my testing, only one of the input types that scs-did-creator currently supports is actually working with the compliance API:

#	Input Type	Example	Works with Gaia-X API?	Comment
1	RSA or EC Public Key file (PEM)	keys: ["/local/path/key.pub"]	No	alg and x5u fields missing; alg can only be extracted from certs, not keys
2	X.509 Certificate file (PEM)	x509s: ["/local/path/cert.pem"]	No	x5u field missing, x5c is set but not accepted by Gaia-X API
3	X.509 Certificate URL	x509s: ["https://domain.com/fullchain.pem"]	Yes	alg can be extracted from the certificate, x5u is set to the URL

Judging from the documentation alone, both no. 1 and no. 2 should work as any of the fields that the API is complaining about are stated to be optional.

No. 3 currently only works if alg parameter calculation is added. I'll create a PR for this. EDIT: done.

[anjastrunk]

Comments regards "Missing x5u field for RSA type verificationMethod"

Configuration of scs-did-generator

I intuitively filled in both keys and x509s in the config.yaml.
This seems a misinterpretation on my side (keys is not necessary if x509s is specified because the public key is downloaded from the URL anyway).

The #JWK2020-RSA-0 one is missing the x5u field and is rejected by the Gaia-X Compliance API:

DID generator supports JWK as verification method. JWK Standard allows different key formats, see section 4. There are:

• as JWK isself using parameters e and n
• as X.509 Certificate Chain
• as X.509 Certificate URL
• as X.509 Certificte SHA-1 Thumbprint
• as X.509 Certificate SHA-256 Thumbprint

DID generator supports the first three. Each format requires other settings in config.yaml. key triggers generation of verification method with JWK itself (first option). I want to keep DID generator independent of Gaia-X. Hence, it supports more verification method than required by Gaia-X.

Obviously, documentation of DID generator is not clear with respect to verification methods. I will improve this. See #9.

Mandatory optional attribute x5u

In all existing examples1, the x5u field is always present and the JSON only contains one verificationMethod entry.
The Gaia-X DID documentation categorizes the x5u field as "should" but it seems mandatory nonetheless.

You are right, I opened an issue at Gaia-X Git

Update from 07.08.24

According to Gaia-X Lab Gaia-X Compliance Service has limitations with respect to format of DID document. Tagus release does not support "x5c" certificate. Furthermore, Compliance service requires a x.509 certificate as mentioned in #9, hence ICAM document has to be re-phrased. I created an issue there, see 85

[anjastrunk]

Iff the alg parameter calculation for certificates is added (I locally added some code inspired by gaia-x-101 for testing), according to my testing, only one of the input types that scs-did-creator currently supports is actually working with the compliance API:

Input Type Example Works with Gaia-X API? Comment

1 RSA or EC Public Key file (PEM) keys: ["/local/path/key.pub"] No alg and x5u fields missing; alg can only be extracted from certs, not keys
2 X.509 Certificate file (PEM) x509s: ["/local/path/cert.pem"] No x5u field missing, x5c is set but not accepted by Gaia-X API
3 X.509 Certificate URL x509s: ["https://domain.com/fullchain.pem"] Yes alg can be extracted from the certificate, x5u is set to the URL

Judging from the documentation alone, both no. 1 and no. 2 should work as any of the fields that the API is complaining about are stated to be optional.

No. 3 currently only works if alg parameter calculation is added. I'll create a PR for this. EDIT: done.

You are right. It is intended, that scs-did-generator creates Gaia-X non-compliant verification methods. The reason behind is, that scs-did-creator should be more generic that Gaia-X requirements. I admit, documentation has to be updated, which is part of #9

[anjastrunk]

Missing "alg" field

You are right, I observed the same and forwarded this issue to Gaia-X, see #75...

In the meantime, @markus-hentsch already added missing "alg" attribute via #6 to be compliant with Gaia-X.