You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
### Using a Verifiable Credentials within a Data Space
580
+
581
+
Now that Alice has been given a Verifiable credential, she can use it to claim the role of Operator within the Data Space and gain Access to the Vetenary Records. A First attempt to access the records without holding a token results in an error, indicating that the verifier is present on port `1030`
580
582
581
-
#### ### Verifying a Verifiable Credential
583
+
#### Accessing the Vetenary Records without a Veriable Credential
The response is a **401 - Unauthorized** error code with the following response
593
595
596
+
```json
597
+
{
598
+
"type": "urn:dx:as:MissingAuthenticationToken",
599
+
"title": "Unauthorized",
600
+
"detail": "message"
601
+
}
594
602
```
595
603
596
-
#### Response:
597
604
605
+
### Accessing the Vetenary Records with an invalid Veriable Credential
598
606
599
-
### Verifying a Verifiable Credential
607
+
The Verifiable Credential is added as a Bearer token to the Authorization header. The bearer token is a JWT which is then decoded and verified - if the content of the Bearer token does not match the claimed issuer, then the token is rejected.
"detail": "invalid_signature: no matching public key found"
627
+
}
628
+
```
629
+
630
+
In the case of a rejected credentila The response is a **401 - Unauthorized** error code with the following response.
609
631
610
-
### Verifying a Verifiable Credential
632
+
Note that a real Credential Verifier would not only check that all the claimed issuers of credentials had really signed each verifiable credential, but also ensure that the `exp` and `nbf` are also in range.
633
+
634
+
### Accessing the Vetenary Records with a valid Veriable Credential
635
+
636
+
With a proper Verifiable Presentation, the **Animal** records can be accessed:
The response contains a series of **Animal** records, however checking the output within the
675
+
[Verifiable Presentation Monitor](http://localhost:3000/vp/monitor) at `http://localhost:3000/vp/monitor`, you will find the
676
+
following output:
620
677
621
-
### Verifying a Verifiable Credential
678
+
```
679
+
OperatorCredential issued by did:web:fiware.github.io:tutorials.Step-by-Step:animal-welfare was NOT TRUSTED
680
+
```
681
+
682
+
This is because a further check is required. Not only must the Verifiable Credential be signed by the issuer, but the issuer must be a valid issuer of credentials within the data space. The way that a verifier checks this, is that it must contact a trusted issuers list. The location of this list is defined within the configuration service associated to the Verifiable Credentials verifier.
683
+
684
+
### Checking for trusted issuers
685
+
686
+
The configuration service is running on port 8081, a listing of valid issuers for the vet can be found by making a service request.
622
687
623
688
#### 8️⃣ Request:
624
689
625
690
```console
626
-
691
+
curl -L 'localhost:8081/service/vet'
627
692
```
628
693
629
694
#### Response:
630
695
696
+
```json
697
+
{
698
+
"id": "vet",
699
+
"defaultOidcScope": "default",
700
+
"oidcScopes": {
701
+
"default": [
702
+
{
703
+
"type": "VerifiableCredential",
704
+
"trustedParticipantsLists": [],
705
+
"trustedIssuersLists": [
706
+
"http://trusted-issuers-list:8080"
707
+
],
708
+
"holderVerification": {
709
+
"enabled": false,
710
+
"claim": "subject"
711
+
}
712
+
}
713
+
]
714
+
}
715
+
}
716
+
```
717
+
718
+
The response indicates that VerifiableCredentials can be checked against the trusted issuers list found at `http://trusted-issuers-list:8080`
0 commit comments