SPECIFICATION

제 7 장: 리소스 접근 모드

본 장은 Resource_Access_Mode의 시맨틱, 읽기-쓰기 잠금 매트릭스, 제약 조건 적용 및 Session 권한과의 관계를 정의한다. 본 장은 블루프린트 §2.5의 설계 의도에 대응한다.

7.1 모드 정의

CAP 프로토콜은 4 종류의 접근 모드를 정의한다:

AccessMode = enum["read", "write", "execute", "configure"]

7.1.1 read

시맨틱: Terminal_Resource에 대해 읽기 전용 접근을 수행하며, 리소스 상태를 수정하지 않음.

전형적 작업:

센서 실시간 데이터 읽기(온도, 습도, 측위)
미디어 파일 보기(사진, 동영상)
장치 상태 속성 조회(배터리 잔량, 연결 상태)

동시성: 공유 가능. 여러 Session이 MAY 동일 리소스의 read 모드 접근권을 동시에 보유할 수 있다.

7.1.2 write

시맨틱: Terminal_Resource에 대해 데이터 쓰기 또는 상태 수정을 수행.

전형적 작업:

저장 장치에 파일 쓰기
장치의 동작 매개변수 수정(볼륨, 밝기, 온도 설정)
애플리케이션 창에 콘텐츠 입력 전송

동시성: 배타적. 동일 리소스는 동일 시점에 최대 하나의 Session이 write 모드를 보유한다.

7.1.3 execute

시맨틱: Terminal_Resource에 대해 작업 명령 실행을 발동.

전형적 작업:

애플리케이션 프로그램 시작
하드웨어 작업 명령 발동(촬영, 이륙, 인쇄)
RPC 인터페이스 호출

동시성: 배타적.

write와 execute의 차이: write는 데이터 상태를 수정하고, execute는 액션을 발동한다(둘 다 최종적으로 상태를 변경하더라도). 단말의 접근 제어 입자도가 둘을 엄격히 구분할 수 없을 수 있으며, 이때 구현은 MAY execute를 write의 서브클래스로 간주할 수 있다(write 권한 보유 시 자동으로 execute 능력을 갖춤). 하지만 본 사양의 기본 시맨틱은 둘이 독립이다 — execute 권한 보유는 자동으로 write 권한을 획득하지 않으며, 그 반대도 마찬가지다.

7.1.4 configure

시맨틱: Terminal_Resource에 대해 시스템 레벨 구성 변경을 수행.

전형적 작업:

장치의 하드웨어 매개변수 수정(카메라 해상도, 네트워크 SSID)
보안 정책 조정(방화벽 규칙, 페어링 설정)
리소스의 접근 정책 변경(Handover_Policy 구성 등)

동시성: 배타적이고 고권한. configure는 통상 행사하기 위해 더 높은 레벨의 인가가 필요하다(§7.4.3 참조).

7.2 읽기-쓰기 잠금 매트릭스

읽기-쓰기 잠금 매트릭스는 동일 리소스의 다른 모드 하의 호환성을 정의한다. 새 요청과 기존 점유의 호환성은 다음과 같다:

기존 점유 \ 새 요청	read	write	execute	configure
없음	✓	✓	✓	✓
read(≥1 개)	✓	✗	✗	✗
write	✗	✗	✗	✗
execute	✗	✗	✗	✗
configure	✗	✗	✗	✗

✓: 호환, 새 요청은 즉시 Session 생성이 허용됨. ✗: 비호환, 새 요청은 거부됨(E_RESOURCE_BUSY 반환).

7.2.1 매트릭스 시맨틱 설명

read 간 상호 호환: 여러 읽기 전용 Session이 동시 존재 가능
write/execute/configure 간 임의 두 개는 비호환: 임의의 배타적 모드가 리소스를 점유하면 다른 배타적 모드 요청은 거부됨
read와 배타적 모드는 상호 배타: read 점유 시 배타적 요청 금지; 배타적 점유 시 read 요청 금지

7.2.2 단말의 처리

단말은 AuthRequest 처리 시 MUST:

검증 통과 후, Session이 creating에 진입하기 전에 매트릭스에 따라 호환성 확인
비호환 시 즉시 E_RESOURCE_BUSY 반환, 자동으로 큐에 입력하여 대기시키지 않음
iFay_Runtime은 재시도 또는 인계 요청 발신을 선택할 수 있음(제 6 장 참조)

