This commit is contained in:
Sofía Aritz 2024-06-29 21:02:27 +02:00
parent 7afc8cff5b
commit e23a14e53f
Signed by: sofia
GPG key ID: 90B5116E3542B28F
2 changed files with 3 additions and 3 deletions

View file

@ -27,7 +27,7 @@ The Identity project is composed by a web-app and two servers. In the future, Do
3. Run `yarn dev` and open the specified URL.
4. You're ready to go! Any changes should be reflected in real time.
### `identity-api`
#### `identity-api`
1. Copy the `env.example` file: `cp .env.example .env`
2. Run `yarn` to install the dependencies.
@ -36,7 +36,7 @@ The Identity project is composed by a web-app and two servers. In the future, Do
* **Note:** The `asset-api` server **must** be running before this command is run. [More info](./docs/asset-implementation.md).
4. You're ready to go! You will need to restart the server manually when you make changed (unless you use something like [Nodemon](https://www.npmjs.com/package/nodemon)).
### `asset-api`
#### `asset-api`
1. Copy the `.env.example` file: `cp .env.example .env`
2. Run `yarn` to install the dependencies.

View file

@ -50,7 +50,7 @@ there's less hoops that the `asset-api` has to go through to prove its identity.
Currently, the `identity-api` obtains the `asset-api`'s public key and algorithm by sending an HTTP(S) request. This simplifies
the infrastructure and allows the `asset-api` to rotate keys on the fly, but it also has the downside that the `identity-api`
**must** trust that the URL to the `asset-api` is not compromised. Using manual key rotation would be more secure in that sense,
but in practice rotation would be much slower, potentially leading to more frequent security problems.
but in practice rotation would be much slower, potentially leading to more practical security problems.
It is theoretically possible to make the `identity-api` trust third-party keys using techniques such as DNS poisoning, but in
order to execute such a targeted attack the overall infrastructure must already be compromised.