Service Auth token spec?

[DavidBuchanan314]

Is the token structure specified anywhere?

Can they have scopes, beyond lxm?

What privileges is a PDS expected to grant to inbound service tokens?

Is a PDS expected/required to accept inbound service tokens that it did not issue itself? (signed by repo key)

In my PDS implementation of com.atproto.server.getServiceAuth I'd like to make sure I don't accidentally allow for privilege escalation, and this is challenging without a precise spec. (since I don't control both sides of token issuance/acceptance, in the general case)

[bnewbold]

They are a bit under-specified at the moment; the https://atproto.com/specs/xrpc spec is the best reference. We have some design work on "auth scopes", which will be related, and will try to get some of that shared publicly soon.

Service Auth JWTs must have an endpoint NSID (lxm), iss (the DID of the requesting account), aud (the service DID, optionally with a service fragment, of the recipient), and the timestamp fields. They should have a nonce and should be unique and single-use (not well-defined yet w/r/t errors and retries).

Scopes: we don't have any firm plans to support generic scopes. Client auth sessions (eg, OAuth sessions) will have Auth Scopes, which determine which kinds of Serivce Auth JWTs may be generated, but these aren't UCANs or Macaroons (for now).

I think PDS instances should not accept service auth from any other service for now. The scope is currently pretty limited... unless i'm forgetting something, I think some account/identity endpoints and uploadBlob (for video) are the only current uses for the PDS to accept a service auth token. @devinivy any thoughts on what PDS implementations should allow (or not) for now?

Agree that limiting com.atproto.server.getServiceAuth, while also ensuring interop with apps/clients/services is difficult right now. A vague principle is to not allow generation of any token which the current client session would not be able to call or proxy onwards; and to set relatively short/tight token limits; and to prevent re-use by tracking the nonce.