API Vendor Affiliation

### **Key considerations from API vendor modernization document ([Link](https://can01.safelinks.protection.outlook.com/ap/w-59584e83/?url=https%3A%2F%2Fbcgov.sharepoint.com%2F%3Aw%3A%2Fr%2Fteams%2F07717%2F_layouts%2F15%2FDoc.aspx%3Fsourcedoc%3D%257B6B604155-E2C3-4AA4-AA7E-C253C4A29CD2%257D%26file%3Dinfo_note%2520-%2520API%2520Vendor%2520Affiliation%2520Concerns.docx%26wdLOR%3DcD92704B4-05D7-42AB-9442-347DEABB6128%26action%3Ddefault%26mobileredirect%3Dtrue&data=05%7C02%7CLiz.Govier%40gov.bc.ca%7Cb92f43c0dd4e483b066d08de5a1cf335%7C6fdb52003d0d4a8ab036d3685e359adc%7C0%7C0%7C639047277819119219%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5kUpqQjNTItvJDCZMPe3tLRHq6RiA9PKVGRl4292C%2FA%3D&reserved=0))**

**The core problem**
Right now, when a vendor creates a business through the API, the system automatically links that new business to the vendor’s account. That makes the vendor look like the party with authority, even though the vendor is only providing software.

**What we want instead**
The law firm or the actual business owners should be the affiliated authority. The vendor should be a technical channel that is allowed to submit actions, but never becomes the owner or primary authority.

**Key principle**
- API vendors are tools, not authorities.
- They can perform actions.
- They cannot own or control business relationships.
______________________

**What does BC registries need to change**

At a high level, BC Registries needs to shift from an account centric model to an affiliation centric model.

In practical terms, that means a few key changes.

**Identity and authority**
BC Registries needs to treat real, verified people as the source of authority, not user accounts or organizations alone.
Every action should be traceable to a specific person and their role with a business.

**Affiliation model**
Businesses must be linked to people through explicit roles like owner, director, lawyer, or authorized staff.
Those links become the true access records.

**API model**
API vendors must be treated as applications acting on behalf of people, not as the party being affiliated.
APIs need to support an acting for pattern that includes both the vendor app and the human authority.

**UI and flows**
The UI needs to manage people and roles, not just invite emails.
Inviting someone should create a pending affiliation that must be accepted and verified.

**Delegation and governance**
Owners and authorized roles must be able to delegate access to others.
Delegation chains must be visible and auditable.

**Audit and compliance**
The system must be able to show who did what, for which business, and under what authority.
This becomes critical for legal defensibility and trust.

**Payments and billing**
Billing should align with the party that holds authority, usually the law firm or business owner, not the vendor.

**In simple terms**
BC Registries needs to stop thinking in terms of who has an account, and start thinking in terms of who is formally connected to which business and why.

### **How is that going to solve the issue with API vendors**

Because it separates authority from software.

Right now the problem exists because the system treats the vendor account as if it is the authority. So when a vendor creates a business, the vendor becomes affiliated, even though legally they should not be.

By moving to an affiliation centric model:

- The authority always belongs to a real person and their organization.
- The vendor is just a tool that submits actions.
- Businesses are linked to law firms or owners, not to software companies.
- Every API action can say who it was for and who authorized it.
- Audit trails show both the human and the system involved.

So the vendor can still automate everything, but they never become the owner or the legal actor in the system.

In other words, the vendor stops being part of the business relationship and becomes part of the delivery channel, which is exactly what they are in real life.

______________________

### A real life example in the system

**Actors**
**Law firm:** Maple Law LLP
**Lawyer:** Marie Tremblay (verified person)
**Vendor app:** FilingPro Software (the API vendor)
**Client business:** Blue Pine Consulting Inc.

**What the system stores**

**Business affiliations**
Blue Pine Consulting Inc.

**Marie Tremblay**
Role: Legal representative
Authority: Can file and manage
Granted by: Client owner or onboarding rule

This makes it clear that the business is the main entity, and the person is listed under it with their specific relationship and permissions.

**Maple Law LLP**
Role: Organization acting for client
Authority: Legal services only
Granted by: Client owner or policy

