top of page
GSCA-logo
Login

GSCA ONE ID Identity & Trust Policy

Effective Date: August 9, 2026
Last Updated: August 9, 2026
 

Global Standard Certified Alliance ("GSCA"), operated by Techevent Limited and its affiliated entities ("GSCA", "we", "us", or "our"), provides a global digital trust infrastructure designed to establish, authenticate, verify, authorize, and manage trusted digital identities and relationships across individuals, organizations, pets, assets, credentials, and supported Trust Services.
 

The GSCA ONE ID Identity & Trust Policy ("ONE ID Policy") establishes the principles and framework governing GSCA ONE ID, including identity creation, authentication, verification, authorization, Trust Assurance Levels, organizational relationships, credentials, access, suspension, revocation, and identity continuity.
 

This Policy is intended to provide a long-term framework for the GSCA Trust Infrastructure and is not intended to prescribe a fixed technical implementation for any particular product or service.
 

This Policy should be read together with the applicable GSCA Terms of Service, Privacy Policy, Security & Responsible Disclosure Policy, Certification & Verification Policy, Intellectual Property & Trademark Policy, Acceptable Use & Trust Integrity Policy, Payment, Billing & Refund Policy, eOrigin C2C Transfer & Marketplace Terms, and any applicable product or service terms.

 

1. GSCA ONE ID
 

GSCA ONE ID is the identity and authorization layer of the GSCA Trust Infrastructure.

ONE ID provides a common identity foundation through which eligible individuals, organizations, and other supported entities may authenticate, establish trusted relationships, receive authorizations, and interact with applicable GSCA Trust Services.

ONE ID is designed to support continuity of identity across multiple services, organizations, applications, and Trust environments.

ONE ID is therefore not limited to a single product or application.

 

2. ONE ID and the GSCA Trust Infrastructure
 

ONE ID forms part of the foundational architecture of the GSCA Trust Infrastructure.

Depending on the applicable service, ONE ID may interact with or support Trust Services including:

  1. eCert;

  2. eAsset;

  3. eOrigin;

  4. eStamp;

  5. VCard;

  6. PET ID;

  7. Employee ID;

  8. Student ID;

  9. Organization identity;

  10. Other current or future GSCA Trust Services.

The list above is not exhaustive.

GSCA may introduce, modify, combine, expand, or discontinue Trust Services without changing the fundamental identity principles established by this Policy.

 

3. Identity, Authorization and Trust Services
 

GSCA distinguishes between three fundamental concepts:

3.1 Identity

Identity establishes who or what is being represented.

3.2 Authorization

Authorization establishes what an identity is permitted to access, manage, represent, issue, receive, or transfer.

3.3 Trust Service

A Trust Service provides a particular digital function, credential, record, verification mechanism, asset relationship, or trusted representation.

Authentication of a ONE ID does not automatically provide every available authorization or Trust Service.

Likewise, authorization granted by an organization does not necessarily transfer ownership or control of an individual's underlying personal ONE ID.

 

4. ONE ID Identity Domains
 

GSCA ONE ID may support different identity domains according to the applicable Trust Service.

These may include:

Individual Identity

A personal ONE ID representing an eligible individual.

Organization Identity

An identity representing an eligible organization or institution.

Pet Identity

A PET ID representing a registered pet and its authorized relationships.

Asset Identity

A digital identity or trusted record associated with an eligible asset, product, certificate, or other supported object.

Credential Identity

A trusted digital credential or representation associated with an identity, organization, asset, or authorized relationship.

The applicable identity domain does not necessarily determine ownership, legal title, or statutory identity. Such matters remain subject to applicable law and the relevant service terms.

 

5. Personal ONE ID
 

Where ONE ID is issued to an individual, the personal ONE ID is intended to provide a continuing identity foundation across eligible GSCA services.

An individual may use the same ONE ID across different personal or organizational relationships, subject to applicable authentication, verification, authorization, and service requirements.

For example, an individual may use one ONE ID as:

  1. A student;

  2. An employee;

  3. A member;

  4. An authorized representative;

  5. A professional;

  6. A customer;

  7. A participant in another GSCA Trust environment.

A change in employment, education, membership, or organizational relationship does not automatically require creation of a new personal ONE ID.

 

6. Organizational Authorization
 

An organization may establish an authorized relationship with an individual's ONE ID.

Depending on the applicable GSCA service, the organization may assign:

  1. Employee number;

  2. Student number;

  3. Member number;

  4. Position;

  5. Department;

  6. Role;

  7. Access permissions;

  8. Corporate credentials;

  9. Employee ID;

  10. Corporate VCard;

  11. Corporate eStamp;

  12. Other organization-specific credentials or services.

