Permissions Standard

Permissions systems facilitate efficiency, consistency, and a seamless workflow across entities responsible for permissions issuance. Unique business needs and governing requirements will dictate solution selection, design, and implementation.

The considerations outlined in the Standard below are intended ensure suitable and effective permission implementations across government, assisting entities with reuse of existing investment as well as developing repeatable patterns.

Confirm permissions applicability

To assist the applicability and classification as a permissions solution use of the following criteria are recommended:

1. Does the Permission allow the assessed entity to be something, do something, or have something?
2. Is an eligibility assessment conducted, and does a specific set of eligibility conditions have to be met?
3. Has the outcome of the eligibility assessment been captured, and the assessed entity advised of the outcome?

Examples of outcomes that meet the above criteria include:

• data sharing or usage consent
• authorising someone to act on behalf of another person or entity (e.g. power of attorney, nominee)
• providing a permit to a resident to do something (e.g. at their property or business).

Other applicable examples will depend on the business function of each entity. Note that some permissions may lead to an entitlement being provided. The scope and granting of entitlements are covered in the entitlements capability in the Australian Government Architecture.

Comply with legislation

Entities must:

• comply with relevant whole-of-government laws, regulations, and domain standards including (but not limited to):
  • Archives Act 1983 (Cth)
  • Data Availability and Transparency (DAT) Act 2002 (Cth)
  • Freedom of Information Act 1982 (Cth)
  • Privacy Act 1988 (Cth) 
• comply with any other legislation applicable to specific functions and circumstances.

Identify permissions related roles

Entities should:

• define a model for permissions that suits their needs
• align (and maintain) a mapping of roles in their context to this model
• utilise this model to shape decisions on solution design and ongoing utilisation.

The W3C Verifiable Credentials Data Model v1.1 (w3.org) introduces several key roles, and could be considered for suitability to modelling an entity’s permissions structure. The separation of each role indicates separate steps and functions in the end-to-end permissions process. The following roles are introduced in the specification:

• Holder - A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers.
• Issuer - A role an entity performs by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organisations, trade associations, governments, and individuals.
• Subject - An entity about which claims are made. Example subjects include human beings, animals, and things. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, a parent (the holder) might hold the verifiable credentials of a child (the subject), or a pet owner (the holder) might hold the verifiable credentials of their pet (the subject).
• Verifier - A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include employers, security personnel, and websites.
• Verifiable Data Registry - A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Example verifiable data registries include trusted databases, decentralised databases, government ID databases, and distributed ledgers. Often there is more than one type of verifiable data registry utilised in a Permissions ecosystem.

Identify permissions decision type

Permissions solutions can be used within entities to assist decision-making. Typically, entity decision-making may be broadly classified into one of:

• Immediate decisions based on the provision of evidence and/or specific guardrails being met. These permissions generally allow the applicant to proceed with their application as a right, whether it is framed as an ad hoc permission or part of their ongoing eligibility.
• Future decisions based on assumptions about future need. These decisions are predictive, and subject to future review and confirmation. For example, “life events”, where an entity predicts that an individual may need a service/services in the future.

Entities should:

• recognise and identify against decision types during the design stage of Permissions solution development
• identify business and technology systems to suit decision types within the entity’s operational requirements.

Align operational and technological needs

Whilst a range of functional requirements can be captured, typically the end user system will be aligned to a supplier-specific solution. Options will vary, however there are a range of vendor-agnostic system functions that should be considered and incorporated if appropriate, e.g. zero-trust architecture.

Entities must:

• ensure permissions solutions appropriately log and attribute all permissions decisions, including the denying, granting, and revoking of permissions in line with auditability requirements
• meet privacy requirements of individuals, organisations, processes, or intellectual property
• meet security needs, particularly if the system contains sensitive or personally identifying data or is otherwise likely a target for threat actors.

Entities should:

• design permission solutions to integrate seamlessly with an entity’s existing infrastructure
• ensure permissions systems enable seamless management as well as robust permission handling
• consider business requirements of the entity for the granting of permission, which may include client servicing, compliance, or regulatory oversight
• consider technology functionality needed in the permission solution either to ensure rules-based assessment, end-to-end workflow management or outcome-based information capture and notification
• consider services wrapper needed to maintain the proposed solution, especially in areas such as records management and storage, change management, and business continuity.

Apply a risk-based approach

Entities should:

• be careful to ensure that permission systems do not inadvertently impact the performance, availability, accessibility, or other aspects of systems to the detriment of the user experience
• be careful to ensure that permission mechanisms do not inadvertently make digital records inaccessible in the long term
• ensure that permissions are suitably applied to non-production environments as well as production, to ensure appropriate quality assurance of permission handling and to protect information contained in those systems.

There are also specific non-functional needs that require upfront consideration, either for legislative or practical reasons. Any system proposal that does not meet these needs would immediately be deemed unfit for implementation and ruled out of consideration. These needs may include (but are not limited to):

• auditability requirements of process compliance and determination outcomes
• privacy requirements of individuals, organisations, processes, or intellectual property
• security needs, particularly if the system contains sensitive or personally identifying data or is otherwise likely a target for threat actors.

Lower development and maintenance complexity of Permissions solutions

Entities are encouraged to work with potential suppliers during design and implementation phases to:

• minimise the development effort and pathway required, including Proof of Concept and solution pilots, and de-risk final solution implementation
• align with and adopt vendor and industry best practice when developing, deploying, and applying permissions solutions, particularly incorporating lessons learned from other government entity implementations
• adopt streamlined maintenance models where the value may reduce overall cost and decrease ongoing management effort without adding additional risk.

Ensure the ongoing viability of Permissions solutions

The variance in permissions requirements across government inhibits an ability to pursue a single, centralised solution, or a universally applicable pattern. Unique permissions needs will dictate solution selection, design, and implementation.

Entities should:

• ensure that their selected solution is supportable, affordable, secure, and fit-for-purpose
• check contractual arrangements, MoU currency, and AGA Design state in advance of procuring capability
• maintain their solution to ensure currency and reduce the creation of technical debt.

Adhere to reuse principles

Reuse content on the Australian Government Architecture provides information for entities on reuse.

Entities should:

• consider permissions-specific functional and non-functional requirements prior to solution design or consideration of technology choice, including:
  • nature of permissions
  • user needs
  • broader system purpose
  • performance and availability requirements
  • privacy/sensitivity concerns
• meet the requirements of the whole-of-government reuse policy.