Skip to content
This repository has been archived by the owner on Jul 31, 2024. It is now read-only.

Commit

Permalink
Update Verifier (#70)
Browse files Browse the repository at this point in the history
* add issuer

* add charts

* initial local and test setup

* doc

* fix key

* enable did-helper

* add test workflow

* tests and docs

* more doc

* more documentation

* more doc

* verify the results

* deploy the chart

* fix verification

* stable version

* update verifier chart

* improve verifier
  • Loading branch information
Stefan Wiedemann authored Jun 6, 2024
1 parent a387d51 commit 42d2cbe
Show file tree
Hide file tree
Showing 4 changed files with 6 additions and 11 deletions.
2 changes: 1 addition & 1 deletion charts/data-space-connector/Chart.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ dependencies:
# authentication
- name: vcverifier
condition: vcverifier.enabled
version: 2.7.0
version: 2.9.0
repository: https://fiware.github.io/helm-charts
- name: credentials-config-service
condition: credentials-config-service.enabled
Expand Down
11 changes: 5 additions & 6 deletions doc/LOCAL.MD
Original file line number Diff line number Diff line change
Expand Up @@ -250,7 +250,7 @@ The policy can be created at the PAP via:

Data can be created through the NGSI-LD API itself. In order to make interaction easier, its directly available through
an ingress at ```http://scorpio-provider.127.0.0.1.nip.io/ngsi-ld/v1```. In
real environments, no endpoint should be publicly available without being protected by the authorization framework.
real environments, no endpoint should be publicly available without beeing protected by the authorization framework.
Create an entity via:

```shell
Expand Down Expand Up @@ -297,7 +297,7 @@ If you try to request the provider api without authentication, you will receive
The normal flow is now to request the oidc-information at the well-known endpoint:

```shell
curl -s -X GET 'http://mp-data-service.127.0.0.1.nip.io:8080/.well-known/openid-configuration'
export TOKEN_ENDPOINT=$(curl -s -X GET 'http://mp-data-service.127.0.0.1.nip.io:8080/.well-known/openid-configuration' | jq -r '.token_endpoint'); echo $TOKEN_ENDPOINT
```

In the response, the grant type `vp_token` will be present, indicating the support for the OID4VP authentication flow:
Expand All @@ -306,7 +306,7 @@ In the response, the grant type `vp_token` will be present, indicating the suppo
{
"issuer": "http://provider-verifier.127.0.0.1.nip.io:8080",
"authorization_endpoint": "http://provider-verifier.127.0.0.1.nip.io:8080",
"token_endpoint": "http://provider-verifier.127.0.0.1.nip.io:8080/token",
"token_endpoint": "http://provider-verifier.127.0.0.1.nip.io:8080/services/data-service/token",
"jwks_uri": "http://provider-verifier.127.0.0.1.nip.io:8080/.well-known/jwks",
"scopes_supported": [
"default"
Expand Down Expand Up @@ -397,10 +397,9 @@ The JWT representation of the JWT has to be Base64-encoded(no padding!):
The vp_token can then be exchanged for the access-token

```shell
export DATA_SERVICE_ACCESS_TOKEN=$(curl -s -X POST http://provider-verifier.127.0.0.1.nip.io:8080/token \
export DATA_SERVICE_ACCESS_TOKEN=$(curl -s -X POST $TOKEN_ENDPOINT \
--header 'Accept: */*' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'client_id: data-service' \
--data grant_type=vp_token \
--data vp_token=${VP_TOKEN} \
--data scope=default | jq '.access_token' -r ); echo ${DATA_SERVICE_ACCESS_TOKEN}
Expand Down Expand Up @@ -451,7 +450,7 @@ the local installation uses [did:key](https://w3c-ccg.github.io/did-method-key/)
they are well-supported, can be resolved without any external interaction and can easily be generated within the deployment. That makes
them a perfect fit for the local use-case.
All participants(e.g. the consumer and the participant) get a did generated on installation, by using the [did-helper](https://github.com/wistefan/did-helper).
The identities and connected key-material is automatically distributed in the cluster and set in the components that require it.
The identities and connected key-material is automatically distributed in the cluster and set in the componets that require it.

In real world data spaces, the participants should rather use stabled identities, which can be [did:key](https://w3c-ccg.github.io/did-method-key/), but also
more organization-focused once like [did:web](https://w3c-ccg.github.io/did-method-web/) or [did:elsi](https://alastria.github.io/did-method-elsi/).
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,6 @@ public abstract class MPOperationsEnvironment {
public static final String SCORPIO_ADDRESS = "http://scorpio-provider.127.0.0.1.nip.io:8080";

public static final String OIDC_WELL_KNOWN_PATH = "/.well-known/openid-configuration";
public static final String CLIENT_ID = "data-service";
private static final OkHttpClient HTTP_CLIENT = new OkHttpClient();
private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper();

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -58,8 +58,6 @@ public class Wallet {
private static final String OID_WELL_KNOWN_PATH = "/.well-known/openid-configuration";
private static final String PRE_AUTHORIZED_GRANT_TYPE = "urn:ietf:params:oauth:grant-type:pre-authorized_code";

private static final String SAME_DEVICE_ENDPOINT = "/api/v1/samedevice";

private final Map<String, String> credentialStorage = new HashMap<>();

private static final OkHttpClient HTTP_CLIENT = new OkHttpClient();
Expand All @@ -84,7 +82,6 @@ public String exchangeCredentialForToken(OpenIdConfiguration openIdConfiguration
.build();
Request tokenRequest = new Request.Builder()
.post(requestBody)
.addHeader("client_id", MPOperationsEnvironment.CLIENT_ID)
.url(openIdConfiguration.getTokenEndpoint())
.build();
Response tokenResponse = HTTP_CLIENT.newCall(tokenRequest).execute();
Expand Down

0 comments on commit 42d2cbe

Please sign in to comment.