Faying Protocol/1.0 — §1 Overview

프로토콜 본문 내비게이션: 장 목차 ｜ 다음 장 §2 아키텍처

§1 Overview

이 장에서는 Faying Protocol이 무엇이고, 무엇을 풀고, 무엇은 풀지 않는지를 정리한다. 프로토콜 명칭, 기술 스택 안에서의 위치, 여덟 가지 설계 목표, OAuth/WebAuthn 등 기존 방식과의 역할 분담, 한 줄 정의, 규격의 적용 범위와 명시적 비목표, 그리고 버전 관리와 호환성 규칙을 다룬다. 이 장을 읽고 나면 뒤에 이어지는 §2–§11과 부록의 용어와 제약이 자리를 잡는다.

본문에서 규칙 뒤에 Trace:로 대응하는 EARS 하위 조항 번호(출처는 본 규격의 요구사항 베이스라인)를 표기하며, 형식은 R<requirement>.<criterion>.<clause>다. 요구사항 출처를 되짚어 보기 쉽게 하기 위함이다.

§1.1 프로토콜 명칭

프로토콜 규격의 정식 명칭은 Faying Protocol이며, 버전 표기는 Faying Protocol/1.0이다.

이 프로토콜에는 별도의 약칭이 없으므로, 줄여 부를 필요가 있을 때도 전체 명칭을 그대로 쓴다. 초기 초안에서는 "Faying Auth Protocol(FAP)"을 쓴 적이 있으나 지금은 폐기되었다. 새 문서에서는 FAP, FAP/1.0, Faying Auth Protocol, application/fap+json, POST /fap/v1/... 같은 옛 표기가 더 이상 등장하지 않는다. 외부 자료에서 FAP를 만나면 Faying Protocol의 옛 이름으로 이해하면 된다.

§1.2 프로토콜 위치

Faying Protocol은 TLS 위에 놓이는 애플리케이션 계층의 "지속적 인가 계층" 프로토콜로, "인간 원형(Human Prime)이 자신의 iFay에 대해 어떤 재현(在場) 상태에서, 어떤 범위로, 어떤 등급으로, 어느 기간 동안 인가하는가"라는 한 묶음의 의미론을 담는다.

• TLS 아래: 채널의 기밀성과 상대방 신원은 TLS 1.3(필요 시 mTLS 선택)이 담당하며, Faying Protocol은 이를 다시 하지 않는다.
• OAuth/OIDC 옆: OAuth는 애플리케이션 인가를, OIDC는 신원 단언을 담당하지만 둘 다 "순간 토큰" 모델이다. Faying Protocol은 두 방식 모두 풀지 못하는 문제, 즉 지속적 대리 + 재현 결속 + 등급 전환 + 책임 귀속의 유일성을 해결한다.
• WebAuthn 위: WebAuthn / FIDO2는 Bootstrapping 단계에서 인간 원형의 "사용자 재현"을 하드웨어 수준으로 증명하며, Faying Protocol은 그 자격증명 형태를 파생 신뢰의 뿌리로 재사용한다.

Faying Protocol은 TLS를 대체하지 않고 OAuth를 다시 발명하지도 않는다. TLS 위, 업무 의미론 아래에서 iFay의 모든 대외 행위가 Mandate 검증 게이트를 반드시 통과하도록 강제한다. 본 프로토콜 게이트를 우회하는 모든 대외 호출은 Rogue Action으로 간주되며, 전송 계층 위·업무 계층 아래의 미들웨어에서 반드시 거부되어야 한다.

§1.3 설계 목표

아래 표는 Faying Protocol의 8가지 설계 목표 G1–G8(핵심 목표)과 §9 / §5에서 파생된 2가지 엔지니어링 목표(보안 속성 / 프로토콜 상호운용성)를 제시한다. 각 목표는 요구사항 베이스라인의 정확히 한 개 Requirement에 정렬되어, 본 프로토콜 본문과 Requirements 문서 사이의 양방향 역참조 앵커를 이룬다.

