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

(Authentication and authorization message are transmitted using (signed) SAML assertions and protocols.)

Phase 2.1: Authenticated Session

First, our client (mobile phone) opens an authenticated session (by authenticating to service device (beamer) of course). This involves communication client<->service device and client<->Identity Provider:

• Client presents identity to service device
• Service device asks for prove
• Client asks Identity Provider for a signed authentication statement (SAML Authentication query)
• Identity Provider provides this (SAML Authentication statement)
• Client presents IP-signed identity
• -> authenticated session opened (service device issues some session-id)

Phase 2.2: Authorized Session

Within this session, an authorized usage session (or multiple?) may be opened. This involves communication client<->service device and client<->Access Control Manager

• Client asks service device for usage access
• Service device asks client for authorization
• Client asks Access Control Manager for authorization to access service device (SAML Authorization decision query)
• Client gets authorization from Access Control Manager (SAML Authorization decision statement)
• Client hands authorization over to service device
• -> authorized session opened (service device issues some session-id)

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). (See SPAN Web Ressources)

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.)