# SSIS Evaluation for Pigeon

🚨 In progress: Please don't share outside prod-eng

## Benefits
- Convenient implementation of:
- ION DID creation and resolution
- Creation of VC
- Privacy preserving revocation
- Standards compliant
- Written by domain experts
- Guaranteed maintenance

## Neutral
Has many features not needed for Pigeon:
- Presentation Exchange
- Credential Manifest
- Application
- Credential Schema
- Verification

## Concerns

### 1. Data ownership

SSIS doesn't have domain knowledge of its data. It's a generalised service, with dynamic schema for VCs. Examples of relevant field level domain knowledge would be:
- DSL info
- PCI scope
- Safe logging format (e.g. masking)

SSIS doesn't control its data:
- No access control or audit trail
- Can't do field level authorization, authentication, or audit trail.

SSIS can't provide fliexible access to data. Its key/value storage model doesn't allow field level access:
- Query on fields (e.g. find VCs issued to "Alice")
- Aggregate over VCs (e.g. count of KYC VCs with the same address)

Any realistic issuer will need **duplicated storage of all fields in credentials** in another system, to serve these needs.

### 2. Data Security
VCs are persisted as atomic objects, with all fields encrypted together. It can't:
- Field-level encrypt
- Tokenise
- Selectively delete or redact fields
- Support least privilege and need-to-know policies

Applications and Presentation Submissions are also persisted, so sensitive data used to create VCs is duplicated across multiple objects.

In order to support GDPR deletion requests, an issuer will need **an index from every individual to their VCs and Applications, external to SSIS**.

Every issuer will need to implement authorization, authentication, and audit, external to SSIS.

The VC itself isn't valuable to an issuer. It can be reproduced from the input fields for nearly free, so **storage of VCs by an issuer isn't necessary**.

### 3. Operational Complexity

SSIS is a service that introduces significant deployment and operational complexity.
- a new database. Possibly one an issuer has no experience with
- multipe components to run
- network configuration to restrict access to SSIS
- Data Security Governance reviews
- monitoring, metrics, and logs
- potential for downtime
- need to create a client of the REST API

## "North Star" SSI
Instead of running a service, our ideal SSI solution would be SSI SDKs usable by many languages. Kotlin and TypeScript for Pigeon, Swift for future mobile apps. This meets issuers where they are.

Statelessness solves the data ownership, duplication, security, and complexity problems.

Feature Requirements:
- High level API implementing VC and related concepts
- ION DID creation
- ION DID Resolution
- Create Verifiable Credential function
- Maintain a revocation status list
- Get StatusList credential

Nice to haves:
- Idiomatic VC objects and their claims e.g.

data class VerifiableCredential<T>(
    val type: List<CredentialType>,
    val issuer: DID,
    val credentialSubject: T,
    ...
)