7.3 Session 권한과의 관계

7.3.1 권한 목록

각 Session은 생성 시 granted_modes 목록을 휴대한다(§2.5 참조). 목록 내용은 Authorization_Descriptor.grants 또는 Trusted_Ticket.grants 중 매칭된 Grant.modes에서 유래한다.

Fay가 해당 Session을 통해 리소스를 작업할 때, granted_modes에 포함된 모드만 사용 가능
iFay_Runtime이 AuthRequest에서 지정하는 access_mode는 MUST Grant 인가 목록의 부분 집합이다

7.3.2 최소 권한 원칙

iFay_Runtime은 SHOULD AuthRequest에서 현재 작업에 필요한 최저 권한 모드만 요청한다. 예를 들어, 데이터를 읽기만 한다면 read를 요청하고, read + write가 아니다.

발급자는 SHOULD Authorization_Descriptor 내에서 최소 권한 원칙에 따라 인가하여, 불필요한 권한 완화를 회피한다.

7.3.3 모드 간 계층 포함 없음

CAP v1에서 각 접근 모드는 상호 독립적이며, 계층 포함 관계 없음:

configure 보유는 MUST NOT 자동으로 read / write / execute 능력을 획득
write 보유는 MUST NOT 자동으로 read 능력을 획득
각 접근 모드는 MUST 독립적으로 인가됨

구현은 MUST NOT 인가 범위를 자동 확장한다.

7.3.4 권한 비승격

Session 생성 후, 그 granted_modes는 MUST NOT 라이프사이클 내에서 승격된다. Fay가 더 높은 권한의 모드를 필요로 하는 경우:

iFay_Runtime은 현재 Session을 능동 해제
필요한 모드를 갖춘 자격 증명을 사용하여 새 AuthRequest 발신
단말은 완전 흐름에 따라 새 Session 생성

구현은 MUST NOT 어떤 "권한 승격" 런타임 인터페이스도 제공하지 않는다.

7.4 제약 조건 적용

Grant.constraints는 발급자에 의한 인가에 대한 부가 제한 조건이다. 본 사양은 다음 표준 제약 키를 정의하며, 구현은 MUST 지원한다. MAY 커스텀 제약을 지원할 수 있다(커스텀 제약의 시맨틱은 발급자와 단말이 협의하지만, MUST schema 문서에서 선언한다).

7.4.1 시간 윈도우 제약

constraints["time_window"] = "08:00-22:00"           // 매일 8:00-22:00 유효
constraints["time_window_tz"] = "Asia/Shanghai"     // 시간대, 기본 UTC

검증 시점: §3.3.2 단계 6에서 각 Grant가 제약을 충족하는지 확인. 현재 시각이 윈도우 내에 없음 → Grant 매칭 안 됨.

7.4.2 빈도 제한 제약

constraints["max_calls_per_hour"] = "60"
constraints["max_calls_per_day"]  = "1000"

단말은 SHOULD 각 (descriptor_id, fay_id, resource_id) 조합의 호출 카운트를 유지한다. 제한 초과 시 → Grant 매칭 안 됨(E_RATE_LIMIT_EXCEEDED 반환).

7.4.3 고민감 모드 제약

constraints["require_human_confirmation"] = "true"

access_mode == "configure" 또는 해당 제약을 충족하는 다른 시나리오에서, 단말은 MUST Session 생성 전에 인간 사용자에게 일회성 확인을 요청한다. 확인 UI는 §6.4.3과 동일 채널을 공유한다.

7.4.4 지리 펜스 제약

constraints["geo_fence"] = "geohash:wx4g0bm"        // 지정된 지리 범위 내에서만 유효
constraints["geo_fence_radius_m"] = "1000"

단말의 위치 정보 출처는 SHOULD 보정된 GPS 또는 네트워크 측위를 사용한다. 위치 정보 사용 불가 시 → Grant 매칭 안 됨(보수적으로 거부).

7.4.5 미식별 제약의 처리

단말이 미식별 constraints 키에 직면한 경우 MUST:

기본적으로 해당 Grant를 거부(보수적 원칙)
E_UNSUPPORTED_CONSTRAINT를 반환하고 미식별 키명 첨부

발급자는 커스텀 제약 사용 시 SHOULD 다른 채널로 단말에 제약 시맨틱을 알리고, 인가 실패를 회피한다.

7.5 모드와 OS 접근 제어의 매핑