Vendor relationship
FilingPro Software is registered as a vendor application.
It is approved by Maple Law LLP as a tool.
It has technical permissions only.
It is not affiliated to the business.

### What happens when a business is created through the vendor

**Step 1. Law firm connects the vendor**
Maple Law LLP approves FilingPro Software in the UI.
This is like connecting an app to your account.

**Step 2. API call includes who it is for**
The request says:
- Create business for Maple Law LLP
- Acting user: Marie Tremblay

**Step 3. Business is affiliated to the right people**
Blue Pine Consulting Inc. becomes affiliated to
- Marie Tremblay, Maple Law LLP

The vendor is not affiliated.

**Step 4. Audit trail is clear**
The system can show:
- Marie created the business
- Marie works for Maple Law LLP
- Maple Law acts for Blue Pine Consulting
- FilingPro was the technical channel used
So both the human authority and the software are visible.

How delegation chains fit:
- Marie can delegate to her assistant.
- That delegation stays inside the law firm.
- The vendor never sits inside the authority chain.
- It always stays outside as a tool.

### What this means for verification

**Verified people**
Lawyers and business owners must be verified using government identity.

**Vendors**
Vendors authenticate as applications.
They do not replace or bypass human identity.

**Each API request must include**
- Which vendor app is calling
- Which verified person it is acting for
- Which affiliated organization it represents

### What needs to change from today

- Businesses created through vendors must not auto link to vendor accounts.
- APIs must support acting on behalf of a person and organization.
- Audit must always show both authority and technical channel.

**One sentence summary**
API vendors should be treated as authorized tools acting on behalf of verified, affiliated people and organizations, not as the party that owns or controls the business.

_____________________

### **Summary: What to watch out for from the API vendor modernization document**

**Affiliation is the real unit of access**
Access is not just about inviting users. At a foundational level, every person needs to have a formal affiliation with a business, and that affiliation represents a real world relationship, not just a technical permission. Even if the UI uses simpler language, the access list should really be thought of as an affiliation list.
Imagine the Business Registry has an Access page for a company called Blue Pine Consulting Inc.

Instead of just showing emails, it shows something like:

People affiliated with this business:

Liz Govier
Role: Owner
Affiliated by: System
Authority: Full control

Marie Tremblay
Role: Lawyer
Affiliated by: Liz Govier
Authority: File legal documents

Alex Chen
Role: Law firm staff
Affiliated by: Marie Tremblay
Authority: Prepare filings

What is really happening under the hood:

Each line is not just a user account.
It is a formal record that says:

This real person is officially connected to this business.
This is why they are connected.
This is who authorized that connection.
This is what they are allowed to do.

So the access list is actually a structured list of real world relationships, not just a list of people who can log in.

**Business ownership is foundational**
The business owner is the ultimate authority over access and data. This role is stronger than Admin and should be treated as holding the master key. Design decisions should always preserve the idea that ownership cannot be overridden by delegated roles.

**The system must allow access to pass through multiple people**
There is not just one level of access. You should not be forced into a model where only the owner invites everyone. Instead, access can flow through a chain of trusted people, like in real organizations. In short: the system needs to support real world hierarchies, not just a simple owner invites everyone model.

**Third party vendors are not real users**
API vendors should never appear as business owners or long term admins in the UI. They are technical intermediaries only. Any future integrations need to make sure vendors do not become part of the visible access model.

**Verified identity is not optional long term**
Access will eventually need to be tied to verified individuals using trusted identity services. Designs should avoid assuming that email based invites will always be sufficient.

Data integrity is a core requirement
This tool is not just a convenience feature. It plays a role in the registry’s data governance model. Incorrect role assignments or affiliations directly impact the legal integrity of the business record.

Future API use will surface edge cases
Businesses created through APIs will expose weaknesses in the access model very quickly. The tool should be designed with the expectation that businesses may be created by third parties, but must ultimately belong to real business owners and legal professionals, not vendors.

The issue identifies an API vendor affiliation and authority model but names no repository files, tests, or implementation entry points. Start by locating the existing business-affiliation and API-creation flows, then establish the concrete scope and acceptance criteria for separating vendor applications from human authority before making changes.

Written by the indexing model from the issue text.