Pers Ubiquit Comput(2007)11: 157-169 Fig. 1 The overall MobiPass A ECA Mobile phone . m MobiManager Requestor MobiManager reference for our trusted infrastructure, although it is 2.2.2 MobiPolicy not mandatory in the architecture The Cr has responsibility for several issues MobiPolicy allows a flexible and extensible approach Accrediting of an ECA, assigning the unique Id to to describing the particular service and evaluating an ECA (ECA-ID), and providing the interface to mobile entities based on their backgrounds and other allow a mobile entity to pull the ECAs public key. related information for this particular service. It is a and check the relevant details of an eca service oriented description schema which is used to Allowing organizations to register their MobiPoli- depict how and which mobile entities will interact with cies, assign the unique ID to the MobiPolicy each other for this service. Different services will ha different mobiPolicies and which information the (Policy-ID), and provide the interface to allow a mobile entity to pull the schema( description)of the MobiPolicy needs to describe it is entirely based on the Mobipolicy characteristic of the service An Xml schema is used to describe the detailed The detailed interaction between the CR and mobile data structure of each MobiPolicy, and each Mobi entities will be discussed shortly. We recognize that Policy will have a globally unique ID, a service building a trusted environment in ubiquitous/mobile describing section and the mobile entity (service computing requires more than an enabling technical description) describing section. It can either infrastructure alone. Law, legislation and social norms signed with a globally unique id by the Cr or be self- [17, 15] are also needed to establish a working trustworthy assigned with an ID in a certain range. Due to the system. For example, the operation of the Cr will be complexity of real business services and the differences dministered by a trusted third party, e. g, a government between service providers, XML schema is a good authority. For practical reasons, we choose a geograph- candidate for constraining the data structure ical domain-based architecture to implement this CR The awareness/scope of MobiPolici SCs This means the word central in here is a logical concept, able. This means the policies can be published by, e.g and the physical architecture of the CR is decentralized international standard bodies and recognized globally and self-regulated. It uses a URI to indicate/represent or be published by an individual person and shared trustworthiness. For instance, we can say that the root with friends. The reason to allow flexibility and scala- trusted URI for the Cr is mobipass. org, so all ECAs bility with MobiPolicies is that ubiquitous computing which operate in Paramatta, Australia can, e. g, be listed can be used for multitudinous purposes and indus- at city state country. mobipass org and managed by, e. g, tries--it is almost impossible to finalize with a rigid the"Local City Mobile Service Authority framework how to use all ubiquitous services. Wereference for our trusted infrastructure, although it is not mandatory in the architecture. The CR has responsibility for several issues: • Accrediting of an ECA, assigning the unique ID to an ECA (ECA-ID), and providing the interface to allow a mobile entity to pull the ECA’s public key, and check the relevant details of an ECA. • Allowing organizations to register their MobiPoli￾cies, assign the unique ID to the MobiPolicy (Policy-ID), and provide the interface to allow a mobile entity to pull the schema (description) of the MobiPolicy. The detailed interaction between the CR and mobile entities will be discussed shortly. We recognize that building a trusted environment in ubiquitous/mobile computing requires more than an enabling technical infrastructure alone. Law, legislation and social norms [7, 15] are also needed to establish a working trustworthy system. For example, the operation of the CR will be administered by a trusted third party, e.g., a government authority. For practical reasons, we choose a geograph￾ical domain-based architecture to implement this CR. This means the word central in here is a logical concept, and the physical architecture of the CR is decentralized and self-regulated. It uses a URI to indicate/represent trustworthiness. For instance, we can say that the root trusted URI for the CR is mobipass.org, so all ECAs which operate in Paramatta, Australia can, e.g., be listed at city.state.country.mobipass.org and managed by, e.g., the ‘‘Local City Mobile Service Authority’’. 2.2.2 MobiPolicy MobiPolicy allows a flexible and extensible approach to describing the particular service and evaluating mobile entities based on their backgrounds and other related information for this particular service. It is a service oriented description schema which is used to depict how and which mobile entities will interact with each other for this service. Different services will have different MobiPolicies and which information the MobiPolicy needs to describe it is entirely based on the characteristic of the service. An XML Schema is used to describe the detailed data structure of each MobiPolicy, and each Mobi￾Policy will have a globally unique ID, a service describing section and the mobile entity (service description) describing section. It can either be as￾signed with a globally unique ID by the CR or be self￾assigned with an ID in a certain range. Due to the complexity of real business services and the differences between service providers, XML schema is a good candidate for constraining the data structure. The awareness/scope of MobiPolicies is very scal￾able. This means the policies can be published by, e.g., international standard bodies and recognized globally, or be published by an individual person and shared with friends. The reason to allow flexibility and scala￾bility with MobiPolicies is that ubiquitous computing can be used for multitudinous purposes and indus￾tries—it is almost impossible to finalize with a rigid framework how to use all ubiquitous services. We Fig. 1 The overall MobiPass architecture Pers Ubiquit Comput (2007) 11:157–169 159 123