목표	의미	청사진 출처	대응 Requirement
G1 책임 귀속 유일성	어느 시점에서든 iFay의 대외 행위는 한 명의 Human Prime(인간 원형)에게 모호함 없이 귀속될 수 있다	제13장 윤리 하한선	Requirement 1
G2 기본 거부	유효한 Mandate가 없으면 → 대외 행동 불가; 어느 필드든 누락되면 즉시 거부	제13장 Rogue 기본값	Requirement 2
G3 관측·감사·폐기 가능	상태 전이, Action 발기, 갱신 / 폐기 세 종류의 이벤트가 모두 관측·감사·독립 검증 가능	제11, 13장	Requirement 3
G4 대칭적 폐기	폐기 경로의 도달성 ≥ 수립 경로의 도달성, 폐기는 되돌릴 수 없다	제10, 12장	Requirement 4
G5 지속적 보정	재현 신호와 Mandate 등급이 매 순간 다시 확인될 수 있다; 만료된 신뢰를 캐시하지 않는다	제11, 12장	Requirement 5
G6 등급화 인가	단일 Mandate가 모든 강도를 대표할 수 없다; 등급은 반드시 표현·전환·강등 가능해야 하고, 승급은 반드시 HP 입회를 동반한다	사용자 원시 요점 3	Requirement 6
G7 디바이스 간 파생 가능	동일 iFay가 단말을 넘나들며 동작할 때, 신뢰는 파생할 수 있되 책임 주체는 변하지 않는다; scope / grade는 엄격히 수렴한다	Phase 2/3 진화 예약	Requirement 7
G8 포스트 양자 진화 가능	알고리즘 스위트는 협상·롤링 업그레이드 가능하다; PQC 협상 비트를 예약한다	엔지니어링 일반 요구	Requirement 8
—(파생) 보안 속성	재전송 방지 / 탈취 방지 / 피싱 방지 / 디커플링 상태 식별 / AI-Era Adversarial Threats	§9 보안 고려사항	Requirement 9(13 파생 포함)
—(파생) 프로토콜 상호운용성	CBOR / JSON 등가, Deterministic CBOR, 구현 간 호환 매트릭스	§5 프로토콜 메시지	Requirement 10

목표 ↔ Requirement 일대일 원칙: 이 표는 프로토콜 본문과 Requirements 문서 사이의 유일한 권위 매핑이다. 이후 장에서 어떤 불변식이나 메커니즘을 설명하며 인용하는 EARS 하위 조항 번호 R<n>.<m>.<k>의 루트 Requirement 번호 <n>은 반드시 이 표의 "대응 Requirement" 열 안에 들어간다. G6 / G4 / G5 / G7에서 파생된 Endorsed_Mandate(Requirement 11), Disconnection 정책(Requirement 12), AI-Era 방어(Requirement 13)는 G1–G8의 세부 요구로서 각각 §4 / §8 / §9에서 프로토콜 수준의 구현을 제시한다.

§1.4 기존 방식과의 핵심 차이(한 줄 버전)

기존 방식	풀어낸 것	Faying Protocol이 반드시 풀어야 하지만 풀지 못한 것
OAuth 2.0 / 2.1	애플리케이션의 자원 접근 인가	일회성 token, 등급 없음·재현 없음·대칭 폐기 없음
OIDC SSO	신원 단언(who)	지속적 대리(acting on behalf of)가 없고 등급도 없음
mTLS	채널 양 끝단의 상대방 신원	"누가 어떤 재현 상태에서 누구에게 무엇을 위임했는가"를 표현할 수 없음
JWT	자기완결적 클레임의 서명	폐기 없음·등급 의미론 없음, 긴 수명과 "대칭적 폐기"가 충돌
FIDO2 / WebAuthn	인간 원형의 하드웨어 수준 재현 증명	로그인 순간만 커버, iFay의 지속적 대리는 미커버
Macaroons	caveats가 붙은 파생 가능 token	재현 결속 없음·인간 원형의 명시적 입회 없음
SPIFFE / SPIRE	워크로드 신원	워크로드 관점이라 인간 책임 주체가 없음

Faying Protocol은 위의 어느 방식과도 경쟁하지 않는다. TLS 위, 업무 의미론 아래에서 "인간 원형 ↔ iFay"라는 한 묶음의 전용 의미론을 채워 넣는다: 지속적 대리 + 재현 결속 + 등급 전환 + 책임 귀속 유일성 + 대칭적 폐기.

