Ідентичність партнера та повні користувацькі сценарії

AGNT2-532: Безкоштовно. Оплату поки не підключено. Для створення, активації та підключення організації не потрібні договір, договірний ліміт, картка або адреси повернення. Використання не створює заборгованості чи майбутніх платіжних зобов’язань. Технічні ліміти, затверджені політики, права операторів і явна активація платформою зберігаються. Майбутня оплата підключається окремо та явно; безкоштовний період не оплачується заднім числом.

Історичний проєкт

Ця сторінка фіксує попередній проєкт, а не поточний стан випуску. Підготовка ресурсів, scoped authorization і trusted MCP уже реалізовані в комітах Agentfy; див. контракт серверного чату та межі доказів. Браузерні/BONSITE протоколи й ширші пропозиції щодо оплати/життєвого циклу зберігають власні умови випуску. Бойовий запуск партнера не мається на увазі.

1. Пряма реєстрація

На екрані Створити акаунт Agentfy людина підтверджує прямий email/спосіб входу та обирає credentials. Підтвердження: «Створити мою команду; я відповідаю за її оплату». Безплатний тариф не дозволяє списань: платна робота потребує чинного мандата та бюджету. Однією транзакцією фіксуються direct user, команда Agentfy, членство власника, початкове призначення відповідального платника й операція підготовки. Далі Готуємо асистента, Відкрити команду або Не вдалося підготувати — повторити. Повтор продовжує ту саму операцію, не створює команду чи платіж удруге.

Це не credential-only сценарій розділу 5. Наявний акаунт входить незалежно; збіг email із записом без пароля не дозволяє його привласнити. Старі invitation stubs потребують підтвердженого прийняття та міграції. Партнерські потоки не використовують поточний email-stub claim чи механізм засновника платформи.

2. Підключення організації та ключі

Безкоштовно. Оплату поки не підключено. Для створення, активації та підключення організації не потрібні договір, договірний ліміт, картка або адреси повернення. Використання не створює заборгованості чи майбутніх платіжних зобов’язань. Технічні ліміти, затверджені політики, права операторів і явна активація платформою зберігаються. Майбутня оплата підключається окремо та явно; безкоштовний період не оплачується заднім числом.

Інтеграція → Серверні ключі показує scope, середовище, строк і останнє використання. Створити provisioning-ключ показує секрет один раз, зберігається лише хеш. Секрет залишається на сервері BONSITE. Browser authorization має окремий identity-issuer credential, привілейоване підтвердження та аудит. Розробник ротує делегований provisioning-ключ, але не додає scope входу. Зберігаються issuer, createdAt, expiresAt, revokedAt, версія; видалення не замінює відкликання.

Рекомендації: ключ на 90 днів, планове перекриття ротації до 24 годин, аварійне відкликання без перекриття. Новий ключ повторює операції в тій самій області організації. Відкликання issuer key відкликає похідні сесії; ротація provisioning не видаляє користувачів і не зачіпає незалежні прямі сесії. Призупинена/закрита організація не видає та не використовує партнерські контексти.

Кожен code, proof, link і похідна сесія містять issuer credential та org auth epoch. Відкликаний ключ не завершує початий code/link flow. Компрометація issuer підвищує epoch та карантинить links/proofs за підозрілий інтервал; відновлення — нові незалежні докази або аудитований recovery. Звичайна ротація не стирає законні зв’язки, власність та історію.

3. Реєстрація BONSITE і bootstrap команди

BONSITE автентифікує людину та визначає opaque externalUserId із серверної сесії. Команду можна підготувати до першого візиту за відомим серверу стабільним subject. ID із браузера не є доказом; фіктивний email і спільний власник заборонені.

BONSITE надсилає зовнішній ID команди й визначеного творця. Agentfy атомарно визначає/створює actor, team, owner membership, payer assignment та durable operation. Типово платить організація. Team-paid потребує заздалегідь прийнятого прямим платником consent для цієї команди або free/pending-billing команди: намір відповідальності творця записаний, платна робота заборонена до незалежної згоди. Ключ не приймає особистий борг. Організація команди після згоди не змінюється.

