1. Purpose
This specification defines the AGOV model for separating private and business use at AGOV account level.
The model deliberately remains simple. A Business Account is based primarily on self-declaration, a business email address and the continued ability to receive email at that address.
The specification defines:
- Private and Business Accounts;
- Business Email Domain binding;
- Shared Use declaration;
- Business Email reception verification and recertification;
- static and runtime requirements from Relying Parties;
- Domain Policy;
- migration and cleanup of the existing account population;
- self-learning Domain Policy;
- the information made available to Relying Parties;
- the Mail Domain ID as a simple by-product of email reception verification.
2. Normative terminology
MUST and MUST NOT define mandatory requirements.
SHOULD and SHOULD NOT define expected behaviour from which deviation requires a justified reason.
MAY defines optional behaviour.
OPEN DESIGN DECISION identifies a deliberately unresolved question.
3. Core product principle
A person SHOULD use a long-lived private AGOV account with an email address that is suitable for private use and preferably independent of an employer or organisation.
A person SHOULD use a separate AGOV Business Account with an email address belonging to the relevant business or organisational context.
A person acting in several distinct organisational contexts SHOULD generally use separate Business Accounts for those contexts.
4. Person-bound AGOV identity
Every AGOV account represents exactly one natural person.
AGOV does not provide a function for reassigning an existing account identity from one natural person to another.
The account does not by itself establish:
- membership of an organisation;
- employment;
- affiliation;
- a role;
- representation rights;
- signing authority.
Operational sharing of access does not change the natural person represented by the AGOV account.
5. Account Types
5.1 PRIVATE
The account holder declares the AGOV account for private use.
5.2 BUSINESS
The account holder declares the AGOV account for business or organisational use.
This declaration does not establish any relationship between the account holder and an organisation beyond the facts explicitly defined in this specification.
5.3 UNDECLARED
UNDECLARED is a transitional state for existing accounts created before the introduction of Account Types.
A migrated account MUST ultimately be either PRIVATE or BUSINESS.
6. Shared Use
Shared Use is defined only for Business Accounts.
The value is an explicit self-declaration by the account holder.
6.1 shared_use = false
The account holder declares that the Business Account is intended to be used only by the account holder.
This does not prove that another person has never had access to the account and does not prove that the account holder is necessarily the physical operator of a particular transaction.
6.2 shared_use = true
The account holder declares that access to the Business Account may be used by more than one person.
This declaration does not:
- authorise Shared Use;
- legitimise Shared Use;
- identify additional users;
- authenticate additional users;
- establish organisation approval.
7. Email Local Part
The email Local Part is the part before @.
It MUST NOT be used to determine:
- Account Type;
- Shared Use;
- Domain Policy.
AGOV therefore makes no distinction between addresses that appear personal, functional, generic or shared.
8. Email Domain and Policy Domain
8.1 Email Domain
The Email Domain is the complete canonical domain following @.
8.2 Policy Domain
The Policy Domain is the registrable domain used for Domain Policy.
The Policy Domain MUST be derived deterministically using a maintained public-suffix mechanism or an equivalent authoritative implementation.
It MUST NOT be derived merely by taking the final two labels of a hostname.
9. Business Email Domain binding
When an account is successfully declared as BUSINESS, its complete Email Domain becomes the permanently bound Business Email Domain.
The Business Email Domain MUST NOT subsequently change.
9.1 Email address change within the same domain
The new email address MUST be verified.
9.2 Change to another domain
A different business domain requires a different Business Account.
9.3 No circumvention
AGOV MUST retain sufficient historical information to prevent such circumvention.
10. Domain Policy
The Policy Domain may be used for Private Accounts but not for Business Accounts.
The Policy Domain may be used for Business Accounts but not for Private Accounts.
The Policy Domain is not restrictively classified. Both Account Types are permitted.
| Domain Policy | PRIVATE | BUSINESS |
|---|---|---|
PRIVATE_ONLY |
Allowed | Not allowed |
BUSINESS_ONLY |
Not allowed | Allowed |
UNKNOWN |
Allowed | Allowed |
A Policy Domain for which no restrictive classification exists is treated as UNKNOWN.
11. Domain Policy semantics
Domain Policy answers one question only:
Domain Policy does not establish:
- domain ownership;
- organisation identity;
- employment;
- affiliation;
- representation rights;
- signing authority.
12. New account enforcement
12.1 New Private Account
If the selected email address belongs to a BUSINESS_ONLY Policy Domain, the user MUST provide another email address suitable for private use.
12.2 New Business Account
An organisation does not need to be previously known to AGOV. A previously unseen domain can therefore be used for a Business Account while its Policy Domain remains UNKNOWN.
13. Business Account onboarding
The onboarding flow is:
- the user selects Business Account;
- the business email address is entered or confirmed;
- the Email Domain and Policy Domain are derived;
- Domain Policy is checked;
- reception at the exact email address is verified;
- the complete Email Domain is permanently bound to the Business Account;
- the user declares
shared_use = trueorfalse; - the Business Account becomes usable.
No organisation onboarding, UID, DNS verification or organisation administrator is required.
14. Business Email reception verification
AGOV MUST verify reception at the exact business email address during Business Account onboarding.
The verification establishes only that email reception at the relevant address could be successfully demonstrated at that time.
It does not establish employment, affiliation or representation rights.
15. Periodic recertification
AGOV MUST require a successful Business Email reception verification at least annually.
If the AGOV-wide maximum permitted age of the previous verification has been exceeded, a new reception verification MUST be completed before a Business Account can complete a Business authentication.
Expiry of the reception verification:
- does not delete the account;
- does not change the account to
PRIVATE; - does not change the bound Business Email Domain.
16. Relying Party requirements for reception verification
A Relying Party MAY require the Business Email reception verification to be more recent than the general AGOV requirement.
The requirement MAY be defined in two ways.
16.1 Fixed requirement in AGOV connect
The Relying Party MAY define a maximum acceptable age as part of its integration configuration in AGOV connect.
The configured requirement applies by default to authentications for that integration.
16.2 Dynamic requirement at runtime
The Relying Party MAY request a maximum acceptable age dynamically for an individual authentication transaction.
This allows an application to require a fresh reception verification for a particular transaction without changing its general configuration in AGOV connect.
16.3 Effective requirement
AGOV MUST apply the strictest applicable requirement:
A runtime requirement MAY make the requirement stricter.
It MUST NOT weaken the AGOV-wide requirement or a stricter requirement configured in AGOV connect.
17. Runtime reception verification
If the existing Business Email reception verification is not recent enough for the current authentication, AGOV MUST perform a new verification before completing the authentication.
A successful verification becomes the new last successful Business Email reception verification.
18. Failed reception verification
If a required reception verification cannot be completed successfully, the corresponding Business authentication MUST NOT complete.
The Business Account itself remains intact.
The user MAY:
- retry the verification;
- replace the email address with another address under the same permanently bound Business Email Domain and verify it;
- create a new Business Account for a different business context or domain.
19. Natural offboarding
If a person loses access to the business email address, the person will eventually be unable to satisfy the required reception verification.
This provides a simple natural offboarding mechanism without requiring AGOV to maintain information about employment or organisational relationships.
20. Information in authentication tokens
The Business Account characteristic MUST be made available to the Relying Party in OIDC and SAML authentication results.
For Business Accounts, the Shared Use declaration MUST also be made available.
Conceptually:
A Private Account MUST NOT carry shared_use=false, because Shared Use is not defined for Private Accounts.
The exact OIDC claim names and SAML attribute names are defined in the applicable federation interface specification.
The Relying Party does not need to calculate reception-verification freshness from a timestamp where AGOV has already enforced the applicable requirement before issuing the authentication result.
21. Relying Party interpretation
A Relying Party MAY:
- accept Private and Business Accounts;
- require a Business Account;
- accept Business Accounts with either value of
shared_use; - reject Business Accounts with
shared_use=true; - ignore Shared Use where it is irrelevant;
- require a more recent Business Email reception verification.
shared_use=false MUST NOT be interpreted as technical proof that the account holder is necessarily the physical operator of the current transaction.
22. AGOV subject, authentication quality and Shared Use
The AGOV subject continues to represent the natural person associated with the AGOV account, including where shared_use=true.
Authentication quality and person-bound identity attributes likewise relate to the natural person represented by the AGOV account.
23. Existing accounts and Domain Policy
Domain Policy applies not only to new accounts but also to the existing account population.
Whenever a restrictive Domain Policy is activated or changed, AGOV MUST re-evaluate all affected existing accounts.
A Domain Policy change MUST NOT:
- silently change an Account Type;
- silently change a Business Email Domain;
- automatically delete an account.
24. Mandatory cleanup at next login
An existing account marked MIGRATION_REQUIRED MUST be remediated through a mandatory wizard at the next successful login.
If the required remediation is abandoned, the normal authentication to the Relying Party MUST NOT complete.
Recovery, necessary account-management functions and support remain available.
25. Legacy Account Type migration
An existing account whose Account Type has not yet been declared is asked:
The result is reconciled with the applicable Domain Policy.
25.1 Private
The account becomes PRIVATE. If its Policy Domain is BUSINESS_ONLY, the user MUST provide a suitable private email address.
25.2 Business
The account becomes BUSINESS, subject to Domain Policy, successful email reception verification, permanent Business Email Domain binding and Shared Use declaration.
25.3 Private and business
The account MUST be disentangled.
26. Mandatory disentanglement
An AGOV account that has been used for both private and business contexts MUST be split into separate contexts.
The user decides which context keeps the existing AGOV account.
A new AGOV account is created for the other context.
The new account receives a new AGOV account identifier.
27. PRIVATE account under BUSINESS_ONLY
The account remains a Private Account.
The user MUST provide and verify another email address whose Policy Domain permits private use.
If the user also requires a Business Account for company.tld, a separate Business Account is created.
28. BUSINESS account under PRIVATE_ONLY
The Business Email Domain MUST NOT simply be replaced by another domain.
The remediation flow determines whether the user still requires the business context.
The legacy account may be regularised as a Private Account through the migration process.
A new compliant Business Account is created with a suitable business email address. The legacy account is regularised separately.
The historic Business Email Domain MUST remain recorded so that the domain lock cannot later be circumvented.
29. Shared Use declaration for existing Business Accounts
An existing Business Account for which Shared Use has not yet been explicitly declared MUST obtain a declaration.
AGOV MUST NOT silently assume shared_use=false.
30. Policy reversal
A Domain Policy classification MUST be reversible.
If a restrictive classification is removed or corrected, AGOV MUST recalculate outstanding migration requirements for affected accounts.
Completed migrations are not automatically undone.
31. Self-learning Domain Policy
The Domain Policy lists SHOULD progressively learn from actual AGOV usage.
The purpose of learning is limited to identifying Policy Domains that are strong candidates for:
Possible signals include:
- voluntary PRIVATE and BUSINESS declarations;
- the number and proportion of such declarations;
- known general-purpose private email providers;
- existing AGOV classifications;
- later stronger evidence where available.
The learning mechanism does not determine employment, affiliation, domain ownership or representation rights.
32. Learning must not confirm itself
The learning mechanism MUST distinguish genuine observations from behaviour caused by an already active Domain Policy.
Once company.tld is classified as BUSINESS_ONLY, the resulting Business-only population is not independent new evidence proving that classification.
33. Protection against trivial misclassification
A small number of unusual declarations MUST NOT be sufficient to reclassify a major general-purpose domain.
The learning mechanism SHOULD consider at least observation volume, proportions and source quality.
34. Policy suggestion and activation
The initial model is deliberately simple:
The learning process MAY generate:
A suggestion alone does not restrict users.
Before restrictive activation, AGOV MUST show the effect on the existing account population, including how many accounts would require migration.
35. Mail Domain ID (MDID)
The Mail Domain ID is a simple by-product of email reception verification.
AGOV MUST provide an MDID Issuer within agov.ch/me.
The Issuer issues a Verifiable Credential to the user based on an already successfully verified AGOV email address.
The AGOV-specific content of the credential is:
The email Local Part MUST NOT be included in the MDID.
No separate MDID-specific email reception verification is required.
The MDID states only that email reception for the user under the stated domain could last be successfully demonstrated at the stated time.
It does not establish:
- domain ownership;
- organisation identity;
- employment;
- affiliation;
- a role;
- representation rights;
- signing authority.
The roles in the VC context are:
The concept of a Relying Party belongs to the AGOV authentication context and is not used to describe the Verifier role of a Verifiable Credential.
36. MDID remains deliberately narrow
The MDID does not introduce a second Business Account lifecycle.
It does not introduce:
- a separate MDID recertification process;
- a separate MDID freshness policy in AGOV;
- a separate Domain Policy;
- a separate organisation model.
The Verifier evaluates the timestamp and the credential according to its own use case.
37. AHVN on Shared Business Accounts
Should an AHVN be available where shared_use=true?
The potential problem is that the AHVN relates to the natural person represented by the AGOV account while, in a Shared Business Account, AGOV does not assert that this person is necessarily the physical operator of a particular transaction.
38. AHVN on Business Accounts generally
Should Business Accounts carry or transmit an AHVN at all?
A possible strategic rule is that AHVN remains exclusively associated with Private Accounts.
39. Other person-bound attributes
Which additional person-bound attributes, if any, require restrictions when shared_use=true?
The question SHOULD be decided attribute by attribute rather than by introducing a generic additional account model.
40. General AGOV Account VC
The MDID is intentionally a narrow, purpose-specific Verifiable Credential.
It should be considered whether agov.ch/me should additionally provide a more comprehensive AGOV Account VC.
Such an AGOV Account VC could contain a portable snapshot of AGOV Account Data, Account characteristics and the corresponding Account Data Quality information.
Conceptually, it could expose information that AGOV is also able to provide as part of an authentication result.
Possible examples include:
- selected AGOV Account Data;
- Account Type;
- Shared Use declaration where applicable;
- verified person attributes where permitted;
- the corresponding Account Data Quality or assurance information.
The credential SHOULD NOT automatically contain every technical claim present in an OIDC or SAML authentication result. Its attribute set would need to be explicitly defined.
An AGOV Account VC would represent the state attested by AGOV at issuance time. A Verifier would decide whether that snapshot is suitable for its use case.
The introduction of such a credential would not replace the MDID.
41. Support and recovery
Support and recovery processes MUST respect the same invariants as self-service.
They MUST NOT provide a bypass for:
- Business Email Domain binding;
- Domain Policy;
- mandatory migration;
- Shared Use declaration;
- the person-bound AGOV account identity.
42. Auditability
Changes relevant to the Business Account model MUST be auditable.
This includes at least:
- Account Type declarations and migration changes;
- Business Email Domain binding;
- email address changes;
- successful email reception verification;
- Shared Use declarations and changes;
- Domain Policy activation and changes;
- migration and disentanglement;
- MDID issuance.
43. Minimal data model
The core model intentionally requires little data.
The permanent Business Email Domain binding additionally requires sufficient historical information to prevent circumvention.
44. Explicitly outside the core model
The core implementation does not require:
- organisation onboarding;
- organisation accounts;
- organisation administrators;
- employment records;
- affiliation records;
- UID lookup;
- Zefix lookup;
- DNS domain claims;
- EasyGov integration;
- email Local Part analysis;
- generic mailbox detection;
- technical detection of actual account sharing;
- subdomain-specific Domain Policy;
- representation or signing-right management.
Stronger organisation or domain evidence MAY be added later if a concrete requirement justifies it.
45. Core invariants
- I-01: Every AGOV account represents exactly one natural person.
- I-02: AGOV does not reassign an existing account identity from one natural person to another.
- I-03: Every fully migrated account is either PRIVATE or BUSINESS.
- I-04: A Business Account remains a natural-person account and does not represent an organisation.
- I-05: Shared Use is defined only for Business Accounts.
- I-06: Shared Use is an explicit self-declaration.
- I-07:
shared_use=falseis not proof of individual physical operation. - I-08:
shared_use=truedoes not legitimise or authorise Shared Use. - I-09: The email Local Part is irrelevant to Account Type, Shared Use and Domain Policy.
- I-10: A Business Account has one permanently bound complete Business Email Domain.
- I-11: The Business Email Domain cannot subsequently be changed.
- I-12: An email address may be changed within the same Business Email Domain after successful verification.
- I-13: Account Type changes MUST NOT circumvent the Business Email Domain binding.
- I-14: Domain Policy is evaluated using the Policy Domain.
- I-15: PRIVATE_ONLY permits Private Accounts and prohibits Business Accounts.
- I-16: BUSINESS_ONLY permits Business Accounts and prohibits Private Accounts.
- I-17: UNKNOWN permits both Account Types.
- I-18: Domain Policy does not establish organisation identity, affiliation or representation.
- I-19: Business Email reception is verified during Business Account onboarding.
- I-20: Business Email reception is recertified at least annually.
- I-21: A Relying Party MAY configure a stricter reception-verification requirement in AGOV connect.
- I-22: A Relying Party MAY request a stricter reception-verification requirement dynamically for an authentication transaction.
- I-23: AGOV always applies the strictest applicable reception-verification requirement.
- I-24: A runtime requirement may tighten but never weaken another applicable requirement.
- I-25: If the current reception verification is too old, AGOV performs a new verification before completing authentication.
- I-26: A successful runtime verification becomes the new last successful reception verification.
- I-27: Failed or expired reception verification does not delete or reclassify the Business Account.
- I-28: Business Account status is available to Relying Parties in OIDC and SAML.
- I-29: Shared Use is available to Relying Parties for Business Accounts.
- I-30: Private Accounts do not carry a Shared Use assertion.
- I-31: A restrictive Domain Policy change triggers re-evaluation of the affected existing account population.
- I-32: Domain Policy never silently changes an Account Type.
- I-33: Domain Policy never directly deletes an account.
- I-34: A non-compliant existing account receives MIGRATION_REQUIRED.
- I-35: MIGRATION_REQUIRED is resolved through a mandatory wizard at the next login.
- I-36: Mixed private and business use MUST be disentangled.
- I-37: An additional account created during disentanglement receives its own AGOV account identifier.
- I-38: AGOV does not silently transfer application roles, mappings or entitlements between disentangled accounts.
- I-39: Domain Policy learning distinguishes voluntary observations from policy-induced behaviour.
- I-40: Learned classifications concern domain suitability only and do not establish organisation relationships.
- I-41: AGOV MUST provide an MDID Issuer within
agov.ch/me. - I-42: The MDID is a Verifiable Credential.
- I-43: The MDID states the Mail Domain and the time at which email reception under that domain was last successfully verified for the user.
- I-44: The MDID does not contain the email Local Part.
- I-45: The MDID uses the existing email reception verification fact; no separate MDID-specific reception verification is required.
- I-46: The MDID does not establish domain ownership, organisation identity, employment, affiliation, role or representation rights.
- I-47: In the MDID context the roles are Issuer, Holder and Verifier; Relying Party is an authentication role.
- I-48: A general AGOV Account VC is not part of the mandatory core model unless ODD-04 is positively decided.
- I-49: Stronger future organisation mechanisms MUST NOT change the semantics of the simple Business Account core model.
46. Acceptance criteria
The core Business Account model is complete when:
- Private and Business Accounts can be explicitly distinguished;
- Business Accounts permanently bind the complete Business Email Domain;
- changes to another Business Email Domain are prevented;
- email address changes within the same domain require verification;
- Shared Use can be explicitly declared for Business Accounts;
- Shared Use is not defined for Private Accounts;
- the email Local Part is not interpreted;
- Domain Policy supports PRIVATE_ONLY, BUSINESS_ONLY and UNKNOWN;
- unknown domains do not prevent new Business Accounts;
- Business Email reception is verified during onboarding;
- annual recertification is enforced;
- Relying Parties can define a stricter requirement in AGOV connect;
- Relying Parties can dynamically request a stricter requirement during authentication;
- the strictest applicable requirement is enforced by AGOV before authentication completes;
- Business Account and Shared Use information are available in OIDC and SAML;
- existing accounts are re-evaluated when restrictive Domain Policy changes;
- non-compliant accounts are marked MIGRATION_REQUIRED;
- mandatory remediation occurs at the next login;
- mixed private and business accounts can be disentangled;
- no account is silently retyped or deleted;
- Domain Policy can progressively learn from the account population without learning from its own enforcement;
- an MDID Issuer exists within
agov.ch/me; - the MDID can be issued as a VC containing the domain and the last successful email reception verification time;
- MDID issuance requires no additional email reception process.
The optional AGOV Account VC described in ODD-04 is not required to meet these core acceptance criteria.
47. Core architecture
48. Architectural maxim
Keep the model simple. An AGOV account represents a natural person. Separate private and business contexts. Bind a Business Account permanently to its business email domain. Declare Shared Use rather than trying to detect it. Verify that email can still be received, normally at least annually and more recently when an application requires it. Let Domain Policy progressively clean up the population. Resolve conflicts at the next login instead of silently changing accounts. Expose the existing email reception fact as a minimal Mail Domain ID where useful. Broader portable AGOV Account Data may be considered separately without making it part of the Business Account core model.