Authorization, not Authentication

AHI make a clear distinction between what is Authentication and Authorization.

• User authentication is the process related to verifying that the person is who they say they are. For example, prior knowledge of username/email and password, or associated Social login (Facebook, Google, etc..). It is separate to user authorization.
• User authorization is the process related to providing access to services to the authenticated user.

The user base is the responsibility of the partner, therefore AHI do not offer services to manage or implement user authentication or management solutions. However, once a user is authenticated and verified by the partner App, that user must be granted permission to AHI services through an authorization process with AHI.

In summary, authentication is "proving" that the user is who they say they are, and authorization is "granting access" to the user to the services they have permission to.

AHI suggest finding more information on the topic here.

‍

Why do we need authorization?

A unique user ID, salt and claims ensure that all billable events can be registered to a unique user and transmitted and stored securely, thereby preventing unauthorized or potentially malicious actors from undertaking unauthorized scans or intercepting unencrypted and or manipulating billing events in transit.

‍

How do we authorize users?

AHI MultiScan SDK authorizes a user with 3 requirements.

• userID - Unique to the user that never changes; do not use email or phone numbers as these may change.
• salt - The salt, also known as "initiation vector", is used for signing the user, which enables secure encryption of details and greatly assists in preventing decryption of transported data. You can read more about using salt an best security practices here:
• https://public.cyber.mil/stigs/
• https://www.okta.com/au/identity-101/hmac/
• claims - An array of claims unique to the user and will not change (e.g. registration date). Likewise, the order must not change. Therefore, don’t include the email, as the user could change this.

‍

..............................................................................................................................................................................................

Cloud

AHI Cloud provides mechanisms to support AHI technologies, including such features as:

• Remote files hosting to offload some of the SDK content to help reduce the SDK install size.
• User authorization (authZ), not to be confused with user authentication, which helps control rate limits.
• Billing service for the SDK to submit billing events to for AHI to track and create invoices.

AHI Cloud is built in a way that can be deployed and managed by AHI clients. Optionally, AHI can deploy and manage on the cloud service on the client's behalf.

AHI Cloud is implemented as a suite of Terraform scripts, following the "Infrastructure as Code" architecture solution. Currently, AHI Cloud is devised of AWS (Amazon Web) services, but as these services are generic and widely offered by other Cloud providers, it is entirely possible for AHI Cloud to adopt other Cloud providers in the future.

‍

Architecture

High level architecture of the AHI Cloud solution:

Where the cloud components are:

• a. The AHI Billing service.
• b. The AHI License service.
• c. The CDN files service. SDK resources can either be geo-located (as depicted) or global (default).
• d. The license auto-renew service.
• e. The client specific billing service backbone.
• f. The client specific user authorization service.
• g. The "Scan Control" mechanism, where user's must first be in credit to do a scan.

And MultiScan client SDK interacts with AHI Cloud:

1. MultiScan Client SDK will request and receive configuration details when setup() is called.
2. SDK remote resources will be downloaded by the MultiScan Client SDK. This can either be from AHI global CDN, or client confined CDN (as depicted), depending on the arrangement.
3. Once user has been authenticated (i.e. logged in), the user must be "announced" to AHI to grant them access, through a process of user authorization. No sensitive data is transmitted for user authorization to AHI services.
4. Billing events will be sent from AHI MultiScan Client SDK to AHI Cloud so that AHI may can accurately determine invoices and usage metrics for AHI clients.
5. Some scan technologies require cloud resources for processing, such as FaceScan. This can be unique depending on the particular scan being requested.
6. Each client deployment will periodically be reissued with a new AHI service license. Without this license, the service will expire and cause scans to be disabled.
7. Billing events are first buffered in each client deployment, then submitted to AHI global as a batch operation. This allows AHI service to be highly scalable and consist of multiple data redundancies. AHI Billing solution utilizes a ledger technology where each billing event is unique and immutable on the chain, allowing for a high degree of confidence in the security and accuracy of billing events.
8. Scan credit will be recorded and signed by AHI as a security measure.

‍

..............................................................................................................................................................................................

‍

Data

AHI have made a commitment to refrain from the collection and storage of our partner's user data. Because of this, AHI do not persist/store user scan result data. Therefore:

ATTENTION: it is the responsibility of AHI partner to persist the scan result data.

‍

Smoothing

Occasionally, results from scans would have outliers, values that were not consistent and seemingly wrong / not as expected. This has been defined as an issue relating to "repeatability", the expectation that doing multiple scans in a row should yield similar/same results.

The solution is to "smooth" scan results with respect to prior scan results to yield more repeatable and stable results. However, due to AHI not persisting scan result data, the App must implement and provide a persistence delegate that the AHI SDK can invoke to retrieve prior scan data for the smoothing algorithm to be able to run.

IMPORTANT: An app should use _adj_ measurement values from the scan result where possible, and fallback to using the _raw_ values. For example:

var waistCM = result["cm_adj_waist"] ?? result["cm_raw_waist"]

‍

Persistence Delegate

MultiScan SDK provides a protocol/interface class specification that an App must implement for smoothing algorithm to invoke. This implementation, referred to as the "persistence delegate", should be registered with MultiScan SDK for scan modules to utilize.

If a persistence delegate is not provided, smoothing will not run, and only the _raw_ measurement values (see schema) will be present.

‍

Scan Extra

Some scan modules can provide extra measurement data, not returned during the initial scan result. This can be due to many factors, such as for performance reasons or level of importance. Once such example is the generation of the 3D mesh artifact from a BodyScan result.

For scan extra to work, it is expected that the scan result is in the same format as returned, per result schema.

‍

..............................................................................................................................................................................................

‍

Quality Assurance

AHI have a Quality Assurance team to help verify that AHI technology is integrated appropriately. This is help our clients get the most out of the AHI scan technology and avoid common mistakes.

‍

What We Check

The AHI quality assurance team will check off the following:

User Interface: Where pertaining to activities directly affecting the Scan operations and outputs, the implemented UI will be compared to the designs provided by the client to ensure implementation matches designs.

Functional Checks: The functionality of the individual Scans is verified for consistency. Including the app displaying expected results, and any derived results.

Usability/User Experience Checks: The flow of the app directly leading up to the creation of a scan, the act of performing a scan, and any part of the app either displaying results or displaying derived results will be checked to ensure it makes sense for users. And that the first and returning user experiences are acceptable.

‍

What We Don't Check

The AHI quality assurance team is not responsible for the general testing of client's apps. However, if the team does discover something in your app, as a courtesy we will inform the client.

‍

How We Check

AHI's quality assurance team will execute several test scenarios against the client's app.

‍

Minimum Acceptance Criteria

1. The implemented UI matches designs supplied.
2. The UI contains no unreadable text.
3. The app contains no offensive language.
4. Users of the app can create a new account.
5. Users of the app can perform Scan(s).
6. Any in-app purchases pertaining to the ability to perform Scans are functioning.
7. When a user is either unsubscribed or hasn't purchased a Scan, they are unable to perform a Scan.
8. Expected results are being returned from the Scans, any derived results are being calculated correctly.
9. The appropriate billing events are being sent to AHI's billing database.

‍

What happens if a defect is discovered?

Any defects discovered in the activities directly pertaining to the operation of performing a Scan or Scans will be logged, prioritized and categorized.

Defects will be prioritized by their likelihood to occur, and the severity of their impact on a user performing a Scan or Scans.

Defects will be categorized into two categories, blockers and potential issues for consideration.

Blockers will need to be completed prior to the app being signed off by AHI, an example blocker is the user being unable to perform one of the provided Scans or the Scan not functioning correctly. Considerations are generally graphical inconsistencies in the app that the client might want to action prior to go live, or potentially in a different version of the app. An example of a consideration is a color in one of the Scan capture processes not matching the colors used throughout the app.

‍

Sign Off

Once all blockers have been resolved, and any of the considerations determined to be completed for release have been verified, the AHI quality assurance team will sign the app off, and it will be considered go-live ready.

‍

..............................................................................................................................................................................................

‍

Remote Resources

Some of AHI scan technologies are able to perform processing entirely within the user's device, without the need for processing on servers. This does come with the drawback that Machine Learning models must first need to be available on the user's device and can require a larger file size footprint for the app that otherwise would not be the case for more simple offerings.

AHI's solution for this is to allow such resources to be remotely hosted, instead of needing to be packaged with the App install bundle. This is particularly important for some App distribution stores, where there is a specific size limitation. It is also possible to embed these resources where remote asset download is not feasible, such as due to network limitations or other factors.

An advantage of remote resources solution is that updates to scan models can be rolled out without the user needing to reinstall the App (or App needing an AHI SDK version update), in most cases.