Клієнт бачить Готуємо асистента, Відкрити асистента, Підготовку перервано — повторити з безпечним номером звернення. Наявний subject може створити нову команду. Повтор вихідного bootstrap повертає операцію/поточну готовність, не відновлює видаленого творця і не змінює owner/payer. Інші початкові факти з тим самим external ID дають конфлікт; зміни — окремі дозволені дії. Чужий/невідповідний ресурс: «Команда недоступна», без розкриття іншого клієнта.

4. Відкрити в Agentfy: browser-авторизація

Відкрити в Agentfy починає транзакцію на origin Agentfy; посилання BONSITE — точка входу, не твердження особи. Перевага перевіреному OAuth authorization-code/OIDC, якщо партнер підтримує його. Альтернатива нижче не є заявою про відповідність OIDC.

1. Agentfy створює транзакцію login, link або invite, випадкові state/nonce, PKCE S256 challenge/verifier для code exchange та Secure/HttpOnly cookie browser binding. Сервер зберігає хеш транзакції, точний redirect, org/environment, ресурс і строк. Без відповідної транзакції вхід неможливий.
2. Redirect лише на зареєстрований authorization endpoint BONSITE. Партнер перевіряє людину/workspace і показує «Продовжити в Agentfy як [акаунт BONSITE]?». Identity backend доводить subject через автентифікований backchannel, прив’язаний до transaction ID, nonce, purpose, audience, environment, expiry. Provisioning-ключ відхиляється. Перший proof фіксує subject/purpose; інший subject у повторі — відмова. Одна транзакція має не більш як один redeemable code/session result, зокрема після повтору callback.
3. Agentfy генерує одноразовий code, зберігає хеш і binding до proof/transaction. Бажаний POST на зареєстрований callback. Access/refresh bearer не потрапляє до URL, логів чи browser storage. Якщо code передається query, його вилучають із логів/referrer, ставлять Referrer-Policy: no-referrer, негайно очищують URL; callback не завантажує сторонні ресурси.
4. Перевіряються binding/state/nonce/proof/redirect/PKCE. Одна транзакція переводить unused/unexpired code у consumed, повторно перевіряє subject/org/membership і створює restricted session. У гонці один переможець; помилки не створюють сесій.
5. Екран називає org/team і Продовжити в контексті BONSITE. Інший уже відкритий direct account не замінюється і не зв’язується автоматично: Окремий контекст партнера, Обрати інший акаунт, Скасувати. Link потребує двох свіжих proof і окремого підтвердження розділу 5.

Кожна вкладка має окремі transaction/context handle; перемикання однієї не змінює повноваження іншої. Мутації зв’язані з явним серверним контекстом, перевіряють Origin/CSRF; застаріла форма: «Контекст змінився; оновіть сторінку перед збереженням». Cancel/expiry анулює transaction; повтор починає нову. Витік code/invite URL чи нав’язане attacker login посилання не замінює browser binding і свіжу автентифікацію.

Рекомендовані строки: transaction 5 хвилин, code 60 секунд, proof не старше 5 хвилин для link/unlink/owner/payer/credential changes; partner access 5 хвилин, server-managed rotating refresh family, idle 30 хвилин, absolute 12 годин. Direct і partner families окремі. Це проєктні значення, не виміряні гарантії.

Cookie — Secure/HttpOnly і найсуворіший сумісний SameSite (типово Lax; cross-site POST потребує окремого CSRF-безпечного рішення). Bearer не зберігається в local/session storage. Перевіряються issuer/audience/type/algorithm/time/source/family/authorization versions. Direct user, partner, runtime worker, guest embed — різні токени; refresh/exchange не розширює source/scope. Звичайні user routes не приймають partner principal без явної підтримки обмежень.

5. Додати прямий вхід або зв’язати наявний акаунт

