2 This is the Zot! social communications protocol.
4 Specification revision: 1
8 This specification is public domain.
10 Zot is a framework for secure delivery of messages on the web based on
11 webfinger and encapsulating salmon.
13 First read the salmon and salmon magic envelope specifications. Zot also
14 makes use of webfinger and ActivityStreams and several concepts from RFC822
15 (email). Zot encompasses the zot delivery framework, and the zid remote
22 Format of a zot wrapper. This completely encapsulates a salmon magic envelope
23 and provides privacy protection, while defining a delivery envelope - a
24 concept familiar to email systems. All addresses in zot are webfinger
25 resolvable addresses containing both salmon and zot endpoints.
28 <?xml version='1.0' encoding='UTF-8'?>
29 <zot:msg xmlns:zot='http://purl.org/zot/1.0'>
30 <zot:key>((key))</zot:key>
31 <zot:iv>((iv))</zot:iv>
32 <zot:env>((envelope))</zot:env>
33 <zot:alg>AES-256-CBC</zot:alg>
34 <zot:data type='application/magic-envelope+xml'>((salmon))</zot:data>
41 A suitable randomly generated encyption key of length 32 octets for encrypting
42 the envelope and salmon packet. This is then encrypted with the sender's
43 private key and base64url encoded.
48 A suitable randomly generated initialisation vector of length 16 octets for
49 encrypting the envelope and salmon packet. This is then encrypted with the
50 sender's private key and base64url encoded.
55 This consists of RFC822-style header fields representing the sender and
56 recipient(s). Example:
59 Sender: bob@example.com
62 Both "From:" and "Sender:" MUST be provided, and represent a webfinger
63 address of the author and sender respectively. The webfinger address for
64 the From address MUST contain a discoverable salmon public key that
65 is needed to verify the enclosed salmon data. Sender is used to indicate
66 the webfinger identity respnsible for transmitting this message. From
67 indicates the message author.
69 In web-based social systems, a reply to a message SHOULD be conveyed to all of
70 the original message participants. Only the author of the original message
71 may know all the recipients (such as those contained in Bcc: elements). The
72 author of a message always provides 'From'. They MUST duplicate this
73 information as 'Sender'.
75 A reply to a given message MUST be sent to the original From address, and MAY
76 be sent to any additional addresses in the recipient list. The original author
77 MUST send the reply to all known recipients of the original message, with
78 their webfinger identity as Sender, and the comment/reply author as From.
80 Receiving agents MUST validate the From identity as the signer of the salmon
81 magic envelope, and MAY reject it. They MAY also reject the message if the
82 Sender is not allowed in their "friend list", or if they do not have a
83 suitable relationship with the Sender.
88 indicates a public message with no specifically enumerated recipients.
90 The fields To:, Cc:, and/or Bcc: MAY be present. At least one recipient field
91 MUST be present. These fields may use the entire syntax specified by RFC822,
94 To: "Bob Smith" <bob@example.com>, "Alice Jones" <alice@example.com>
96 is a valid entry. A zot envelope is UTF-8 encoded, which differs from RFC822.
97 The host component MUST be US-ASCII, with punycode translation of
98 internationalised domain names applied.
100 The entire envelope is encrypted with alg using key and iv. Only AES-256-CBC
101 is defined as an algorithm in this specification. The encrypted envelope is
102 then base64url encoded for transmission.
104 The zot envelope MAY include remote addresses. A zot delivery agent MUST parse
105 all addresses and determine whether a delivery address to the current endpoint
106 is valid. This may be the result of:
108 1. An address contains the public message wildcard '*'
110 2. The current endpoint is a personal endpoint and one of the recipients
111 listed in the To:, Cc:, or Bcc: addresses matches the webfinger address of
112 the "owner" of the endpoint.
114 3. The current endpoint is a bulk delivery endpoint. The bulk delivery
115 ednpoint is defined elsewhere in this document. The bulk delivery agent
116 will deliver to all local addresses found in the address lists.
121 Currently the only valid choice for alg is "AES-256-CBC".
127 The data field is a salmon magic envelope. This is encrypted with alg using
128 key and iv. The result is then base64url encoded for transmission.
130 For the first release of this specification, the data format of the enclosed
131 salmon SHOULD be 'application/xml+atom' representing an Atom formatted
132 ActivityStream. Future revisions MAY allow other alternate data formats.
133 All acceptable formats MUST be listed in an XRD property (described elsewhere
140 The zot message is then POSTed to the zot endpoint URL as
141 application/text+xml and can be decoded/decrypted by the recipient using
144 The normal salmon endpoint for a service MAY be used as an alternate
145 delivery method for non-encrypted (e.g. public) messages.
147 Discover of the zot endpoint is based on webfinger XRD:
149 <link rel="http://purl.org/zot/1.0/post"
150 href="http://example/org/zot-endpoint" />
156 A site MAY provide a bulk delivery endpoint, which MAY be used to avoid
157 multiple encryptions of the same data for a single destination.
158 This is discoverable by providing a zot endpoint with a corresponding
159 salmon public key in the site's .well-known/host-meta file.
160 A delivery to this endpoint will deliver to all local recipients provided
161 within the zot envelope.
167 This specification is subject to change. The current version which is in
168 effect at a given site may be noted by XRD properties. The following
169 properties MUST be present in the XRD providing the relevant endpoint:
171 <Property xmlns:zot="http://purl.og/zot/1.0"
172 type="http://purl.org/zot/1.0/version"
175 <Property xmlns:zot="http://purl.og/zot/1.0"
176 type="http://purl.org/zot/1.0/accept"
177 zot:accept="application/atom+xml" />
179 Version is specified in this document and indicates the current revision.
180 Implementations MAY provide compatibility to multiple incompatible versions
181 by using this version indication. The "accept" indicates a range of document
182 content types which may be enclosed in the underlying salmon magic envelope.
183 We anticipate this specification will in the future allow for a close variant
184 of "message/rfc822" and which may include MIME. This may also be used to
185 embed alternate message formats and protocols such as
186 "application/x-diaspora+xml". If a delivery agent is unable to provide any
187 acceptable data format, the delivery MUST be terminated/cancelled.
190 **********************
191 * Zid authentication *
192 **********************
194 URLs may be present within a zot message which refer to private and/or
195 protected resources. Zid uses OpenID to gain access to these protected
196 resources. These could be private photos or profile information - or *any*
197 web accessible resource. Using zid, these can have access controls which
198 extends to any resolvable webfinger address.
200 Zid authentication relies on the presence of an OpenID provider element in
201 webfinger, and a URL template which is applied to protected resources within
204 The template is designated with the characters "{zid=}" within a URL of a zot
205 message. When the page is rendered for viewing to an observer, this template
206 is replaced with the webfinger address of the viewer (if known), or an empty
207 string if the webfinger address of the viewer cannot be determined.
209 For example in a message body:
211 http://example.com/photos/bob/picture.jpg?{zid=}
213 refers to a private photo which is only visible to alice@example.com.
215 If Alice is viewing the page, the link is rendered with
217 http://example.com/photos/bob/picture.jpg?zid=alice@example.com
219 If the page viewer is unknown, it is rendered as
221 http://example.com/photos/bob/picture.jpg?zid=
224 When the link is visited, the web server at example.com notes the presence of
225 the zid parameter and uses information from webfinger to locate the OpenID
226 provider for the zid webfinger address. It then redirects to the OpenID
227 server and requests authentication of the given person. If this is successful,
228 access to the protected resource is granted.
230 Only authentication via OpenID is defined in this version of the specification.
232 This can be used to provide access control to any web resource to any
233 webfinger identity on the internet.