FIWARE / data-space-connector

FIWARE Data Space Connector following DSBA TC recommendations
MIT License
17 stars 2 forks source link

Instantiation of Trusted Issuers #22

Closed sermars closed 3 days ago

sermars commented 1 month ago

Hi @wistefan

We have replicated the local example with the new connector in Terraform. All services are deployed without problems, but we may be missing some configurations because DATA_SERVICE_ACCESS_TOKEN is not generated. We are following all the steps of your local example.

We have tried to analyze the reason, and it seems that the Issuer's did:key is not being saved in the Trusted Issuer List of the provider. As you can see in the vc-verifier log:

{"level":"debug","msg":"Issuer did:key:zDnaeTPAE8QMfozMfhwq94RoSmuro2HbyHirN56hPHnNo8uhP is not known at http://trusted-issuers-list:8080.","time":"2024-10-16T13:06:08Z"}

In fact, the MySQL database is empty; however, in the local example, this does not happen.

Screenshot from 2024-10-16 15-12-53

At what point is that did:key generated during deployment? Which service might be causing this error?

Best,

wistefan commented 1 month ago

Hi @sermars the example uses an init-container to register the first issuers: https://github.com/FIWARE/data-space-connector/blob/main/charts/data-space-connector/values.yaml#L498-L511 Was that executed successfully?

sermars commented 1 month ago

Yes, @wistefan is executed correctly.

Setting up openssl (3.0.13-0ubuntu3.4) ...
Setting up publicsuffix (20231001.0357-0.1) ...
Setting up libldap2:amd64 (2.6.7+dfsg-1~exp1ubuntu8) ...
Setting up ca-certificates (20240203) ...
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC entries checked: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.38.2 /usr/local/share/perl/5.38.2 /usr/lib/x86_64-linux-gnu/perl5/5.38 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.38 /usr/share/perl/5.38 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 8.)
debconf: falling back to frontend: Teletype
Updating certificates in /etc/ssl/certs...
146 added, 0 removed; done.
Setting up libgssapi-krb5-2:amd64 (1.20.1-6ubuntu2.1) ...
Setting up libssh-4:amd64 (0.10.6-2build2) ...
Setting up libcurl4t64:amd64 (8.5.0-2ubuntu10.4) ...
Setting up curl (8.5.0-2ubuntu10.4) ...
Processing triggers for libc-bin (2.39-0ubuntu8.3) ...
Processing triggers for ca-certificates (20240203) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
>> Registering at TIR
>> DID: did:key:zDnaespCm6ofjdcEgFmd93TW81CyQPeGKQ3Qhu5c21T9HSpKS
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    87    0     0  100    87      0   5118 --:--:-- --:--:-- --:--:--  5437

(I added a couple of "echo" now just to verify that it was running, and the value of $DID)

DIDs are stored correctly in the Trusted Issuers List of the Trust-Anchor.

mysql> SELECT * FROM trusted_issuer;
+-----------------------------------------------------------+
| did                                                       |
+-----------------------------------------------------------+
| did:key:zDnaeirSwTgqoXxAQYhBeLFNpBk1GgTJnRPTiAL2mSkViNTNi |
| did:key:zDnaespCm6ofjdcEgFmd93TW81CyQPeGKQ3Qhu5c21T9HSpKS |
+-----------------------------------------------------------+
2 rows in set (0.00 sec)

But where it is not being saved is the Trusted Issuers List of the Provider connector, which is where the vc-verifier points (is not known at http://trusted-issuers-list:8080.).

wistefan commented 2 weeks ago

@sermars The registration at the provider-til in the local environment also happens through an init-container: https://github.com/FIWARE/data-space-connector/blob/main/k3s/consumer.yaml#L96

This is not part of the "default" setup, since this local registration should be a conscious decision by the "provider" organization.

sermars commented 4 days ago

Thanks @wistefan!! That was it, I had misconfigured the endpoint in registration.

Continuing with this topic, is it documented anywhere on how to create/allow/remove (manage in general) "users" from a data space? I mean to have the steps with their queries to perform this process that is automatically done in the deployment.

wistefan commented 3 days ago

@sermars Probably not in the level of detail you are hoping for. We are still improving in that part. However, I will have a webinar today, that will focus on deploying a Data Space Connector and it will also cover some parts of that: https://lnkd.in/dGbqpfqA Btw. I would rather not use the term "users" here, but "participants" instead. Most of the time, we will not create/allow/remove individual users, but organizations. Those organization then can delegate their powers to users(be they human or machines).

sermars commented 3 days ago

Understood, thank you very much @wistefan!!. If in the future the management of participants users is explained in detail, it would be great 😄.

I was following the series of webinars that FIWARE is doing, but through youtube, which is sometimes difficult to attend live.