Skip to content
This repository
tree: b95f415f2c
Fetching contributors…

Cannot retrieve contributors at this time

file 360 lines (254 sloc) 13.454 kb
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 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360
This is the Zot! social communications protocol.

Specification revision: 1
2 October 2011

Mike Macgirvin
This specification is public domain.

Zot is a framework for secure delivery of messages on the web based on
webfinger and encapsulating salmon.

First read the salmon and salmon magic envelope specifications. Zot also
makes use of webfinger and ActivityStreams and several concepts from RFC822
(email). Zot encompasses the zot delivery framework and the zid remote
access protocol.

The current specification revision (1) is frozen until a reference
implementation is available. After that, any protocol changes will require a
change to the revision number.

****************
* Zot delivery *
****************

Format of a zot wrapper. This completely encapsulates a salmon magic envelope
and provides privacy protection, while defining a delivery envelope - a
concept familiar to email systems. All addresses in zot are webfinger
resolvable addresses containing zot endpoints and salmon public keys (zot
is a superset of salmon).


<?xml version='1.0' encoding='UTF-8'?>
<zot:msg xmlns:zot='http://purl.org/zot/1.0'>
 <zot:key>((key))</zot:key>
 <zot:iv>((iv))</zot:iv>
 <zot:env_key>((env_key))</zot:env_key>
 <zot:env_iv>((env_iv))</zot:env_iv>
 <zot:env>((envelope))</zot:env>
 <zot:sig key_id="xxx">((sender signature))</zot:sig>
 <zot:alg>AES-256-CBC</zot:alg>
 <zot:data type='application/magic-envelope+xml'>((salmon))</zot:data>
</zot:msg>


zot:key
*******

A suitable randomly generated encyption key of length 32 octets for encrypting
the salmon packet. This is then encrypted with the sender's private key and
base64url encoded.

zot:iv
******

A suitable randomly generated initialisation vector of length 16 octets for
encrypting the salmon packet. This is then encrypted with the sender's private
key and base64url encoded.

zot:env_key
***********

A suitable randomly generated encyption key of length 32 octets for encrypting
the envelope. This is then encrypted with the recipient's public key and
base64url encoded. For bulk deliveries, it is encrypted with the site bulk
delivery public key.


zot:env_iv
**********

A suitable randomly generated initialisation vector of length 16 octets for
encrypting the envelope. This is then encrypted with the recipient's public
key and base64url encoded. For bulk deliveries, it is encrypted with the site
bulk delivery public key.


zot:env
*******

This consists of RFC822-style header fields representing the sender and
recipient(s). Line lengths have no defined limit and RFC822 continuation
lines are not supported. If an inbound server is not able to process an
envelope or post due to size constraints, it SHOULD return a
"413 Entity too large" HTTP response.

Example:

Z-From: zot:bob@example.com
Z-Sender: zot:bob@example.com
Z-To: zot:alice@example.com

Both "Z-From:" and "Z-Sender:" MUST be provided, and represent a single
webfinger address of the author and sender respectively. The webfinger
address for the From address MUST contain a discoverable salmon public key
which is needed to verify the enclosed salmon data. Sender is used to indicate
the webfinger identity responsible for transmitting this message. From
indicates the message author.

In web-based social systems, a reply to a message SHOULD be conveyed to all of
the original message participants. Only the author of the original message
may know all the recipients (such as those contained in Bcc: elements). The
author of a message always provides 'From'. They MUST duplicate this
information as 'Sender' when posting a followup message.

A reply to a given message MUST be sent to the From address of the original
post, and MAY be sent to any additional addresses in the recipient list. The
original post author MUST send the reply to all known recipients of the
original message, with their webfinger identity as Sender, and the
comment/reply author as From.