§1.5 한 줄 정의

Faying Protocol = "Mandate(token 대체) + Presence Signal(재현 신호) + Attestation Chain(증언 체인) + Revocation Registry(폐기 등록)" 네 요소가 TLS 위에서 협동하여 표현하는, 인간 원형과 iFay가 양방향으로 발기하고 인간 원형이 명시적으로 승인해야 발효되며, 지속적으로 보정되고 대칭적으로 폐기되는 인가 계약이다.

§1.5.1 양방향 Faying은 HP의 명시적 승인으로 발효된다(핵심 단언)

Faying 관계(수립 또는 조정)의 발기는 양방향이다.

• HP-initiated: Human Prime(인간 원형)이 능동적으로 Faying을 발기하며 BOOTSTRAP 통로를 탄다(§2.4 Phase A, §5.3.1 참조).
• IF-initiated: iFay가 능동적으로 Human Prime에게 Faying을 요청할 수 있으며(즉 FAYING_REQUEST), §2.4 Phase A0 → BOOTSTRAP 두 단계 경로를 탄다(§5.3.6 참조).

그러나 어느 쪽이 발기하든, Faying 상태 변화의 최종 발효 조건은 Human Prime이 내놓는 명확하고 기만당하지 않으며 검증 가능한 승인 확인이다(기본 형태는 WebAuthn 사용자 재현 단언 또는 그에 준하는 하드웨어 수준 증명).

이로부터 본 프로토콜의 넘을 수 없는 세 가지 하드 제약이 곧바로 도출된다.

1. iFay 자신은 Faying 발효 조건을 구성하지 못한다: iFay가 능동 발기한 FAYING_REQUEST가 BootstrapTimeout(기본 60s, 부록 B 참조) 내에 HP의 명확한 승인을 얻지 못하면 만료되거나 거부되며, 어떤 Faying 상태 변화도 일으키지 않는다. Mandate_Service는 반드시 E_FAYING_REQUEST_NOT_CONFIRMED(오류 코드 1014)를 반환하고, "누가 발기했는지, 언제 확인했는지, 발효되었는지"의 되돌릴 수 없는 증거를 남기기 위해 해당 이벤트를 Attestation Chain에 기록한다.
   • Trace: R1.3.2(IF-initiated 경로는 HP의 명확한 승인 확인 후에만 발효), R1.3.3(BootstrapTimeout 내 미승인 시 거부하고 상태 변화 없음), R1.3.4(발효 여부와 무관하게 AC에 기록).
2. 대체 입회 경로는 존재하지 않는다: 프로토콜 계층은 iFay, Mandate_Service, Supervisory_Agent가 Human Prime을 대신해 Faying 승인 확인을 완료하는 합법 경로를 일절 제공하지 않는다. human_witness가 누락되었거나 human_witness 검증에 실패한 BOOTSTRAP은 반드시 E_HUMAN_WITNESS_REQUIRED(오류 코드 1010)로 거부되어야 한다.
   • Trace: R1.3.5(IF / MS / SA가 HP를 대신해 Faying 승인 확인을 완료하는 합법 경로를 일절 제공하지 않음).
3. 폐기는 iFay가 일방적으로 우회할 수 없다: iFay는 "Faying 단절 요청" 메시지(Disclosure_Report로 간주)를 발기할 수 있으나, 자신의 Mandate를 폐기할 권한은 갖지 않는다. 모든 폐기는 최종적으로 Human Prime 또는 컴플라이언스 의미의 권위 기관이 발기해야 하며 HP 시야 통로를 통해 가시화되어야 한다(§4 / §10 참조).
   • Trace: R4.1.4(IF는 자신의 Mandate 폐기 권한을 갖지 않음), R4.1.5(단절 요청은 Disclosure_Report로 AC에 기록하고 HP 시야로 푸시).

본 항은 §2.4 Phase A0, §5.3.6 FAYING_REQUEST, §5.4 오류 코드 1010 / 1014를 Overview 계층에서 통합하는 앵커이며, 이후 장들의 "HP 입회 없이는 Faying 없음"에 관한 모든 논증의 출발점이다.

