SPAN Design - Revision history

Mstigge: /* High-Level Protocol Design */

2005-11-17T14:38:23Z

High-Level Protocol Design

Mstigge: /* High-Level Protocol Design */

2005-11-17T14:35:02Z

High-Level Protocol Design

← Older revision		Revision as of 14:35, 17 November 2005
Line 3:		Line 3:
	= High-Level Protocol Design =		= High-Level Protocol Design =

	[[Image:SPAN_structure.png\|frame\|Our basic communication structure]]		[[Image:SPAN_structure.png\|frame\|thumb\|Our basic communication structure]]

	The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.		The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.

Mstigge: /* Phase 2: Authentification and Authorization */

2005-11-17T14:24:59Z

Phase 2: Authentification and Authorization

← Older revision		Revision as of 14:24, 17 November 2005
Line 39:		Line 39:
	First, the client is identified by some Identity Provider chosen by the service device (which means that the client has to be known by some Identity Provider trusted by the service device). The assertion issued by the IP may be cached for future use. After that, the authorization information for the access has to be retrieved from an Access Control Manager (also chosen by the service device) who manages the access policies for the service device. IP and ACM will usually (?) be two different entities (e.g. mobile phone company and photo print shop).		First, the client is identified by some Identity Provider chosen by the service device (which means that the client has to be known by some Identity Provider trusted by the service device). The assertion issued by the IP may be cached for future use. After that, the authorization information for the access has to be retrieved from an Access Control Manager (also chosen by the service device) who manages the access policies for the service device. IP and ACM will usually (?) be two different entities (e.g. mobile phone company and photo print shop).

	[[Image:~~SPAN_structure~~.png\|frame\|right\|Basic communication structure with direct communication between ACM and IP (bad design)]]		[[Image:SPAN_structure2.png\|frame\|right\|Basic communication structure with direct communication between ACM and IP (bad design)]]
	One could think of methods for minimizing the communication efforts of the client. Besides caching of identity assertions (within the clients cache), the idea could be to let the ACM identify the client itself (with the help of an IP), so that it's not necessary for the client to directly communicate to the IP. But this would have some disadvantages like leakage of information (used service, ...) to the IP or the difficulty of transmitting the needed credentials through the ACM, so we don't consider this as a good design choice.		One could think of methods for minimizing the communication efforts of the client. Besides caching of identity assertions (within the clients cache), the idea could be to let the ACM identify the client itself (with the help of an IP), so that it's not necessary for the client to directly communicate to the IP. But this would have some disadvantages like leakage of information (used service, ...) to the IP or the difficulty of transmitting the needed credentials through the ACM, so we don't consider this as a good design choice.

Mstigge: /* High-Level Protocol Design */

2005-11-17T14:23:19Z

High-Level Protocol Design

← Older revision		Revision as of 14:23, 17 November 2005
Line 3:		Line 3:
	= High-Level Protocol Design =		= High-Level Protocol Design =

	[[Image:SPAN_structure.png\|frame~~\|right~~\|Our basic communication structure]]		[[Image:SPAN_structure.png\|frame\|Our basic communication structure]]

	The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.		The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.

Mstigge at 14:19, 17 November 2005

2005-11-17T14:19:44Z

← Older revision		Revision as of 14:19, 17 November 2005
Line 2:		Line 2:

	= High-Level Protocol Design =		= High-Level Protocol Design =

			[[Image:SPAN_structure.png\|frame\|right\|Our basic communication structure]]

	The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.		The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.
