services_relations

диаграмма взаимосвязей сервисов (без методов)

Исправленная диаграмма (убраны кириллические символы из ID, исправлены названия узлов):

📖 Пояснительная записка: VC-реестр и DID-владелец

Контекст: X.509 vs Verifiable Credential (VC)

Вывод: X.509 — частный случай VC с более строгой иерархией. В прототипе VC-реестр выступает универсальным слоем абстракции над любыми источниками СКПЭП.

а) Получение СКПЭП из разных источников

Проблема:
Система получает сертификаты из:

• Российских УЦ (ГОСТ 34.10)

• Европейских УЦ (ECDSA/RSA)

• Ведомственных УЦ (Минпромторг, ФНС)

• Самоподписанных (для тестов)

Решение:

VC-сервис (VcSvc) выступает адаптером-нормализатором:

1. Приём:

   • На вход подаётся любой сертификат (PEM/DER) + метаданные об источнике (страна, стандарт, УЦ).

2. Валидация на уровне PKISvc:

   • Проверка базовой цепочки (если доступен корневой сертификат)

   • Проверка статуса (CRL/OCSP, если доступен)

3. Трансформация в VC (VcSvc):

   • Из X.509 извлекаются:

     • subject → credentialSubject

     • serialNumber → id

     • validityNotBefore/After → validFrom/Until

     • issuer → issuer (DID, если есть маппинг)

     • publicKey → publicKeyJwk или publicKeyMultibase

   • Добавляется type: ["VerifiableCredential", "X509Credential"]

   • Добавляется proof (подпись VC, если требуется)

б) Подтверждение DID-владельца (личность/организация/прибор)

Проблема:
У DID нет встроенного механизма подтверждения связи с реальным субъектом.
Кто и как должен подтвердить, что DID did:example:123 действительно принадлежит Иванову И.И., ООО «Ромашка» или датчику давления №42?

Решение — композитная модель подтверждения:

Процесс создания DID-владельца:

1. Первичная регистрация (сам себе):

   • Субъект создаёт DID и DID Document (хранится в HLF).

   • DID Document содержит публичный ключ и ссылки на VC-подтверждения (если есть).

2. Проверка личности (onboarding через OrganizationsSvc):

   • Представитель загружает свой X.509-сертификат.

   • PKISvc валидирует сертификат, извлекает данные.

   • VcSvc создаёт VC-обёртку (тип PersonCredential).

   • Этот VC становится первичным подтверждением для DID.

   • OrganizationsSvc проверяет, что данные из VC совпадают с заявленными.

3. Проверка организации:

   • Если субъект — представитель ЮЛ, он дополнительно предъявляет VC от ФНС (или X.509 с ИНН/ОГРН).

   • VcSvc создаёт OrganizationCredential и привязывает к тому же DID.

4. Проверка прибора (если актив):

   • Производитель выпускает ЦП на прибор.

   • ЦП содержит VC с характеристиками прибора и серийным номером.

   • DID прибора создаётся при регистрации ЦП (или извлекается из него).

   • Производитель подписывает DeviceCredential и сохраняет в реестр.

Итоговая модель:

DID: did:example:person_123
├── PersonCredential (от УЦ/нотариуса)
│   ├── fullName: Иванов И.И.
│   ├── snils: 123-456-789-01
│   └── issuer: did:example:uc_ros
├── OrganizationCredential (от ФНС)
│   ├── inn: 7701234567
│   ├── ogrn: 1027700123456
│   └── issuer: did:example:fns
└── DeviceCredential (от производителя) — если прибор
    ├── serialNumber: SN-2026-001
    ├── model: ВЗЛЕТ-ФБ
    └── issuer: did:example:manufacturer_456

Проверка DID-владельца (алгоритм):

1. Запросить DID Document из реестра (HLF).

2. Получить все VC, связанные с этим DID.

3. Для каждого VC проверить:

   • подпись VC (issuer должен быть доверенным)

   • статус VC (не отозван, не истёк)

4. Если хотя бы один VC подтверждает нужный атрибут (личность/организация/прибор) — DID считается валидным.

5. Уровень доверия зависит от количества и качества VC (чем больше подтверждений — тем выше уровень).

🏷️ Резюме для архитектурного решения

Журнал изменений