uniqueg · Nov 13, 2026 · Nov 13, 2026 · Nov 13, 2026 · Nov 13, 2026 · Nov 13, 2026
@@ -1,3 +1,4 @@
 {
-  "service-create": "Service Create"
+  "service-create": "Service Create",
+  "service-verification": "Service Verification"
 } 
@@ -0,0 +1,194 @@
+import { Callout, Tabs } from 'nextra/components'
+import ComponentName from '@/components/common/ComponentName'
+
+# EccClientElixirCloudRegistryServiceVerification Component
+
+<ComponentName
+  tagName='ecc-client-elixir-cloud-registry-service-verification'
+  reactTagName='EccClientElixirCloudRegistryServiceVerification'
+  version='2.0.0-alpha.51'
+/>
+
+## Overview
+
+The `ecc-client-elixir-cloud-registry-service-verification` component shows whether a service in the Cloud Registry is verified, i.e. whether an admin of the registry checked it (e.g. that it accepts the tokens of the deployment's identity provider). Verified services get a "Verified" badge; its tooltip says when. For admins, the component also offers "Verify" and "Remove verification".
+
+It uses the verification endpoints of Cloud Registry 0.4.0 and later (see [Verifications](/docs/cloud-registry/providers#verifications)):
+
+- `GET /services/{serviceId}/verification` to load the verification of the service;
+- `PUT /services/{serviceId}/verification` to verify it (admins only);
+- `DELETE /services/{serviceId}/verification` to remove its verification (admins only).
+
+<Callout type='info'>
+  The registry removes a verification when the URL or API type of the service changes. Verified doesn't mean trusted: users decide which services to use.
+</Callout>
+
+## Usage
+
+### One service
+
+The component loads the verification of the service and shows the badge if the service is verified; otherwise it shows nothing. Pass the service with `service`, as the app shows it: the badge then only shows while the verification matches the service's URL and API type, and "Verify" sends them to the registry as the ones that the admin checked, so that a service that has changed meanwhile isn't verified.
+
+<Tabs items={['React', 'HTML']}>
+  <Tabs.Tab>
+    ```tsx showLineNumbers copy filename="service-verification.tsx"
+    import React, { useMemo } from 'react';
+    import { EccClientElixirCloudRegistryServiceVerification } from '@elixir-cloud/cloud-registry/react/service-verification';
+    import { RestCloudRegistryProvider } from '@elixir-cloud/cloud-registry/providers';
+
+    export default function ServiceHeader({ service, me }) {
+      // created once: a new provider makes the component load again
+      const provider = useMemo(
+        () => new RestCloudRegistryProvider('https://cloud-registry.example.com/ga4gh/registry/v1'),
+        []
+      );
+
+      return (
+        <h1>
+          {service.name}{' '}
+          <EccClientElixirCloudRegistryServiceVerification
+            provider={provider}
+            service={service}
+            admin={me.admin}
+            onEccServiceVerificationFailed={(event) => console.error(event.detail.error)}
+          />
+        </h1>
+      );
+    }
+    ```
+  </Tabs.Tab>
+  <Tabs.Tab>
+    ```html showLineNumbers copy filename="service-verification.html"
+    <ecc-client-elixir-cloud-registry-service-verification
+      service-id="org.example.my-tes"
+    ></ecc-client-elixir-cloud-registry-service-verification>
+
+    <script type="module">
+      import '@elixir-cloud/cloud-registry';
+      import { RestCloudRegistryProvider } from '@elixir-cloud/cloud-registry/providers';
+
+      document.querySelector('ecc-client-elixir-cloud-registry-service-verification').provider =
+        new RestCloudRegistryProvider('https://cloud-registry.example.com/ga4gh/registry/v1');
+    </script>
+    ```
+  </Tabs.Tab>
+</Tabs>
+
+### A list of services
+
+For a list, load all verifications with one request (`getVerifications()`), keep those that still match their services (`verifiedServices()`), and pass each row's verification with `verification`: the rows then send no requests of their own. `null` means that the service isn't verified.
+
+```tsx copy
+import { verifiedServices } from '@elixir-cloud/cloud-registry/providers';
+
+const [services, verifications] = await Promise.all([
+  provider.getServices(),
+  provider.getVerifications(),
+]);
+// e.g. in React state, so that the rows follow verify and remove; after
+// reloading the lists, call setVerified(verifiedServices(...)) again
+const [verified, setVerified] = useState(
+  () => verifiedServices(services, verifications)
+);
+// `me` is the response of the registry's GET /me
+
+services.map((service) => (
+  <EccClientElixirCloudRegistryServiceVerification
+    key={service.id}
+    provider={provider}
+    service={service}
+    admin={me.admin}
+    verification={verified.get(service.id) ?? null}
+    onEccServiceVerificationChanged={({ detail }) =>
+      setVerified((current) => {
+        const next = new Map(current);
+        if (detail.verification) {
+          next.set(detail.serviceId, { serviceId: detail.serviceId, ...detail.verification });
+        } else {
+          next.delete(detail.serviceId);
+        }
+        return next;
+      })
+    }
+  />
+));
+```
+
+After a verify or remove, the component shows the result for that service until the app sets `verification` again, also if the provider is replaced meanwhile by one for the same registry (the same base URL, e.g. with a new token); update your verifications from `ecc-service-verification-changed`, as above. Pass a stable value (e.g. the object from the map, not one built on each render): every new value counts as set again.
+
+<Callout type='info'>
+  The services list of the GA4GH Service Registry package (`ecc-client-ga4gh-service-registry-services`) doesn't show verifications itself; place the component in a row's `actions-<id>` slot or in your own list.
+</Callout>
+
+## Properties
+
+| Property       | Type                    | Default     | Description |
+|----------------|-------------------------|-------------|-------------|
+| `baseUrl`      | `string`                | `""`        | Base URL of the Cloud Registry API, if no `provider` is set |
+| `provider`     | `CloudRegistryProvider` | `undefined` | Data provider (see [Providers](/docs/cloud-registry/providers)); takes precedence over `baseUrl` |
+| `serviceId`    | `string`                | `""`        | ID of the service (attribute `service-id`); defaults to the ID of `service` |
+| `service`      | `ExternalService`       | `undefined` | The service as the app shows it: the badge only shows while the verification matches its URL and API type, and "Verify" sends them as checked |
+| `verification` | `Verification \| null`  | `undefined` | The verification if the app has loaded it (`null`: not verified); if `undefined`, the component loads it |
+| `admin`        | `boolean`               | `false`     | Whether to offer "Verify" and "Remove verification" |
+
+### `provider` and `baseUrl`
+The component loads the verification again when `provider`, `baseUrl`, `serviceId` or the ID of `service` changes, also if the app sets them after the first render; if the app passes `verification`, it shows that instead (or the result of a verify or remove since, until the app sets `verification` again). A new object of the same service (e.g. of a reloaded list) needs no new request, unless its URL or API type changed: the registry then removes the verification. In React, create the provider only when its inputs change, e.g. with `useMemo`.
+
+Custom providers implement the optional verification methods of `CloudRegistryProvider`; without them, the component fires `ecc-service-verification-failed`.
+
+### `service`
+Without `service`, the component shows the registry's verification as it is, and "Verify" verifies the service as it is registered at the time of the request. With `service`, a verification of another URL (compared as written) or API type (`type.group` and `type.artifact`, trimmed and case-insensitive, as the registry compares them) doesn't count.
+
+### `admin`
+Apps take the value from `admin` of the registry's `GET /me`. The property only changes what the component offers: the registry checks permissions itself and answers other users with `403`. For admins, unverified services show a "Not verified" badge and a "Verify" button; verified services show "Remove verification".
+
+## Events
+
+| Event Name                         | React Event Name                   | Detail Type | Description |
+|------------------------------------|------------------------------------|-------------|-------------|
+| `ecc-service-verification-changed` | `onEccServiceVerificationChanged`  | `{ serviceId: string, verification: Verification \| null }` | Fired when an admin verified the service or removed its verification |
+| `ecc-service-verification-failed`  | `onEccServiceVerificationFailed`   | `{ serviceId: string, action: "load" \| "verify" \| "remove", error: string, status?: number, title?: string, detail?: string, code?: string, cause?: unknown }` | Fired when loading, verifying or removing the verification fails |
+
+### `ecc-service-verification-changed`
+Emitted after an admin verified the service (`verification`: the new verification) or removed its verification (`null`). A verification that was removed already (`404`) counts as removed. The event is fired whenever the registry has applied the change, also if the component shows another service by then (`serviceId` names the service). Apps that pass `verification` update it from this event, e.g. in their map of verified services.
+
+### `ecc-service-verification-failed`
+Emitted when a request fails. Services that aren't verified (`404` when loading) are no failure.
+
+- `action`: what failed: `load`, `verify` or `remove`;
+- `error`: what went wrong, e.g. the registry's explanation (the problem's `detail`);
+- `status`: the HTTP status, e.g. `403` (not an admin) or `409`;
+- `title`, `detail`: the problem details that the registry sent, if any;
+- `code`: the conflict code of a `409`: `verification-mismatch` if the service has another URL or API type than the one shown (the component then loads the verification again, unless the app passes `verification`), `pending-service` if the service awaits approval. After a failure without a status (e.g. a lost connection) or with a server error, the component also loads the verification again, as the registry may have applied the change;
+- `cause`: the error that the provider threw.
+
+<Tabs items={['React', 'JavaScript']}>
+  <Tabs.Tab>
+    ```tsx copy
+    <EccClientElixirCloudRegistryServiceVerification
+      onEccServiceVerificationFailed={(event) => {
+        if (event.detail.code === 'verification-mismatch') {
+          alert('The service has changed. Reload it and check it again.');
+        } else {
+          alert(event.detail.error);
+        }
+      }}
+    />
+    ```
+  </Tabs.Tab>
+  <Tabs.Tab>
+    ```javascript copy
+    element.addEventListener('ecc-service-verification-failed', (event) => {
+      console.error(event.detail.action, event.detail.status, event.detail.error);
+    });
+    ```
+  </Tabs.Tab>
+</Tabs>
+
+## CSS parts
+
+| Part            | Description |
+|-----------------|-------------|
+| `badge`         | The "Verified" (for admins also "Not verified") badge |
+| `verify-button` | The "Verify" button (admins) |
+| `remove-button` | The "Remove verification" button (admins) |
@@ -20,6 +20,7 @@ The `Cloud Registry` package provides web components for managing and creating s
 ## Available Components
 
 - [`<ecc-client-elixir-cloud-registry-service-create>`](./components/service-create): A component for creating new service registrations.
+- [`<ecc-client-elixir-cloud-registry-service-verification>`](./components/service-verification): A component that shows whether a service is verified, and lets admins verify it or remove its verification.
 - [`<ecc-client-ga4gh-service-registry-services>`](../service-registry/components/services): A component for listing existing service registrations.
 - [`<ecc-client-ga4gh-service-registry-service>`](../service-registry/components/service): A component for displaying details of a specific service.
 

@@ -33,6 +33,12 @@ export interface CloudRegistryProvider extends ServiceRegistryProvider {
 
   // Service info methods (Cloud Registry specific)
   createOrUpdateServiceInfo?(service: ServiceRegister): Promise<void>;
+
+  // Verification methods (Cloud Registry 0.4.0 and later; see Verifications)
+  getVerifications?(): Promise<ServiceVerification[]>;
+  getServiceVerification?(id: string): Promise<Verification>;
+  verifyService?(id: string, verification?: VerificationRegister): Promise<Verification>;
+  deleteServiceVerification?(id: string): Promise<string>;
 }
 ```
 
@@ -155,6 +161,48 @@ Creates or updates the service registry's own service information.
 createOrUpdateServiceInfo?(service: ServiceRegister): Promise<void>
 ```
 
+### Verifications
+
+Cloud Registry 0.4.0 and later let admins verify services, e.g. after checking that they accept the tokens of the deployment's identity provider. The methods are optional in `CloudRegistryProvider`, so that custom providers without them still conform; `RestCloudRegistryProvider` has them all. The [Service Verification component](/docs/cloud-registry/components/service-verification) uses them.
+
+```typescript
+// GET /verifications: the verified services, sorted by ID
+getVerifications?(): Promise<ServiceVerification[]>
+
+// GET /services/{id}/verification: rejects with status 404 if not verified
+getServiceVerification?(id: string): Promise<Verification>
+
+// PUT /services/{id}/verification (admins): with the URL and API type that
+// were checked, rejects with status 409 (problem `code`
+// `verification-mismatch`) if the service no longer has them; without
+// them, verifies the service as registered
+verifyService?(id: string, verification?: VerificationRegister): Promise<Verification>
+
+// DELETE /services/{id}/verification (admins): rejects with status 404 if
+// not verified; resolves to the service ID
+deleteServiceVerification?(id: string): Promise<string>
+```
+
+A verification only counts while the service still has the verified URL (as written) and API type (`type.group` and `type.artifact`, trimmed and case-insensitive; not `type.version`). The registry removes verifications when these change, but a list of services and a list of verifications loaded one after the other may disagree. Two helpers compare them as the registry does:
+
+```typescript
+import {
+  matchesVerification,
+  verifiedServices,
+} from '@elixir-cloud/cloud-registry/providers';
+
+const [services, verifications] = await Promise.all([
+  provider.getServices(),
+  provider.getVerifications(),
+]);
+
+// Map of service ID to verification, for the services that are verified
+const verified = verifiedServices(services, verifications);
+
+// Whether one verification still matches a service (or form values)
+matchesVerification(service, verification);
+```
+
 ## Errors
 
 If the registry answers with an error status, the methods of `RestCloudRegistryProvider` reject with a `CloudRegistryError`. It extends `Error` and carries the status and the [problem details](https://www.rfc-editor.org/rfc/rfc9457) that the registry sends:
@@ -166,6 +214,7 @@ If the registry answers with an error status, the methods of `RestCloudRegistryP
 | `title`     | `string \| undefined`         | Short summary of the problem type, e.g. "Conflict"                          |
 | `detail`    | `string \| undefined`         | Explanation of this occurrence, e.g. which field is invalid                 |
 | `serviceId` | `string \| undefined`         | ID of the existing service, for duplicate registrations (`409`)             |
+| `code`      | `string \| undefined`         | Why a request conflicts (`409`), e.g. `verification-mismatch`; treat unknown codes as a general conflict |
 | `problem`   | `ProblemDetails \| undefined` | The whole response body, if it was a JSON object                            |
 
 ```typescript
@@ -257,6 +306,28 @@ interface RegistrationRules {
 }
 ```
 
+### Verification, ServiceVerification and VerificationRegister
+
+```typescript
+// GET and PUT /services/{id}/verification
+interface Verification {
+  url: string; // URL of the verified service, as registered
+  type: ServiceType; // API type of the verified service
+  verifiedAt: string; // when an admin verified it (RFC 3339, UTC)
+}
+
+// GET /verifications
+interface ServiceVerification extends Verification {
+  serviceId: string;
+}
+
+// Body of PUT /services/{id}/verification: what the admin checked
+interface VerificationRegister {
+  url: string; // exactly as registered
+  type: ServiceTypeRegister; // `version` isn't compared
+}
+```
+
 ## Using with Components
 
 ### Service Creation

@@ -1 +1,2 @@
 import "./service-create/index.js";
+import "./service-verification/index.js";
@@ -0,0 +1,15 @@
+import ECCClientElixirCloudRegistryServiceVerification from "./service-verification.js";
+
+export * from "./service-verification.js";
+export default ECCClientElixirCloudRegistryServiceVerification;
+
+window.customElements.define(
+  "ecc-client-elixir-cloud-registry-service-verification",
+  ECCClientElixirCloudRegistryServiceVerification
+);
+
+declare global {
+  interface HTMLElementTagNameMap {
+    "ecc-client-elixir-cloud-registry-service-verification": ECCClientElixirCloudRegistryServiceVerification;
+  }
+}
Original file line number	Diff line number	Diff line change
		@@ -1 +1,2 @@
		import "./service-create/index.js";
		import "./service-verification/index.js";