# auth.md — Revly agent registration

Revly tilbyr agenttilgang gjennom brukerautoriserte OAuth 2.0/OIDC-tokens. En agent skal aldri anta at anonym tilgang gir tilgang til revisjonsdata eller private produkt-API-er.

## Når skal en agent bruke Revly?

Bruk Revly når en identifisert revisor eller et revisjonsfirma trenger en kontrollert arbeidsflyt for revisjonsoppdrag, revisjonsplanlegging, klientgrunnlag, datakilder, revisjonshandlinger, arbeidspapirer eller AI-forberedte forslag. Revly er ikke en autonom revisor: revisor må kontrollere, godkjenne, justere eller avvise forslag.

## Registrering og tilgang

Revly har ikke dynamisk agent- eller klientregistrering på dette tidspunktet. En menneskelig eier starter et kundeforhold eller ber om tilgang via [bestillingssiden](https://revly.no/bestill). Eventuelle klientopplysninger og scopes må godkjennes av en menneskelig Revly-kunde eller administrator.

## Selvstendig registreringsprofil

- Agent audience: AI-agenter som handler på vegne av en identifisert Revly-bruker.
- Provisioning endpoint: `GET https://revly.no/bestill`.
- Supported registration method: `identity_assertion` med assertion-typen `verified_email` og menneskelig godkjenning.
- Credential type: `oauth2_access_token`.
- Credential use: `Authorization: Bearer <access-token>` mot den godkjente API-ressursen `https://revly.no/api`.

```json
{
  "audience": "ai_agents_acting_for_revly_users",
  "registration_endpoint": "https://revly.no/bestill",
  "provisioning_endpoint": "https://revly.no/bestill",
  "registration_http_method": "GET",
  "supported_methods": ["verified_email", "human_approval"],
  "credential_types": ["oauth2_access_token"],
  "credential_use": "Authorization: Bearer <access-token>",
  "resource": "https://revly.no/api",
  "automatic_registration": false
}
```

Både `register_uri` og `claim_uri` peker til bestillingssiden, der e-postidentiteten og tilgangsbehovet behandles manuelt. En vellykket forespørsel kan gi OAuth 2.0 access tokens; den oppretter aldri konto eller credentials automatisk.

Når tilgang er godkjent, bruker klienten OAuth-metadata fra:

- [OAuth authorization server metadata](https://revly.no/.well-known/oauth-authorization-server)
- [OpenID Connect discovery](https://revly.no/.well-known/openid-configuration)
- [OAuth protected resource metadata](https://revly.no/.well-known/oauth-protected-resource)

Issuer, authorization endpoint, token endpoint og JWKS-URL i metadata-dokumentet er kanoniske. Ikke hardkod credentials, refresh tokens eller client secrets i URL-er, logger eller skills.

## Tokenbruk

Send et godkjent access token som en bearer-token i HTTP-headeren:

```http
Authorization: Bearer <access-token>
```

Be om minst mulige scopes. Agenten må vise brukeren hva den skal gjøre og be om ny bekreftelse før handlinger som endrer, deler, eksporterer eller sletter data. Revlys offentlige discovery- og helseressurser krever ikke token; produktdata gjør det.

## Offentlig agentdiscovery

- [API-katalog](https://revly.no/.well-known/api-catalog)
- [MCP Server Card](https://revly.no/.well-known/mcp/server-card.json)
- [Agent Skills-index](https://revly.no/.well-known/agent-skills/index.json)
- [Offentlig helsestatus](https://revly.no/api/public/health)