Such authorization represents the relationship between the organization and the individual's ONE ID.

It does not automatically transfer ownership of the individual's personal ONE ID to the organization.

 

7. Employee and Student Identity
 

ONE ID may be used as an identity foundation for organization-issued identity programs, including:

  1. Employee ID;

  2. Student ID;

  3. Staff ID;

  4. Member ID;

  5. Institutional credentials;

  6. Other authorized organizational identity representations.

For example:

Individual ONE ID
↓
Organization Authorization
↓
Employee / Student Number
↓
Organization Credential

The organization may determine the appropriate role, authorization, credential, and access rights within its authorized environment.

 

8. Corporate VCard and Corporate eStamp
 

Where supported, an organization may issue or associate a Corporate VCard or Corporate eStamp with an authorized individual's ONE ID.

A corporate representation may include information such as:

  1. Name;

  2. Organization;

  3. Position;

  4. Employee number;

  5. Department;

  6. Corporate contact information;

  7. Other organization-authorized information.

The organization may establish, modify, suspend, or revoke the individual's authorization to use such corporate services.

An individual's personal VCard or personal eStamp may remain separate from organizational credentials.

Accordingly, a person may maintain both:

Personal Services

and

Organization Services

through the same underlying ONE ID.

 

9. Organizational Relationship and Employment Termination
 

Where an employee leaves an organization, the organization may revoke or modify the employee's organizational authorization.

This may result in the deactivation, suspension, or revocation of applicable:

  1. Employee ID;

  2. Corporate VCard;

  3. Corporate eStamp;

  4. Organization access;

  5. Organization-issued credentials;

  6. Other organization-specific permissions.

Such action does not automatically terminate or delete the individual's personal ONE ID.

The individual may continue to use eligible personal GSCA services, subject to the applicable terms and account status.

 

10. ONE ID Continuity
 

A fundamental principle of the GSCA ONE ID framework is:

Identity may remain continuous while relationships, roles, permissions, credentials, and access rights may change.

For example:

Student

→ Graduation

→ Employee

→ Change of Employer

→ Director / Authorized Representative

The underlying personal ONE ID may remain continuous while the applicable organizational relationships change.

This principle is intended to support long-term identity continuity across different Trust environments.

 

11. Authentication
 

Authentication establishes whether a user is authorized to access a ONE ID or applicable GSCA service.

Depending on the service, GSCA may support one or more authentication methods, including:

  1. Username;

  2. Email address;

  3. Password;

  4. Verification codes;

  5. Multi-factor authentication;

  6. Device-based authentication;

  7. Biometric authentication;

  8. Other appropriate authentication mechanisms.

The specific authentication method may vary according to the applicable service, security requirements, Trust Assurance Level, jurisdiction, risk profile, or organizational requirements.

GSCA does not define this Policy around a single permanent authentication technology.

 

12. Verification
 

Verification is distinct from registration and authentication.

Verification may be applied to particular attributes, identities, organizations, credentials, assets, relationships, or transactions.

Depending on the applicable service, verification may involve:

  1. Identity information;

  2. Contact information;

  3. Organization information;

  4. Supporting documentation;

  5. Government-issued identification;

  6. Biometric verification;

  7. Organizational confirmation;

  8. Asset information;

  9. Other appropriate verification methods.

Verification of one attribute does not automatically mean that all information associated with the ONE ID has been verified.

 

13. GSCA Trust Assurance Levels
 

GSCA may establish different levels of Trust Assurance within the GSCA Trust Infrastructure.

The Trust Assurance framework may include:

L1 — Trust Assurance Level 1

A foundational level of assurance suitable for services, identities, relationships, or transactions where basic trust and authentication requirements are appropriate.

L2 — Trust Assurance Level 2

An enhanced level of assurance intended for services, identities, relationships, permissions, or transactions requiring additional trust, verification, authentication, authorization, or security controls.

L3 — Trust Assurance Level 3

An advanced level of assurance intended for services, identities, relationships, permissions, assets, or transactions requiring a higher degree of trust, verification, authentication, authorization, security, or transaction assurance.

 

14. Flexible Application of L1, L2 and L3
 

L1, L2 and L3 are Trust Assurance Levels, not permanent product classifications.

GSCA does not intend to permanently assign a particular product, application, credential, or service to one specific level through this Policy.

