NFR004 - key mgt

[bluesteens]

Steering summary:
Unclear wording around wallet security aspects. Suggest to reword to avoid ambiguity.

---

It is not entirely clear whether this NFR is to deals only with keys in relation to the DID document or also provider app-specific security.

It says under Conformance Criteria

• Solution SHALL provide secure key management for encryption and signing keys
  -Solution SHALL provide features to update DID documents and to rotate keys in accordance with the W3C DID standards and best practices/implementation guidelines on a regular basis, keys SHALL be rotated no less often than once every 12 months.
• Solution SHALL provide rotation features for encryption keys (e.g. database encryption, certificate renewal)

The last bullet reads as if it was meant to address sth like API keys for a provider app. The rest seems to apply to DID docs.

OCI should consider splitting both scopes into 2 NFR or making it clearer within this 004 what is meant.

[bluesteens]

• Is Issue appropriate for OCI Architecture
• Create Steering-level Summary of request
• Assign Size
• Assign Priority
• Assign Label (if needed)
• OCI affected Artifacts Identified
• Assign Triage - Artifact Version Target (v x.x.x Milestone)
• Assign Triage - Interop Profile Version Target (v x.x.x Milestone)
• Create sub-project (if needed)

Affected Parties (help determine Sunrise/Sunset):

• Trading Partners
• Issuers
• Wallet Solutions
• PI Verification Solutions

[bluesteens]

Mtg July 27:
also consider specifying what happens to rotated keys (deleted, retired)

• deletion complicates re-verifiability of old VC and thus makes auditability of past events difficult. reliance would need to be placed on historical database records
• P&A leans towards not deleting keys and instead retiring them

[bluesteens]

consider adding that key rotation is only required for PROD accounts/usage

[bluesteens]

14.9. P&A: edits to make text work for both DID methods
persisted in the DID document = discoverable via the DID document