Website of https://litepub.social/
commit: b62dc97a011f164cfebc0da7863fd9020a3721bc
parent 1676c2f89051c87c1fc343cf42b214933c9100f8
Author: William Pitcock <nenolod@dereferenced.org>
Date:   Fri, 12 Apr 2019 23:33:29 -0500

lice: discuss property assertions a bit more per puck


1 file changed, 24 insertions(+), 0 deletions(-)

diff --git a/lice.md b/lice.md @@ -221,6 +221,19 @@ fetching the proof object if a valid signature is not present. [lds]: https://w3c-dvcg.github.io/ld-signatures/ +### Asserting Properties in the Child Object + +Proof objects MAY include fragments of the child object being authorized. In the +event that a fragment of the child object is included, at least the `id` property +must be present. + +When verifying proof objects that contain fragments of a child object, the verifier +MUST ensure that the object being authorized against the proof has the same +properties as present in the proof object. In the event that the proof object's +child fragments and the referent object disagree, the verifier MUST fail the +verification. + + # Security Considerations *This section is non-normative.* @@ -228,6 +241,17 @@ fetching the proof object if a valid signature is not present. ## Recursive Object Fetching Denial of Service +A malicious proof object could reference itself, either directly or indirectly. + Implementations SHOULD limit the depth to which they fetch referenced activities and proof objects. A valid activity will never have a recursive loop, so the depth limit can be very low. + + +## Proof Object/Child Object Swapping + +A malicious server could swap the authorized object with a newer version that contains +content that was not authorized by the granting server. + +Implementations SHOULD include key properties of the child object when generating a +proof object, such as `content`, `name`, `summary` and `attachment`.