§1.6 프로토콜 산출물 범위와 비목표

§1.6.1 범위 내(Normative, 본 프로토콜 본문이 담당)

본 프로토콜 본문(즉 이 단일 문서 묶음)은 다음 내용을 규범화하며 그것만 규범화한다.

• 프로토콜 데이터 객체: Mandate / Presence_Signal / Attestation / SignatureBundle / Faying Protocol Envelope / Endorsed_Mandate / Disclosure_Report 등의 CBOR 주 형식과 JSON 폴백 형식(CDDL이 권위, §4 / §5 참조).
  • Trace: R10.1.1, R10.1.2, R10.2.1–R10.2.4.
• 프로토콜 구성요소 인터페이스: Mandate_Service / Presence_Channel / Attestation_Chain / Revocation_Registry / Liveness_Channel / Behavior_Baseline_Service의 책임 경계와 불변식(§3 참조).
• 프로토콜 메시지: BOOTSTRAP / PRESENCE / GRADE_SWITCH / DELEGATE / REVOKE / FAYING_REQUEST / DISCLOSURE 일곱 종 메시지의 필드 정의, 오류 코드, 프로토콜 수준 하드 제약(§5 참조).
• 암호학 규칙: 알고리즘 스위트 협상, 키 파생 계층, 서명 입력 정규화(Endorsed_Mandate의 서명 입력 앵커 포함, §6 참조).
  • Trace: R8.1.1–R8.1.4, R8.2.1–R8.2.4.
• 인가 등급 의미론: G0–G4 다섯 단계 등급의 정확한 정의, 트리거 조건 매트릭스, 강등 단조성 원칙, Endorsement Grades 하위 등급(§7 참조).
  • Trace: R5.1.1, R6.1.1, R6.1.2.
• 생명주기와 상태 기계: Unpaired / Pairing / Active / Degraded / Disconnected / Suspended / Revoked 일곱 상태의 전이 조건과 재연결 대사(對賬) 트랜잭션(§8 참조).
• 보안 고려사항: STRIDE 위협 모델, 재전송 방지 / 탈취 방지 / 피싱 방지 / 디커플링 상태 식별, 디바이스 간 파생 신뢰 전달, AI-Era Adversarial Threats T1–T7(§9 참조).
• 오류 처리: 14개 오류 코드(1010 E_HUMAN_WITNESS_REQUIRED, 1013 E_ENDORSEMENT_INVALID, 1014 E_FAYING_REQUEST_NOT_CONFIRMED 포함)의 프로토콜 응답, 복구 경로, 관측성 제약, Default-Deny 수렴(§10 참조).
  • Trace: R2.1.1–R2.1.4(기본 거부), R3.3.1(HP 시야 통로 필달).
• 부록: 용어 정렬 퀵 레퍼런스(부록 A), 기본 파라미터 예산(부록 B).

§1.6.2 범위 외(Non-normative, 본 프로토콜이 담당하지 않음)

다음 내용은 본 프로토콜 본문의 규범 범위에 속하지 않으며, 참조 구현 / 엔지니어링 가이드로만 제공되고 본 프로토콜 본문의 호환성 테스트와 무관하다.

• 업무 의미론: iFay의 구체적 업무 행위, 단말 드라이버, 애플리케이션 통합 방식.
• UI / UX 설계: Human Prime 시야 통로의 구체적 표현 형태, 확인 팝업 설계, 모바일 / 데스크톱 인터랙션.
• 운영과 배포: Mandate_Service / Revocation_Registry의 고가용 배포 모델, 스케일링 전략, 리전 간 동기화.
• 전송 계층 세부사항: TLS 1.3 자체의 핸드셰이크 세부(RFC 8446이 규범), HTTP/2 / gRPC / QUIC의 구체적 파라미터 튜닝.
• PD(Presence Device) 구현: WebAuthn authenticator / TPM / Platform Keystore 자체의 하드웨어 구현(W3C / ISO / TCG가 각각 규범).
• 법률·컴플라이언스 세부사항: 규제 / 컴플라이언스 주체가 프로토콜 밖에서 법률적 의미의 "권위 기관" 역할을 어떻게 수행하는지(프로토콜 계층은 RevokeReason 열거에서의 위치와 서명 체인 요건만 규정할 뿐, 그 법적 제도는 규정하지 않는다).
• 참조 구현 코드: 본 프로토콜의 어떤 reference 구현(예: schemas/types.ts TypeScript 뷰, pbt/ 속성 테스트 스위트)도 명시적으로 **"Reference Implementation, Not Normative"**로 표기되며 프로토콜 본체를 구성하지 않는다.
• 미해결 과제: §11 Open Questions 중 status: open인 모든 항목.

