SPAN Design

Protocol Design

Phase 1: Service Discovery

(Bluetooth built-in? IP-based: Bonjour?)

We should define a service discovery mechanism that is completely IP-based (most probably: use Bonjour for that) and completely agnostic of the lower layers. Then there should also be the possibility to use mechanisms that are specific to the respective lower layer, e.g. to speed up discovery and most importantly to optimize the operation (there's no sense in establishing a full IP connection with ZeroConf etc. when it can be determined at the Bluetooth layer that the remote side won't talk with us anyways). These lower layer mechanisms would have to be defined separately for each NFC technology. In the case of Bluetooth that would most probably be based on SDP.

Phase 2: Authentification and Authorization

All (?) communication can be done using (signed) SAML assertions and protocols

• Client (mobile phone) authenticates to service device (beamer)
• Client asks service device for usage access
• Service device asks client for authorization
• Client asks Access Control Manager for authorization to access service device
• Client gets authorization from Access Control Manager
• Client hands authorization over to service device
• Service device grants access

Used SAML assertions and protocols:

• SAML Authentication query
• SAML Authentication statement
• SAML Authorization decision query
• SAML Authorization decision statement

Phase 3: Using the Service

...

Base communications

Phases 2 and 3 need a common base communications protocol. It seems logical to use XML for all protocol messages. One question still remains: How do we transfer our XML messages over the IP network? The common approach apparently is to use SOAP. Although SOAP theoretically can be used over any transport mostly no one ever uses anything else than SOAP over HTTP. This approach doesn't fit our environment:

• HTTP fundamentally is a synchronous request-response protocol. Our implementation however will probably need asynchronous communications.
• Also not all exchanges will be initiated by the same side. E.g. most of the time the mobile phone will initiate a request-response type exchange with the beamer, however, sometimes the beamer might want to initiate an exchange, such as asking for authentication. This type of communication does not nicely map to HTTP operations. (It would be necessary to implement an HTTP server on the mobile phone, which just doesn't feel right.)

One candidate for an appropriate base protocol to wrap the XML messages up in would be SCTP, the Stream Control Transmission Protocol (RFC 2960). Another candidate would be BEEP (RFC 3080). A third choice would be XMPP (RFC 3920).

I (Henryk 18:34, 3 Nov 2005 (CET)) personally would like to see SCTP used. However, there are a couple of drawbacks:

• SCTP sits directly on top of IP, and I'm not sure whether we can get down that far in the mobile phone's IP stack
• There is no existing SOAP over SCTP binding, so we would have to invent that
• Implementing SCTP might be more complex than is needed for our project

So from a purely rational standpoint BEEP (over TCP) seems to be the best choice:

• There is an SOAP over BEEP binding (RFC 3288)
• BEEP explicitly supports TLS.
• BEEP can be used over TCP, which should be comparatively easy to implement on the mobile phone.
• If need be, BEEP can used over other transports than TCP/IP, e.g. Bluetooth RFCOMM.

(And of course: BEEP has the superior abbreviation compared with SCTP.)