-
Notifications
You must be signed in to change notification settings - Fork 21
Open
Description
There are/can be scenarios where there are UCAN tokens that are almost valid (validish), and can be reasonably interpreted as such. Canonicalization of these tokens (x = serialize(deserialize(x))) is at odds with encoding valid tokens and being lenient in what we parse.
Examples of validish tokens:
- An unexpected field, either irrelevant or from a different implementation or spec/version flux
- An empty value for an optional field
"prf": [](which "MUST be omitted") - UCAN with missing
exp, re-encoded as"exp": null(feat: Allow nullable expiry per 0.9.0 spec. Fixes #23 #95 currently will trigger this scenario if given a validish token without extra handling) - Capabilities/proofs reordered to a canonicalized order (not in spec currently, but add a note about prf sorting canonicalization#2 and JSON Canonicalization ordering could be in play)
Some options forward:
- Strictly reject validish tokens.
- Allow validish tokens. Retain canonicalization and encode validish tokens.
- Allow validish tokens. Encode as valid tokens, break canonicalization.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels