Invite people and grant application access

A person needs an enrolled central account, Institution membership and separately approved application access. Commissioning an application does not create its users.

Invite someone who needs a new account

1. An approved Sponsor opens the Institution’s New account enrollment page.
2. Choose Propose a new account and enter the person’s delivery email and an audit reason. The email receives setup instructions; it is not their permanent identity key.
3. A different current Institution administrator opens the exact request, reviews it and approves it with recent strong authentication.
4. Wait for invitation delivery. Approval queues account setup; it does not prove that email arrived or credentials were completed.
5. The person opens the issuer’s Set up your account link and completes the credential ceremony offered there. The configured engine may require a passkey or offer password plus an authenticator code.
6. Confirm credential completion and activation before asking the person to sign in to an application.

The owned-engine page is /institutions/{institution_id}/admission. Its proposals use the existing auth-engine-enrollments API. The legacy provider’s /enrollment page is a separate migration workflow.

There is no public unrestricted sign-up or password-only admission. Creating a browser account does not bypass sponsorship or activation.

Invite someone who already has a central account

Open Organizations → your Institution → Invitations → Invite a member. The delivered link asks the person to sign in with their existing central identity and redeem the Institution invitation.

This membership invitation does not create a password or grant application permissions. For a person without a central account, use new account enrollment first.

Give the person access to a project

1. The person opens Account → Applications → Request access, chooses their current Institution and submits an audit reason in the modal.
2. A different Sponsor opens Organization → Application access and endorses the request.
3. A different authorized Institution administrator reviews and approves it.
4. Where required, review the exact application access version and grant event in the same workspace. Historical or direct grants do not gain review authority automatically.
5. Confirm current issuer assignment and product acknowledgement before claiming sign-in works. Queued, approved or pending records alone do not prove effective access.

Application-local roles are managed by that application. An Institution invitation cannot silently assign an application’s administrator role.

Commission the application first

An authorized project approver uses Administration → Applications → Register project. A different reviewer approves the project. The owner then opens its commissioning and lifecycle page to propose the permission catalog and exact client policy for independent review.

The owner uses Create custody intent to record the exact client, version and configured runtime. Complete secret delivery through the private custody path within 120 seconds. This dashboard never receives the secret. After a different approver reviews the prepared policy, Queue reviewed installation submits that exact policy.

The issuer registration, credential custody, current authority and product lifecycle acknowledgement must succeed before the application’s sign-in is ready. See create a project and register a client.

Passwords and sign-in

When password setup is enabled, the person chooses their password during the issuer’s reviewed setup ceremony and enrolls TOTP. Sign-in then uses the username and password followed by the authenticator code. A configured passkey can provide another permitted sign-in method.

If the setup ceremony requires a passkey, follow that policy. Institution and project administrators do not choose a password for the person or convert a passkey admission into password-only registration. Password or factor recovery requires the supported reviewed recovery flow.