# Tasks: Credential Filtering API & Parsed Output

**Input**: Design documents from `/specs/003-credential-filtering-api/`
**Prerequisites**: plan.md ✓, spec.md ✓, research.md ✓, data-model.md ✓, contracts/ ✓

**Tests**: Not explicitly requested in the feature specification. Test tasks are excluded per template rules.

**Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.

## Format: `[ID] [P?] [Story] Description`

- **[P]**: Can run in parallel (different files, no dependencies)
- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
- Include exact file paths in descriptions

## Path Conventions

- **Single library crate**: `src/`, `tests/`, `examples/` at repository root
- Paths follow plan.md structure

---

## Phase 1: Setup (Shared Infrastructure)

**Purpose**: Create new module structure and foundational types

- [X] T001 Create constraints module at src/policies/constraints.rs with CredentialConstraint enum
- [X] T002 [P] Create src/types/device_attestation.rs with DeviceAttestation struct
- [X] T003 [P] Create src/types/device_security.rs with DeviceSecurity struct
- [X] T004 [P] Create src/types/field_verification.rs with FieldVerificationMetadata struct
- [X] T005 [P] Create src/types/parsed/mod.rs module re-exports
- [X] T006 Update src/policies/mod.rs to export constraints module
- [X] T007 Update src/types/mod.rs to export new types and parsed module

---

## Phase 2: Foundational (Blocking Prerequisites)

**Purpose**: Core infrastructure that MUST be complete before ANY user story can be implemented

**⚠️ CRITICAL**: No user story work can begin until this phase is complete

- [X] T008 Add credential_parse error variant to LastIDError in src/error.rs
- [X] T009 [P] Implement CredentialConstraint validation methods (validate_did, validate_domain) in src/policies/constraints.rs
- [X] T010 Add constraints field to CredentialPolicyRequest in src/policies/base.rs (if not present)

**Checkpoint**: Foundation ready - user story implementation can now begin

---

## Phase 3: User Story 1 - Enterprise Domain Verification (Priority: P1) 🎯 MVP

**Goal**: Allow enterprise customers to filter employment credentials by employer domain and issuer DID

**Independent Test**: Create a policy with `.with_employer_domain("acme.com")` and `.with_issuer_did("did:lastid:acme-corp")` and verify constraints are generated correctly

### Implementation for User Story 1

- [X] T011 [US1] Add with_issuer_did method to EmploymentPolicy<Incomplete> in src/policies/employment.rs
- [X] T012 [US1] Add with_employer_did method to EmploymentPolicy<Incomplete> in src/policies/employment.rs
- [X] T013 [US1] Update EmploymentPolicy::to_request() to include constraints validation and serialization in src/policies/employment.rs
- [X] T014 [US1] Add doc comments with examples to with_issuer_did and with_employer_did methods in src/policies/employment.rs

**Checkpoint**: User Story 1 complete - employment domain filtering works independently

---

## Phase 4: User Story 2 - Subject Matching Constraints (Priority: P1)

**Goal**: Enable relying parties to constrain credentials to a specific known subject DID

**Independent Test**: Create a BaseCredentialPolicy with `.with_subject_did("did:lastid:user123")` and verify only that subject's credentials match

### Implementation for User Story 2

- [X] T015 [US2] Add with_subject_did method to BaseCredentialPolicy<Incomplete> in src/policies/base.rs
- [X] T016 [US2] Add with_issuer_did method to BaseCredentialPolicy<Incomplete> in src/policies/base.rs
- [X] T017 [US2] Add with_claim_constraint method to BaseCredentialPolicy<Incomplete> in src/policies/base.rs
- [X] T018 [US2] Update BaseCredentialPolicy::to_request() to include constraints in src/policies/base.rs
- [X] T019 [US2] Add doc comments with examples to constraint methods in src/policies/base.rs

**Checkpoint**: User Story 2 complete - subject binding works independently

---

## Phase 5: User Story 3 - Email Domain Filtering on Persona (Priority: P1)

**Goal**: Allow SaaS apps to filter persona credentials by email domain

