1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
//! The subject kind of a delegation: the namespace its subject value is read
//! in, its frozen wire values, and the table of roles each kind permits.
use DelegationRole;
/// What kind of thing a delegation's subject is. A **closed** enum, exactly as
/// [`DelegationRole`] is: a value on the wire that is not listed here is a
/// decode failure, never a value carried through.
///
/// # Why the subject carries a kind at all
///
/// An earlier draft of this format had a single `origin` field whose documented
/// meaning was fixed — a DNS-style origin — so "a lapsed domain orphans every
/// proof" was a property of the *artifact*. Generalising that field to a bare
/// string would have moved the protection out of the format and into the
/// caller: an anchor could pass a seat identifier, or a seat consumer a domain,
/// and **nothing would notice**. The delegation would verify perfectly and mean
/// something no verifier could pin down — a signed value whose semantics live
/// nowhere, which is the same failure the closed [`DelegationRole`] refuses.
///
/// So the subject carries its kind alongside its value, and
/// [`verify_delegation`](crate::delegation::sign::verify_delegation) requires the caller to
/// **state the kind it expects**. Cross-kind confusion is refused at decode
/// rather than discovered downstream: a seat delegation cannot be presented to
/// a domain verifier and a domain delegation cannot be presented to a seat one,
/// for the same structural reason an inclusion receipt cannot be re-labelled as
/// a consistency receipt.
///
/// The kind set is closed and unknown kinds are refused. **Both inhabitants
/// therefore had to ship in `v1`**: adding a kind later is a compatibility
/// event, because an old verifier refuses what it does not recognise, so a `v1`
/// with one kind would still have needed a `v2` for the second — which defeats
/// the point of the mechanism. A third kind is a `v3`, and that is what
/// versioned wire contracts are for.