160 Pers Ubiquit Comput(2007)11: 157-169 recognize this diversity and try to make our architec- Policy.lD_(2 bit digitals) ture open and extensible enough A MobiPolicy uses customized criteria to enable it Reversed Block (issued (I bits to produce a fine-grained evaluation result. For in- SelfUsing block [1 (I bits) stance, a MobiPolicy published by the National Accommodation association will have one section for describing the attributes for real estate agents, and Fig. 2 Policy ID allocation another sections for describing properties such as their type, the number of bed rooms, location etc. For an example"Friend-Finder"service, the service provider self-using Policy-IDs Non-collision is assured for Pol can publish a MobiPolicy which tries to describe the icy-IDs from the reserved block person who subscribes to the service. For example, the The purpose of the Policy-ID is that it allows the name, gender, nationality and some other service re- user (or his/her MobiManager)to recognize which lated attributes could be described in the Friend-Fin- service an incoming MobiPass is related to By check der MobiPolicy. It is important to note that a ing the Policy-ID, it enables the MobiManager to MobiPolicy to govern mobile interactions with an recognize and discard and/ or process all different individual could equally well not contain personally types of MobiPasses identifying information, e.g., only their shopping By having this specific standard for incoming infor- interests or other preferences, enabling privacy main- mation to a mobile user, describing the unpredicted taining mobile interactions. environment and surrounding entities, if this informa In theory, any organization (person) can publish tion can also be authoritatively certified, the mobile their MobiPolicies, there is no technical barrier to de- entity can trust other entities which present the certi ter the organization (person) to publish their own fied evaluation results, even a previously unseen mo- MobiPolicy. For instance, either the Australian Taxa- bile entity, based on the particular required tion Office(ATO) or Paramatta Football Club can characteristics of the entity that have been certified publish their own specific MobiPolicy to describe their For example, by employing the standard for describing ervice and which mobile entities will be involved in a furniture shop, when the mobile entity receives the their services. This is absolutely acceptable and feasi- message formatted in accordance with a MobiPolicy ble in the technical sense. The reason to enable this is for a shop-finder service, it can easily have a quickly to meet the maximum flexibility and scalability in our attained and trusted idea of the seller and its business architecture Due to the pre-defined standard that a MobiPolicy In terms of practical concerns (related to end user represents, requestees will be able to design custom- Acceptance), although there is no limitation about the ized rules in advance through their knowledge of the publishing ability of MobiPolicies, it is surmised that criteria provided by a MobiPolicy sually market forces would push the similar services to be merged and form a more general and commonly 2.2.3 Extended certificate authority usable MobiPolicy, shared in by a larger user set/ market As the name suggests, the ECa is a functionally ex- 6 The Policy-ID is very important in our architecture tended CA Beyond issuing the digital certificate, it can because it allows for the reuse, recognizing and man- also evaluate the mobile entities according to the mo- aging of the MobiPolicy. It is a globally unique 32 bit biPolicy, and digitally sign the results of the evaluation digital number. The Policy-ID range has two blocks, In our architecture, the eCa is a trusted third party which are the reserved block and self-using block. IDs Trust is(partially) delegated to the ECA, and the with the first digit a 0 belong to the reserved block and output produced by the ECa is the MobiPass. The the remainder of IDs are in the self-using block ECA is the connector which links the potentially (Fig. 2). The Policy-ID in the reserved range can be communicating but untrusted entities into a scalable only assigned by the Cr. If a MobiPolicy is created by and safe network. someone who does not want it to be registered in the The ECA can be the MobiPolicy publisher or the CR(e.g, a MobiPolicy shared with a few friends), a third party who is asked to certify the related business self-using block is available. Generally, random 32-bit entities and activities. It can vary according to the de numbers are chosen to work as the Policy-ID. As the gree of trustworthiness needed in the service. Or in set of available numbers is relatively large, it mitigates some scenarios, the ECA might not have the real against, (but not totally eliminates) the collision of the authority to evaluate mobile entities and all relevant Sprrecognize this diversity and try to make our architec￾ture open and extensible enough. A MobiPolicy uses customized criteria to enable it to produce a fine-grained evaluation result. For in￾stance, a MobiPolicy published by the National Accommodation Association, will have one section for describing the attributes for real estate agents, and another sections for describing properties such as their type, the number of bed rooms, location etc. For an example ‘‘Friend-Finder’’ service, the service provider can publish a MobiPolicy which tries to describe the person who subscribes to the service. For example, the name, gender, nationality and some other service re￾lated attributes could be described in the Friend-Fin￾der MobiPolicy. It is important to note that a MobiPolicy to govern mobile interactions with an individual could equally well not contain personally identifying information, e.g., only their shopping interests or other preferences, enabling privacy main￾taining mobile interactions. In theory, any organization (person) can publish their MobiPolicies, there is no technical barrier to de￾ter the organization (person) to publish their own MobiPolicy. For instance, either the Australian Taxa￾tion Office (ATO) or Paramatta Football Club can publish their own specific MobiPolicy to describe their service and which mobile entities will be involved in their services. This is absolutely acceptable and feasi￾ble in the technical sense. The reason to enable this is to meet the maximum flexibility and scalability in our architecture. In terms of practical concerns (related to end user acceptance), although there is no limitation about the publishing ability of MobiPolicies, it is surmised that usually market forces would push the similar services to be merged and form a more general and commonly usable MobiPolicy, shared in by a larger user set/ market. The Policy-ID is very important in our architecture because it allows for the reuse, recognizing and man￾aging of the MobiPolicy. It is a globally unique 32 bit digital number. The Policy-ID range has two blocks, which are the reserved block and self-using block. IDs with the first digit a 0 belong to the reserved block and the remainder of IDs are in the self-using block (Fig. 2). The Policy-ID in the reserved range can be only assigned by the CR. If a MobiPolicy is created by someone who does not want it to be registered in the CR (e.g., a MobiPolicy shared with a few friends), a self-using block is available. Generally, random 32-bit numbers are chosen to work as the Policy-ID. As the set of available numbers is relatively large, it mitigates against, (but not totally eliminates) the collision of the self-using Policy-IDs. Non-collision is assured for Pol￾icy-IDs from the reserved block. The purpose of the Policy-ID is that it allows the user (or his/her MobiManager) to recognize which service an incoming MobiPass is related to. By check￾ing the Policy-ID, it enables the MobiManager to recognize and discard and/ or process all different types of MobiPasses. By having this specific standard for incoming infor￾mation to a mobile user, describing the unpredicted environment and surrounding entities, if this informa￾tion can also be authoritatively certified, the mobile entity can trust other entities which present the certi- fied evaluation results, even a previously unseen mo￾bile entity, based on the particular required characteristics of the entity that have been certified. For example, by employing the standard for describing a furniture shop, when the mobile entity receives the message formatted in accordance with a MobiPolicy for a shop-finder service, it can easily have a quickly attained and trusted idea of the seller and its business. Due to the pre-defined standard that a MobiPolicy represents, requestees will be able to design custom￾ized rules in advance through their knowledge of the criteria provided by a MobiPolicy. 2.2.3 Extended certificate authority As the name suggests, the ECA is a functionally ex￾tended CA. Beyond issuing the digital certificate, it can also evaluate the mobile entities according to the Mo￾biPolicy, and digitally sign the results of the evaluation. In our architecture, the ECA is a trusted third party. Trust is (partially) delegated to the ECA, and the output produced by the ECA is the MobiPass. The ECA is the connector which links the potentially communicating but untrusted entities into a scalable and safe network. The ECA can be the MobiPolicy publisher or the third party who is asked to certify the related business entities and activities. It can vary according to the de￾gree of trustworthiness needed in the service. Or in some scenarios, the ECA might not have the real authority to evaluate mobile entities and all relevant Policy-ID (32 bit digitals) Reversed Block (issued by CR) [0]…. …. …. …. (31 bits) Self-Using Block [1]…. … …. ….. (31 bits) Fig. 2 Policy ID allocation 160 Pers Ubiquit Comput (2007) 11:157–169 123