Invitations and Xiaobei OAuth

Organization administrators invite users by email. Invitations are stored by normalized email, expire after seven days, and may optionally include a Team assignment.

Current invitation flow

1. An organization admin opens Members or a Team's member dialog.
2. The admin enters an email and selects organization role admin or member.
3. Weaver records a pending invitation. A Team invitation requests organization membership and Team membership together.
4. The recipient signs in through Xiaobei OAuth using the same verified email.
5. Weaver accepts all matching pending invitations transactionally and adds the requested memberships.

An existing organization member can be added directly to a Team by email. A user who is not yet in the organization must be invited first (or through the Team invitation flow).

Verified identity requirement

An email string alone is not identity proof. Before accepting invitations, Weaver requires:

• an active Xiaobei provider session;
• a stable provider subject (identity.id for the Xiaobei/Ory whoami contract, or sub for OIDC userinfo);
• a syntactically valid email; and
• provider-owned verification evidence for that same email.

Accepted evidence is either a matching Ory identity.verifiable_addresses[] entry with verified: true, or matching OIDC email and email_verified: true claims. A user with an unverified email may sign in, but Weaver does not consume their email invitation.

Email delivery status

Email delivery is not configured in the current deployment. Creating an invitation returns and displays delivery_status: not_configured; it does not claim that a message was sent. The invited user joins automatically after signing in with the matching verified email, but the administrator must share the Console address through another channel.

The stored invitation token is hashed and is not exposed by the public API. Adding a mail provider later must preserve verified-provider identity matching; clicking an email link alone must not bypass Xiaobei authentication.

Permission and safety rules

• Only organization admins can list members/invitations or create and manage them.
• Public member and Team-member responses use email, role, and timestamps, not internal user IDs.
• The final organization admin cannot be removed or demoted.
• Accepting an invitation and adding optional Team membership occurs in one transaction.
• Invitation creation and acceptance are control-plane audited without storing token or credential material.