Акаунт → Під’єднати вхід Agentfy: Створити прямий вхід, Використати мій акаунт. Пояснення: «Це під’єднає доступ до команди BONSITE. Команда, власник і платник не зміняться; BONSITE не отримає доступу до інших ваших команд». Показуємо org і впізнавану мітку partner context без вимоги особистих даних від BONSITE.

Нові credentials збираються/перевіряються в Agentfy поза partner API. Створюється direct actor без нової команди/консьєржа, потім link. Наявний акаунт потребує свіжого незалежного direct proof і свіжого BONSITE proof; старого cookie, однакового email або partner key недостатньо. Зайнятий email вимагає входу/recovery відповідного акаунта, не дубля чи непомітного claim.

Зв’язати [direct account] із [BONSITE context] показує direct account лише незалежно автентифікованому браузеру. Commit перевіряє обидва proofs, active subject/org, policy та відсутність іншого active link. Subject/link lock і unique active-subject constraint вирішують гонку. Повтор того самого підтвердження повертає результат. Інший уже пов’язаний акаунт: «Уже під’єднано; від’єднайте або відновіть попередній зв’язок», без розкриття direct account партнеру. Партнер не переприв’язує самостійно.

Локальні credentials + перший link атомарні. Якщо зовнішній credential provider устиг створити вхід, але link commit не вдався, лишається незалежно доступний порожній direct account і явний конфлікт; без компенсаційної команди та видалення наявних credentials. Прострочені proofs потребують нового підтвердження. Членство/owner/agent ID/debt/ledger не змінюються.

6. Перемикання контекстів та від’єднання

Після direct login Команди розділяють Мої команди Agentfy та названі partner contexts. Вибір BONSITE перевіряє active link, subject, org policy, team, membership. Effective actor — partner User, direct account — authenticator; права не додаються. Повернення до direct використовує незалежну direct session. Partner-origin login не отримує цього шляху без окремого direct proof та не перелічує його команди/зв’язки.

Рекомендовані allowNewLinks і allowLinkedLogin: перший вимкнений забороняє нові зв’язки, зберігаючи старий доступ; другий відкликає всі link-derived contexts, зберігаючи записи для явного ввімкнення. Subject deprovision блокує linked access незалежно від direct account. Увімкнення не відновлює revoked memberships/families.

Від’єднати BONSITE вимагає свіжого незалежного direct login: «Команда й рахунки BONSITE залишаться. Для входу використовуйте BONSITE». Відкликаються link, його pending transactions, похідні contexts/refresh families. Окремі BONSITE-origin sessions можуть працювати, доки subject активний. Інші direct sessions, owner/debt не змінюються. Relink потребує двох нових proofs; старі codes/refresh не оживають. Partner revocation закриває його доступ, але не змінює прямі credentials.

Останній direct login method не видаляється до іншого перевіреного способу або явного account deletion. Видалення direct account відкликає його sessions/links, зберігає partner actors/teams. Власні direct-team ownership і борги потребують transfer/retention, не cascade delete. Direct recovery — через незалежний Agentfy channel, ніколи partner key. Втрата BONSITE не обходиться через link. Support recovery — окремо дозволена перевірка особи з аудитом; без доказу доступ закритий.

7. Запрошення та передача власності

Команда → Учасники → Запросити обирає role/допустимий actor: у BONSITE customer teams лише його external subjects, у Agentfy — direct actors. Partner owner не запрошує власний direct account для обходу revocation. Partner invite адресовано namespace + subject; direct invite — verified account або one-use invitation після independent login. Email — доставка, не право привласнити subject.

Запис містить team/target/role/inviter/version/expiry (типово 7 днів)/consumed. Екран org/team/role: Прийняти / Відхилити, без chats/secrets. Acceptance повторно перевіряє inviter authority, target proof, team/policy. Пересилання URL/email collision не змінює target. Redemption + membership атомарні/ідемпотентні; expired/revoked: Запросіть нове запрошення.

