kcode-k1-access-profile-codec 0.1.0

Canonical byte codec for K1 authorization profiles
Documentation 
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

# K1 access profile codec

`kcode-k1-access-profile-codec` is the stateless canonical binary codec for `AuthorizationProfile` values. It reexports the profile, owner, viewer, and identifier types needed to construct and inspect codec inputs and outputs.

## API

```rust
use kcode_k1_access_profile_codec::{
    AuthorizationProfile, ProfileOwner, ProfileViewer, decode_profile, encode_profile,
};

let profile = AuthorizationProfile::new(
    vec![ProfileOwner::RequestUser],
    vec![ProfileViewer::RequestModel],
)?;
let bytes = encode_profile(&profile)?;
assert_eq!(decode_profile(&bytes)?, profile);
# Ok::<(), String>(())
```

- `encode_profile(&AuthorizationProfile) -> Result<Vec<u8>, String>` emits version 1 canonical bytes.
- `decode_profile(&[u8]) -> Result<AuthorizationProfile, String>` accepts only a complete canonical version 1 encoding.

## Version 1 format

Bytes are `[1][owner_count:u32 big-endian][owners...][viewer_count:u32 big-endian][viewers...]`.

Owner tags are:

- `0`: request user, with no payload
- `1`: user, followed by its 12-byte transaction ID
- `2`: group, followed by its 12-byte transaction ID

Viewer tags are:

- `0`: request user, with no payload
- `1`: request model, with no payload
- `2`: user, followed by its 12-byte transaction ID
- `3`: group, followed by its 12-byte transaction ID
- `4`: model, followed by its 32-byte model ID

Encoding uses the normalized order supplied by the value type. Decoding rejects truncation, unknown versions and tags, trailing bytes, an empty owner set, count conversion overflow, duplicate entries, and noncanonical ordering. Errors are stable descriptive `String` values. The crate performs no I/O and owns no persistence, mutation operations, profile names, migration, legacy decoding, or authorization behavior.