Receiving agents SHOULD validate the From identity as the signer of the salmon
magic envelope, and MAY reject it. They SHOULD also verify the Sender signature
of the zot packet if it is different than the salmon signature. They MAY
reject the message if the Sender is not allowed in their "friend list", or if
they do not have a suitable relationship with the Sender, or if either
signature fails to validate. Rejected messages for one of these reasons SHOULD
be indicated with a "400 Bad Request" HTTP response.


Z-To: *

indicates a public message with no specifically enumerated recipients.

The fields Z-To: and/or Z-Bcc: MAY be present. At least one recipient field
MUST be present.

Z-To: zot:bob@example.com, zot:alice@example.com, mailto:dave@example.com
Z-Bcc: zot:https://example.com/profile/richard

are valid entries. Adresses are comma separated and individual entries MUST NOT
contain commas. There MAY be any number of ASCII space characters between
entries for legibility. Header lines are terminated with a linefeed character
(ASCII 0x0A).

This specification provides the following protocol address prefixes
for use in Z-To: or Z-Bcc: elements:

zot: - normal zot delivery using webfinger or LRDD resolvable address
dfrn: - legacy DFRN mode delivery using webfinger or LRDD resovable address
ostatus: - normal OStatus delivery using webfinger or LRDD resovable address
diaspora: - Diaspora network delivery using webfinger address
facebook: - Facebook profile page URL
twitter: - Twitter personal page URL without AJAX '#!' fragment
mailto: - email RFC822/ESMTP address

Examples:

twitter:http://twitter.com/bjensen
facebook:http://facebook.com/profile.php?id=000000001

Foreign protocol addresses which have not been defined in this specification
or future revisions of this specification and which are unknown to the
recipient delivery process MAY be ignored.

In cases where an address may contain either a webfinger or LRDD address, the
webfinger address SHOULD be used preferentially.


Z-Bcc:
******

The Z-Bcc element may contain one or more addresses which are hidden from end
user presentation. A zot receiving system MUST NOT store or allow for
the display of the Bcc information. Implementations which require extreme
privacy SHOULD send individual posts to each of the Bcc: recipients containing
only a single address. They MAY send all Bcc: posts using bulk delivery,
however this may have privacy implications as there is no guarantee a
receiving system will not log, store, or otherwise reveal the contents of the
Bcc recipient list.

Z-To: addresses MAY be shown to an end user.
 

Envelope encryption
*******************


The entire envelope is encrypted using alg with env_key and env_iv and
base64url encoded for transmission.

The zot envelope MAY include remote addresses. A zot inbound delivery agent
MUST parse the envelope and determine whether a delivery address to the
current endpoint is valid. This may be the result of:

1. An address contains the public message wildcard '*'

2. The current endpoint is a personal endpoint and one of the recipients
listed in the Z-To: or Z-Bcc: addresses matches the webfinger address of
the "owner" of the endpoint.

3. The current endpoint is a bulk delivery endpoint. The bulk delivery
endpoint is defined elsewhere in this document. The bulk delivery agent
will deliver to all local addresses found in the address lists.

zot:sig
*******

The Sender of the message signs the underlying salmon data in the manner
prescribed by salmon. If the Sender and From address are identical, the
signature will be identical to the signature of the underlying salmon packet.
If they are different, this signature is verified with the Sender's public
key to verify the Sender.

zot:alg
*******

Currently the only valid choice for alg is "AES-256-CBC".


zot:data
********

The data field is a salmon magic envelope. This is encrypted with alg using
key and iv. The result is then base64url encoded for transmission.

For the first release of this specification, the data format of the enclosed
salmon SHOULD be 'application/atom+xml' representing an Atom formatted
ActivityStream. Future revisions MAY allow other alternate data formats.
All acceptable formats MUST be listed in an XRD property (described elsewhere
in this document).


Delivery
********

The zot message is then POSTed to the zot endpoint URL as
application/text+xml and can be decoded/decrypted by the recipient using
their private key.

The normal salmon endpoint for a service MAY be used as an alternate
delivery method for non-encrypted (e.g. public) messages.

Discover of the zot endpoint is based on webfinger XRD:

<Link rel="http://purl.org/zot/1.0/post"
href="http://example/org/zot-endpoint" />


Bulk Delivery
*************

A site MAY provide a bulk delivery endpoint, which MAY be used to avoid
multiple encryptions of the same data for a single destination.
This is discoverable by providing a zot endpoint with a corresponding
salmon public key in the site's .well-known/host-meta file.
A delivery to this endpoint will deliver to all local recipients provided
within the zot envelope.


Extensibility
*************

This specification is subject to change. The current version which is in
effect at a given site may be noted by XRD properties. The following
properties MUST be present in the XRD providing the relevant endpoint:

<Property type="http://purl.org/zot/1.0/version">1</Property>
<Property type="http://purl.org/zot/1.0/accept">application/atom+xml</Property>


Version is specified in this document and indicates the current revision.
Version is an increasing non-zero integer value. There are no minor versions.
Implementations MAY provide compatibility to multiple incompatible versions
by using this version indication. The "accept" indicates a range of document
content types which may be enclosed in the underlying salmon magic envelope.
We anticipate this specification will in the future allow for a close variant
of "message/rfc822" and which may include MIME. This may also be used to
embed alternate message formats and protocols such as
"application/x-diaspora+xml". If a delivery agent is unable to provide any
acceptable data format to the remote system, the delivery to that system MUST
be terminated/cancelled.

Foreign Messages
****************

Messages MAY be imported from other networks and systems which have no
knowledge of salmon signatures. The salmon signature in this case MUST be the
exact string 'NOTSIGNED' to indicate that the author (From address) cannot be
validated using salmon verification. This message MUST be relayed by a Sender
who can provide a valid salmon signature of the message via zot:sig. Delivery
systems MAY reject foreign messages.





*******************************
* Zid (Zot-ID) authentication *
*******************************

This section of the document is considered separate from the delivery
specification precding it and represents a different protocol, which is
currently incomplete. This will be split off into another document in the
future, but is presented here as a synergistic component of the Zot network
model.


URLs may be present within a zot message which refer to private and/or
protected resources. Zid uses OpenID to gain access to these protected
resources. These could be private photos or profile information - or *any*
web accessible resource. Using zid, these can have access controls which
extends to any resolvable webfinger address.

Zid authentication relies on the presence of an OpenID provider element in
webfinger, and a URL template which is applied to protected resources within
a zot message.

The template is designated with the characters "{zid=}" within a URL of a zot
message. When the page is rendered for viewing to an observer, this template
is replaced with the webfinger address of the viewer (if known), or an empty
string if the webfinger address of the viewer cannot be determined.

For example in a message body:

http://example.com/photos/bob/picture.jpg?{zid=}

refers to a private photo which is only visible to alice@example.com.

If Alice is viewing the page, the link is rendered with

http://example.com/photos/bob/picture.jpg?zid=alice@example.com

If the page viewer is unknown, it is rendered as

http://example.com/photos/bob/picture.jpg?zid=


When the link is visited, the web server at example.com notes the presence of
the zid parameter and uses information from webfinger to locate the OpenID
provider for the zid webfinger address. It then redirects to the OpenID
server and requests authentication of the given person. If this is successful,
access to the protected resource is granted.

A browser cookie may be provided to avoid future authentication redirects
and allow authenticated browsing to other resources on the website.

Only authentication via OpenID is defined in this version of the specification.

This can be used to provide access control of any web resource to any
webfinger identity on the internet.


*********
* Links *
*********

Salmon Protocol
http://www.salmon-protocol.org/salmon-protocol-summary

Salmon Magic Envelope
http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html

Atom Activity Stream Draft
http://activitystrea.ms/specs/atom/1.0/

Activty Stream Base Schema
http://activitystrea.ms/head/activity-schema.html

WebFinger Protocol
http://code.google.com/p/webfinger/wiki/WebFingerProtocol
Something went wrong with that request. Please try again.