XMPP authenticates connected entities with SASL. Presence subscriptions provide a first authorization boundary: an approved contact learns the full JID needed for direct
iq request/response. This is useful but insufficient—every receiver must still authorize the stanza sender and requested operation.
Distributed identity tokens
Provisioning tokens let a request carry user, service, or device identity across intermediaries.
Token issuance uses two exchanges:
- The client sends
<getToken>with the Base64 public certificate. - The issuer validates it and returns
<getTokenChallenge seqnr="…">containing an OAEP-encrypted random challenge. - The client decrypts it with the private key and sends
<getTokenChallengeResponse>with the same sequence number. - The issuer returns
<getTokenResponse token="issuer:random-value">.
Validate a token
The first time a receiver sees a token from a sender:- Parse the provisioning-service address from the token.
- Send
<getCertificate token="…">to that service and obtain the public certificate. - Encrypt a fresh random value to the certificate and send
<tokenChallenge token="…">to the request origin. - Intermediaries forward the challenge to the original actor.
- Accept the identity only when
<tokenChallengeResponse>decrypts to the original value.
Authorization order
- Authenticate the XMPP connection and preserve the sender’s full JID.
- Validate any supplied identity tokens; absence is distinct from invalidity.
- Resolve the owner/provisioning policy.
- Authorize the operation, target node, fields/parameters, time range, and requested privileges.
- Fail closed when policy or decision support is unavailable.