단말은 운영체제의 접근 제어 인터페이스를 통해 access_mode의 실행을 실시한다. 본 절은 모드에서 OS 제어로의 권장 매핑을 정의한다. 구체적 구현은 플랫폼에 따라 차이가 있을 수 있지만, MUST 시맨틱 등가성을 유지한다.

리소스 종류	read	write	execute	configure
파일/디렉토리	파일 시스템 읽기 권한	파일 시스템 쓰기 권한	실행 권한	메타데이터 수정 권한
장치 파일	장치 읽기	장치 쓰기	ioctl/제어 인터페이스	장치 구성 레지스터
애플리케이션 프로세스	상태 조회	입력 주입	시작/호출	시작 매개변수 수정
네트워크 리소스	데이터 수신	데이터 송신	연결 확립	라우팅/방화벽 수정
카메라	화면 읽기	적용 안 됨	촬영/녹화 제어	해상도/프레임 레이트 조정

플랫폼 고유의 접근 제어 메커니즘(SELinux, AppArmor, macOS Sandbox, Android Permission 등)은 단말 구현이 선택하고 통합한다.

7.6 모드 변경의 제약

동일 (Session, Resource)는 MUST 라이프사이클 내에서 초기 access_mode를 유지하며 변경하지 않는다. 모드 변경은 새 Session으로 실현한다:

현재 Session 해제
새 Session 생성 시 새 access_mode 지정
단말은 매트릭스에 따라 리소스 점유 호환성 재평가

단말은 MUST NOT "모드 전환"의 런타임 인터페이스를 제공하지 않는다.

7.7 리소스 접근의 가관측성

단말은 SHOULD 각 리소스 접근의 핵심 정보를 기록한다(감사용):

session_id
fay_id
resource_id
access_mode
작업 종류(읽기 크기, 쓰기 바이트 수 등)
타임스탬프

구체적 감사 로그 형식은 본 사양의 범위를 벗어난다(블루프린트 §3.2 제외 항목 "감사 로그 표준 형식" 참조).

7.8 모드 시맨틱의 경계

7.8.1 read 모드는 리소스가 동시 수정되는 것을 막지 않음

read 모드는 "읽기" 권한만 인가하며, 읽기 프로세스 중 리소스가 다른 제어자에 의해 수정되지 않음을 보장하지 않는다:

여러 read Session 간은 상호 간섭하지 않지만, 리소스가 "활성 Session 없음" 상태에서 인간 사용자가 직접 작업한 경우(CAP 프로토콜 우회), read Session은 여전히 변경된 데이터를 읽을 수 있다
read 모드는 트랜잭션 일관성 보장을 제공하지 않는다

7.8.2 write 모드의 원자성

write 모드는 프로토콜 계층에서 "동일 시점 최대 하나의 write Session"의 보장만 제공한다. 구체적 쓰기 작업의 원자성(부분 쓰기 실패 등)은 리소스의 기저 시맨틱에 의존하며, CAP 프로토콜 범위 외다.

7.8.3 execute 모드의 부작용

execute 모드가 발동하는 작업은 MAY 리소스 상태를 변경한다. Fay가 execute를 통해 발동하는 부작용은 해당 Fay가 책임을 진다. CAP 프로토콜은 execute 작업의 롤백 능력을 제공하지 않는다.

7.9 완전 결정 흐름

단말이 리소스 접근을 처리하는 완전 결정 흐름:

[AuthRequest 도달]
        │
        ▼
  ┌─────────────────────┐
  │ §3 / §4 자격 증명 검증 │
  └──────┬──────────────┘
         │ 통과
         ▼
  ┌─────────────────────┐
  │ §7.4 제약 조건 평가   │
  │ (constraints)       │
  └──────┬──────────────┘
         │ 통과
         ▼
  ┌─────────────────────┐
  │ §7.2 읽기-쓰기 잠금 매트릭스 확인 │
  └──────┬──────────────┘
         │ 호환
         ▼
  ┌─────────────────────┐
  │ §5.2 Session 생성   │
  └──────┬──────────────┘
         │
         ▼
  ┌─────────────────────┐
  │ §7.5 OS 접근 제어   │
  │     하달            │
  └──────┬──────────────┘
         │
         ▼
  [AuthResult granted 반환]

임의 단계 실패 시 대응하는 에러 코드를 반환하며 후속 단계로 진입하지 않는다.