Closed markus-hentsch closed 1 month ago
solved via #3
I observed the issues reported above on 3a0a0d84db8b041e150741cefa418a8b55416267 which already had #3 merged.
Reopening.
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.
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:
e
and n
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.
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
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
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 thatscs-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"]
Noalg
andx5u
fields missing;alg
can only be extracted from certs, not keys 2 X.509 Certificate file (PEM)x509s: ["/local/path/cert.pem"]
Nox5u
field missing,x5c
is set but not accepted by Gaia-X API 3 X.509 Certificate URLx509s: ["https://domain.com/fullchain.pem"]
Yesalg
can be extracted from the certificate,x5u
is set to the URLJudging 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
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.
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 ...)
```yaml 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 ...)
```json { "@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 typeverificationMethod
I intuitively filled in both
keys
andx509s
in theconfig.yaml
. This seems a misinterpretation on my side (keys
is not necessary ifx509s
is specified because the public key is downloaded from the URL anyway). This inevitably led to twoverificationMethod
s 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 thex5u
field and is rejected by the Gaia-X Compliance API:In all existing examples[^1], the
x5u
field is always present and the JSON only contains oneverificationMethod
entry. The Gaia-X DID documentation categorizes thex5u
field as "should" but it seems mandatory nonetheless. The alternativex5c
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 (fromkeys:
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 correctx5u
field but leads to the next problem (see below).Missing
alg
fieldEven when only using the
x509s
input and generating a singleverificationMethod
that does include thex5u
field, it is still rejected by the Gaia-X Compliance API:The existing examples[^1] 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
#JWK2020-RSA-*
type (resulting fromkeys:
config entries) is rejected by the Gaia-X Compliance API due to the missingx5u
field; hence it's usefulness is debatable but maybe this is an issue with Gaia-X's API implementationx5c
field as a replacement forx5u
alg
field ofpublicKeyJwk
is missing but mandated by the Gaia-X Compliance API[^1]: examples of existing DIDs are the DID JSON template of gaia-x-101 and the
did.json
hosted at Gaia-X Lab referenced asdid:web:registration.lab.gaia-x.eu:v1#X509-JWK2020
when receiving a signed LRN VC from the Registration API