Tenant Dashboard

Interfaz de operador tenant

Use dashboard.attesto.eu para operaciones orientadas al tenant. Esta página cubre solo workflows externos de tenant.

Identidad y acceso

Los usuarios tenant inician sesión con el flujo email-first del dashboard. La primera pantalla pide solo el correo; después Attesto enruta al usuario al camino configurado de contraseña, community identity, invite, signup o SSO de organización. Los tenant owners configuran Entra ID, OIDC genérico y SAML en Settings → Identity Providers.

Use tenant roles para acceso al dashboard: owner, admin, developer y user.
Las cuentas marketplace developer son solo para el marketplace; no conceden acceso al dashboard.
Use auditor invites para acceso al audit portal; los auditores no reciben privilegios tenant operator.
Revise Tenant SSO antes de forzar SSO de organización para un dominio.

Systems y keys

Cree un system por servicio de producción o entorno aislado.
Copie la system key generada cuando se muestre y guárdela server-side.
Rote keys cuando un system cambie de ownership, hosting boundary o deployment trust.
Desactive systems sin uso en lugar de reutilizar sus keys para servicios no relacionados.

Vistas Proofstream

Las páginas de stream muestran event sequence, receipt state, window y checkpoint state, witness/quorum status, anchor status, fork evidence y verifier bundle readiness.

Un receipt prueba que Attesto aceptó un event específico en una stream head específica.
Un checkpoint resume una range cerrada y enlaza con consistency evidence.
Fork evidence requiere investigación inmediata antes de confiar en esa stream history.
La exportación de bundle solo está disponible cuando se cumplen los policy requirements.

Webhooks y conectores

Los webhooks notifican a sus sistemas cuando cambia la evidence de Attesto. Los conectores escriben observaciones de sistemas fuente en Proofstream. Use el dashboard para crear y revocar tenant webhooks, signed webhook connectors, repository webhook connectors, S3/R2 object commitments e instalaciones Local Vault. Guarde cada secret devuelto server-side; el dashboard no lo vuelve a mostrar.

Las webhook subscriptions entregan notificaciones firmadas; los receptores deben verificar la raw-body signature.
Los signed webhook connectors ingieren custom source events mediante una signed envelope específica del conector.
Los repository connectors verifican las firmas de entrega GitHub/GitLab antes de escribir evidence normalizada.
Los S3/R2 object commitments registran metadatos e integridad sin hacer proxy de object bytes.
Local Vault reenvía customer-edge events outbound y puede actuar como customer-side witness cuando la policy lo habilita.

Evidence exports

Los exports son evidence artifacts immutable para el tenant scope y la date range seleccionados. Comparta bundles exportados con auditores o counterparties solo después de confirmar la range, la policy y los retention requirements.

La generación de Truth Package, su download/access y la verificación criptográfica correcta también son lifecycle evidence. La generación del paquete registra truth_package.generated, el download o auditor access registra truth_package.accessed, y un verifier report validado por backend registra truth_package.verified.

Entrega al audit portal

audit.attesto.eu es el portal read-only para auditores externos invitados por un tenant. Los auditores se autentican con el flujo audit, inspeccionan solo los tenant scopes concedidos, descargan exports aprobados y revisan events, receipts, checkpoints y bundle evidence sin convertirse en tenant operators.

El login audit está separado deliberadamente de la identidad del dashboard y del marketplace. Un auditor introduce su e-mail, recibe un magic link de un solo uso cuando la dirección pertenece a un auditor invitado o activo, y después completa TOTP con una authenticator app. El enlace es válido durante 15 minutos; los auditores first-time pasan primero por TOTP enrollment. La respuesta request-link siempre es genérica para impedir la enumeración de e-mails de auditores.

La landing page del auditor muestra solo tenant grants activos con el scope aprobado, fecha de expiración, event count de 30 días e indicador del último anchor. Desde ahí la tenant view sigue siendo read-only: grants expirados o revocados se rechazan antes de cargar events, exports, Proofstream bundles, forks o IVC epochs. Las audit sessions no inician sesión del auditor en el dashboard, marketplace ni en ninguna superficie interna del staff de Attesto.

Acción audit portal	Qué se registra	Por qué importa
Abrir dashboard	`auditor.view.dashboard` por tenant dentro del scope.	El tenant puede ver que el auditor abrió la landing page audit.
Abrir tenant audit view	Read-only access check contra un auditor grant activo y no expirado.	Grants expirados o revocados fallan cerrados.
Ver event/export/bundle data	Tenant audit entries como views de event, export, bundle y Proofstream bundle.	La actividad de review se convierte en evidence visible para el tenant.
Descargar export aprobado	`truth_package.accessed` con contexto auditor y package hash.	El acceso al export se vuelve parte del lifecycle Proof of Evolution.
Verificar Proofstream bundle o IVC epoch	`auditor.verify.proofstream_bundle` o `auditor.verify.proofstream_ivc_epoch` con verifier result y problems.	Los auditores distinguen evidence verificada de evidence fallida o incompleta.

Cree auditor access desde el dashboard solo para el scope y periodo necesarios.
Revoque auditor access cuando la review termine o el reviewer cambie de rol.
Cada acceso significativo a export se registra como lifecycle evidence.
Los auditores deben verificar bundles localmente antes de apoyarse en ellos en un archivo de assurance.

Verify portal y API verifier pública

verify.attesto.eu es el origen público de verificación y API. Úselo para llamadas SDK server-side, POST /v1/public/verify, POST /v2/verify, health checks y el endpoint público de signing key. No es una UI de settings tenant y no requiere una sesión del dashboard tenant para verificar proof objects públicos.

Use verificación online cuando un sistema receptor pueda llamar a la API verifier pública.
Use verificación offline cuando un reviewer deba verificar un bundle sin acceso backend.
Fije las witness keys o signing keys esperadas según la trust policy del verifier.
Trate un verifier report fallido como evidence que debe investigarse, no como una advertencia de UI.

Billing

Billing settings muestra el tenant plan activo, los caminos self-service Starter/Growth/Realtime subscription y el Stripe billing portal. En un nuevo tenant signup, el owner elige un self-service tier. Stripe Checkout inicia la trial tenant configurada de 30 días, y el webhook Stripe verificado activa el plan elegido. Enterprise sigue siendo sales-negotiated.