SPECIFICATION

제 1 장: 아키텍처와 역할

본 장은 CAP 프로토콜의 역할, 그들 간의 신뢰 관계, 그리고 외부 시스템과의 인터페이스 계약을 정의한다. 본 장의 내용은 후속 장을 위한 공통 용어 기반과 아키텍처 컨텍스트를 제공한다.

1.1 프로토콜 역할

CAP 프로토콜에는 다음 규범적 역할이 포함된다. 각 역할은 프로토콜 상호작용에서 명확한 책임을 담당하며, 다른 역할과 제한된 인터페이스를 통해 상호작용한다.

1.1.1 인가자 역할

Natural_Person(자연인)과 Official_Post(공식 직위)는 인가의 최종 출처다. 인가자는 프로토콜 메시지 상호작용에 직접 참여하지 않는다 — 인가자는 인가 위임 메커니즘을 통해 발급권을 Descriptor_Issuer에 위임한다.

인가자는 MUST 안전한 신원 검증 메커니즘을 통해 그 신원을 증명한다. 인가자 신원의 구체적 검증 메커니즘은 본 사양의 범위를 벗어나지만, 해당 메커니즘은 MUST 다음 요구사항을 충족한다:

  • 부인 방지성: 인가자는 자신이 내린 인가 결정을 부인할 수 없다
  • 위조 방지성: 제3자는 인가자의 인가 결정을 위조할 수 없다

1.1.2 발급자 역할

Descriptor_Issuer는 Authorization_Descriptor의 생성과 발급을 담당한다. Ticket_Issuer는 Trusted_Ticket의 발급을 담당한다. 하나의 엔티티는 MAY 두 발급자 역할을 동시에 담당할 수 있다.

발급자는 MUST:

  1. 합법적인 인가자로부터 명시적인 인가를 받은 후에만 자격 증명을 발급한다
  2. 제 8 장에서 정의된 서명 알고리즘을 사용하여 자격 증명에 디지털 서명한다
  3. 발급된 자격 증명의 상태 기록을 유지한다(최소한 발급 시각, 유효 기간, 현재 상태 포함)
  4. 폐기 요청을 받으면 신속히 폐기 상태를 갱신하고 폐기 선언을 게시한다

발급자는 MUST NOT:

  1. 인가를 받지 않은 상태에서 자격 증명을 발급한다
  2. 인가자의 인가 범위를 초과하는 자격 증명을 발급한다
  3. 폐기된 자격 증명의 식별자를 재사용한다

1.1.3 보유자 역할

Fay(iFay 및 coFay 포함)는 자격 증명의 보유자이며 리소스 접근의 요청자다. Fay는 iFay_Runtime을 통해 간접적으로 프로토콜 상호작용에 참여한다 — Fay 자체는 프로토콜 메시지를 직접 전송하지 않는다.

Fay는 MUST 자신이 소속된 iFay_Runtime을 통해 단말과의 모든 프로토콜 상호작용을 완료한다. Fay가 보유한 자격 증명은 MUST iFay_Runtime을 통해 단말에 제출된다.

1.1.4 런타임 역할

iFay_Runtime은 Fay 인스턴스의 런타임 환경이며, 프로토콜 메시지의 발신과 수신을 담당한다. 하나의 iFay_Runtime 인스턴스는 MAY 여러 Fay 인스턴스를 관리할 수 있다.

iFay_Runtime은 MUST 제 0.5.3 절에서 정의된 런타임 적합성 등급 요구사항을 충족한다.

1.1.5 단말 역할

단말(Terminal)은 Terminal_Resource의 보유자이며 접근 제어의 실행자다. 단말은 다음 규범적 컴포넌트를 통합한다:

  • Protocol_Engine: CAP 프로토콜의 핵심 로직을 실행하는 시스템 컴포넌트
  • Descriptor_Validator: Authorization_Descriptor의 합법성과 유효성 검증을 담당하는 컴포넌트
  • Session 관리자: Session 상태 머신과 Liveness_Detection 메커니즘을 유지한다
  • 로컬 폐기 목록: 알려진 폐기된 자격 증명 식별자를 저장한다

