Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Signpost Architecture and Communications

sebastian edited this page · 9 revisions

Policy - > social net. Based on resources and identity

A policy checker runs alongside of each signpost.

So the policy checker will be running on each one of the signposts. - Manage users’ address book. - Extended to include affiliation, social nets and friend’s keys (Google docs’ CardDav or whatever else)

Policy maker stores the database. Signpost will request public keys from users. Signpost will be key-agnostic.

Data stored on signposts

Databases. (Is it possible to extend google calendar online?) http://en.wikipedia.org/wiki/CardDAV

Each signpost stores a database with the following tables:

A) USERS TABLE (Extension Address Book) ID(Primary Key), Name, Fields (Address Book, from google?)

B) SIGNPOST_USER_IDS TABLE USER_ID, SIGNPOST_LIKE_NAME (Primary Key, String in the fashion twitter@narseo), KEY (Generated by the other users signpost), TIMESTAMP (Used to refresh keys)

C) POLICIES TABLE ID (primary key for the policy), Policy_data (needs to be defined. Policy language!)

D) USERS_POLICIES_TABLE (Map Policies into users) USER_ID (Index, ID_USERS_TABLE), POLICY_ID (Index, ID IN POLICIES_TABLE)

Push keys?? At the moment we are only pulling stuff from the signpost. It might be possible to exploit channels to refresh your keys in your friends’ tables.

User tables and Policies are kept in sync between all of a users signposts. It will remain secure in your personal signpost network. The entries in the UsersIds table are only cached, but not replicated between signpsosts. If a key entry does not exist in a UserIds table on a signpost, it requests it from the clients signpost using an HTTP GET request (GET /keys/CONNECTING_DEVICE_ID)

Synchronise changes in address book between machines.

Communication between client resolver and signposts

All responses and payloads are in JSON.

Get a list of signposts

Request: GET /v1/signposts

Returns: [{'ip' = IP, 'port' = PORT},...]

A list of signposts objects (crotsos: How does a personal signpost, or a signpost server register in the system?)

Resources provided under a domain

Request: GET /v1/resources/DOMAIN

Returns: [{'resource_name'=RESOURCE_NAME, 'resource_id'=RESOURCE_ID, 'service'=SERVICE_PROVIDED},...]

A list of all the resources the client is allowed to see within a domain. The DOMAIN is either one of the domains under control of the signpost, or a remote domain, in which case the signpost proxies the request to the signpost responsible for the domain.

(crotsos: maybe need to add some information about the identity of the requester)

Resources provided by a particular device

Request: GET /v1/resources/domain/DEVICE

Returns: {'status' = "OK|FAILURE", ('message' = REASON_FOR_FAILURE | 'ip' = IP_TO_CONNECT_TO, 'port' = PORT_TO_CONNECT_TO)}

It returns a status of either OK or FAILURE. If OK is returned, an ip and port is returned alongside the response. If FAILURE is returned, a message describing the failure is returned as well.

Adding a new device to a signpost

Request: POST /v1/resources/DOMAIN

Payload: {'device-name'=NAME_OF_DEVICE, 'device-type'="AWARE|DUMB|ENABLED"}

Response: {'status' = "OK|FAILURE", ('message' = REASON_FOR_FAILURE | 'private-key'=NEW_DEVICE_PRIVATE_KEY)}

Upon approval from the user, the device is added to the signpost domain requested.

Updating the information for a device

Request: PUT /v1/resources/domain/DEVICE

Payload: {'accessible_through'= [{'ip'=IP, 'port'=PORT, 'process_name'=NAME_OF_LISTENING_PROCESS},...]}

Multicast DNS

Request: POST /v1/multicast/domain/device

Payload: [{'source_ip'=IP_OF_BROADCAST_SOURCE, 'port'=PORT_ON_LISTENING_DEVICE, 'service'=SERVICE_TYPE}, ...]

The services broadcasted by a device can be relayed to the signpost network and the other devices of the user.

Invalidated keys

Request: GET /v1/invalidated_keys[/UNIX_TIMESTAMP]

Returns: [{'device'=DEVICE_ID, status='INVALID|NEW','pub-key'=PUB_KEY},...]

Communication between signposts

A signpost of user A, needs the public-key of a DEVICE belonging to the signpost of user B.

Request from A to B: GET /v1/keys/DEVICE

Returns: {'device_id'=ID, 'key'=KEY_DATA} (crotsos: maybe suppress that by doing host authentication in SSL)

Scenarios

The sequence diagram accompanying the following sequence of steps can be found here: diagram with labels and diagram without labels.

  1. client application requests the IP of domain macbook.narseo.name
  2. assuming no DNS cache, the resolving performs a DNS request
  3. the DNS server returns the signpost narseo.name to the resolver
  4. the resolver asks its local signpost on the macbook to resolve macbook.narseo.name
  5. the signpost on macbook.seb.name requests the resource from the narseo.name signpost
  6. the narseo.name signpost asks it’s policy checker if the request should be allowed
  7. if the public-key of macbook.seb.name is cached, a policy decision can be made directly and the reply returned to narseo.name's signpost, otherwise:
  8. the policy checker does a DNS request for macbook.seb.name to find it's signpost
  9. the DNS server returns the signpost name sebastian.name
  10. the policy checker requests the public-key of macbook.sebastian.name from the sebastian.name signpost
  11. the key is returned to the policy checker which caches it
  12. the policy checker makes a decision based on social graph
  13. the decision is returned to the narseo.name signpost
  14. the response is returned to macbook.sebastian.name

The following steps are taken depending on if the policy checker allows or denies a response to be generated (unfortunately the numbering is off. It should read 15-17(d - denied, a - accepted).

Scenario, connection denied:

  1. the signpost on macbook.seb.name returns that there is no response to the local client resolver
  2. the client resolver returns responds to the application DNS request that there is no match for macbook.narseo.name

Scenario, connection accepted:

  1. the signpost on macbook.seb.name returns the ip and port number to connect to, to the client resolver
  2. the resolver returns a SRV record or an A record to the application
  3. the application connects to the application running on macbook.narseo.name

Note: There is a process in on each users authoritative signpost that checks and updates a users social network data. Changes it detects are propagated to the other signposts of the user.

All data distribution between signpost instances (also including data for the policy manager) is handled by the signposts.

Something went wrong with that request. Please try again.