fix: accept HIGH security level keys for profile updates

[thepastaclaw]

Issue

Closes #760 — Editing a profile with a wallet-imported identity fails with "This identity is missing an authentication key required for this operation."

Root Cause

update_profile() in src/backend_task/dashpay/profile.rs only looked for authentication keys at SecurityLevel::CRITICAL, but Platform's default document security level requirement is HIGH. Wallet-imported identities typically have HIGH-level keys, not CRITICAL, so the key lookup failed.

Fix

Accept both CRITICAL and HIGH security levels when searching for a signing key in update_profile(), consistent with how contact_requests.rs already handles authentication key lookup (line 639).

Testing

• cargo check, cargo clippy — clean

Summary by CodeRabbit

• Bug Fixes
  • Expanded authentication key selection criteria during profile updates to support additional security levels, improving flexibility for users managing their account security.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 39437361-227d-4182-860b-a8780413489a

📥 Commits

Reviewing files that changed from the base of the PR and between dfdf7c3 and 921c1de.

📒 Files selected for processing (1)

• src/backend_task/dashpay/profile.rs

---

📝 Walkthrough

Walkthrough

The identity signing key selection logic in update_profile is modified to accept both SecurityLevel::CRITICAL and SecurityLevel::HIGH keys for Purpose::AUTHENTICATION, instead of only SecurityLevel::CRITICAL. The remainder of the control flow and error handling remain unchanged.

Changes

Cohort / File(s)	Summary
Authentication Key Selection src/backend_task/dashpay/profile.rs	Modified update_profile to permit both SecurityLevel::CRITICAL and SecurityLevel::HIGH keys for Purpose::AUTHENTICATION, expanding from the prior CRITICAL-only restriction.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A key, a door, a profile too,
HIGH and CRITICAL both will do,
The vault unlocks with gentler care,
Authentication's now more fair! ✨🔑

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and accurately summarizes the main change: allowing HIGH security level keys alongside CRITICAL for profile updates.
Linked Issues check	✅ Passed	The code change directly addresses issue #760 by accepting both CRITICAL and HIGH security level keys, matching Platform defaults and enabling wallet-imported identities to update profiles.
Out of Scope Changes check	✅ Passed	The change is narrowly scoped to the security level check in update_profile(), directly addressing the linked issue without introducing unrelated modifications.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[lklimek]

claw please find and quote documents (eg. DIP) defining which keys we should use

[thepastaclaw]

Security Level Requirements — DIP-0011 + Platform Contract Defaults

DIP-0011 (Identities) — Key Security Levels

DIP-0011 § Keys defines the security levels and their intended use:

Security Level	Examples	Worst Result if Compromised
Master	Managing Dash Identity	Loss of Identity
Critical	Exchange of assets (e.g., property deed)	Loss of funds/assets
High	Publishing a message on a social network. Sending a contact request in DashPay.	Loss of reputation. Risk of inducing spam.
Medium	Routine background transitions for application metadata	Loss of credits. Loss of anonymity.

DIP-0011 also states:

"Contracts can define for each document type the minimal security level required for signing. Only keys of a higher security level can be used. If no such field is present then all keys except the medium security level keys can be used."

Platform Default Security Level

In the Platform codebase, the document type schema parser sets a default when no signatureSecurityLevelRequirement is specified:

// packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs
let security_level_requirement = schema
    .get_optional_integer::<u8>(property_names::SECURITY_LEVEL_REQUIREMENT)
    .map_err(consensus_or_protocol_value_error)?
    .map(SecurityLevel::try_from)
    .transpose()?
    .unwrap_or(SecurityLevel::HIGH);  // <-- default is HIGH

DashPay Contract — Profile Document Type

The DashPay contract schema (schema/v1/dashpay.schema.json) does not specify a signatureSecurityLevelRequirement for the profile document type, so it inherits the Platform default of HIGH.

This means HIGH or higher (i.e., CRITICAL or MASTER) keys are valid for signing profile updates. The original code only accepted CRITICAL, which was overly restrictive — wallet-imported identities that only carry HIGH-level authentication keys would fail.

Consistency

This PR aligns update_profile() with how contact_requests.rs (line 639) already handles it:

HashSet::from([SecurityLevel::CRITICAL, SecurityLevel::HIGH]),

[thepastaclaw]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[thepastaclaw]

Code Review

Validated the available reviewer output against commit 921c1de and found no code-backed issues to raise on this SHA.

Reviewed commit: 921c1de