BLUEPRINT

제 7 장 Open Questions (미해결 과제)

본 장은 현재 프로토콜 계층에서 결정하지 않고, 구현 측 spec, 후속 프로토콜 버전, 또는 독립 ADR에서 해결하도록 보류된 미해결 문제들을 나열한다. 각 항목은 design.md 제 10 절의 동일 항목에 대응되며, 후속 task 8에서 open-questions.md 아카이브 작성 시 더 구체화될 수 있다.

이 과제들은 FayID 프로토콜의 결함이 아니라 의도적으로 보류된 확장 지점이다. 그 공통 특징은: 프로토콜 계층에서 너무 일찍 결정하면 구현 자유도를 제한하거나, 생태계 진화에 따라 조정이 필요해진다는 점이다.

1. 구체적인 해시 / 서명 / KDF 알고리즘

과제: 프로토콜 계층은 후보(Ed25519 / HKDF-SHA256 / BIP-39)만 제시하며, 최종 선택은 구현 spec에서 결정한다.

영향 범위: 구현 간 상호 운용성, 암호 감사

해결 방향: 구현 spec에서 알고리즘을 고정하고, 버전 관리(예: fayid/dyn/v1, fayid/gmc/v1의 v1 접미사)를 동반한다. 향후 알고리즘 업그레이드는 새 버전 번호를 통해 공존한다.

2. Dynamic Code 시간 창 길이

과제: 프로토콜 계층은 Dynamic Code에 expiresAt이 존재할 것만 요구하며, 구체적 길이(분 단위 / 시간 단위)는 구현 전략이 결정한다.

영향 범위: 사용자 경험, 프라이버시 강도, 교체 빈도

해결 방향: 구현 측이 시나리오에 따라 맞춤 결정한다. 고보안 시나리오는 짧은 창(예: 5분)을 사용하고, 일반 시나리오는 시간 단위까지 완화할 수 있다.

3. Verification Code 검증 실패 속도 제한 임계값

과제: VERIFICATION_RATE_LIMITED의 창 너비, 실패 횟수 임계값, 백오프 전략은 모두 구현 측 결정이다.

영향 범위: 무차별 공격 저항, 사용자 경험

해결 방향: 업계 표준(예: 지수 백오프)을 참고하여 구현 spec에서 기본값을 제시한다.

4. Authorization Grant 기본 TTL 및 갱신 모델

과제: 프로토콜 계층은 expiresAt이 명시적으로 존재할 것만 요구한다. 갱신 / 슬라이딩 만료 / 짧은 TTL + 리프레시 토큰 등 구체적 모델은 구현 spec에 위임한다.

영향 범위: 사용자 경험, 보안성, 전통 인증 소스와의 상호 운용

해결 방향: 구현 spec에서 RefreshGrant 타입을 도입할 수 있다. 또한 서로 다른 legacySourceKind에 대해 차별화된 TTL을 적용할 수 있다.

5. Human ID 폐기 의미

과제: 현재 프로토콜 계층에서 Human ID는 REVOKED 상태에 진입하지 않는다. Mnemonic 유출 후의 "보완" 경로(예: Human ID 재발급, 평판 이전)는 본 명세서 범위를 벗어난다.

영향 범위: 재해 복구, 평판 연속성

해결 방향: 다음과 같이 진화할 수 있다:

상위 계층에서 "평판 이전" 메커니즘 도입 (이전 opaqueRef → 새 opaqueRef의 체인 상 선언)
또는 프로토콜 v2에서 제한된 형태의 Human ID 폐기 + 승계 메커니즘 도입

6. resourceRef 네임스페이스 규범

과제: 본 명세서는 <scheme>://<authority>/<path> 형식 권장만 제시하며, 정식 구문은 독립 spec으로 진화하거나 기존 URI 표준에 연결될 수 있다.

영향 범위: 구현 간 상호 운용

해결 방향: 독립적인 "FayID Resource Identifier" 명세서로 형성되거나, RFC 3986 URI 표준을 직접 채택할 수 있다.

7. 다중 FayID System 인스턴스 간 상호 운용성

과제: 여러 FayID System 배포(서로 다른 운영자)가 존재할 경우, Human ID / iFay ID / Organization ID의 전역 유일성을 위해서는 전역 네임스페이스 또는 접두사 분할 메커니즘이 필요하다.

영향 범위: 다중 운영자 생태계, 크로스 체인 상호 운용

해결 방향: FayID v2의 핵심 과제로 진화할 수 있다. 후보 방안은 다음을 포함한다:

네임스페이스 접두사 (예: hid_us_xxx vs hid_eu_xxx)
DNSSec 스타일의 루트 명명 권한
체인 상 등록 시스템

8. GMC opaqueRef의 키 롤링

과제: gmc_namespace_secret의 교체는 장기 평판 연결을 파괴한다. 동일한 Human ID가 새/이전 키 하에서 파생한 opaqueRef는 다르기 때문이다.

영향 범위: 평판 연속성, 키 보안

해결 방향:

새/이전 namespace_secret 공존 창 설계
또는 체인 상 "opaqueRef 마이그레이션 선언"을 통해 새/이전 참조 간 등가 관계 확립
본 과제는 독립 ADR이 필요하다

9. Property P9의 강제 메커니즘

과제: 프로토콜 계층은 "Human ID는 외부로 나가지 않고 로그에 기록되지 않는다"는 행동을 규정한다. 구현 측의 강제 메커니즘(타입 시스템 태그, 직렬화 redact, CI 정적 스캔)은 구현 spec이 선택한다.

영향 범위: 구현 품질, 보안 감사

해결 방향:

타입 시스템 계층: newtype / branded type을 사용하여 Human ID와 다른 엔티티 구분
직렬화 계층: 기본 redact, 명시적 스위치 화이트리스트
CI 계층: 출항 페이로드와 로그 경로의 정적 스캔

10. 전통 인증 소스의 신뢰도 등급

과제: 모든 전통 자격 증명이 동등하게 Authorization Grant를 교환할 수 있는가? SMART_CONTRACT와 PASSWORD에 서로 다른 TTL 상한을 적용해야 하는가?

영향 범위: 보안 정책, 위험 통제

해결 방향:

legacySourceKind에서 TTL 상한으로의 매핑 도입
저신뢰 소스(예: 단순 PASSWORD)에 더 짧은 TTL 적용
고신뢰 소스(예: SMART_CONTRACT)에 제한 완화

아카이브 및 추적

위의 10개 과제는 후속 task 8에서 .kiro/specs/fayid-identity-system/open-questions.md에 아카이브되며, 각 항목은 다음과 같이 표기된다:

owner: 과제 책임자
영향 범위: 영향을 받는 하위 시스템
해결 마일스톤: v1 / v2 / 구현 spec / ADR

본 장은 블루프린트의 "미해결 과제" 인덱스로서 과제 개요만 다시 서술한다. 자세한 아카이브와 추적은 후속에 생성될 open-questions.md를 참조한다.