§1.6.3 전달 형태

본 규격의 본문은 장별로 분할되어 §1–§11 총 11개 파일에, 부록 A/B/C 세 부를 더해 모두 docs/zh-CN/specification/2025-10-25/ 아래에 둔다. 장 번호 파일명은 목차를 참조하라. 그중 부록 A(용어 정렬 퀵 레퍼런스), 부록 B(기본 파라미터 예산)는 규격 수준의 참조이며, 부록 C(변경 이력)는 프로토콜이 초안에서 확정까지 진화한 과정과 버전 번호 전략을 기록해 참여자가 프로토콜이 어떻게 형성되고 진화하는지 이해하도록 돕는다.

영문 규격은 docs/en/specification/2025-10-25/에 있으며 단일 파일 구조다. 프로토콜 본문(§1–§11 + 부록 A/B)이 모두 Faying-Protocol-1.0.md 한 파일에 인라인되어 있고, 영문 측은 부록 C(변경 이력) 같은 중문 측 독립 파일을 유지하지 않는다. 양측의 "일대일 대응"은 장 앵커 수준의 대응이다. 장 번호, Mermaid 다이어그램, CDDL / TypeScript 코드 블록, 오류 코드 표, 부록 A/B가 하나하나 정렬되며, 파일 단위로 일대일 대응하는 것은 아니다. 중문판과 차이가 있을 경우 간체 중국어판을 정본으로 하며, 다음 리뷰 때 영문을 동기화 수정한다.

§1.7 버전 관리와 호환성

이 절은 Faying Protocol 버전 번호의 권위 정의다. 버전 번호는 단순한 문서 표식이 아니라 상호운용 계약의 일부다. 와이어 인벨로프, schema, 협상 비트에 등장하여 두 독립 구현이 대화할 수 있는지를 직접 결정한다. 따라서 이 절은 Normative다. 구현자는 이 절의 규칙대로 버전 번호를 해석하고 버전 협상을 수행해야 한다. 부록 C 변경 이력은 역사만 기록하며 규칙을 다시 정의하지 않는다.

§1.7.1 서로 직교하는 세 가지 버전 축

Faying Protocol은 서로 독립적인 세 축으로 한 규격의 버전을 기술하며, 셋을 하나의 번호로 뭉뚱그려서는 안 된다.

축	답하는 질문	형태	매개체	예시
프로토콜 버전(상호운용 계약)	두 구현이 대화할 수 있는가	MAJOR.MINOR	산문 / 와이어 인벨로프 version 필드 / schema 파일명	Faying Protocol/1.0
문서 상태(생명주기)	이 규격이 확정되었는가	열거	front matter status	Draft / Final / Deprecated / Obsolete
편집 판차(정오와 명확화)	동일 프로토콜 버전에서 몇 번째 문구 개정인가	배포 일자	배포 디렉터리명 / front matter date	2025-10-25

핵심 제약: 오직 "프로토콜 버전" MAJOR.MINOR만 와이어 형식에 들어간다(인벨로프 version 필드, schema 파일명). 문서 상태와 편집 판차는 와이어 형식에 들어가지 않는다. 이들은 문서 거버넌스 표식이며 상호운용 판정에 관여하지 않는다. 구현은 상대방의 문서 상태나 편집 판차가 다르다는 이유로 메시지 처리 동작을 바꿔서는 절대 안 된다.

§1.7.2 프로토콜 버전 MAJOR.MINOR 의미론

프로토콜 버전 번호는 Faying Protocol/MAJOR.MINOR로 표기하며, 두 단계만 두고 PATCH 자리는 두지 않는다. 와이어 형식과 상호운용 의미론은 두 단계의 호환성만 구분한다.