Line 20:		Line 22:

	=== Phase 1.2: Secured Connection ===		=== Phase 1.2: Secured Connection ===

			[[Image:SPAN_fingerprint.png\|frame\|right\|The user verifies the fingerprint optically]]

	After we know to which service on which device we want to talk to, a connection has to be built. It seems logical to start with encryption right here (using e.g. TLS), so that all information potentially leaked to malicious third parties is minimized. It's also a good point to verify that the other end point to which the client talks to is the actual service device, so that any kind of man-in-the-middle attack is prevented. This can be done by using some public-key protocol, so that the client can present the fingerprint (encoded as some colored symbols? Is there some standard to do this?) of the received key used by the service device to its user, who can compare it to some physical label on the service device.		After we know to which service on which device we want to talk to, a connection has to be built. It seems logical to start with encryption right here (using e.g. TLS), so that all information potentially leaked to malicious third parties is minimized. It's also a good point to verify that the other end point to which the client talks to is the actual service device, so that any kind of man-in-the-middle attack is prevented. This can be done by using some public-key protocol, so that the client can present the fingerprint (encoded as some colored symbols? Is there some standard to do this?) of the received key used by the service device to its user, who can compare it to some physical label on the service device.

			[[Image:SPAN_fingerprint_ACM.png\|frame\|right\|The ACM provides the fingerprint (bad design)]]
⚫	Other alternatives seemed possible to verify the fingerprint. E.g. the ACM could provide this information (in phase 2.2), so that the authenticity of the service device could be verified by the client later on, instead of asking the user to compare some colored symbols. But this would mean that the user would have to trust the ACM, and as the service device itself provides the information which ACM to use, this could also be a compromised service (provided by e.g. an attacker who tries to MitM-attack the connection between client and actual service device). Note that the fingerprint can't be provided by the IP as it doesn't necessarily know about ACM or even service device (as they may not have an identity in the sense of an IP).

		⚫	Other alternatives seemed possible to verify the fingerprint. E.g. the ACM could provide this information (in phase 2.2), so that the authenticity of the service device could be verified by the client later on, instead of asking the user to compare some colored symbols. But this would mean that the user would have to trust the ACM, and as the service device itself provides the information which ACM to use, this could also be a compromised service (provided by e.g. an attacker who tries to MitM-attack the connection between client and actual service device), so we consider this as bad design. Note that the fingerprint can't be provided by the IP as it doesn't necessarily know about ACM or even service device (as they may not have an identity in the sense of an IP).

	In cases where it's not that important to ensure that the client talks to the right service device (it may be important in a photo print shop where the user doesn't want to give his photos to somebody else with e.g. much higher prices, but unimportant when accessing a beamer), one could think of a third option "unimportant" besides "matches" and "doesn't match" regarding the fingerprint (with "match" cached for future use and "unimportant" only valid for one use or sth. like that).		In cases where it's not that important to ensure that the client talks to the right service device (it may be important in a photo print shop where the user doesn't want to give his photos to somebody else with e.g. much higher prices, but unimportant when accessing a beamer), one could think of a third option "unimportant" besides "matches" and "doesn't match" regarding the fingerprint (with "match" cached for future use and "unimportant" only valid for one use or sth. like that).
Line 33:		Line 39:
	First, the client is identified by some Identity Provider chosen by the service device (which means that the client has to be known by some Identity Provider trusted by the service device). The assertion issued by the IP may be cached for future use. After that, the authorization information for the access has to be retrieved from an Access Control Manager (also chosen by the service device) who manages the access policies for the service device. IP and ACM will usually (?) be two different entities (e.g. mobile phone company and photo print shop).		First, the client is identified by some Identity Provider chosen by the service device (which means that the client has to be known by some Identity Provider trusted by the service device). The assertion issued by the IP may be cached for future use. After that, the authorization information for the access has to be retrieved from an Access Control Manager (also chosen by the service device) who manages the access policies for the service device. IP and ACM will usually (?) be two different entities (e.g. mobile phone company and photo print shop).

			[[Image:SPAN_structure.png\|frame\|right\|Basic communication structure with direct communication between ACM and IP (bad design)]]
	One could think of methods for minimizing the communication efforts of the client. Besides caching of identity assertions (within the clients cache), the idea could be to let the ACM identify the client itself (with the help of an IP), so that it's not necessary for the client to directly communicate to the IP. But this would have some disadvantages like leakage of information (used service, ...) to the IP or the difficulty of transmitting the needed credentials through the ACM.		One could think of methods for minimizing the communication efforts of the client. Besides caching of identity assertions (within the clients cache), the idea could be to let the ACM identify the client itself (with the help of an IP), so that it's not necessary for the client to directly communicate to the IP. But this would have some disadvantages like leakage of information (used service, ...) to the IP or the difficulty of transmitting the needed credentials through the ACM, so we don't consider this as a good design choice.

	Both authentication and authorization messages between all four parties are transmitted using (signed) SAML assertions and protocols, as follows:		Both authentication and authorization messages between all four parties are transmitted using (signed) SAML assertions and protocols, as follows:

