Service search
You can find participants of a use case via their registered services. A use case defines the service identifier and which credentials are required through the presentation definition. Any constraint in the presentation definition with an identifier can also be used in the search query.
GET /internal/discovery/v1/coffeecorner?organization_name=Care*
Matching is case-insensitive and an *
can be used as wildcard. (Similar to the SQL LIKE %
)
Some valid examples for query parameters:
-
credentialSubject.givenName=John
-
credentialSubject.organization.city=Town
-
credentialSubject.organization.name=Hospital*
-
credentialSubject.organization.name=*clinic
-
issuer=did:web:example.com
See API
Result:
[
{
"id":"did:web:example.com:iam:657f064a-ebef-4f0f-aa87-88ed32db3142#049fb56e-1ba8-4e9e-a7af-0071342a1378",
"credential_subject_id":"did:web:example.com:iam:657f064a-ebef-4f0f-aa87-88ed32db3142",
"vp":...
"fields": {
"organization_name":"Care Bears"
},
"registrationParameters": {
"authServerURL":"https://example.com/oauth2/my_subject_identifier",
"fhir": "https://api.example.com/fhir",
"contact": "alice@example.com"
}
}
]
As you can see in the search results:
-
organization_name
has been added because of the constraint mapping from the presentation definition. -
registrationParameters
from the service activation are included. -
authServerURL
has been added autmatically. You need this for the access token request.