The applicable Trust Assurance Level may be determined according to factors including:

  1. Nature of the service;

  2. Risk profile;

  3. Type of identity;

  4. Type of organization;

  5. Type of asset;

  6. Transaction value or significance;

  7. Security requirements;

  8. Regulatory requirements;

  9. Member requirements;

  10. Institutional requirements;

  11. User requirements;

  12. Intended use case.

Accordingly, different organizations may require different Trust Assurance Levels for similar services, depending on their specific requirements.

 

15. Member-Defined Trust Requirements
 

GSCA institutional and organizational members may establish or request specific Trust Assurance requirements for their applicable services or environments, subject to the capabilities and rules of the GSCA Trust Infrastructure.

For example, an organization may determine that:

  1. General users require L1;

  2. Employees require L2;

  3. Administrators or high-risk functions require L3.

Another organization may adopt a different configuration according to its own risk profile and requirements.

The applicable Trust Assurance Level may therefore be determined at the appropriate service, organizational, identity, transaction, or use-case level.

 

16. Trust Assurance Levels Are Not Technology-Specific
 

L1, L2 and L3 are not defined solely by a particular technology, device, authentication method, biometric mechanism, credential, or product.

GSCA may use different technical or operational mechanisms to satisfy the applicable assurance requirements.

As technology, security standards, regulatory requirements, and Trust Services evolve, GSCA may update the implementation requirements associated with each Trust Assurance Level without changing the fundamental principles of this Policy.

 

17. GSCA Assurance Requirements
 

GSCA may publish or maintain additional requirements, specifications, procedures, or implementation standards governing how a particular Trust Assurance Level is achieved.

Such requirements may vary according to:

  1. Service;

  2. Region;

  3. Industry;

  4. Organization;

  5. Risk;

  6. Technology;

  7. Regulatory environment;

  8. Member requirements.

The applicable requirements may therefore evolve without requiring a corresponding amendment to this Policy.

 

18. Role-Based Authorization
 

GSCA may support role-based authorization.

Examples may include:

  1. User;

  2. Employee;

  3. Student;

  4. Member;

  5. Manager;

  6. Administrator;

  7. Issuer;

  8. Authorized Representative;

  9. Organization Administrator;

  10. Other designated roles.

A role may determine the functions that a user is permitted to access or perform.

Authentication alone does not automatically provide authorization for a particular role.

 

19. Organization Administrators
 

Where supported, an authorized organization administrator may be permitted to:

  1. Add authorized users;

  2. Associate ONE IDs with organizational roles;

  3. Assign employee or student numbers;

  4. Issue applicable organizational credentials;

  5. Modify organizational permissions;

  6. Suspend organizational access;

  7. Revoke organizational authorization.

Organization administrators are responsible for using such authority only within the scope granted to them.

 

20. Personal and Organizational Services
 

An individual may maintain personal and organizational GSCA services through the same ONE ID.

For example:

Personal

  1. Personal VCard;

  2. Personal eStamp;

  3. Personal eCert;

  4. Other eligible personal services.

Organization

  1. Employee ID;

  2. Corporate VCard;

  3. Corporate eStamp;

  4. Organization credentials;

  5. Organization permissions.

Organizational authorization does not automatically give an organization ownership or unrestricted access to the individual's personal GSCA services.

 

21. PET ID
 

GSCA ONE ID may support PET ID as a dedicated Pet Identity domain within the GSCA Trust Infrastructure.

PET ID may establish a digital identity and trusted relationship for a registered pet.

Depending on the applicable service, PET ID may support:

  1. Pet identity;

  2. Pet identification number;

  3. NFC identification;

  4. Owner or guardian relationship;

  5. Medical records;

  6. Vaccination records;

  7. Nutrition information;

  8. Certificates;

  9. Product records;

  10. Emergency information;

  11. Other authorized pet information.

A PET ID is distinct from the personal ONE ID of the pet owner.

The relationship between a pet and its authorized owner, guardian, organization, or other eligible party may be established, modified, or transferred according to applicable GSCA procedures.

 

22. ONE ID and Asset Identity

​

ONE ID and Asset Identity are separate but connectable concepts.

An individual or organization may be authorized to manage, hold, access, verify, or transfer an eligible asset through a relationship established within the GSCA Trust Infrastructure.

Examples may include:

  1. eAsset;

  2. eOrigin;

  3. Product identity;

  4. Certificate-related asset;

  5. Other supported digital or physical assets.

The existence of an identity relationship does not, by itself, determine legal ownership or title unless recognized by the applicable agreement or law.

 

23. ONE ID and eOrigin

​