Mstigge at 10:53, 14 November 2005

2005-11-14T10:53:04Z

← Older revision		Revision as of 10:53, 14 November 2005
Line 1:		Line 1:
	[[Category:SPAN]]		[[Category:SPAN]]

	= Protocol Design =		= High-Level Protocol Design =

	The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.		The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.

Mstigge at 10:51, 14 November 2005

2005-11-14T10:51:34Z

@@ Line 3: / Line 3: @@
 = Protocol Design =
 (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 ==
 === 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:

Mstigge at 11:34, 7 November 2005

2005-11-07T11:34:29Z

← Older revision		Revision as of 11:34, 7 November 2005
Line 1:		Line 1:
	[[Category:SPAN]]		[[Category:SPAN]]

	== Protocol Design ==		= Protocol Design =

	=== Phase 1: Service Discovery ===		== Phase 1: Service Discovery ==

	(Bluetooth built-in? IP-based: Bonjour?)		(Bluetooth built-in? IP-based: Bonjour?)
Line 9:		Line 9:
	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.		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 ===		== Phase 2: Authentification and Authorization ==
	(Authentication and authorization message are transmitted using (signed) SAML assertions and protocols.)		(Authentication and authorization message are transmitted using (signed) SAML assertions and protocols.)

			=== Phase 2.1: Authenticated Session ===
⚫	* Client ~~(mobile~~ ~~phone)~~ ~~authenticates~~ to service device ~~(beamer):~~
			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
⚫	** Service device asks for ~~prove~~
⚫	** Client asks Identity Provider for a signed authentication statement
⚫	** Identity Provider provides this
	** Client presents IP-signed identity
	** -> authenticated session opened

	* Client ~~opens~~ ~~authorized~~ ~~session with~~ service device:		* Client presents identity to service device
	** ~~Client~~ asks ~~service device~~ for ~~usage access~~		* Service device asks for prove
		⚫	* Client asks Identity Provider for a signed authentication statement (SAML Authentication query)
	** Service device asks client for authorization
		⚫	* Identity Provider provides this (SAML Authentication statement)
⚫	** Client asks Access Control Manager for authorization to access service device
		⚫	* Client presents IP-signed identity
⚫	** Client gets authorization from Access Control Manager
	** ~~Client~~ ~~hands~~ ~~authorization~~ ~~over to~~ service device		* -> authenticated session opened (service device issues some session-id)
⚫	** -> authorized session opened

		⚫	=== Phase 2.2: Authorized Session ===
	Used SAML assertions and protocols:
			Within this session, an authorized usage session (or multiple?) may be opened. This involves communication client<->service device and client<->Access Control Manager
	* SAML Authentication query
	* SAML Authentication statement
	* SAML Authorization decision query
	* SAML Authorization decision statement

			* Client asks service device for usage access
⚫	=== Phase 3: ~~Using~~ ~~the Service~~ ===
		⚫	* 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 ===		== 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:		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.		* HTTP fundamentally is a synchronous request-response protocol. Our implementation however will probably need asynchronous communications.

Mstigge: /* Phase 2: Authentification and Authorization */

2005-11-07T11:07:01Z

Phase 2: Authentification and Authorization

← Older revision		Revision as of 11:07, 7 November 2005
Line 10:		Line 10:

	=== Phase 2: Authentification and Authorization ===		=== Phase 2: Authentification and Authorization ===
		⚫	(Authentication and authorization message are transmitted using (signed) SAML assertions and protocols.)

			* Client (mobile phone) authenticates to service device (beamer):
⚫	~~All~~ (?) ~~communication~~ ~~can~~ be ~~done~~ using (signed) SAML assertions and protocols
			** Client presents identity
		⚫	** Service device asks for prove
			** Client asks Identity Provider for a signed authentication statement
			** Identity Provider provides this
			** Client presents IP-signed identity
			** -> authenticated session opened

	* Client ~~(mobile~~ ~~phone)~~ ~~authenticates~~ to service device ~~(beamer)~~		* Client opens authorized session with service device:
	* Client asks service device for usage access		** Client asks service device for usage access
	* Service device asks client for authorization		** Service device asks client for authorization
	* Client asks Access Control Manager for authorization to access service device		** Client asks Access Control Manager for authorization to access service device
	* Client gets authorization from Access Control Manager		** Client gets authorization from Access Control Manager
	* Client hands authorization over to service device		** Client hands authorization over to service device
			** -> authorized session opened
⚫	* Service device ~~grants~~ ~~access~~

	Used SAML assertions and protocols:		Used SAML assertions and protocols:
Line 25:		Line 32:
	* SAML Authentication statement		* SAML Authentication statement
	* SAML Authorization decision query		* SAML Authorization decision query
	* SAML Authorization decision statement		* SAML Authorization decision statement

	=== Phase 3: Using the Service ===		=== Phase 3: Using the Service ===

Mstigge: /* Base communications */

2005-11-04T15:25:06Z

Base communications

← Older revision		Revision as of 15:25, 4 November 2005
Line 36:		Line 36:
	* 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.)		* 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 [http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/index.html SCTP], the Stream Control Transmission Protocol (RFC 2960). Another candidate would be BEEP (RFC 3080). A third choice would be XMPP (RFC 3920).		One candidate for an appropriate base protocol to wrap the XML messages up in would be [http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/index.html 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 ([[User:Henryk\|Henryk]] 18:34, 3 Nov 2005 (CET)) personally would like to see SCTP used. However, there are a couple of drawbacks:		I ([[User:Henryk\|Henryk]] 18:34, 3 Nov 2005 (CET)) personally would like to see SCTP used. However, there are a couple of drawbacks:

← Older revision		Revision as of 14:38, 17 November 2005
Line 3:		Line 3:
	= High-Level Protocol Design =		= High-Level Protocol Design =

	[[Image:SPAN_structure.png~~\|frame~~\|thumb\|Our basic communication structure]]		[[Image:SPAN_structure.png\|thumb\|Our basic communication structure]]

	The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.		The proposed high-level protocol we use is devided into 3 phases: In the first phase (Low-Level Connectivity) the client discovers all the available services offered by services devices (phase 1.1) and builds a cryptographically secured connection to the service device from which it will use a service (phase 1.2). We will use this phase also to verify the identity of the service device so that the user can be confident that he uses the assumed service and not the one of a malicious third party.
Line 23:		Line 23:
	=== Phase 1.2: Secured Connection ===		=== Phase 1.2: Secured Connection ===

	[[Image:SPAN_fingerprint.png\|~~frame~~\|~~right\|The user~~ verifies the fingerprint optically]]		[[Image:SPAN_fingerprint.png\|thumb\|User verifies the fingerprint optically]]

	After we know to which service on which device we want to talk to, a connection has to be built. It seems logical to start with encryption right here (using e.g. TLS), so that all information potentially leaked to malicious third parties is minimized. It's also a good point to verify that the other end point to which the client talks to is the actual service device, so that any kind of man-in-the-middle attack is prevented. This can be done by using some public-key protocol, so that the client can present the fingerprint (encoded as some colored symbols? Is there some standard to do this?) of the received key used by the service device to its user, who can compare it to some physical label on the service device.		After we know to which service on which device we want to talk to, a connection has to be built. It seems logical to start with encryption right here (using e.g. TLS), so that all information potentially leaked to malicious third parties is minimized. It's also a good point to verify that the other end point to which the client talks to is the actual service device, so that any kind of man-in-the-middle attack is prevented. This can be done by using some public-key protocol, so that the client can present the fingerprint (encoded as some colored symbols? Is there some standard to do this?) of the received key used by the service device to its user, who can compare it to some physical label on the service device.

	[[Image:SPAN_fingerprint_ACM.png\|~~frame~~\|~~right\|The~~ ACM provides the fingerprint (bad design)]]		[[Image:SPAN_fingerprint_ACM.png\|thumb\|ACM provides the fingerprint (bad design)]]

	Other alternatives seemed possible to verify the fingerprint. E.g. the ACM could provide this information (in phase 2.2), so that the authenticity of the service device could be verified by the client later on, instead of asking the user to compare some colored symbols. But this would mean that the user would have to trust the ACM, and as the service device itself provides the information which ACM to use, this could also be a compromised service (provided by e.g. an attacker who tries to MitM-attack the connection between client and actual service device), so we consider this as bad design. Note that the fingerprint can't be provided by the IP as it doesn't necessarily know about ACM or even service device (as they may not have an identity in the sense of an IP).		Other alternatives seemed possible to verify the fingerprint. E.g. the ACM could provide this information (in phase 2.2), so that the authenticity of the service device could be verified by the client later on, instead of asking the user to compare some colored symbols. But this would mean that the user would have to trust the ACM, and as the service device itself provides the information which ACM to use, this could also be a compromised service (provided by e.g. an attacker who tries to MitM-attack the connection between client and actual service device), so we consider this as bad design. Note that the fingerprint can't be provided by the IP as it doesn't necessarily know about ACM or even service device (as they may not have an identity in the sense of an IP).
Line 39:		Line 39:
	First, the client is identified by some Identity Provider chosen by the service device (which means that the client has to be known by some Identity Provider trusted by the service device). The assertion issued by the IP may be cached for future use. After that, the authorization information for the access has to be retrieved from an Access Control Manager (also chosen by the service device) who manages the access policies for the service device. IP and ACM will usually (?) be two different entities (e.g. mobile phone company and photo print shop).		First, the client is identified by some Identity Provider chosen by the service device (which means that the client has to be known by some Identity Provider trusted by the service device). The assertion issued by the IP may be cached for future use. After that, the authorization information for the access has to be retrieved from an Access Control Manager (also chosen by the service device) who manages the access policies for the service device. IP and ACM will usually (?) be two different entities (e.g. mobile phone company and photo print shop).

	[[Image:SPAN_structure2.png\|~~frame\|right~~\|Basic communication structure with direct communication between ACM and IP (bad design)]]		[[Image:SPAN_structure2.png\|thumb\|Basic communication structure with direct communication between ACM and IP (bad design)]]
	One could think of methods for minimizing the communication efforts of the client. Besides caching of identity assertions (within the clients cache), the idea could be to let the ACM identify the client itself (with the help of an IP), so that it's not necessary for the client to directly communicate to the IP. But this would have some disadvantages like leakage of information (used service, ...) to the IP or the difficulty of transmitting the needed credentials through the ACM, so we don't consider this as a good design choice.		One could think of methods for minimizing the communication efforts of the client. Besides caching of identity assertions (within the clients cache), the idea could be to let the ACM identify the client itself (with the help of an IP), so that it's not necessary for the client to directly communicate to the IP. But this would have some disadvantages like leakage of information (used service, ...) to the IP or the difficulty of transmitting the needed credentials through the ACM, so we don't consider this as a good design choice.