# LittleFish NFT Authentication - Minting Guide

## Overview

This document provides guidelines for minting Single Sign-On (SSO) NFTs on the Cardano blockchain that are compatible with the LittleFish Authentication Framework. These NFTs serve as authentication tokens with configurable properties such as expiration dates, usage limits, and transferability.

## Metadata Standard

The SSO metadata must be included in the NFT's on-chain metadata under the `721` standard. Here's the required structure:

`
    "721": {
        "policyID": {
            "AssetName": {
                "name": "Asset Name",
                "image": "ipfs://YourIPFSHash",
                "mediaType": "image/png",
                "description": "Authentication token description",
                "files": [
                    {
                        "name": "image name",
                        "mediaType": "image/png",
                        "src": "ipfs://YourIPFSHash"
                    }
                ],
                "sso": {
                    "version": "0.1.0",
                    "uniqueIdentifier": "Platform-unique-identifier",
                    "issuer": "platformName",
                    "issuanceDate": "2024-01-01T00:00:00Z",
                    "expirationDate": "2025-01-01T00:00:00Z",
                    "isTransferable": 0,
                    "tiedWallet": "stake_address",
                    "isMaxUsageEnabled": 1,
                    "maxUsage": 10,
                    "isInactivityEnabled": 1,
                    "inactivityPeriod": "30d",
                    "role": ["role1", "role2"]
                }
            }
        }
    }
}

### SSO Metadata Fields

| Field | Type | Description | Required |
|-------|------|-------------|-----------|
| version | string | Current version of SSO metadata (0.1.0) | Yes |
| uniqueIdentifier | string | Platform-specific unique identifier | Yes |
| issuer | string | Name of the issuing platform/organization | Yes |
| issuanceDate | string | ISO 8601 timestamp of token issuance | Yes |
| expirationDate | string | ISO 8601 timestamp of token expiration | Yes |
| isTransferable | number | 0 for non-transferable, 1 for transferable | Yes |
| tiedWallet | string | Stake address for non-transferable tokens | If isTransferable = 0 |
| isMaxUsageEnabled | number | 0 for unlimited, 1 for limited uses | Yes |
| maxUsage | number | Maximum number of authentication attempts | If isMaxUsageEnabled = 1 |
| isInactivityEnabled | number | 0 for no timeout, 1 for inactivity timeout | Yes |
| inactivityPeriod | string | Duration format: "30d", "3m", or "1y" | If isInactivityEnabled = 1 |
| role | string[] | Array of roles granted by this token | Yes |

## Minting Process

1. **Policy Creation**
- Create a policy script
- Set appropriate time locks or other conditions if needed
- Generate the policy ID

2. **Prepare Metadata**
- Follow the metadata standard above
- Ensure all required fields are present
- Upload images to IPFS if needed

3. **Transaction Building**
- Create a minting transaction
- Include the metadata in the transaction
- Sign with policy keys
- Submit to the network

## Off-Chain Storage Requirements

The SSO validation system requires certain data to be maintained off-chain in your application's database to properly enforce authentication rules:

### Required Database Records
1. **Token Usage Tracking**
- Usage count (for `maxUsage` validation)
- Last activity timestamp (for `inactivityPeriod` validation)

2. **Platform Configuration**
- Authorized `issuer` names
- Valid `uniqueIdentifier` names
- Mapping between tokens and user accounts

### Database Schema Example

## Validation

The LittleFish Authentication Framework automatically validates:

1. Token expiration
2. Usage limits
3. Transferability restrictions
4. Inactivity periods
5. Issuer verification

## Best Practices

1. **Unique Identifiers**: Use a consistent naming scheme for uniqueIdentifier
2. **Expiration Dates**: Set reasonable expiration periods
3. **Usage Limits**: Consider your application's security requirements
4. **Transferability**: Non-transferable tokens provide better security
5. **Roles**: Keep role names consistent across your platform
6. **Minting Control**: The PolicyID and asset name are critical security components of the authentication system. The minting process, including policy keys and minting rights, must remain under the sole control of the issuing organization. This ensures that only authorized tokens can be created and prevents unauthorized parties from minting valid authentication tokens. We recommend:
- Secure storage of policy keys
- Time-locked or single-use minting policies
- Documented minting procedures
- Regular audits of minted tokens

## Testing

Before deployment:
1. Verify metadata structure
2. Test token authentication
3. Verify expiration handling
4. Test usage limits
5. Verify transferability restrictions