path: root/spec/zot-2012.txt

 

Initial cut at Zot-2012 protocol. This is a very rough draft of some very rough ideas and concepts. 
It is not yet intended to be a definitive specification and many things like the security handshakes are yet to be specified precisely. 

All communications are https


First create a global unique channel and assign a location

Site id is 'https://macgirvin.com'
Site channel-id is 'https://macgirvin.com/channel/1'

$guid = base64url_encode(hash('whirlpool','https://macgirvin.com/channel/1.' . mt_rand(1000000,9999999),1);

$guid_sig = base64_urlencode(rsa_sign($guid,$myprivatekey));

$location = Site id
$location_sig = base64_urlencode(rsa_sign($location,$myprivatekey));


This information will identify a channel+site pair in the future. When contact is made initially, a lookup is performed to a well known URL at this site to verify the signatures of both the guid and the site. After this information has been verified, it is stored and we can use them to uniquely identify a channel/location pair in the future. 

If a new location is provided, this process is repeated but only the new location needs to be verified and stored.

Messages are sent by providing this information in an HTTP post (*) to the other site, along with a protocol version specifier and type of message and a verification token. For message types which do not require identity validation, the message may be included. Others will require a security handshake with the remote site calling back the original to verify the identity assertion and the message is only collected at that time. 

Multiple messages may be sent, and a callback may  result in the collection of multiple messages destined for this site, not necessarily limited to the channel/location which was asserted. 
 

(*) A POST method is used for many protocol transactions as site "hardening" tools may place overly restrictive length limits on GET data. We are typically sending several encoded/encrypted strings and these requests are likely to fail on some sites and become a nagging support issue if a GET request is used.

The verification token is signed by the remote site and the signed token returned during the callback. This verifies the identity of the callback - by matching with known tokens. 


Permissions:

Permissions are available for several different activities. This list is enumerated by a POST to the permissions service with the above channel+location information. An array of permissions will be returned. If no identity assertion is made, a list of the default channel permissions is returned. 
Initial cut at Zot-2012 protocol. This is a very rough draft of some very rough ideas and concepts. 
It is not yet intended to be a definitive specification and many things like the security handshakes are yet to be specified precisely. 

All communications are https


First create a global unique channel and assign a location

Site id is 'https://macgirvin.com'
Site channel-id is 'https://macgirvin.com/channel/1'

$guid = base64url_encode(hash('whirlpool','https://macgirvin.com/channel/1.' . mt_rand(1000000,9999999),1);

$guid_sig = base64_urlencode(rsa_sign($guid,$myprivatekey));

$location = Site id
$location_sig = base64_urlencode(rsa_sign($location,$myprivatekey));


This information will identify a channel+site pair in the future. When contact is made initially, a lookup is performed to a well known URL at this site to verify the signatures of both the guid and the site. After this information has been verified, it is stored and we can use them to uniquely identify a channel/location pair in the future. 

If a new location is provided, this process is repeated but only the new location needs to be verified and stored.

Messages are sent by providing this information in an HTTP post (*) to the other site, along with a protocol version specifier and type of message and a verification token. For message types which do not require identity validation, the message may be included. Others will require a security handshake with the remote site calling back the original to verify the identity assertion and the message is only collected at that time. 

Multiple messages may be sent, and a callback may  result in the collection of multiple messages destined for this site, not necessarily limited to the channel/location which was asserted. 
 

(*) A POST method is used for many protocol transactions as site "hardening" tools may place overly restrictive length limits on GET data. We are typically sending several encoded/encrypted strings and these requests are likely to fail on some sites and become a nagging support issue if a GET request is used.

The verification token is signed by the remote site and the signed token returned during the callback. This verifies the identity of the callback - by matching with known tokens. 


Permissions:

Permissions are available for several different activities. This list is enumerated by a POST to the permissions service with the above channel+location information. An array of permissions will be returned. If no identity assertion is made, a list of the default channel permissions is returned.