Where applicable, ONE ID may provide the identity and authorization layer for eOrigin transactions.

A transaction may establish a relationship between:

Seller / Current Holder ONE ID

→ eOrigin Asset

→ Buyer / New Holder ONE ID

The applicable transfer, ownership, marketplace, and transaction requirements are governed by the relevant eOrigin terms.

 

24. ONE ID and Credentials

​

ONE ID may be used to access, receive, manage, authenticate, or present eligible GSCA credentials.

These may include:

  1. eCert;

  2. eAsset credentials;

  3. eStamp;

  4. VCard;

  5. Employee ID;

  6. Student ID;

  7. PET ID-related credentials;

  8. Other GSCA credentials.

Each credential remains subject to its own applicable issuance, verification, security, and service requirements.

 

25. Credential Independence

​

A credential associated with a ONE ID may have its own:

  1. Issuer;

  2. Status;

  3. Validity;

  4. Verification requirements;

  5. Authorization;

  6. Expiry;

  7. Revocation status.

Therefore:

A ONE ID does not automatically make every associated credential valid, verified, or active.

The status of each credential should be determined independently according to the applicable GSCA Trust Service.

 

26. Multiple Organizational Relationships

​

Where supported, one personal ONE ID may have relationships with multiple organizations.

Each organization may maintain its own:

  1. Employee or member number;

  2. Role;

  3. Authorization;

  4. Credentials;

  5. Permissions;

  6. Organizational information;

  7. Access status.

Authorization granted by one organization does not automatically grant access to another organization's information or systems.

 

27. Identity and Authorization Records

​

GSCA may maintain records necessary to support the operation of the ONE ID framework, including records relating to:

  1. Authentication;

  2. Verification;

  3. Authorization;

  4. Organizational relationships;

  5. Credential issuance;

  6. Credential status;

  7. Asset relationships;

  8. Transfer events;

  9. Security events;

  10. Other Trust Service activities.

Such records may support trust, security, verification, auditability, and service continuity.

 

28. Privacy and Data Protection

​

GSCA processes personal information associated with ONE ID in accordance with the GSCA Privacy Policy and applicable data protection requirements.

The existence of a ONE ID does not provide unrestricted access to all information associated with the identity.

Access should be governed by:

  1. Authorization;

  2. Role;

  3. Service requirements;

  4. Purpose;

  5. Security controls;

  6. Applicable law.

 

29. Identity Integrity

​

Users must provide accurate information and must not intentionally misrepresent their identity or authorization.

Users must not:

  1. Impersonate another person;

  2. Create or use a ONE ID without authorization;

  3. Falsify verification information;

  4. Manipulate identity records;

  5. Circumvent verification controls;

  6. Obtain unauthorized organizational permissions;

  7. Misuse another person's credentials.

GSCA may take appropriate action where identity integrity is compromised.

 

30. Security of ONE ID

​

Users are responsible for protecting their authentication credentials and access methods.

Users should not:

  1. Share passwords;

  2. Share authentication credentials improperly;

  3. Permit unauthorized persons to use their ONE ID;

  4. Circumvent security controls;

  5. Attempt to bypass Trust Assurance requirements.

Security incidents involving ONE ID should be reported according to the GSCA Security & Responsible Disclosure Policy.

 

31. Suspension

​

GSCA may suspend a ONE ID, credential, authorization, or applicable Trust Service where reasonably necessary to:

  1. Protect security;

  2. Prevent unauthorized access;

  3. Investigate suspected fraud;

  4. Investigate identity abuse;

  5. Protect the GSCA Trust Infrastructure;

  6. Comply with applicable law;

  7. Address serious policy violations.

Suspension may apply to the whole ONE ID or only to specific services, credentials, roles, or authorizations, where technically and operationally appropriate.

 

32. Revocation

​

GSCA or an authorized organization may revoke a credential, authorization, role, permission, or service where permitted.

Reasons may include:

  1. Employment termination;

  2. Student status termination;

  3. Membership termination;

  4. Change of role;

  5. Security concerns;

  6. Fraud;

  7. Unauthorized activity;

  8. Material misrepresentation;

  9. Policy violations;

  10. Legal or regulatory requirements.

Where possible and appropriate, revocation of a specific organizational authorization should not automatically terminate the underlying personal ONE ID.

 

33. ONE ID Revocation

​

GSCA may suspend or revoke the underlying ONE ID in circumstances permitted by applicable law and GSCA Terms.