**Independent Test**: Create PersonaPolicy with `.with_email_domain("bigcorp.com")` and verify pattern constraint is generated

### Implementation for User Story 3

- [X] T020 [US3] Add with_email_domain method to PersonaPolicy<Incomplete> in src/policies/persona.rs
- [X] T021 [US3] Add with_issuer_did and with_subject_did methods to PersonaPolicy<Incomplete> in src/policies/persona.rs
- [X] T022 [US3] Update PersonaPolicy::to_request() to include constraints in src/policies/persona.rs
- [X] T023 [P] [US3] Add with_domain_constraint method to VerifiedEmailPolicy<Incomplete> in src/policies/verified_email.rs
- [X] T024 [US3] Add doc comments with examples in src/policies/persona.rs and src/policies/verified_email.rs

**Checkpoint**: User Story 3 complete - email domain filtering works independently

---

## Phase 6: User Story 4 - Full Credential Output Parsing (Priority: P1)

**Goal**: Provide typed accessors for common claims without JSON parsing

**Independent Test**: After verification, access claims via `.email()`, `.phone_number()`, `.display_name()`, `.device_attestation()` directly on VerifiedCredential

### Implementation for User Story 4

- [X] T025 [US4] Add singular claim accessors (email, phone_number, display_name, given_name, family_name, company, job_title) to VerifiedCredential in src/types/verified_credential.rs
- [X] T026 [US4] Add plural claim accessors (emails, phone_numbers) to VerifiedCredential in src/types/verified_credential.rs
- [X] T027 [US4] Add verified_at accessor returning Option<DateTime<Utc>> to VerifiedCredential in src/types/verified_credential.rs
- [X] T028 [US4] Add device_attestation accessor returning Option<DeviceAttestation> to VerifiedCredential in src/types/verified_credential.rs
- [X] T029 [US4] Add device_security accessor returning Option<DeviceSecurity> to VerifiedCredential in src/types/verified_credential.rs
- [X] T030 [US4] Add field_verification accessor returning Option<FieldVerificationMetadata> to VerifiedCredential in src/types/verified_credential.rs
- [X] T031 [US4] Add doc comments with examples to all new accessors in src/types/verified_credential.rs

**Checkpoint**: User Story 4 complete - typed accessors work independently

---

## Phase 7: User Story 5 - Claim Value Constraints (Priority: P2)

**Goal**: Enable advanced filtering by claim values (minimum trust level, age, verification level)

**Independent Test**: Create TrustPolicy with `.with_minimum_level(3)` and verify minimum constraint is generated

### Implementation for User Story 5

- [X] T032 [US5] Add with_minimum_level method to TrustPolicy<Incomplete> in src/policies/trust.rs
- [X] T033 [US5] Update TrustPolicy::to_request() to include level_minimum constraint in src/policies/trust.rs
- [X] T034 [P] [US5] Add with_minimum_age method to AgeProofPolicy<Incomplete> in src/policies/age_proof.rs
- [X] T035 [P] [US5] Update AgeProofPolicy::to_request() to include age_minimum constraint in src/policies/age_proof.rs
- [X] T036 [P] [US5] Add with_email_domain method to VerifiedPersonaPolicy<Incomplete> in src/policies/verified_persona.rs
- [X] T037 [US5] Add doc comments with examples to constraint methods in src/policies/trust.rs, src/policies/age_proof.rs, src/policies/verified_persona.rs

**Checkpoint**: User Story 5 complete - claim value constraints work independently

---

## Phase 8: User Story 6 - Typed Credential Response Structs (Priority: P2)

**Goal**: Provide type-specific structs for each credential type with compile-time safety

**Independent Test**: Parse a verified Persona credential into `ParsedPersona::try_from(&credential)` and access `.display_name`, `.company` directly

### Implementation for User Story 6