단말은 MUST 제 0.5.1 절에서 정의된 단말 적합성 등급 요구사항을 충족한다.

1.1.6 신뢰 인프라 역할

Registration_Authority(등록 기관)는 단말의 등록 관리 및 Verification_Key의 배포를 담당한다. Registration_Authority는 CAP 프로토콜 신뢰 체인의 루트 앵커다.

Registration_Authority는 MUST:

  1. 신원 검증을 통과한 단말에만 Verification_Key를 배포한다
  2. 안전한 채널(제 8 장 참조)을 통해 키 배포를 완료한다
  3. 키 갱신 및 로테이션 메커니즘을 제공한다
  4. 단말 등록 상태의 권위 있는 기록을 유지한다

1.2 신뢰 체인

CAP 프로토콜의 신뢰 체인은 인가자에서 단말의 Descriptor_Validator로 전달되며, 독립적이지만 협력하는 두 개의 신뢰 경로로 구성된다.

1.2.1 인가 신뢰 경로

인가 신뢰 경로는 어떤 Fay가 어떤 리소스에 접근할 수 있도록 인가되었는지를 결정한다:

인가자(Natural_Person / Official_Post)
    │
    │ ① 인가 위임(부인 방지 증거 첨부)
    ▼
Descriptor_Issuer
    │
    │ ② Authorization_Descriptor 발급(디지털 서명 첨부)
    ▼
Fay
    │
    │ ③ Authorization_Descriptor 제출
    ▼
Descriptor_Validator

단말은 MUST 인가 신뢰 경로상의 각 단계의 진실성을 검증한다:

  • 단계 ①의 진실성은 Descriptor_Issuer가 발급 시 검증하며, 단말은 직접 관여하지 않는다
  • 단계 ②의 진실성은 단말이 Descriptor_Issuer의 디지털 서명을 검증하여 확인한다(키 신뢰 경로에 의존)
  • 단계 ③의 진실성은 단말이 Authorization_Descriptor와 제출자 Fay 식별자의 바인딩 관계를 검증하여 확인한다

1.2.2 키 신뢰 경로

키 신뢰 경로는 단말이 어떤 Descriptor_Issuer의 서명을 신뢰하는지를 결정한다:

Registration_Authority(신뢰 앵커)
    │
    │ ① Verification_Key 배포(안전한 채널 경유)
    ▼
단말 로컬 키 저장소
    │
    │ ② Verification_Key를 Descriptor_Validator에 제공
    ▼
Descriptor_Validator
    │
    │ ③ Verification_Key로 Authorization_Descriptor 서명 검증
    ▼
검증 통과 / 거부

단말은 MUST:

  1. Registration_Authority에서 배포된 Verification_Key만 신뢰한다
  2. Verification_Key를 안전하게 보관한다(키 보관 요구사항은 제 8 장 참조)
  3. Registration_Authority에서 배포되지 않은 키를 사용한 서명 검증을 거부한다

1.3 외부 인터페이스 계약

CAP 프로토콜 계층은 명확히 정의된 인터페이스를 통해 4 개의 외부 시스템과 상호작용한다. 본 절은 이러한 인터페이스의 규범적 계약을 정의한다.

1.3.1 iFay_Runtime과의 인터페이스

iFay_Runtime과 단말 Protocol_Engine 간의 인터페이스는 양방향 메시지 인터페이스이다.

메시지 방향: iFay_Runtime → Protocol_Engine

메시지 종류용도필수 필드
AuthRequest인가 검증 요청 발신fay_id, resource_id, access_mode, credential
SessionRelease세션 능동 해제session_id
Heartbeat애플리케이션 계층 하트비트session_id, sequence_number
HandoverResponse인계 요청 응답handover_id, accept

메시지 방향: Protocol_Engine → iFay_Runtime

메시지 종류용도필수 필드
AuthResult인가 검증 결과request_id, status, session_id(성공 시), error_code(실패 시)
SessionStateChanged세션 상태 변경 알림session_id, new_state, reason
HandoverRequest인계 요청 알림handover_id, target_resource_id, deadline
HeartbeatAck하트비트 확인session_id, sequence_number