Team admin не призначає owners. Owner пропонує підвищення/transfer активному учаснику. Передати власність називає recipient, агентів і майбутню роль відправника. Recipient приймає зі свіжим proof і відповідним контекстом: direct для Agentfy, external actor BONSITE для його команди. Team lock/version: спочатку новий owner, потім demotion ініціатора. Інші owners залишаються; cancel/decline/expiry не змінюють ролей. Оплата не передається.

Робочій команді потрібен мінімум один active owner. Добровільне видалення/demotion останнього блокується транзакційно, включно з гонками. Перед видаленням/deactivation actor перевіряємо Agent(ownerId, teamId): явно передаємо агентів придатному active member із підтвердженням або зупиняємо та зберігаємо inactive membership tombstone. Без orphan schedules і випадкового auto-owner. Передача агента не відкриває приватних user-scoped secrets; залежні grants відкликаються/переналаштовуються перед resume.

8. Призупинення, видалення та відновлення

Security revocation важливіший за last-owner guard. Якщо відкликано останнього external owner, зупиняємо team/work, зберігаємо ownership evidence, вимагаємо явного аудитованого recovery/appointment. Не можна відмовити у revocation чи автоматично підвищити учасника.

Подія	Негайний ефект	Recovery / збережене
Subject suspended/deprovisioned	Partner/linked contexts, sessions/invites заборонені; автоматика чекає reassignment	Той самий subject після перевірки; revoked membership потребує нового grant; ID не повторюється
Direct account suspended/deleted	Його та похідні contexts закриті, ownership/payer зобов’язання опрацьовані	Partner actors залишаються, незалежний BONSITE login можливий; фінансові докази зберігаються
Team suspended	Немає work/invite acceptance/new grants, contexts відкликані	Перевірити owners/agents/grants/payer; без automatic job replay
Team deleted	Tombstone ID, revoke keys/invites, stop jobs, provider cancellation	Дозволений export до видалення, фінанси/аудит збережені; bootstrap не відновлює
Org suspended/closed	Немає issuance/work усіх її teams, включно з linked contexts і делегуванням	Інші org/direct teams доступні; namespace/фінанси/tombstones збережені
BONSITE недоступний/припинив роботу	Немає нового proof; linked access лише доки active policy/subject/lease	Немає auto-move до Agentfy; окремо дозволений договором export/transition або stop/billing resolution
Sponsor/mandate removed	Немає нових paid reservations із cutoff	Free entitlement зберігається; owner не починає платити автоматично

BONSITE надсилає автентифіковані retryable lifecycle updates із монотонною subject revision. Agentfy підтверджує лише durable write; старе active event не скасовує нову suspension. Рекомендація: reconciliation щонайменше раз на 5 хвилин, lease не старше 15 хвилин на кожну partner/linked action. Lease окремий для кожного subject і поновлюється лише свіжою автентифікованою звіркою цього subject. Org heartbeat, duplicate/stale event не змінюють confirmedAt і не подовжують lease. Під час outage доступ припиняється після lease; login proof не скасовує відому suspension. SLA починається з прийняття revocation Agentfy, не з невідомої upstream-події.

Кожна action/refresh/download authorization/job перевіряє authoritative state; недоступність означає fail closed. Streams/sockets анулюються; цільова cancellation — до 60 секунд, із вимірюванням під навантаженням до release. Зовнішній ефект не скасувати заднім числом; фактичний usage записується. Download capability спливає в ту саму межу або проходить revocation-aware proxy. Resume заново авторизує роботу, не відтворює стару чергу. Аудит містить ID/причину, не tokens/secrets.

Підґрунтя безпеки

Доказ обох сторін відповідає порадам Auth0, але їхню global merge семантику не приймаємо. Redirect/PKCE/login-CSRF спираються на RFC 9700, стабільний issuer/subject замість email — на OpenID Connect Core. Сам протокол, строки й ізоляція — рекомендації Agentfy, що потребують перевірки реалізації.