Separate sections

main
Bob Mottram 2022-06-29 16:44:11 +01:00
parent 4c4c17730a
commit c5d2638b99
1 changed files with 5 additions and 1 deletions

View File

@ -1148,6 +1148,8 @@ Servers should not trust client submitted content, and federated servers also sh
Servers should be careful to verify that new content is really posted by the actor that claims to be posting it, and that the actor has permission to update the resources it claims to. See also section 3. Objects Authentication and Authorization.
#### B.2.1 HTTP Signature
Verification of incoming posts SHOULD occur via a `http header signature` check. Currently, [draft 07 of the http signatures RFC](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-07) has become the *de facto* standard, although later versions MAY be implemented provided that sufficient support exists between federated servers.
A typical http signature created by Alyssa's server on an outgoing POST might look like the following:
@ -1163,7 +1165,9 @@ http signatures SHOULD include `host`, `date` and a `digest` created from the po
The receiving server can obtain Alyssa's public key from `https://instancedomain/users/alyssa#main-key` and use it to verify the signature.
In addition, to allow for relaying of posts [linked data signatures](https://w3c-ccg.github.io/data-integrity-spec) MAY be used. This can allow posts to be verified as authentic even if they have passed through intermediate servers. An incoming post SHOULD be considered valid if its `http header signature` fails but an attached `linked data signature` passes.
#### B.2.2 Linked Data Signature
To allow for relaying of posts [linked data signatures](https://w3c-ccg.github.io/data-integrity-spec) MAY be used. This can allow posts to be verified as authentic even if they have passed through intermediate servers. An incoming post SHOULD be considered valid if its `http header signature` fails but an attached `linked data signature` passes.
### B.3 Accessing localhost URIs
It is often convenient while developing to test against a process running on localhost. However, permitting requests to localhost in a production client or server instance can be dangerous. Making requests to URIs on localhost which do not require authorization may unintentionally access or modify resources assumed to be protected to be usable by localhost-only.