One login doesn't mean one identity across every business

A common login screen is convenient. A publisher, an independent retailer and a software agency may all want customers to sign in without creating another password. The challenge is that sharing an authentication mechanism does not mean the businesses should share their underlying customer records or authority.

The NIST SP 800-63-4 guidelines^{[1]NIST SP 800-63-4 guidelines} describe identity proofing, authenticators and federation as distinct areas. Its federation section^{[2]federation section} discusses how separate relying parties can accept assertions from an identity provider.

An identity provider might assert that a person successfully authenticated. A retailer still has to decide whether that person may view an order. A company may grant them permission to approve an invoice but not to export payroll data.

The same human can appear as a buyer, employee, contributor and agency administrator. Those are relationships to different organizations, not one universal privilege.

Bonfÿre's Matrix identity work keeps person and organization relationships available across applications. Account destinations and application authorities decide which records and actions belong to a particular context.

That allows a personal profile and a business workspace to refer to the same person without granting the personal profile the powers of a finance officer.

A well-designed federation system reduces repeated login friction. It should also make it easy to explain which account is acting, whose data will be changed and why the action is permitted.

The most useful identity system is one that helps people move between contexts without erasing their boundaries.