Merge pull request #49 from FIWARE/support-holder-verification

add holder verification
FIWARE · Jan 15, 2025 · 783c5a4 · 783c5a4
2 parents b825588 + 7edf80a
commit 783c5a4
Show file tree

Hide file tree

Showing 4 changed files with 87 additions and 4 deletions.
diff --git a/charts/data-space-connector/Chart.yaml b/charts/data-space-connector/Chart.yaml
@@ -2,7 +2,7 @@ apiVersion: v2
 name: data-space-connector
 description: Umbrella Chart for the FIWARE Data Space Connector, combining all essential parts to be used by a participant.
 type: application
-version: 7.22.5
+version: 7.22.7
 dependencies:
   - name: postgresql
     condition: postgresql.enabled
@@ -11,11 +11,11 @@ dependencies:
   # authentication
   - name: vcverifier
     condition: vcverifier.enabled
-    version: 2.11.0
+    version: 2.11.2
     repository: https://fiware.github.io/helm-charts
   - name: credentials-config-service
     condition: credentials-config-service.enabled
-    version: 0.1.5
+    version: 0.1.6
     repository: https://fiware.github.io/helm-charts
   - name: trusted-issuers-list
     condition: trusted-issuers-list.enabled

diff --git a/doc/deployment-integration/local-deployment/LOCAL.MD b/doc/deployment-integration/local-deployment/LOCAL.MD
@@ -841,6 +841,71 @@ with the TMForum-APIs directly.
     -H 'Accept: */*' \
     -H "Authorization: Bearer ${ACCESS_TOKEN}"
 ```
+
+## Holder Verification
+
+All previous steps allowed essentially everyone to use the credentials issued, since the verification does not check if they belong to the holder presenting them.
+However, in a lot of usecases only the one that got the credential issued should be able to use it. Therfor, the [Verifier](../../../README.md#components) can be configured to check that the presenter is actually the lawful holder of the credential.
+
+To try it out, insert your holder did (```echo $HOLDER_DID```) into the mapper configuration of your consumer(e.g. [consumer.yaml](../../../k3s/consumer.yamlL234-L241)). Redeploy the connector and then try the following: 
+
+1. Configure holder verfifcation for a certain scope:
+```shell
+  curl -X 'PUT' \
+  'http://provider-ccs.127.0.0.1.nip.io:8080/service/data-service' \
+  -H 'accept: application/json' \
+  -H 'Content-Type: application/json' \
+  -d '{
+        "defaultOidcScope": "default",
+        "oidcScopes": {
+            "default": [
+                {
+                    "type": "UserCredential",
+                    "trustedParticipantsLists": [
+                        "http://tir.trust-anchor.svc.cluster.local:8080"
+                    ],
+                    "trustedIssuersLists": [
+                        "http://trusted-issuers-list:8080"
+                    ],
+                    "holderVerification": {
+                        "enabled": true,
+                        "claim": "subject"
+                    }
+                }
+            ],
+            "operator": [
+                {
+                    "type": "OperatorCredential",
+                    "trustedParticipantsLists": [
+                        "http://tir.trust-anchor.svc.cluster.local:8080"
+                    ],
+                    "trustedIssuersLists": [
+                        "http://trusted-issuers-list:8080"
+                    ],
+                    "holderVerification": {
+                        "enabled": true,
+                        "claim": "subject"
+                    }
+                }
+            ]
+        }
+    }'
+``` 
+
+With that configuration, the providers service is only available for Operators with ```OperatorCredentials``` bound to there individual identity anymore. E.g. only if the claim ```subject``` contains the did that the [presentation was created with](#authenticate-via-oid4vp).
+
+If you now try to get an `ACCESS_TOKEN` with the `USER_CREDENTIAL`, it will fail(since it does not contain the `subject`):
+```shell
+  ./doc/scripts/get_access_token_oid4vp.sh http://mp-data-service.127.0.0.1.nip.io:8080 $USER_CREDENTIAL default
+```
+
+When using the `OPERATOR_CREDENTIAL`, it will work:
+```shell
+  ./doc/scripts/get_access_token_oid4vp.sh http://mp-data-service.127.0.0.1.nip.io:8080 $OPERATOR_CREDENTIAL operator
+```
+
+
+
 ## eIDAS compliancy
 
 In order to provide eIDAS complinacy, the Dataspace Connector supports the usage of the [did:elsi method](https://alastria.github.io/did-method-elsi/).

diff --git a/k3s/consumer.yaml b/k3s/consumer.yaml
@@ -230,6 +230,16 @@ keycloak:
               "supportedCredentialTypes": "UserCredential,OperatorCredential"
             }
           },
+          {
+            "name": "subject-mapper",
+            "protocol": "oid4vc",
+            "protocolMapper": "oid4vc-static-claim-mapper",
+            "config": {
+              "subjectProperty": "subject",
+              "staticValue": "did:key:zDnaeiVpxCT7ARwqLndbWiCeGG2YZXvLfWFs1cGPgKUe8GPLe",
+              "supportedCredentialTypes": "OperatorCredential"
+            }
+          },
           {
             "name": "lastName-mapper",
             "protocol": "oid4vc",

diff --git a/k3s/provider.yaml b/k3s/provider.yaml
@@ -81,6 +81,14 @@ apisix:
           policy: policy/main
           with_body: true
 
+credentials-config-service:
+  ingress:
+    enabled: true
+    hosts:
+      - host: provider-ccs.127.0.0.1.nip.io
+        paths:
+          - "/"
+
 vcverifier:
   ingress:
     enabled: true
@@ -289,4 +297,4 @@ trusted-issuers-list:
       hosts:
         - host: til-provider.127.0.0.1.nip.io
           paths:
-            - /
+            - /