Pers Ubiquit Comput(2007)11: 157-169 DOI10.1007/s007790060100-9 ORIGINAL ARTICLE MobiPass: a passport for mobile business Robert steele· Will ao eceived: 28 May 2006/ Accepted: 1 August 2006/Published online: 3 November 2006 c Springer-Verlag London Limited 2006 themselves inte potentially vast business opportunity for many industry the fabric of everyday life until they are indistin participants, it also carries challenges along with it. In guishable from it"[1] this paper, a passport-based architecture has been Ubiquitous computing envisions a world embedded proposed to convert this unpredictable, highly dynamic with a vast number of visible or invisible computing pervasive environment into a trusted business plat- artifacts. Ubiquitous computing is producing a pro- form. It utilizes the widely accepted passport concept found effect on the way people use services and here named MobiPass to evaluate and classify the po- information, enabling new types of context aware ser tential mobile entities into a trustworthy form. It allows vices. Ultimately, these technologies will support a fine-grained access control without necessarily having world of ubiquitous commerce [2] had prior interaction with or knowledge of other par- Enormous business opportunities from ubiquitous ties and environments by setting customized rules computing are emerging, from adopted services such as against a MobiPolicy. a detailed case study has been mobile banking to emerging services such as location introduced to demonstrate how the MobiPass archi- based services and remote monitoring services. Ubiq tecture can help customers and retailers to build a uitous computing provides a huge platform to allow trong trusted connection and how the shopping industry participants to catch this"wave experience can be enriched and efficiency improved However, for ubiquitous computing to gain wide- pread adoption and success, certain requirements must be satisfied. One of the major concerns to deter ubiquitous commerce is that currently there is no effective approach to building a trusted environment in 1 Introduct such a highly dy predictable other words there must exist a feasible mechanism to Being regarded as the third wave of the computing protect sensitive information when mobile entities revolution, ubiquitous computing is on the horizon to interact with each other while still allowing the nec permeate modern business and community activities. essary information to be exchanged for useful mobile As it has been stated, the most profound technologies interaction, so as to allow the success of ubiquitous business 3, 4 As ubiquitous computing is based on a massive R. Steele(). W. Tao networked environment with a large population of di Faculty of Information Te University of Technology, verse smart mobile entities, it poses a new challenge P O. Box 123, Broadway, NSw, Australia 2007 from traditional computing. It is hard to know in ad e-mail: steele @it. uts. edu.au vance which entities will be interacted with and a re- quest can come from unknown environments or e-mail: wtao@@it.uts. edu.au entities where holistic information is not available [5
ORIGINAL ARTICLE MobiPass: a passport for mobile business Robert Steele Æ Will Tao Received: 28 May 2006 / Accepted: 1 August 2006 / Published online: 3 November 2006 Springer-Verlag London Limited 2006 Abstract While pervasive computing provides a potentially vast business opportunity for many industry participants, it also carries challenges along with it. In this paper, a passport-based architecture has been proposed to convert this unpredictable, highly dynamic pervasive environment into a trusted business platform. It utilizes the widely accepted passport concept here named MobiPass to evaluate and classify the potential mobile entities into a trustworthy form. It allows fine-grained access control without necessarily having had prior interaction with or knowledge of other parties and environments by setting customized rules against a MobiPolicy. A detailed case study has been introduced to demonstrate how the MobiPass architecture can help customers and retailers to build a strong trusted connection and how the shopping experience can be enriched and efficiency improved. 1 Introduction Being regarded as the third wave of the computing revolution, ubiquitous computing is on the horizon to permeate modern business and community activities. As it has been stated, ‘‘the most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it’’ [1]. Ubiquitous computing envisions a world embedded with a vast number of visible or invisible computing artifacts. Ubiquitous computing is producing a profound effect on the way people use services and information, enabling new types of context aware services. Ultimately, these technologies will support a world of ubiquitous commerce [2]. Enormous business opportunities from ubiquitous computing are emerging, from adopted services such as mobile banking to emerging services such as locationbased services and remote monitoring services. Ubiquitous computing provides a huge platform to allow industry participants to catch this ‘‘wave’’. However, for ubiquitous computing to gain widespread adoption and success, certain requirements must be satisfied. One of the major concerns to deter ubiquitous commerce is that currently there is no effective approach to building a trusted environment in such a highly dynamic, unpredictable environment; in other words, there must exist a feasible mechanism to protect sensitive information when mobile entities interact with each other while still allowing the necessary information to be exchanged for useful mobile interaction, so as to allow the success of ubiquitous business [3, 4]. As ubiquitous computing is based on a massive networked environment with a large population of diverse smart mobile entities, it poses a new challenge from traditional computing. It is hard to know in advance which entities will be interacted with and a request can come from unknown environments or entities where holistic information is not available [5, R. Steele (&) W. Tao Faculty of Information Technology, University of Technology, Sydney, P.O. Box 123, Broadway, NSW, Australia 2007 e-mail: rsteele@it.uts.edu.au W. Tao e-mail: wtao@it.uts.edu.au 123 Pers Ubiquit Comput (2007) 11:157–169 DOI 10.1007/s00779-006-0100-9
Pers Ubiquit Comput(2007)11: 157-169 6]. In this decentralized infrastructure, the mobile en- The most significant difference in ubiquitous com tity might have to make autonomous decisions with puting from traditional mainframe and personal com ly limited information available. All these aspects puting is that the environment and network is introduce the new issue which is trustworthiness in unpredictable and keeps changing. The biggest chal ubiquitous business computing. This issue is regarded lenge is that the mobile entity does not know which as the greatest barrier which may stop ubiquitous entity is trustworthy, including previously un-encoun computing success in the longer-term [7-9. Previous tered entities. However, here, we claim that the mobile studies show that trust plays a critical role in customer user usually will have a rough idea about which ser elations [10 and the importance of trust has also been vices they want to use and which group of entities they examined for e Commerce [11, 12] and mCommerce would like to interact with. So here we use the well known and proven passport concept, here migrated to In this paper, we propose an architecture named a mechanism to allow dynamic authentication and bipAss to build a trusted and flexible environment authorization, to convert this unpredictability into a for ubiquitous business computing. Our architecture predictable, trusted form aims to allow transaction entities to create trusted The new architecture is based on extending digital interaction without necessarily having prior knowledge certificate technologies of each other. By employing our architecture, mobile entities can interact safely with each other by enabling 2.2 Overview of the mobiPass architecture pre-set customized preferences. Our architecture adopts a user centric philosophy that delegates the final The infrastructure of the architecture utilizes a number decision to the user, still with reasonable flexibility and of existing technologies such as digital certificates, extensibility In our architecture, the mobile entity only certificate authorities (CAs)and asymmetric key talks with another trusted entity/environment which satisfies this customized access control rules encryption. There is some virtue in reusing existing This paper is structured as follows. Section 2 de- technology building blocks in the infrastructure of scribes the overall architecture of mobipass and mobile computing, as a large number of devices are interactions between different elements for establish already in the field. If the architecture is to build on top ing the trusted environment in mobile business com of existing and well-proven technologies, it can be puting. In Sect. 3, a representative case study is used to easily adopted and implemented The new elements introduced in this architecture to demonstrate our architecture. Section 4 discusses re- enable the specific MobiPass functionality are as fol lated work and Sect. 5 concludes the pape lows. Central Registry (not mandatory) 2 MobiPass architecture MobiPolicy Extended Certificate Authority(ECA) 2.1 Motivation Mobipass · Mobimanager As we have emphasized, to pursue success in ubiqui tous/mobile business a trusted environment must be All the new elements are shown in Fig. 1, and the established via a practical approach. As mobile com- following sections discuss how these elements inter puting is a user-centric business model. the approach operate to create a flexible and trusted mobile business for creating a trusted network must be straightforward platform. The architecture will be addressed as follows. Firstly, generally describe the elements in the and easily adoptable by end users and it must provide architecture respectively, and then we explain how fine-grained access control with an easily operable user these elements can establish the trusted mobile should not be exposed directly to the end user. In our other ht, i.e., how these elements interact with architecture, we have considered both technical factors and human factors and utilized the well-known pass- port concept combined with a preference wizard to 2.2. 1 Central registry allow users to easily set their customized rules to de cide which service they want to use and which trans- The central registry( CR) is a global, trusted service action entities they want to interact with in a flexible registry in our architecture. The purpose of introducing and understandable way the Cr into our architecture is to provide a solid base Spr
6]. In this decentralized infrastructure, the mobile entity might have to make autonomous decisions with only limited information available. All these aspects introduce the new issue which is trustworthiness in ubiquitous business computing. This issue is regarded as the greatest barrier which may stop ubiquitous computing success in the longer-term [7–9]. Previous studies show that trust plays a critical role in customer relations [10] and the importance of trust has also been examined for eCommerce [11, 12] and mCommerce [13, 14]. In this paper, we propose an architecture named MobiPass to build a trusted and flexible environment for ubiquitous business computing. Our architecture aims to allow transaction entities to create trusted interaction without necessarily having prior knowledge of each other. By employing our architecture, mobile entities can interact safely with each other by enabling pre-set customized preferences. Our architecture adopts a user centric philosophy that delegates the final decision to the user, still with reasonable flexibility and extensibility. In our architecture, the mobile entity only talks with another trusted entity/environment which satisfies this customized access control rules. This paper is structured as follows. Section 2 describes the overall architecture of MobiPass and interactions between different elements for establishing the trusted environment in mobile business computing. In Sect. 3, a representative case study is used to demonstrate our architecture. Section 4 discusses related work and Sect. 5 concludes the paper. 2 MobiPass architecture 2.1 Motivation As we have emphasized, to pursue success in ubiquitous/mobile business, a trusted environment must be established via a practical approach. As mobile computing is a user-centric business model, the approach for creating a trusted network must be straightforward and easily adoptable by end users and it must provide fine-grained access control with an easily operable user interface. For example, complex security protocols should not be exposed directly to the end user. In our architecture, we have considered both technical factors and human factors and utilized the well-known passport concept combined with a preference wizard to allow users to easily set their customized rules to decide which service they want to use and which transaction entities they want to interact with in a flexible and understandable way. The most significant difference in ubiquitous computing from traditional mainframe and personal computing is that the environment and network is unpredictable and keeps changing. The biggest challenge is that the mobile entity does not know which entity is trustworthy, including previously un-encountered entities. However, here, we claim that the mobile user usually will have a rough idea about which services they want to use and which group of entities they would like to interact with. So here we use the well known and proven passport concept, here migrated to a mechanism to allow dynamic authentication and authorization, to convert this unpredictability into a predictable, trusted form. The new architecture is based on extending digital certificate technologies. 2.2 Overview of the MobiPass architecture The infrastructure of the architecture utilizes a number of existing technologies such as digital certificates, certificate authorities (CAs) and asymmetric key encryption. There is some virtue in reusing existing technology building blocks in the infrastructure of mobile computing, as a large number of devices are already in the field. If the architecture is to build on top of existing and well-proven technologies, it can be easily adopted and implemented. The new elements introduced in this architecture to enable the specific MobiPass functionality are as follows: • Central Registry (not mandatory) • MobiPolicy • Extended Certificate Authority (ECA) • MobiPass • MobiManager All the new elements are shown in Fig. 1, and the following sections discuss how these elements interoperate to create a flexible and trusted mobile business platform. The architecture will be addressed as follows. Firstly, we generally describe the elements in the architecture respectively, and then we explain how these elements can establish the trusted mobile environment, i.e., how these elements interact with each other. 2.2.1 Central registry The central registry (CR) is a global, trusted service registry in our architecture. The purpose of introducing the CR into our architecture is to provide a solid base 158 Pers Ubiquit Comput (2007) 11:157–169 123
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. We
reference 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 MobiPolicies, 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 geographical 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 MobiPolicy will have a globally unique ID, a service describing section and the mobile entity (service description) describing section. It can either be assigned with a globally unique ID by the CR or be selfassigned 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 scalable. 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 scalability with MobiPolicies is that ubiquitous computing can be used for multitudinous purposes and industries—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
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 Spr
recognize this diversity and try to make our architecture open and extensible enough. A MobiPolicy uses customized criteria to enable it to produce a fine-grained evaluation result. For instance, 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 related attributes could be described in the Friend-Finder 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 maintaining mobile interactions. In theory, any organization (person) can publish their MobiPolicies, there is no technical barrier to deter the organization (person) to publish their own MobiPolicy. For instance, either the Australian Taxation 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 feasible 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 managing 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 Policy-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 checking 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 information to a mobile user, describing the unpredicted environment and surrounding entities, if this information can also be authoritatively certified, the mobile entity can trust other entities which present the certi- fied evaluation results, even a previously unseen mobile 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 customized 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 extended CA. Beyond issuing the digital certificate, it can also evaluate the mobile entities according to the MobiPolicy, 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 degree 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
Pers Ubiquit Comput(2007)11: 157-169 documents for evaluating may still go through the MobiPolicy. It contains the real data describing a government authority/ agency to be certified/ evalu- particular mobile entity in relation to a certain service ated, then mobile entities would bring these hard For instance, if the MobiPolicy is used to describe copies to the ECA. After checking these"stamped" which business entities will use a location-based service documents, the ECA represents the evaluation results to promote their products, the data in the mobiPass in signed electronic form according to the MobiPolicy. can provide a signed description of a particular busi The digitally signed output using the ECA's private ness entity such as the registration time of the business key is the mobiPass entity and the self-description of the business entity As we discussed, it is hard to build a trusted envi- Here is the general structure of the MobiPass, all ronment based only on technological features. For contents in the certified elements need to be certified practical concerns, in here, we assume ECAs can be by the ECA such as the business profile and the maybe there is also the potential for a different ap- certifier tit categorized into three main types: (in the real case, mobile entity(service provider ),'s public key, and non content can be put into the non-Certified proach to arranging ECA elements as extra description such as the price they credited ECA sell the particular model of sofa at, at that particular time Registered ECA · UnRegistered ECA There are five dedicated elements in the mobipass to ensure trustworthiness The structure is shown in the All ECAs are supposed to have a unique ECA-ID. Fig 3 An ECA-ID has a similar structure with the Policy-ID 32 bits long with reserved and self-using blocks. The the eca element has two sub elements which are eca and ecalocation which contains the accredited ECA usually are highly trusted third parties, such as the Justice Department and the Fair Trading ID of the ECA(ECA-ID)and the URI from which Association, and are registered with the Cr. Accred you can obtain the ECA's public key. The protocol ited ECAs perform the similar duty as they do for to retrieve the public key of the eCa is included as current real businesses, such as issuing the permission well. In here, cr:// means the public key resides or to trade suspending a license if a rule is breached etc the Cr. also, for a non-registered ECA, it is In our architecture, the MobiPass issued by an possible to get the public key by short-range Accredited ECA should be fully trusted. Following the wireless, such as bt: // Bluetooth. The protocol for structure of the cr. the accredited eca is structured retrieving should be very flexible and the no- according to a geographical domain-based architec Internet access situation is fully supported. ture, and the number of accredited ECAs is strictly the MobiPolicy has a similar struc- limited/co-coordinated (this helps to enforce non ture with the element. with Id and the competing/non-overlapping MobiPolicies for given location to retrieve the schema. Also, the protocol domains in given geographical areas) to retrieve the schema is fexible The Registered ECA means the eCA itself has been this element is used to store the xamined by the Cr, and certain business information digitally signed digest value by the ECA. It is used has been verified, such as business name business for checking the integrity/ non-corruption of the registration date and business description. Both content in the certified obiPass element. such as the public key of the service provider. accredited and registered ECAs will be assigned a. kmobiPass Digest/> to ensure the authentication, a unique number from the reserved block, and the public key of the accredited and registered ECA can be re- : this element is used for storing trieved from the CR by specifying the ECA ID. The the whole mobiPass digest value. And it is digitally ECAs business details can also be queried by provid signed by the service provider itself. This means ing the ECA-ID to the Cr. A non-registered ECA can element is used for ensuring the only pick a number from the self-using block, and the public key of the service provider is true, and the public key cannot be stored in the Cr element is used for ensuring the MobiPass is sent by this particular service provider. the timestamp element is used to 2. 2. 4 MobiPass indicate the time frame the mobiPass lives and the value of and will be A MobiPass is described by XML which complies signed by the sender's public key. This is used to with the corresponding XML schema represented prevent man-in-middle attack. The difference value
documents for evaluating may still go through the government authority/ agency to be certified/ evaluated, then mobile entities would bring these hard copies to the ECA. After checking these ‘‘stamped’’ documents, the ECA represents the evaluation results in signed electronic form according to the MobiPolicy. The digitally signed output using the ECA’s private key is the MobiPass. As we discussed, it is hard to build a trusted environment based only on technological features. For practical concerns, in here, we assume ECAs can be categorized into three main types: (in the real case, maybe there is also the potential for a different approach to arranging ECAs) • Accredited ECA • Registered ECA • UnRegistered ECA All ECAs are supposed to have a unique ECA-ID. An ECA-ID has a similar structure with the Policy-ID; 32 bits long with reserved and self-using blocks. The accredited ECA usually are highly trusted third parties, such as the Justice Department and the Fair Trading Association, and are registered with the CR. Accredited ECAs perform the similar duty as they do for current real businesses, such as issuing the permission to trade, suspending a license if a rule is breached etc. In our architecture, the MobiPass issued by an Accredited ECA should be fully trusted. Following the structure of the CR, the accredited ECA is structured according to a geographical domain-based architecture, and the number of accredited ECAs is strictly limited/co-coordinated (this helps to enforce noncompeting/non-overlapping MobiPolicies for given domains in given geographical areas). The Registered ECA means the ECA itself has been examined by the CR, and certain business information has been verified, such as business name, business registration date and business description. Both accredited and registered ECAs will be assigned a unique number from the reserved block, and the public key of the accredited and registered ECA can be retrieved from the CR by specifying the ECA ID. The ECA’s business details can also be queried by providing the ECA-ID to the CR. A non-registered ECA can only pick a number from the self-using block, and the public key cannot be stored in the CR. 2.2.4 MobiPass A MobiPass is described by XML which complies with the corresponding XML schema represented MobiPolicy. It contains the real data describing a particular mobile entity in relation to a certain service. For instance, if the MobiPolicy is used to describe which business entities will use a location-based service to promote their products, the data in the MobiPass can provide a signed description of a particular business entity such as the registration time of the business entity and the self-description of the business entity Here is the general structure of the MobiPass, all contents in the certified elements need to be certified by the ECA such as the business profile and the mobile entity (service provider)’s public key, and noncertified content can be put into the non-Certified elements as extra description such as the price they sell the particular model of sofa at, at that particular time. There are five dedicated elements in the MobiPass to ensure trustworthiness. The structure is shown in the Fig. 3. • the ECA element has two sub elements, which are eca and ecaLocation, which contains the ID of the ECA(ECA-ID) and the URI from which you can obtain the ECA’s public key. The protocol to retrieve the public key of the ECA is included as well. In here, cr:// means the public key resides on the CR. Also, for a non-registered ECA, it is possible to get the public key by short-range wireless, such as bt://, Bluetooth. The protocol for retrieving should be very flexible and the noInternet access situation is fully supported. • the MobiPolicy has a similar structure with the element, with ID and the location to retrieve the schema. Also, the protocol to retrieve the schema is flexible. • this element is used to store the digitally signed digest value by the ECA. It is used for checking the integrity/ non-corruption of the content in the certified MobiPass element, such as the public key of the service provider. • to ensure the authentication, a : this element is used for storing the whole mobiPass digest value. And it is digitally signed by the service provider itself. This means element is used for ensuring the public key of the service provider is true, and the element is used for ensuring the MobiPass is sent by this particular service provider. • the timestamp element is used to indicate the time frame the MobiPass lives. And the value of and will be signed by the sender’s public key. This is used to prevent man-in-middle attack. The difference value Pers Ubiquit Comput (2007) 11:157–169 161 123
Pers Ubiquit Comput(2007)11: 157-169 Fig. 3 MobiPass format SYDAU102. 23474 cr: //paramatta. nsw. au. mobipass com 1223-3328-.24 paramatta.nsw.au.mobipass.com mobiPolicy> UTD Furniture Sydney K .. 6fh7fl. da84 1132622517640 l 132622519640 of not After and not Before will be fairly small to get requirements, and how sensitive the data is inside the maximum security. MobiPass. and it is also renewable Mobile entities can Here it must be noticed that if the first digit of the renew their MobiPass at any time to prevent the ECA-ID is 0, then the location(URI) of the ECA must expiration and increase their degree of trustworthiness be in the sub-domain of the Cr(mobipass org in our case), and the same for the MobiPolicy. Furthermore, 2.2.5 MobiManager if the Policy-ID is registered (0 for the first digit), then MobiManager is a software package which has all the it can only be verified by the accredited ECA necessary functionalities to manage and process Mo- MobiPass can be regarded as a special form of dig- biPasses in our architecture For instance, the Mobi- ital certificate which carries necessary and context aware information for mobile entities. As such it does anager will parse the MobiPass, can contact the CR not just provide authentication as a normal certificate and automatically generate the preference selection does but also contains information to drive authoriza- interface for a MobiPass by referring to the schema in tion decisions the mobipolicy and so on. From Fig. 1, we can see that all mobile entities are virtually connected through the eCa by referring to 2.3 A trusted interaction using MobiPass the MobiPolicy in the ubiquitous computing environ ment. The MobiPass expires after a certain time In a highly dynamic and unpredictable ubiquitous depending on the functional and nonfunctional computing environment, it is neither efficient nor fea Spr
of notAfter and notBefore will be fairly small to get maximum security. Here it must be noticed that if the first digit of the ECA-ID is 0, then the location (URI) of the ECA must be in the sub-domain of the CR (mobipass.org in our case), and the same for the MobiPolicy. Furthermore, if the Policy-ID is registered (0 for the first digit), then it can only be verified by the accredited ECA. MobiPass can be regarded as a special form of digital certificate which carries necessary and context aware information for mobile entities. As such it does not just provide authentication as a normal certificate does but also contains information to drive authorization decisions. From Fig. 1, we can see that all mobile entities are virtually connected through the ECA by referring to the MobiPolicy in the ubiquitous computing environment. The MobiPass expires after a certain time depending on the functional and nonfunctional requirements, and how sensitive the data is inside the MobiPass, and it is also renewable. Mobile entities can renew their MobiPass at any time to prevent their expiration and increase their degree of trustworthiness. 2.2.5 MobiManager MobiManager is a software package which has all the necessary functionalities to manage and process MobiPasses in our architecture. For instance, the MobiManager will parse the MobiPass, can contact the CR and automatically generate the preference selection interface for a MobiPass by referring to the schema in the MobiPolicy and so on. 2.3 A trusted interaction using MobiPass In a highly dynamic and unpredictable ubiquitous computing environment, it is neither efficient nor fea- SYDAU102...23474 cr://paramatta.nsw.au.mobipass.com 1223-3328-...24 paramatta.nsw.au.mobipass.com 1124030906734 ... UTD Furniture Sydney ...... ...... mQENBEJvo.... ...... f5f7f7...8a53 6fh7f1...cda84 1132622517640 1132622519640 skz...==z Fig. 3 MobiPass format 162 Pers Ubiquit Comput (2007) 11:157–169 123
Pers Ubiquit Comput(2007)11: 157-169 sible to use username and password combinations as an information the device owner wants to share. This approach to build a trusted and stable mobile business usually can improve the quality of the service environment, due to the vast number of interactions The full interaction of a mobile device upon possible and the frequent encountering of previously receiving a MobiPass can be described as five main unseen entities. Also, from the usability perspective, if steps, which are the mobile entity is a mobile phone, it is difficult to require of the user to type in username and password Validity checking and retrieving the public key of combinations in such small devices [16. In our ap the eca proach, the simple preference setup is sufficient for Verifying the mobiPass mobile entities to protect and prove themselves. Mo Enabling the MobiPolicy bile entities only need to pre-define the customized Setting the rules rules(via preference) by referring to the MobiPolicy pplying the rules and using these rules they can manage and build the If the mobile service requestor decides to interact trusted relationship with potentially a large set of with a particular requestee, the service requestor will previously unknown mobile entities automatically send its MobiPass to the requestee as Fig. l indicates. In this section, we will provide depth expla- If the MobiPass is not ignored by the requstee, then the nation of the work processes in the MobiPass archi- first step(verify the ECA)will be activated tecture, and in the case study in the following section more concretely grounded examples will be discussed. 2.3.1 Validity checking and retrieve the public key Before interaction with the mobiPass. the user of the eCA (device owner) can set a primer mode as to how to deal with MobiPasses/ECAS. For example, in the optimistic If the requestee receives the MobiPass, it will retrieve ode, any ECA will be trusted automatically without the public key of the eCA. Firstly, after getting the prompt. And in the pessimistic mode, if the ECA-ID/ ECA-ID with the location of its public key, and Policy public key is not found already loaded in the Mobi- ID with the policy location, the MobiManager will Manager, a prompt dialogue will be used to ask the apply the general checks at first. That is, whether the user to make a decision, even if the ECA is an ECA-ID is in the reserved block(assigned by the Cr) accredited ECA. The default mode is that all MobiPass or whether it is in the self-using block. If it is in the issued by an accredited ECA can be trusted automat- reserved block then the location(URi) must be a sub ically,andthedialoguewillonlyappeariftheEca-Iddomainofmobipass.com.AndifthePolicy-idisinthe is not found and the eca is not an accredited ECA. reserved block the schema has to be in the trusted uRI also. For non-registered ECA, a"highly dangerous" as well. If the MobiPass breaches the general rules it is alert will be presented considered not valid and it will be rejected immedi MobiPass is the key enabler to apply these rules as it ately arries within it certified data which is highly related After passing the general rules check, the Mobi- with the service and the requestor. The key point here Manager examines whether this ECA-ID has already is that once the device has set customized rules via been stored in the device. if the eca-id is found in preferences, it can"smartly"decide using trusted the MobiManager, it means the ECa's public key ca information which interaction should be allowed by be used directly. Otherwise the key has to be retrieved examining the MobiPass. In our architecture, we call remotely this push mode, because the requestor pushes the If the public key is not on the trusted URI(belon Mobipasstotherequesteetohaveaccess.Thetothemobipass.cominthiscase)ortheEca-Idis requestor can also use the pull mode to ask for a re- from an unknown party, MobiManager will suspend questee's MobiPass. This means that not only can the the processing and prompt the user that this is the first requestee check the requestor's MobiPass to decide time to communicate with this ECa and whether to whether or not to conduct an interaction with reques- proceed or not. In addition it will indicate whether this tor or not, but also the requestor can choose who it ECA is accredited or not, with business name and wishes to communicate with by checking the reque- description. If the ECA is not accredited, a high-risk stee's MobiPass. This model has several advantages. symbol should be displayed. After a short period of Firstly, it can decrease the risk on the requestor's side. use, the MobiManager should have stored the public Secondly, by employing and pre-checking the Mobi- keys of the common ECAs in operation in the area Pass, it provides the chance to provide smarter context Whether this ECA is trusted or not depends on how aware services because it might contain more detailed the user decides upon it. As an accredited ECA must
sible to use username and password combinations as an approach to build a trusted and stable mobile business environment, due to the vast number of interactions possible and the frequent encountering of previously unseen entities. Also, from the usability perspective, if the mobile entity is a mobile phone, it is difficult to require of the user to type in username and password combinations in such small devices [16]. In our approach, the simple preference setup is sufficient for mobile entities to protect and prove themselves. Mobile entities only need to pre-define the customized rules (via preference) by referring to the MobiPolicy and using these rules they can manage and build the trusted relationship with potentially a large set of previously unknown mobile entities automatically. In this section, we will provide an in-depth explanation of the work processes in the MobiPass architecture, and in the case study in the following section, more concretely grounded examples will be discussed. Before interaction with the MobiPass, the user (device owner) can set a primer mode as to how to deal with MobiPasses/ECAs. For example, in the optimistic mode, any ECA will be trusted automatically without prompt. And in the pessimistic mode, if the ECA-ID/ public key is not found already loaded in the MobiManager, a prompt dialogue will be used to ask the user to make a decision, even if the ECA is an accredited ECA. The default mode is that all MobiPass issued by an accredited ECA can be trusted automatically, and the dialogue will only appear if the ECA-ID is not found and the ECA is not an accredited ECA, also. For non-registered ECA, a ‘‘highly dangerous’’ alert will be presented. MobiPass is the key enabler to apply these rules as it carries within it certified data which is highly related with the service and the requestor. The key point here is that once the device has set customized rules via preferences, it can ‘‘smartly’’ decide using trusted information which interaction should be allowed by examining the MobiPass. In our architecture, we call this push mode, because the requestor pushes the MobiPass to the requestee to have access. The requestor can also use the pull mode to ask for a requestee’s MobiPass. This means that not only can the requestee check the requestor’s MobiPass to decide whether or not to conduct an interaction with requestor or not, but also the requestor can choose who it wishes to communicate with by checking the requestee’s MobiPass. This model has several advantages. Firstly, it can decrease the risk on the requestor’s side. Secondly, by employing and pre-checking the MobiPass, it provides the chance to provide smarter context aware services because it might contain more detailed information the device owner wants to share. This usually can improve the quality of the service. The full interaction of a mobile device upon receiving a MobiPass can be described as five main steps, which are: • Validity checking and retrieving the public key of the ECA • Verifying the MobiPass • Enabling the MobiPolicy • Setting the rules • Applying the rules If the mobile service requestor decides to interact with a particular requestee, the service requestor will send its MobiPass to the requestee as Fig. 1 indicates. If the MobiPass is not ignored by the requstee, then the first step (verify the ECA) will be activated. 2.3.1 Validity checking and retrieve the public key of the ECA If the requestee receives the MobiPass, it will retrieve the public key of the ECA. Firstly, after getting the ECA-ID with the location of its public key, and PolicyID with the policy location, the MobiManager will apply the general checks at first. That is, whether the ECA-ID is in the reserved block (assigned by the CR) or whether it is in the self-using block. If it is in the reserved block then the location (URI) must be a subdomain of mobipass.com. And if the Policy-ID is in the reserved block the schema has to be in the trusted URI as well. If the MobiPass breaches the general rules it is considered not valid and it will be rejected immediately. After passing the general rules check, the MobiManager examines whether this ECA-ID has already been stored in the device. If the ECA-ID is found in the MobiManager, it means the ECA’s public key can be used directly. Otherwise the key has to be retrieved remotely. If the public key is not on the trusted URI (belongs to the mobipass.com in this case) or the ECA-ID is from an unknown party, MobiManager will suspend the processing and prompt the user that this is the first time to communicate with this ECA and whether to proceed or not. In addition it will indicate whether this ECA is accredited or not, with business name and description. If the ECA is not accredited, a high-risk symbol should be displayed. After a short period of use, the MobiManager should have stored the public keys of the common ECAs in operation in the area. Whether this ECA is trusted or not depends on how the user decides upon it. As an accredited ECA must Pers Ubiquit Comput (2007) 11:157–169 163 123
Pers Ubiquit Comput(2007)11: 157-169 be verified by the Cr, the business name of the get access or not. This will be done without needing to accredited ECA cannot be forged. If the business name interact with the mobile device user of the ECa is the Fair Trading Association in Aus- If the Policy-ID is not found in the Policy Manager, tralia, which belongs to a government department, it then this is a previously unseen service. After would be readily trusted by users. If the accredited retrieving the mobiPolicy schema, the interactive ECA is a small, faceless company, although it has been interface will be displayed to ask the user certified by the Cr with its business name, it may still their preferences. As XML schema is used to be suspected by the users. If this user does not trust this the specific service, our previous research ECA, the MobiManager can also help the user to block Xplorer can automatically generate the service spe- this eCa this once, at certain times or always cific interface by analyzing the MobiPolicy schema, If the user chooses to proceed and trust the ECA, and the preference interface is also relatively easy to MobiManager will retrieve the public key associated be understood by the user [17. After setting up the with the ECA-ID, stored in the MobiManager. preference, it means the rules have been already Otherwise. the mobiPass will be discarded and this created in this understandable and user-friendly ECA might be banned for some period. This depends interactive way and the Policy ID will be stored in the on how the user has set the primer preferences MobiManager. Alternatively, the user can drop the MobiPass into the folder in the mobiman 2.3.2 Verifying the MobiPass ager, and set the preferences later or from another device, such as a desktop computer After getting the public key of a trusted ECA, the next step is to verify the MobiPass In this paper, we assume 2.3.4 Applying the rules that MD5 is used for generating the digest. The Mo- biManager will firstly check whether the MobiPass is If rules have been created for this particular Mobi expired or not by examining the element, Policy, this means the MobiPass which is associated if the MobiPass is expired, it will be discarded imme- with the same Policy ID will be processed directly. The diately. If the MobiPass is not expired, the Mobi- typical access control will be or 'no,, but in the Manager will use the ECA's public key to decrypt the complex case, Role-Based Access Control(RBAC) certifiedDigest element, get the original digest value, can be employed to decrease the complexity of the rehashing the certified element again to compare authorization issues whether the MobiPass is tampered with or not. If the To build a trusted environment in ubiquitous com fingerprint is not a match, the MobiManager will ig- puting, mobile requestors are supposed to be recog- nore and discard this MobiPass immediately, other- nized by just presenting their MobiPass. In our wise, the public key of the requestor will be extracted architecture, we do not encourage users to hide or from the certified element, and used to compare the simply turn off some functionalities due to worry about digest value of the whole MobiPass, if the digest value privacy or security concerns. Our architecture provides is matched, it means that the MobiPass is originally a considered balance with trusted interaction and ri sent by the requestor, and sent in the reasonably cher services immediate past. At this point the rules corresponding to this particular MobiPolicy/ service will determine what happens next. 3 Case study 2.3.3 Enabling the Mobi Policy and setting the rules In this section, we use a representative and complex case study to demonstrate how to use the mobiPass If the digest value is accepted, now the MobiManager architecture to enhance the retailing industry, so as to will pull the schema and generate the preference enrich the shopping experience and provide nev automatically capabilities in all stages of the retailing process, i.e When the ECA is trusted, the MobiPass will look up how to use the MobiPass architecture to achiev the Policy-ID in the MobiPass. If the Policy-ID has ubiquitous retailing. By employing the MobiPass been found already in the MobiManager, it means that architecture in the retailing industry, retailers the preference for this particular MobiPolicy has been shoppers, can establish a trustworthy connection for already set, so the MobiManager will process the purchasing and information gathering, regardless of MobiPass directly to see whether the requestee should whether they have prior knowledge of each other or Spr
be verified by the CR, the business name of the accredited ECA cannot be forged. If the business name of the ECA is the Fair Trading Association in Australia, which belongs to a government department, it would be readily trusted by users. If the accredited ECA is a small, faceless company, although it has been certified by the CR with its business name, it may still be suspected by the users. If this user does not trust this ECA, the MobiManager can also help the user to block this ECA this once, at certain times or always. If the user chooses to proceed and trust the ECA, MobiManager will retrieve the public key associated with the ECA-ID, stored in the MobiManager. Otherwise, the MobiPass will be discarded and this ECA might be banned for some period. This depends on how the user has set the primer preferences. 2.3.2 Verifying the MobiPass After getting the public key of a trusted ECA, the next step is to verify the MobiPass. In this paper, we assume that MD5 is used for generating the digest. The MobiManager will firstly check whether the MobiPass is expired or not by examining the element, if the MobiPass is expired, it will be discarded immediately. If the MobiPass is not expired, the MobiManager will use the ECA’s public key to decrypt the certifiedDigest element, get the original digest value, rehashing the certified element again to compare whether the MobiPass is tampered with or not. If the fingerprint is not a match, the MobiManager will ignore and discard this MobiPass immediately, otherwise, the public key of the requestor will be extracted from the certified element, and used to compare the digest value of the whole MobiPass, if the digest value is matched, it means that the MobiPass is originally sent by the requestor, and sent in the reasonably immediate past. At this point the rules corresponding to this particular MobiPolicy/ service will determine what happens next. 2.3.3 Enabling the MobiPolicy and setting the rules If the digest value is accepted, now the MobiManager will pull the schema and generate the preference automatically. When the ECA is trusted, the MobiPass will look up the Policy-ID in the MobiPass. If the Policy-ID has been found already in the MobiManager, it means that the preference for this particular MobiPolicy has been already set, so the MobiManager will process the MobiPass directly to see whether the requestee should get access or not. This will be done without needing to interact with the mobile device user. If the Policy-ID is not found in the PolicyManager, then this is a previously unseen service. After retrieving the MobiPolicy schema, the interactive interface will be displayed to ask the user to enter their preferences. As XML schema is used to describe the specific service, our previous research work Xplorer can automatically generate the service specific interface by analyzing the MobiPolicy schema, and the preference interface is also relatively easy to be understood by the user [17]. After setting up the preference, it means the rules have been already created in this understandable and user-friendly interactive way and the Policy ID will be stored in the MobiManager. Alternatively, the user can drop the MobiPass into the folder in the MobiManager, and set the preferences later or from another device, such as a desktop computer. 2.3.4 Applying the rules If rules have been created for this particular MobiPolicy, this means the MobiPass which is associated with the same Policy ID will be processed directly. The typical access control will be ‘yes’ or ‘no’, but in the complex case, Role-Based Access Control (RBAC) can be employed to decrease the complexity of the authorization issues. To build a trusted environment in ubiquitous computing, mobile requestors are supposed to be recognized by just presenting their MobiPass. In our architecture, we do not encourage users to hide or simply turn off some functionalities due to worry about privacy or security concerns. Our architecture provides a considered balance with trusted interaction and richer services. 3 Case study In this section, we use a representative and complex case study to demonstrate how to use the MobiPass architecture to enhance the retailing industry, so as to enrich the shopping experience and provide new capabilities in all stages of the retailing process, i.e., how to use the MobiPass architecture to achieve ubiquitous retailing. By employing the MobiPass architecture in the retailing industry, retailers and shoppers, can establish a trustworthy connection for purchasing and information gathering, regardless of whether they have prior knowledge of each other or 164 Pers Ubiquit Comput (2007) 11:157–169 123
Pers Ubiquit Comput(2007)11: 157-169 not. Information gathering can be more intelligent and This case study assumes a dedicated mobipolicy for accurate and it enlarges the range of the customer's the retailing industry will be published and both options and helps the retailer to filter to more likely retailers and shoppers will provide relevant informa genuine potential buyers. tion to apply for their MobiPasses from the ECA according to that MobiPolicy. The ECA, e.g., can be a 3.1 Mobile retailing background Fair Trading Department in the local government. The sho pers will have mobile phones with MobiPass sup- Retailing means selling quantities of goods to the port(MobiManager ), and the retailers will also have a goods for personal consumption either from a fixed municate wi. Mopper's MobiManager and penor ?. ultimate customer directly. It consists of the sale of MobiPass enabled device with can be used to co location such as a department store or kiosk, or un- all necessary functions fixed location and the related subordinated services The basic principle to enhance awareness is that by With the rapid development of mobile computing, using the MobiPass architecture it is possible to help hand-held computers like the mobile phone and per- the customer entity to selectively receive incoming sonal digital assistant(PDA)have been getting used guiding information such as an advertisement, and it is for such tasks as voice communication, text messag- also possible for the sender(retailer)to also have the ng,scheduling, calendar management and more option to choose the target buyer precisely and reli complicated shopping aid services. There are some ably. This solves the two main issues in current retail retailers who have already adopted mobile retailing to promotion, which are spam(receivers, mostly shop- improve their business. For example, the Broadway pers, do not have the choice to reject unsolicited and shopping center in Sydney, Australia has employed non-relevant information) and untargeted broadcast short-range communication technology to guide the (seller does not know who should most relevantly get customers who have Bluetooth enabled mobile the information) phones [18. My Grocer is a second generation per The way that MobiPass helps the potential custom- vasive retailing system which provides new solutions ers in the awareness stage of retailing can be consid for home inventory replenishment [19, 20). Easi-Order ered under two main approaches, which are: is a PDA application which is used to create and send a shopping list to the grocery remotely [21]. Kle The push approach verKart [22] is an interesting on-cart device to inform . The pull approach the customer of in-store information such as which The push approach is based on the traditional products are on sale, some detailed information for advertisement principle, i.e., the seller's piece of certain products and so on. While these products/ information is broadcast by the sender to get maximum architectures are mainly focused on how to help cus- effect. There are a number of ubiquitous advertisin tomers purchase goods, in this paper, we demonstrate research projects that have been conducted recently, how the MobiPass architecture can go beyond this to e.g., push-based location-aware mobile advertising help and to develop new retailing capabilities for systems. However, these ubiquitous advertisement potential customers in all the stages of retailing systems do not ensure the sender/source of the infor- including in the stage of forming customer product mation(advertisements) is trustworthy and moreover, and need awareness, product information gathering by they do not provide a practical approach to filter the customers and in comparing alternatives as well as in unwanted information(spam) in current mobile/ubiq uitous advertising. By employing the MobiPass archi- tecture. these issues can be solved in an efficient 3.2 Case study flexible and reliable manner As mentioned previously, we assume both retailers It is very important to associate and acquaint custom- and customers have adopted the mobiPass architec ers with potential products that relate to their needs, as ture and have the enabled equipment ready. For in it is the entry point to trigger the potential customer's stance, a supermarket will have a MobiPass enabled motivation to purchase and the first stage of the device which connects to its intranet, which in this retailing process. In the first stage of retailing, Mobi- more realistic and extended case study might include Pass can be used to achieve an intelligent and trusted an internal database server, sensor network and approach to guide potential customers, find out application server. As the database server has all specific interests, and to help shoppers to recog inventory information such as SKU, number of each their needs in an effective manner item in stock and some ordering information, and it
not. Information gathering can be more intelligent and accurate and it enlarges the range of the customer’s options and helps the retailer to filter to more likely genuine potential buyers. 3.1 Mobile retailing background Retailing means selling quantities of goods to the ultimate customer directly. It consists of the sale of goods for personal consumption either from a fixed location such as a department store or kiosk, or un- fixed location and the related subordinated services. With the rapid development of mobile computing, hand-held computers like the mobile phone and personal digital assistant (PDA) have been getting used for such tasks as voice communication, text messaging, scheduling, calendar management and more complicated shopping aid services. There are some retailers who have already adopted mobile retailing to improve their business. For example, the Broadway shopping center in Sydney, Australia has employed short-range communication technology to guide the customers who have Bluetooth enabled mobile phones [18]. MyGrocer is a second generation pervasive retailing system which provides new solutions for home inventory replenishment [19, 20]. Easi-Order is a PDA application which is used to create and send a shopping list to the grocery remotely [21]. KleverKart [22] is an interesting on-cart device to inform the customer of in-store information such as which products are on sale, some detailed information for certain products and so on. While these products/ architectures are mainly focused on how to help customers purchase goods, in this paper, we demonstrate how the MobiPass architecture can go beyond this to help and to develop new retailing capabilities for potential customers in all the stages of retailing including in the stage of forming customer product and need awareness, product information gathering by customers and in comparing alternatives as well as in purchasing. 3.2 Case study It is very important to associate and acquaint customers with potential products that relate to their needs, as it is the entry point to trigger the potential customer’s motivation to purchase and the first stage of the retailing process. In the first stage of retailing, MobiPass can be used to achieve an intelligent and trusted approach to guide potential customers, find out their specific interests, and to help shoppers to recognize their needs in an effective manner. This case study assumes a dedicated MobiPolicy for the retailing industry will be published and both retailers and shoppers will provide relevant information to apply for their MobiPasses from the ECA according to that MobiPolicy. The ECA, e.g., can be a Fair Trading Department in the local government. The shoppers will have mobile phones with MobiPass support (MobiManager), and the retailers will also have a MobiPass enabled device with can be used to communicate with shopper’s MobiManager and perform all necessary functions. The basic principle to enhance awareness is that by using the MobiPass architecture it is possible to help the customer entity to selectively receive incoming guiding information such as an advertisement, and it is also possible for the sender (retailer) to also have the option to choose the target buyer precisely and reliably. This solves the two main issues in current retail promotion, which are spam (receivers, mostly shoppers, do not have the choice to reject unsolicited and non-relevant information) and untargeted broadcast (seller does not know who should most relevantly get the information). The way that MobiPass helps the potential customers in the awareness stage of retailing can be considered under two main approaches, which are: • The push approach • The pull approach The push approach is based on the traditional advertisement principle, i.e., the seller’s piece of information is broadcast by the sender to get maximum effect. There are a number of ubiquitous advertising research projects that have been conducted recently, e.g., push-based location-aware mobile advertising systems. However, these ubiquitous advertisement systems do not ensure the sender/source of the information (advertisements) is trustworthy and moreover, they do not provide a practical approach to filter the unwanted information (spam) in current mobile/ubiquitous advertising. By employing the MobiPass architecture, these issues can be solved in an efficient, flexible and reliable manner. As mentioned previously, we assume both retailers and customers have adopted the MobiPass architecture and have the enabled equipment ready. For instance, a supermarket will have a MobiPass enabled device which connects to its intranet, which in this more realistic and extended case study might include an internal database server, sensor network and application server. As the database server has all inventory information such as SKU, number of each item in stock and some ordering information, and it Pers Ubiquit Comput (2007) 11:157–169 165 123
Pers Ubiquit Comput(2007)11: 157-169 is updated in real time as transactions at the front Know that the information they received is from counters occur. The supermarket also has a number some real business entities. and the received infor- of sensors to collect data about, e.g., easy-to-expire mation is primarily trustworthy. If the customers products. For instance, the meat sensors will collect find that they received false information in some of data about pork/beef products to see how fresh they the detailed information, they can report to are regularly. If some meat products are expired, it relevant mobiPass issuer will be reported to the application server. The role of Get the basic idea of the sender(retailer)'s back- the application server, and a fundamental contribu- ground. For example, they can know this message is tion to retailing considered in conjunction with the from a well-known retailer or from some retailer MobiPass architecture, is to calculate and communi- they have never heard of. Furthermore, they also cate effectively and provably to customers the most can know some detailed information about this suitable price in real-time based on the inventory retailer-information such as the number of the data from the database server. customer numbers and employees and the registration date etc. product turnover, the data collected by the sensors Be able to create a filter, to-filter unwanted mes- and some additional conditions such as weather and sages. For instance, they might only receive infor- the previous sales record. As now the supermarket is mation about music cds and never receive the able to calculate the"best" price in real time, the information for the retailer whose credit rating is problem is how to attract the potential buyer to buy lower than 6 out of 10 hese"real time special"products. For some service- By using MobiPass, we can see that retailers can based retailers such as a hair salon, it would be much build an effective approach to advertising their prod- better if they are able to inform potential customers ucts that embeds their business information This of real time special prices based on their current busy-ness, i.e., if there are only a few customers in greatly builds the confidence for their potential cus- the shop, the nail beauty shop can decrease the price tomers to make the mobile adverting trend more significantly to reach the maximum profit/ utilization workable and practical. of staff. And the problem the hair salon is facing is On the other side. the mobiPass architecture also nables the pull approach for shopping navigation. The how to inform the customers via an effective ap- principle is based on the bid system as the roaming proach, as usually not every potential customer would like to enter the shop to query whether it has potential customer can set some criteria in their Mo- biManager, e.g., price, and broadcast this information a special price if they do not have some urgent to the retailers he/she passes by, with the MobiPass, actually the retailing industry is a very dynamic and each potential seller can decide whether to sell the industry as the context is continually changing in real product to this buyer based on the received criteria and time and this could heavily affect some important the corresponding MobiPass factors such as price. To get the retailing service For the criteria-based pull approach, it is based on efficiency improved, it is quite useful and important how the potential customer sets the criteria to look up to broadcast certain dynamic information, and the desired products by criteria. The criteria can be information sent should be trusted by the receivi The criteria of the products, such as product name, party(buyers) model, price or even some keywords for this Firstly retailers can check the relevant MobiPolicy product and apply the relevant MobiPass. The MobiPass for the The background of the retailer, who provides the retailers usually contains real information about selling of this product, apparently that the custom- retailers such as business name, registration date and ers are willing to buy the products for a reliable, location, and it also contains rating information which ood reputation retailer is given by some trusted third party. After applying for and receiving their MobiPass the retailers can use For example, if a potential customer wants to buy their Mobi Pass enabled devices to broadcast their digital camera with the lowest price she/he wants to context-based advertising information, as the Mobi- pay, this potential customer can firstly set up the cri- Pass is a trusted source to prove the identify of the teria in his/her MobiManager and the sample data can business with rich information, it provides a secure pproach for which the receiver(customer)can totall Here, we can see that the potential customer has set trust the information they receive. This can ensure that the criteria for the digital camera he/she wants to buy, the customer can and we also can see that this potential customer onl Spr
is updated in real time as transactions at the front counters occur. The supermarket also has a number of sensors to collect data about, e.g., easy-to-expire products. For instance, the meat sensors will collect data about pork/beef products to see how fresh they are regularly. If some meat products are expired, it will be reported to the application server. The role of the application server, and a fundamental contribution to retailing considered in conjunction with the MobiPass architecture, is to calculate and communicate effectively and provably to customers the most suitable price in real-time based on the inventory data from the database server, customer numbers and product turnover, the data collected by the sensors and some additional conditions such as weather and the previous sales record. As now the supermarket is able to calculate the ‘‘best’’ price in real time, the problem is how to attract the potential buyer to buy these ‘‘real time special’’ products. For some servicebased retailers such as a hair salon, it would be much better if they are able to inform potential customers of real time special prices based on their current busy-ness, i.e., if there are only a few customers in the shop, the nail beauty shop can decrease the price significantly to reach the maximum profit/ utilization of staff. And the problem the hair salon is facing is how to inform the customers via an effective approach, as usually not every potential customer would like to enter the shop to query whether it has a special price if they do not have some urgent requirement. For these two examples we can see that actually the retailing industry is a very dynamic industry as the context is continually changing in real time and this could heavily affect some important factors such as price. To get the retailing service efficiency improved, it is quite useful and important to broadcast certain dynamic information, and the information sent should be trusted by the receiving party (buyers). Firstly retailers can check the relevant MobiPolicy and apply the relevant MobiPass. The MobiPass for the retailers usually contains real information about retailers such as business name, registration date and location, and it also contains rating information which is given by some trusted third party. After applying for and receiving their MobiPass, the retailers can use their MobiPass enabled devices to broadcast their context-based advertising information, as the MobiPass is a trusted source to prove the identify of the business with rich information, it provides a secure approach for which the receiver (customer) can totally trust the information they receive. This can ensure that the customer can: • Know that the information they received is from some real business entities, and the received information is primarily trustworthy. If the customers find that they received false information in some of the detailed information, they can report to the relevant MobiPass issuer. • Get the basic idea of the sender (retailer)’s background. For example, they can know this message is from a well-known retailer or from some retailer they have never heard of. Furthermore, they also can know some detailed information about this retailer—information such as the number of the employees and the registration date etc. • Be able to create a filter, to-filter unwanted messages. For instance, they might only receive information about music CDs and never receive the information for the retailer whose credit rating is lower than 6 out of 10. By using MobiPass, we can see that retailers can build an effective approach to advertising their products that embeds their business information. This greatly builds the confidence for their potential customers to make the mobile adverting trend more workable and practical. On the other side, the MobiPass architecture also enables the pull approach for shopping navigation. The principle is based on the bid system as the roaming potential customer can set some criteria in their MobiManager, e.g., price, and broadcast this information to the retailers he/she passes by, with the MobiPass, and each potential seller can decide whether to sell the product to this buyer based on the received criteria and the corresponding MobiPass. For the criteria-based pull approach, it is based on how the potential customer sets the criteria to look up the desired products by criteria. The criteria can be: • The criteria of the products, such as product name, model, price or even some keywords for this product. • The background of the retailer, who provides the selling of this product, apparently that the customers are willing to buy the products for a reliable, good reputation retailer. For example, if a potential customer wants to buy a digital camera with the lowest price she/he wants to pay, this potential customer can firstly set up the criteria in his/her MobiManager and the sample data can be as given in Fig. 4. Here, we can see that the potential customer has set the criteria for the digital camera he/she wants to buy, and we also can see that this potential customer only 166 Pers Ubiquit Comput (2007) 11:157–169 123