- [X] T038 [P] [US6] Create ParsedPersona struct with TryFrom<&VerifiedCredential> in src/types/parsed/persona.rs
- [X] T039 [P] [US6] Create ParsedEmployment struct with TryFrom<&VerifiedCredential> in src/types/parsed/employment.rs
- [X] T040 [P] [US6] Create ParsedVerifiedEmail struct with TryFrom<&VerifiedCredential> in src/types/parsed/verified_email.rs
- [X] T041 [P] [US6] Create ParsedVerifiedPhone struct with TryFrom<&VerifiedCredential> in src/types/parsed/verified_phone.rs
- [X] T042 [P] [US6] Create ParsedVerifiedPersona struct with TryFrom<&VerifiedCredential> in src/types/parsed/verified_persona.rs
- [X] T043 [P] [US6] Create ParsedAgeProof struct with TryFrom<&VerifiedCredential> in src/types/parsed/age_proof.rs
- [X] T044 [US6] Update src/types/parsed/mod.rs to export all parsed structs
- [X] T045 [US6] Add module-level documentation to each parsed struct file

**Checkpoint**: User Story 6 complete - typed parsing works independently

---

## Phase 9: User Story 7 - Multiple Credentials in Presentation (Priority: P2)

**Goal**: Provide structured access to multi-credential presentations with chain relationships

**Independent Test**: Receive a multi-credential response and iterate via `.credentials()`, access specific credential via `.credential_by_type("LastID.Persona")`

### Implementation for User Story 7

- [X] T046 [US7] Create VerifiedResponse struct in src/types/verified_response.rs
- [X] T047 [US7] Implement credentials() iterator on VerifiedResponse in src/types/verified_response.rs
- [X] T048 [US7] Implement credential_by_type() lookup on VerifiedResponse in src/types/verified_response.rs
- [X] T049 [US7] Implement credential_chain() and primary_credential() on VerifiedResponse in src/types/verified_response.rs
- [X] T050 [US7] Add device_attestation and device_security accessors on VerifiedResponse in src/types/verified_response.rs
- [X] T051 [US7] Add field_verification accessor on VerifiedResponse in src/types/verified_response.rs
- [X] T052 [US7] Update src/types/mod.rs to export VerifiedResponse
- [X] T053 [US7] Add doc comments with examples to VerifiedResponse in src/types/verified_response.rs

**Checkpoint**: User Story 7 complete - multi-credential handling works independently

---

## Phase 10: User Story 8 - Documentation and Examples (Priority: P2)

**Goal**: Comprehensive examples demonstrating all new capabilities

**Independent Test**: A new developer can implement domain-filtered employment verification by following examples without additional guidance

### Implementation for User Story 8

- [X] T054 [P] [US8] Create examples/enterprise_domain_filter.rs demonstrating EmploymentPolicy with domain and issuer constraints (FR-026)
- [X] T055 [P] [US8] Create examples/subject_binding.rs demonstrating re-authentication with subject DID matching (FR-027)
- [X] T056 [P] [US8] Create examples/typed_response_parsing.rs demonstrating typed accessors and ParsedPersona/ParsedEmployment usage (FR-028)
- [X] T057 [P] [US8] Create examples/multi_credential_chain.rs demonstrating VerifiedResponse chain traversal and type-specific parsing (FR-029)
- [X] T058 [US8] Update examples/employment_verification.rs to demonstrate typed response parsing (FR-030)
- [X] T059 [US8] Update examples/persona_credential.rs to demonstrate typed accessors (FR-030)
- [X] T060 [US8] Update examples/verified_email_credential.rs to demonstrate typed accessors (FR-030)
- [X] T061 [US8] Update crate-level documentation in src/lib.rs to reference new filtering and parsing capabilities (FR-033)

**Checkpoint**: User Story 8 complete - documentation enables self-service learning

---

## Phase 11: Polish & Cross-Cutting Concerns

**Purpose**: Improvements that affect multiple user stories

- [X] T062 Run cargo clippy --all-features and fix any warnings
- [X] T063 Run cargo fmt to ensure consistent formatting
- [X] T064 Verify all examples compile with cargo build --examples
- [X] T065 Run quickstart.md validation - verify all code snippets are accurate
- [X] T066 Verify backward compatibility - existing tests pass without modification

---

## Dependencies & Execution Order

### Phase Dependencies