Such circumstances may include serious:

  1. Identity fraud;

  2. Unauthorized access;

  3. Security abuse;

  4. Identity manipulation;

  5. Repeated material violations;

  6. Legal or regulatory requirements;

  7. Other significant threats to the integrity of the GSCA Trust Infrastructure.

Revocation of the underlying ONE ID may affect associated GSCA services.

 

34. Trust Status

​

GSCA may display or maintain Trust Status information associated with an identity, credential, authorization, or service.

Examples may include:

  1. Registered;

  2. Authenticated;

  3. Verified;

  4. Organization Verified;

  5. Active;

  6. Suspended;

  7. Revoked.

The precise status definitions may vary according to the applicable GSCA Trust Service.

A status should not be interpreted beyond the specific identity, information, authorization, credential, or service to which it applies.

 

35. No Automatic Legal Recognition

​

A GSCA ONE ID is a digital identity within the GSCA Trust Infrastructure.

Unless specifically recognized by applicable law, agreement, institution, or authorized program, a ONE ID should not automatically be interpreted as:

  1. A government-issued identity document;

  2. A passport;

  3. A national identity card;

  4. A statutory corporate registration;

  5. A government license;

  6. Legal title to an asset;

  7. A legally binding signature.

The legal effect of a particular GSCA credential or service depends on its applicable terms, agreements, jurisdiction, and law.

 

36. Third-Party and Institutional Integration

​

GSCA may support integrations with organizations, institutions, platforms, and third-party systems for identity, authentication, verification, authorization, credential issuance, or Trust Services.

The scope of each integration may depend on:

  1. Technical integration;

  2. Authorization;

  3. Applicable agreement;

  4. Service configuration;

  5. Security requirements;

  6. Applicable law.

Third-party services may remain subject to their own terms and privacy policies.

 

37. Trust Infrastructure Evolution

​

GSCA ONE ID is designed as a long-term identity foundation capable of supporting evolving Trust Services.

GSCA may introduce additional identity domains, Trust Services, verification methods, assurance requirements, authorization models, or technical mechanisms as the GSCA Trust Infrastructure develops.

The addition or modification of a Trust Service does not necessarily require a corresponding change to the fundamental principles established in this Policy.

 

38. Changes to Trust Assurance Requirements

​

GSCA may update the requirements associated with L1, L2, or L3 to reflect:

  1. Emerging technologies;

  2. New security standards;

  3. Regulatory requirements;

  4. Industry requirements;

  5. Member requirements;

  6. New risk models;

  7. New Trust Services;

  8. Changes in the GSCA Trust Infrastructure.

Such updates may be implemented through applicable specifications, service documentation, technical requirements, or member arrangements.

 

39. No Permanent Product-Level Assignment

​

For clarity:

L1, L2 and L3 are not intended to permanently classify a particular GSCA product.

A Trust Service may support different Trust Assurance Levels depending on its configuration, use case, risk profile, customer requirements, organizational requirements, or jurisdiction.

This approach allows the GSCA Trust Infrastructure to evolve without requiring this Policy to be rewritten whenever a product or technical implementation changes.

 

40. Relationship with Other GSCA Policies

​

This Policy establishes the identity and authorization framework for ONE ID.

Other GSCA policies govern specific areas, including:

Privacy and Personal Data
→ GSCA Privacy Policy

Security and Vulnerability Disclosure
→ GSCA Security & Responsible Disclosure Policy

Certification and Verification
→ GSCA Certification & Verification Policy

Intellectual Property
→ GSCA Intellectual Property & Trademark Policy

Acceptable Use
→ GSCA Acceptable Use & Trust Integrity Policy

Payments and Credits
→ GSCA Payment, Billing & Refund Policy

Asset Transfer and Marketplace
→ GSCA eOrigin C2C Transfer & Marketplace Terms

The applicable service-specific terms remain controlling for matters specific to a particular GSCA Trust Service.

 

41. Policy Updates

​

GSCA may update this Policy from time to time to reflect:

  1. Changes in the GSCA Trust Infrastructure;

  2. New identity domains;

  3. New Trust Services;

  4. Security improvements;

  5. New assurance requirements;

  6. Technological developments;

  7. Regulatory requirements;

  8. Changes in organizational or member requirements.

The latest version will be published through the applicable GSCA website or service.

 

42. Contact Us

​

For questions relating to GSCA ONE ID, identity verification, organizational authorization, Trust Assurance Levels, credentials, or related GSCA Trust Services:

Global Standard Certified Alliance (GSCA)
Operated by Techevent Limited


Email: cs@ecert.app
Website: www.ecert.app / www.gsca.cc

bottom of page