• MAJOR(파괴적 변경): 옛 규격을 엄격히 따라 구현한 상대방이 새 메시지를 거부하거나 오해하게 만드는 모든 변경. 예: §4.2 CDDL 권위 schema의 필드 의미 변경, 메시지 타입 삭제, 오류 코드 의미 재정의, 상태 기계의 흡수 상태 변경.
  • 규칙: MAJOR 올림, MINOR 0으로 리셋(예: 1.4 → 2.0).
  • 호환성: 서로 다른 MAJOR 사이에서는 상호운용을 보장하지 않는다.
• MINOR(하위 호환 증보): 새 구현이 옛 메시지를 이해할 수 있고, 옛 구현이 인식하지 못하는 선택 항목을 안전하게 무시할 수 있는 증보. 예: 선택 필드 추가, 메시지나 오류 코드 신설, AI-Era 위협 카탈로그 항목 추가, 부록 파라미터 추가, Correctness Property 추가.
  • 규칙: MINOR 증가(예: 1.0 → 1.1).
  • 호환성: 동일 MAJOR 안에서 높은 MINOR는 낮은 MINOR에 대한 하위 호환성을 반드시 유지한다.

판단 기준(구현자 자가 점검): 이 변경이 옛 규격을 엄격히 따라 구현한 상대방으로 하여금 새 메시지를 거부하거나 오해하게 만드는가?

• 그렇다 → MAJOR.
• 아니지만 와이어 형식에 보이는 내용을 새로 추가했다 → MINOR.
• 문구만 손대고 어떤 와이어 형식 의미론도 건드리지 않았다(오타 수정, 예시 보충, 모호함 해소) → 프로토콜 버전 불변, §1.7.4 편집 판차로 처리.

현재 베이스라인은 Faying Protocol/1.0이다.

§1.7.3 버전 협상과 호환성 규칙(Normative)

버전 협상은 §6.1 알고리즘 스위트 협상과 동일한 방식(각자 선언, 공통 지원의 최고값 채택)을 재사용한다. 구현은 다음을 따라야 한다.

1. 선언: BOOTSTRAP 단계에서 클라이언트와 서버는 각자 지원하는 프로토콜 버전 집합을 선언한다(예: supported: [1.0, 1.1]).
2. 동일 MAJOR에서 최고 MINOR 채택: 양측 MAJOR가 같으면 둘이 공통 지원하는 최고 MINOR를 이번 세션의 발효 버전으로 선택해야 한다. 높은 MINOR 구현은 낮은 MINOR 상대방을 반드시 서비스할 수 있어야 한다(MAJOR.0까지 하위 호환).
3. MAJOR 교차 시 거부: 양측에 공통 지원하는 MAJOR가 없으면 협상하지 않고 반드시 E_PROTOCOL(오류 코드 1099)로 해당 BOOTSTRAP을 거부하며, "최선을 다하는" 방식으로 강등 상호운용해서는 안 된다.
4. 롤링 업그레이드가 기존 Mandate를 깨지 않음: 버전 협상으로 새 기본 알고리즘 스위트나 새 MINOR를 도입할 때, 기존 Mandate는 그 not_after 이전까지 여전히 검증 가능해야 한다. 버전 업그레이드는 진행 중인 유효한 Mandate를 무효화해서는 안 된다.
   • Trace: R8.2.4(버전 협상 롤링 업그레이드, 기존 Mandate 검증 가능성 미파괴).
5. 미지의 높은 MINOR 처리: 동일 MAJOR이지만 MINOR가 자신보다 높다고 선언된 메시지를 받으면, 구현은 자신이 지원하는 최고 MINOR로 해석하고 인식하지 못하는 선택 필드를 무시해야 한다(거부가 아니라). 이것이 바로 MINOR 하위 호환 약속의 런타임 착지점이다.

§1.7.4 편집 판차와 정오(Non-normative 변경)

Faying Protocol/1.0이 확정(Final)된 후에도 순수 문구 정오는 불가피하다. 오타 수정, 예시 보충, 모호함 해소, 내부 링크 수정 등이다. 이런 변경은:

• 프로토콜 버전 번호를 건드려서는 안 된다(그러면 상호운용 계약이 바뀌었다고 거짓을 말하는 셈이다).
• 배포 일자를 판차 앵커로 삼는다. 예를 들어 Faying Protocol/1.0 (2025-10-25)는 1.0의 첫 Final 판차이고, 이후 정오는 새 배포 디렉터리(예: 2026-03-xx/)를 만들되 프로토콜 버전은 여전히 1.0이다.
• 부록 C 변경 이력에 Editorial 분류로 등재하고, front matter에 edition 필드로 판차 이전을 표기한다.
• 하드 제약: 편집 판차는 Non-normative 변경만 허용한다. 와이어 형식 의미론을 건드리는 수정은 반드시 MINOR 또는 MAJOR를 올려야 하며, 편집 정오로 위장하여 배포해서는 안 된다.

§1.7.5 버전 번호의 착지점과 표준 실행자 유의사항

아래 표는 버전 번호가 각 위치에서 정확히 어디에 착지하는지를 제시한다. 구현자는 이를 근거로 "어떤 차이가 상호운용에 영향을 주고 어떤 차이는 주지 않는지"를 판단한다.

착지점	무엇을 쓰는가	유의사항
와이어 인벨로프 version 필드(§5.2)	"Faying Protocol/MAJOR.MINOR"	MAJOR.MINOR만 넣는다; 판차 일자도, 문서 상태도 넣지 않는다
schema 파일명(fap-1.0.cddl 등)	MAJOR.MINOR를 따른다	파일명은 편집 판차로 개명하지 않는다. 정오로 fap-1.0.cddl을 바꾸지 않아 기존 참조를 안정적으로 유지한다(초기 fap 접두사 보존도 같은 이유, 부록 C 참조)
content-type(§5.1)	application/faying-protocol+cbor(또는 +json)	content-type은 프로토콜 패밀리를 식별한다. 게이트웨이 계층에서 버전별 라우팅이 필요하면 version= 파라미터를 배포 편의로 붙일 수 있으나, 그 파라미터는 와이어 형식 의미론에 속하지 않고 호환성 판정에 영향을 주지 않는다
front matter status / date	문서 상태 / 편집 판차	문서 거버넌스 표식, 와이어 형식에 들어가지 않음, 상대방은 이를 근거로 메시지 처리를 바꿔서는 안 됨
git tag	faying-protocol-v<MAJOR.MINOR>-<상태>	확정 faying-protocol-v1.0-final; 판차 스냅샷 faying-protocol-v1.0-2026-03-xx; tag는 본문 + vectors/ + schemas/를 동시에 커버하여 상호운용 3종 세트를 함께 동결해야 함

표준 실행자 필독 유의사항:

1. 상호운용 판정은 프로토콜 버전만 본다: "대화 가능 여부"를 결정하는 유일한 근거는 MAJOR.MINOR다. 상대방의 문서 상태(Draft/Final), 편집 판차(배포 일자)는 상호운용 동작을 바꾸지 않는다. 상대가 Draft를 달았거나 판차가 오래되었다는 이유로 그 합법 메시지를 절대 거부하지 말라.
2. 동일 MAJOR는 반드시 하위 호환: 높은 MINOR 버전을 구현할 때는 MAJOR.0부터의 모든 낮은 MINOR 상대방을 동시에 정확히 서비스할 수 있어야 한다.
3. 정오를 업그레이드로 착각하지 말 것: 배포 디렉터리 일자 변화(편집 판차)는 프로토콜이 바뀌었음을 뜻하지 않는다. 오직 MAJOR.MINOR 변화만 상호운용 영향을 평가해야 한다.
4. schema 파일명 안정성: 파일명에 판차가 인코딩되어 있다고 의존하지 말라. 동일 MAJOR.MINOR의 정오는 동명 schema 파일을 재사용하고 판차는 git tag / 배포 디렉터리로 구분한다.
5. Draft 기간에는 호환성 약속 없음: status: Draft 기간에는 동결되지 않은 전제로 MAJOR.MINOR가 조정될 수 있다. 오직 Final 이후에야 이 절의 MAJOR/MINOR 호환성 약속이 완전히 발효된다.