- **Setup (Phase 1)**: No dependencies - can start immediately
- **Foundational (Phase 2)**: Depends on Setup completion - BLOCKS all user stories
- **User Stories (Phases 3-10)**: All depend on Foundational phase completion
  - User stories can proceed in parallel (if staffed)
  - Or sequentially in priority order (P1 → P2)
- **Polish (Phase 11)**: Depends on all desired user stories being complete

### User Story Dependencies

- **User Story 1 (P1)**: Enterprise Domain - No dependencies on other stories
- **User Story 2 (P1)**: Subject Matching - No dependencies on other stories (uses same base constraint pattern)
- **User Story 3 (P1)**: Email Domain Filtering - No dependencies on other stories
- **User Story 4 (P1)**: Credential Output Parsing - No dependencies on other stories
- **User Story 5 (P2)**: Claim Value Constraints - No dependencies on other stories
- **User Story 6 (P2)**: Typed Credential Structs - Depends on US4 typed accessors being available
- **User Story 7 (P2)**: Multi-Credential Handling - Depends on US6 parsed structs for chain parsing examples
- **User Story 8 (P2)**: Documentation - Depends on all prior stories for accurate examples

### Within Each User Story

- Core implementation before doc comments
- Doc comments last (reference working code)

### Parallel Opportunities

- Phase 1: T002, T003, T004, T005 can run in parallel (different files)
- Phase 2: T009, T010 can run in parallel
- Phase 5 (US3): T023 can run in parallel with T020-T022 (different file)
- Phase 7 (US5): T034, T035, T036 can run in parallel (different files)
- Phase 8 (US6): T038-T043 can run in parallel (all different files)
- Phase 10 (US8): T054-T057 can run in parallel (all new example files)

---

## Parallel Example: User Story 6

```bash
# Launch all parsed struct tasks together (all different files):
Task: "Create ParsedPersona struct in src/types/parsed/persona.rs"
Task: "Create ParsedEmployment struct in src/types/parsed/employment.rs"
Task: "Create ParsedVerifiedEmail struct in src/types/parsed/verified_email.rs"
Task: "Create ParsedVerifiedPhone struct in src/types/parsed/verified_phone.rs"
Task: "Create ParsedVerifiedPersona struct in src/types/parsed/verified_persona.rs"
Task: "Create ParsedAgeProof struct in src/types/parsed/age_proof.rs"
```

---

## Implementation Strategy

### MVP First (User Stories 1-4 Only)

1. Complete Phase 1: Setup
2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
3. Complete Phases 3-6: User Stories 1-4 (all P1 priority)
4. **STOP and VALIDATE**: Test all P1 stories independently
5. Deploy/demo if ready - core filtering and parsing complete

### Incremental Delivery

1. Complete Setup + Foundational → Foundation ready
2. Add User Story 1 → Test independently → Enterprise domain filtering works
3. Add User Story 2 → Test independently → Subject binding works
4. Add User Story 3 → Test independently → Email domain filtering works
5. Add User Story 4 → Test independently → Typed accessors work
6. **MVP COMPLETE** - basic filtering and parsing delivered
7. Add User Story 5 → Claim value constraints
8. Add User Story 6 → Typed parsing structs
9. Add User Story 7 → Multi-credential handling
10. Add User Story 8 → Documentation and examples

### Parallel Team Strategy

With multiple developers:

1. Team completes Setup + Foundational together
2. Once Foundational is done:
   - Developer A: User Stories 1 + 2 (constraint methods on policies)
   - Developer B: User Stories 3 + 4 (email domain + typed accessors)
   - Developer C: User Stories 5 + 6 (claim constraints + parsed structs)
3. After P1 complete:
   - Developer A: User Story 7 (VerifiedResponse)
   - Developer B: User Story 8 (examples/docs)

---

## Notes

- [P] tasks = different files, no dependencies
- [Story] label maps task to specific user story for traceability
- Each user story should be independently completable and testable
- Commit after each task or logical group
- Stop at any checkpoint to validate story independently
- All new methods must have `#[must_use]` attribute per constitution
- All code must pass `clippy::pedantic` per constitution
- Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence
