ADR-0014 Scanatar Creation
|Amended By||ADR-0015 Token Service for QuantaCorp API|
|Amended By||ADR-0021 Storage Path Scheme|
In ADR-0010 QuantaCorp propose to write a cross-platform SDK (for Android, iOS and web) that will facilitate photo capture and interact with the QuantaCorp API. This document goes into more detail about the architecture supporting this SDK and the scanatar creation process.
We assume that all of the applications using the SDK will require the user to login using Firebase authentication. This gives the applications access to Cloud Storage and an ID token that can be used to interact with other APIs (including the QuantaCorp API).
We also assume that the QuantaCorp SDK will have access to client-side functionality of the Firebase SDK, as all of the client applications will use the Firebase SDK.
The QuantaCorp SDK will use the ID token obtained via Firebase Auth as a bearer token to authenticate with the QuantaCorp API. It is the responsibility of the QuantaCorp API to validate this token.
The application implementing the SDK will generate pre-signed URLs to store the output from the QuantaCorp system in Cloud Storage owned by eTryOn. We will use a naming scheme that stores all of the user’s files under a prefix of their Firebase user ID, which simplifies the authorization rules controlling access to Cloud Storage.
The application will prompt the user to enter their height and gender and save these as metadata to Cloud Firestore.
The SDK will upload the photos required for avatar generation directly to the QuantaCorp API along with the metadata, the pre-signed URLs and the ID token.
On successful upload of metadata and photos, the QuantaCorp system will generate a thumbnail from the front view photo and a OBJ file for the scanatar.
The QuantaCorp system will use the pre-signed URLs obtained from the client to write the output thumbnail and OBJ file directly to the user’s eTryOn Cloud Storage area.
Successful creation of the OBJ file in Cloud Storage will trigger a Cloud Function to hand off the OBJ file to Metail’s systems for rigging and creation of the final scanatar. This Cloud Function will read the user’s height and gender from Firestore to pass to the Metail API.
The Metail system will also use a pre-signed URL to fetch the input from the user’s Cloud Storage and write back the rigged scanatar.
The eTryOn systems will not handle the user’s photos, so we avoid unnecessary handling of personally identifying data.
Once the thumbnail and scanatar have been written successfully to the user’s eTryOn Cloud Storage, the input photographs can be deleted from QuantaCorp’s systems.
Terms and conditions for applications using the QuantaCorp SDK to generate an avatar must make explicit the retention period for the user’s photos, whether they are deleted immediately on completion of avatar creation or retained; if retained, the terms and conditions must state the reason for retention.
Using pre-signed URLs minimizes the trust between systems and removes the need to issue service credentials.
The Cloud Function invoking the Metail API may need credentials as this is the one place we don’t have access to the user’s ID token.