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/other_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.