인터페이스 구현은 MUST:

  1. Heartbeat 및 비동기 푸시 메시지를 담기 위해 지속 연결을 지원한다
  2. TLS 암호화 전송을 지원한다
  3. 시리얼라이제이션 형식은 schema.json 정의를 따른다

인터페이스 구현은 MAY:

  1. 구체적인 전송 프로토콜(WebSocket, gRPC, HTTP/2 등)을 선택한다

1.3.2 단말 운영체제와의 인터페이스

Protocol_Engine과 단말 운영체제 간의 인터페이스는 로컬 양방향 인터페이스이다.

운영체제는 MUST 다음 능력을 Protocol_Engine에 노출한다:

  1. 리소스 접근 제어 하달: Protocol_Engine이 "Fay X가 모드 Y로 리소스 Z에 접근하는 것을 허용"하는 지시를 하달한다
  2. 리소스 상태 조회: Protocol_Engine이 리소스의 현재 가용성과 점유 상태를 조회한다
  3. 리소스 이벤트 구독: Protocol_Engine이 리소스 상태 변화 이벤트(하드웨어 분리, 소프트웨어 크래시 등)를 구독한다

인터페이스의 구체적 구현 방식은 운영체제 플랫폼(Unix Domain Socket, Named Pipe, D-Bus 등)에 의존한다. 본 사양은 구체적 구현 방식을 규정하지 않지만, MUST 다음을 충족한다:

  1. 접근 제어 지시는 동기 방식으로 실행되고 실행 결과를 반환한다
  2. 리소스 이벤트는 비동기 푸시 방식으로 알림된다
  3. 인터페이스는 운영체제 네이티브 보안 모델로 보호되며, 인가된 Protocol_Engine 프로세스만 호출할 수 있다

1.3.3 하드웨어 드라이버와의 인터페이스(간접)

Protocol_Engine은 MUST NOT 하드웨어 드라이버와 직접 통신한다. 모든 하드웨어 제어는 운영체제를 통해 전달된다.

하드웨어 드라이버에서 Protocol_Engine으로의 상태 보고 경로:

하드웨어 드라이버 → 운영체제 → Protocol_Engine

하드웨어 드라이버는 SHOULD 하드웨어 레벨의 접근 잠금 메커니즘을 구현하여, 운영체제 계층의 접근 제어가 우회되더라도 하드웨어 자체가 미인가 접근을 거부할 수 있도록 보장한다.

1.3.4 Registration_Authority와의 인터페이스

Registration_Authority와 단말 간의 인터페이스는 단방향 인터페이스이다(RA → 단말).

Registration_Authority는 MUST 다음 메시지를 단말에 푸시한다:

메시지 종류용도필수 필드
VerificationKeyDistribution새 검증 키 배포key_id, key_material, valid_from, issuer_id
VerificationKeyRevocation검증 키 폐기key_id, revocation_time, reason
RegistrationStatusUpdate단말 등록 상태 갱신terminal_id, new_status

단말은 MUST:

  1. TLS/mTLS 안전한 채널을 통해 메시지를 수신한다
  2. 메시지의 서명 출처가 신뢰된 Registration_Authority인지 검증한다
  3. 새 키를 수신한 후 Registration_Authority에 확인을 반환한다

단말은 Registration_Authority에 능동적으로 프로토콜 메시지를 발신하지 않는다(단말의 초기 등록 흐름은 CAP 프로토콜 런타임의 정상 상호작용에 속하지 않으며, 본 사양의 범위를 벗어난다).

1.4 역할과 적합성 등급 대응표

구현하는 역할반드시 충족해야 하는 적합성 등급
단말(Protocol_Engine 및 Descriptor_Validator 포함)단말 적합성 등급(§0.5.1)
Descriptor_Issuer 또는 Ticket_Issuer발급자 적합성 등급(§0.5.2)
iFay_Runtime런타임 적합성 등급(§0.5.3)
Registration_Authority본 사양의 적합성 범위 외(등록 흐름은 CAP 프로토콜 런타임을 벗어남)