13 KiB
SMOA Implementation Requirements
Detailed Technical Requirements for Compliance Gaps
Document Classification: Internal Development
Date: 2024-12-20
Application: Secure Mobile Operations Application (SMOA)
Version: 1.0
Table of Contents
- PDF417 Barcode Implementation Requirements
- AS4 Gateway Implementation Requirements
- eIDAS Compliance Requirements
- Digital Signature Requirements
- Certificate Management Requirements
- NCIC/III Integration Requirements
- ATF Integration Requirements
- See Also
- Version History
1. PDF417 Barcode Implementation Requirements
1.1 Functional Requirements
FR-PDF417-001: The application SHALL generate PDF417 barcodes compliant with ISO/IEC 15438:2015.
FR-PDF417-002: The application SHALL support error correction levels 0 through 8, with level 5 as default.
FR-PDF417-003: The application SHALL support the following data structure formats:
- AAMVA DL/ID (American Association of Motor Vehicle Administrators Driver License/ID Card)
- ICAO 9303 (Machine Readable Travel Documents)
- MIL-STD-129 (Military identification)
FR-PDF417-004: The application SHALL display PDF417 barcodes at minimum 200 DPI resolution.
FR-PDF417-005: The application SHALL support PDF417 text compression mode (Mode 902).
FR-PDF417-006: The application SHALL provide barcode scanning capability using device camera.
1.2 Technical Specifications
Library Requirements:
- ZXing (Zebra Crossing) library for PDF417 encoding/decoding
- Minimum version: 3.5.0
- Alternative: iText PDF library with barcode module
Data Encoding:
// Example data structure for AAMVA format
data class AAMVACredential(
val documentDiscriminator: String,
val firstName: String,
val middleName: String?,
val lastName: String,
val address: String,
val city: String,
val state: String,
val zipCode: String,
val dateOfBirth: String, // YYYYMMDD
val expirationDate: String, // YYYYMMDD
val issueDate: String, // YYYYMMDD
val licenseNumber: String,
val restrictions: String?,
val endorsements: String?,
val vehicleClass: String?
)
Display Requirements:
- Minimum display size: 2.0" x 0.8" (50.8mm x 20.3mm)
- Error correction level: 5 (default)
- Quiet zone: Minimum 10X (where X = module width)
2. AS4 Gateway Implementation Requirements
2.1 Functional Requirements
FR-AS4-001: The application SHALL construct AS4 message envelopes per OASIS AS4 Profile 1.0.
FR-AS4-002: The application SHALL implement WS-Security SOAP headers with:
- XML Digital Signature (XMLDSig)
- XML Encryption (XMLEnc)
- X.509 certificate-based authentication
FR-AS4-003: The application SHALL implement WS-ReliableMessaging for guaranteed message delivery.
FR-AS4-004: The application SHALL support both AS4 push and pull protocols.
FR-AS4-005: The application SHALL generate and process AS4 receipts with non-repudiation.
FR-AS4-006: The application SHALL handle AS4 error signal messages per specification.
2.2 Technical Specifications
Library Requirements:
- Apache CXF with AS4 support, OR
- Custom implementation based on OASIS AS4 Profile specification
- Apache Santuario for XML security (XMLDSig/XMLEnc)
Message Structure:
// AS4 Message structure (simplified)
data class AS4Message(
val messageId: String, // UUID
val timestamp: String, // ISO 8601
val fromParty: AS4Party,
val toParty: AS4Party,
val conversationId: String?,
val service: String?,
val action: String?,
val payload: ByteArray,
val security: AS4Security,
val reliability: AS4Reliability?
)
data class AS4Security(
val signature: XMLSignature,
val encryption: XMLEncryption?,
val certificate: X509Certificate
)
Security Requirements:
- TLS 1.2 or higher for transport
- RSA 2048-bit or ECC P-256 for signatures
- AES-256-GCM for encryption
- SHA-256 for hashing
3. ATF Form Support Requirements
3.1 Functional Requirements
FR-ATF-001: The application SHALL support ATF Form 4473 (Firearms Transaction Record) data entry and submission.
FR-ATF-002: The application SHALL integrate with ATF eTrace system for firearms tracing.
FR-ATF-003: The application SHALL support ATF Form 1 (Application to Make and Register a Firearm) processing.
FR-ATF-004: The application SHALL support ATF Form 4 (Application for Tax Paid Transfer and Registration) processing.
FR-ATF-005: The application SHALL validate form data against ATF validation rules.
FR-ATF-006: The application SHALL store form submissions with cryptographic integrity protection.
3.2 Technical Specifications
API Requirements:
- ATF eTrace API integration (requires federal approval)
- RESTful API for form submission
- OAuth 2.0 for API authentication
Data Models:
data class ATFForm4473(
val transactionId: String,
val transactionDate: Date,
val firearmManufacturer: String,
val firearmModel: String,
val firearmSerialNumber: String,
val firearmCaliber: String,
val firearmType: FirearmType,
val transfereeInfo: PersonInfo,
val transferorInfo: PersonInfo,
val nicsCheckNumber: String?,
val nicsCheckDate: Date?,
val signatures: List<DigitalSignature>
)
enum class FirearmType {
HANDGUN,
RIFLE,
SHOTGUN,
OTHER
}
Security Requirements:
- All form data encrypted at rest
- Digital signatures on form submissions
- Audit trail for all form access/modifications
- Role-based access control (only authorized ATF personnel)
4. NCIC/III Integration Requirements
4.1 Functional Requirements
FR-NCIC-001: The application SHALL provide interface for NCIC database queries.
FR-NCIC-002: The application SHALL support III (Interstate Identification Index) queries.
FR-NCIC-003: The application SHALL implement ORI (Originating Agency Identifier) management.
FR-NCIC-004: The application SHALL generate and validate UCNs (Unique Control Numbers).
FR-NCIC-005: The application SHALL handle NCIC response codes per NCIC specifications.
FR-NCIC-006: The application SHALL maintain audit log of all NCIC/III queries.
4.2 Technical Specifications
API Requirements:
- NCIC/III API access (requires CJIS approval)
- Secure communication channel (typically VPN or dedicated line)
- Message format: NCIC 2000 or N-DEx format
Data Models:
data class NCICQuery(
val queryId: String,
val ori: String, // Originating Agency Identifier
val ucn: String, // Unique Control Number
val queryType: NCICQueryType,
val searchCriteria: Map<String, String>,
val timestamp: Date,
val operatorId: String
)
enum class NCICQueryType {
PERSON,
VEHICLE,
ARTICLE,
BOAT,
GUN,
LICENSE_PLATE
}
data class NCICResponse(
val queryId: String,
val responseCode: NCICResponseCode,
val records: List<NCICRecord>?,
val timestamp: Date,
val message: String?
)
enum class NCICResponseCode {
HIT,
NO_HIT,
ERROR,
RESTRICTED
}
Security Requirements:
- CJIS Security Policy compliance (minimum)
- Background checks for all operators
- Encryption of all queries/responses
- Access logging and monitoring
- Two-factor authentication for operators
5. Orders Management Requirements
5.1 Functional Requirements
FR-ORD-001: The application SHALL provide digital orders creation and management.
FR-ORD-002: The application SHALL support multiple order types:
- Authorization orders
- Assignment orders
- Search warrants
- Arrest warrants
- Court orders
- Administrative orders
FR-ORD-003: The application SHALL track order lifecycle:
- Draft
- Pending approval
- Approved
- Issued
- Executed
- Expired
- Revoked
FR-ORD-004: The application SHALL enforce order expiration dates and automatic revocation.
FR-ORD-005: The application SHALL generate authenticated copies of orders.
FR-ORD-006: The application SHALL validate order authenticity upon receipt.
FR-ORD-007: The application SHALL support order templates for common order types.
5.2 Technical Specifications
Data Models:
data class Order(
val orderId: String,
val orderType: OrderType,
val title: String,
val content: String,
val issuedBy: String, // Authority/author
val issuedTo: String?,
val issueDate: Date,
val effectiveDate: Date,
val expirationDate: Date?,
val status: OrderStatus,
val attachments: List<OrderAttachment>,
val signatures: List<DigitalSignature>,
val metadata: OrderMetadata
)
enum class OrderType {
AUTHORIZATION,
ASSIGNMENT,
SEARCH_WARRANT,
ARREST_WARRANT,
COURT_ORDER,
ADMINISTRATIVE
}
enum class OrderStatus {
DRAFT,
PENDING_APPROVAL,
APPROVED,
ISSUED,
EXECUTED,
EXPIRED,
REVOKED
}
data class OrderMetadata(
val classification: ClassificationLevel?,
val jurisdiction: String,
val caseNumber: String?,
val relatedOrders: List<String>,
val keywords: List<String>
)
data class OrderCopy(
val originalOrderId: String,
val copyId: String,
val generatedDate: Date,
val generatedBy: String,
val copyType: CopyType,
val authenticationCode: String, // For verification
val orderContent: ByteArray // Encrypted/signed
)
enum class CopyType {
CERTIFIED_TRUE_COPY,
INFORMATIONAL_COPY,
REDACTED_COPY
}
Security Requirements:
- Digital signatures on all orders
- Encryption of order content
- Role-based access control
- Immutable audit trail
- Copy authentication codes (HMAC-based)
6. Evidence Chain of Custody Requirements
6.1 Functional Requirements
FR-EVID-001: The application SHALL track evidence chain of custody per NIST SP 800-88.
FR-EVID-002: The application SHALL record all custody transfers with:
- Timestamp
- Transferring party
- Receiving party
- Reason for transfer
- Evidence condition
- Digital signatures
FR-EVID-003: The application SHALL generate chain of custody reports.
FR-EVID-004: The application SHALL prevent unauthorized custody transfers.
FR-EVID-005: The application SHALL support evidence metadata:
- Evidence ID
- Description
- Location found
- Collection date/time
- Collection method
- Chain of custody history
6.2 Technical Specifications
Data Models:
data class Evidence(
val evidenceId: String,
val caseNumber: String,
val description: String,
val evidenceType: EvidenceType,
val collectionDate: Date,
val collectionLocation: String,
val collectionMethod: String,
val collectedBy: String,
val currentCustodian: String,
val storageLocation: String?,
val chainOfCustody: List<CustodyTransfer>,
val metadata: EvidenceMetadata
)
data class CustodyTransfer(
val transferId: String,
val timestamp: Date,
val fromCustodian: String,
val toCustodian: String,
val reason: String,
val evidenceCondition: String,
val signature: DigitalSignature,
val notes: String?
)
enum class EvidenceType {
PHYSICAL,
DIGITAL,
BIOLOGICAL,
CHEMICAL,
FIREARM,
DOCUMENT
}
Security Requirements:
- Cryptographic integrity protection
- Immutable chain records
- Digital signatures on transfers
- Access control based on case assignment
- Audit logging
7. Report Generation Requirements
7.1 Functional Requirements
FR-REPT-001: The application SHALL generate reports in multiple formats:
- PDF (Portable Document Format)
- XML (eXtensible Markup Language)
- JSON (JavaScript Object Notation)
- CSV (Comma-Separated Values)
FR-REPT-002: The application SHALL support configurable report templates.
FR-REPT-003: The application SHALL support scheduled report generation.
FR-REPT-004: The application SHALL include digital signatures on reports.
FR-REPT-005: The application SHALL support report distribution:
- Secure file transfer
- Export to storage
7.2 Technical Specifications
Report Types:
- Operational reports
- Compliance reports
- Audit reports
- Evidence reports
- Activity reports
- Regulatory reports (NIBRS, UCR, etc.)
Library Requirements:
- Apache PDFBox or iText for PDF generation
- Jackson or Gson for JSON
- JAXB or similar for XML
- Apache POI for Excel/CSV
8. Implementation Priority Matrix
| Requirement Set | Priority | Estimated Effort | Dependencies | Blocking For |
|---|---|---|---|---|
| PDF417 Barcode | P1 | 2-3 months | ZXing library | Credential display |
| Orders Management | P1 | 3-4 months | Digital signatures | Operational authorization |
| AS4 Gateway | P1 | 9-12 months | AS4 library, WS-Security | Inter-agency messaging |
| ATF Forms | P1 | 4-6 months | ATF API approval | ATF operations |
| NCIC/III | P1 | 6-9 months | CJIS approval | Law enforcement ops |
| Evidence CoC | P1 | 2-3 months | Digital signatures | Legal admissibility |
| Report Generation | P1 | 2-3 months | PDF/XML libraries | Operational reporting |
Document Version: 1.0
Status: Requirements Definition Complete
Next Step: Technical Design and Architecture Documentation