GB2457221A - Smart Card Web Server (SCWS) administration within a plurality of security domains - Google Patents

Abstract

The invention relates to a method for remotely managing content on a web server, the web server being hosted in a storage device within an architecture consisting of a plurality of security domains and the web server being managed though a plurality of administrative agents, each agent using one or more corresponding administrative protocols, the method including securing the administrative protocol processed by each administrative agent by a cryptographic keyset containing at least one key and preventing any given administrative agent from using the keys of any other agent. The web server may be a Smart Card Web Server (SCWS). The security domains may be implemented in accordance with Global Platform specifications and the administrative protocol may be an OMA (Open Mobile Alliance) Full Administrative Protocol or Lightweight Administrative Protocol. The managed content may include executable applications accessible at one or more URLs, and at least one of the executable applications may be an NFC (Near Field Communications) application.

Description

IntellcctuaI ) Property Office Fc Cr. inoai,on Application No. GB0720297. I RTrvI Datc:15 Fcbruary 2005 The following terms are registered trademarks and should be read as such wherever they occur in this document: Java UK Intellectual Property Office is an operating name of the Patent Office dti A DT 3ERV3CE

WEB SERVER ADMINISTRATION

The present invention relates to method and system for web server administration in relation to smart card web servers.

Over the past years "contactiess", or near field communications (NFC), has quickly gained popularity and many contactiess services are now commercially deployed. Public transport schemes all over the world use contactless systems and contactiess payments look set to follow. Contactless typically uses a smart card in "credit card" form factor. Other smart card formats are available: of particular interest in the mobile telecommunications is the ubiquitous UICC (often referred to as the SIM card).

A much-discussed extension to NFC is to replace the "credit card" form factor card used in existing contactless services by a mobile phone handset containing a Secure Element such as the SIM card (this arrangement is referred to as "mobile NFC").

It is expected that the first mobile NFC services will use existing contactiess infrastructure.

Mobile NFC takes advantage of the fact that users typically already carry a mobile phone handset and consider mobiles as personal and trusted. In one mobile handset, a user could, in principle, replace numerous physical "contactiess" cards.

A cornerstone of the Mobile NFC is that all security and NFC functionality is controlled by the Secure Element. In this regard, it is noted that the SIM is the widest available deployed portable and standardised security element with more than 2 billion users worldwide. It is therefore highly desirable to use the existing SIM platform rather than to introduce a new secure element to the phone. Furthermore, the SIM is removable and users can maintain their applications and data from one NFC enabled mobile device to another.

The flexibility of Mobile NFC gives rise to a need to support multiple applications from different service providers. Service providers should be able to operate their own NFC applications within the SIM independent of the mobile network operator (MNO) and other service providers. Software development toolkits and programmable interfaces enable service providers to develop applications that can access phone handset functionality and trigger and register for NFC events.

Furthermore, the NFC service data on the SIM card needs to be securely managed by an administrator with appropriate access rights. These issues are addressed by implementing "Security Domains" on the SIM card, in accordance with Global Platform specifications -see in particular "Global Platform Card Specification Version 2.2, March 2006". Different Service Providers or other trusted administrators (Trusted Service Managers) can then be given their own Security Domains on the SIM card, with keys and applications that are isolated from the Issuer's (MNO's) own Security Domain, keys and applications.

A distinct advantage of the Mobile NFC solution is that it can provide a user interface (screen, keyboard, speakers etc.) for the NFC applications hosted on the SIM card. When a rich user interface is required, two general options are possible: I) The handset's browser (or other application supporting an HTTP client) interacts with an HTTP Server supported on the SIM card.

2) A mobile Java application (MiDlet) on the handset interacts with the SIM card using JSR 177.

In this regard, a further advantage of the HTTP option compared to the JSR 177 option is that no special application needs to be installed onto the handset. Thus the NFC applications can be made more easily portable, just by transferring the SIM card from one handset to another. It is therefore desirable that any solution to the above issues is compatible with the HTTP option for the user interface.

The Smart Card Web Server (SCWS) is a technology standardized by OMA (the Open Mobile Alliance) to allow smart cards used in mobile telecommunications (i.e. subscriber identity module (SIM) cards) to support an HTTP (and HT1'PS) web server.

Details of the technology may be found in "OMA Smartcard-Web-Server", OMA-TS-Smartcard_Web_Server-V1_0-20070209-C, Candidate Version 1.0 -09 Feb 2007, published on the OMA website.

The OMA standard specifies an administration protocol to allow a remote party (typically the mobile network operator) to configure and update the SCWS. For example, the administrator can load and delete content (either applications or static files) to a particular URL, create user "login" accounts for the SCWS, restrict users to particular URL ranges/patterns and so on.

Application of the SCWS to the provision of SIM-based mobile NFC brings advantages for NFC service providers as well as the user. The user-visible aspects of Mobile NFC applications and services (welcome pages, logos, PIN entry screens etc.) can be remotely managed and provisioned. There is a richer user experience because mobile NFC services can use the mobile's display and keypad. There is also cost saving potential, for example through replacing physical cards with virtual ones.

In the SCWS standard, the MNO provides the network over which a Service Provider will serve content, and the MNO may also be a service provider. Where the SCWS needs to serve content for several different service providers, it is to be expected that many of the service providers will not want their content to be seen and uploaded by either the MNO and/or the other service providers. As a result, it is contemplated that service providers will not necessarily trust user management and security management to the MNO.

Conventional implementations of the SCWS provide no mechanism for allowing multiple administrating parties to update content in the SCWS. Each service provider would need to trust a single common party to administer all their content.

It is therefore an object of the invention to obviate or at least mitigate the aforementioned problems.

In accordance with one aspect of the present invention, there is provided a method for remotely managing content on a web server, the web server being hosted in a storage device with an architecture consisting of a plurality of security domains and the web server being managed through a plurality of administrative agents, each agent using one or more corresponding administrative protocols, the method including: securing the administrative protocol processed by each administrative agent by a cryptographic keyset containing at least one key; and preventing any given administrative agent from using the keys of any other administrative agents.

In one implementation, the invention provides a means for managing NFC content on a SIM card via an HTTP server, while advantageously preserving the security features (multiple independent administrators, isolation etc.) that are defined in the Global Platform model.

The method combines any or all of the following co-operating features: 1. The SCWS is allowed to have multiple administrators. Each administrator has a separate key to encrypt and manage content onto the card, while the card architecture (e.g. Global Platform security domains) prevents administrators using each other's keys.

2. There is an ownership hierarchy for URL patterns. Only the administrator who owns a pattern can modify content within the URL tree defined by that pattern. The content concerned may be static (fixed pages, images, menus etc.) or dynamic (applications on the card that are activated when connecting to a particular URL, for example NFC applications).

3. Access control rights concerning web server resources (pages, NFC applications etc.) are partitioned by ownership of patterns. Each administrator defines its own community of users and access rules, and can only apply these rules to a URL tree that it owns.

4. Content uploaded by each administrator is linked to a memory quota for the corresponding security domain.

Using the SCWS on SIM cards allows the cards to be used by more than one service provider, while addressing security concerns and avoiding excessive administration work for the mobile network operator.

The features of the invention thus co-operate to permit each administrating party (Service Provider as well as MNO) to update their respective content in the SCWS without compromising the security of the other administrating parties. In particular: 1. The SCWS is allowed to have multiple administrators, one for each Security Domain (see Global Platform specifications) whose owner needs to update SCWS content. There is a tight link between the administrator and the owner of the Security Domain keys; the Global Platform architecture thereby prevents administrators using each other's keys.

2. There is an ownership hierarchy for URL patterns. For instance, the MNO might own the pattern /vodafone/, a bank SD might own the pattern /barclays/ etc. Only the administrator who owns a pattern can modify content within the URL tree defined by that pattern e.g. only the bank SD can create a page at Ibarclays/welcome.html. Further, to reduce the amount of work the MNO has to do, ownership is assigned dynamically e.g. an administrator establishes ownership of an unused top level pattern just by loading some content under it.

3. Security and access control rules, as defined in the OMA SCWS specification ("protection sets"), are partitioned by ownership of patterns. Each administrator defines its own community of users and access rules (https only etc.), and can only apply these rules (protection sets) to a URL tree that it owns.

4. Content uploaded by an administrator is linked to a memory quota for the corresponding security domain. Thus for instance, if an administrator wants to load a 10KByte JPEG file to a welcome page, it will be charged 10K against its memory quota on the card.

For a better understanding of the present invention, reference will now be made, by way of example only, to the accompanying drawings in which:-Figure 1 illustrates a typical mobile NFC arrangement; and Figure 2 shows diagrammatically how NFC service data in a mobile NFC arrangement is remotely managed using a SCWS.

Figure 1 shows the required elements of a typical mobile NFC arrangement -including a terminal (e.g. a mobile handset, PDA, eBook etc.) and a smart card (e.. SIM card/UICC etc.).

In using a mobile NFC service, the user ideally places his mobile handset (or "terminal") close to an NFC contactiess point of service (typically at a distance of less than 20cm from the point of service) and the NFC transaction automatically occurs.

This will be the case for reader mode and for card emulation mode when using NFC infrastructure.

Although ideally all the relevant NFC applications should be automatically launched when the user places his NFC handset against an external contactiess reader or card, there will be situations where the user will need to select a "default" NFC service for activation. Users can over-ride or change this default service via a contactless management application that is hosted in the SIM and available via the mobile's menu.

It is desirable that the end-to-end transaction for a mobile NFC transaction in card emulation mode shall be as quick as in existing contactless infrastructure.

There are services where users will need to be able to make an NFC transaction when the battery is low or zero. In these cases, it is not expected that the user will be able to use the mobile's display as well.

To protect privacy, users may want to be able to activate and deactivate the generic NFC functionality using a physical button or soft key. An indication of whether NFC is on or off should also be provided, such as an icon.

Preferably, the mobile terminal manages all NFC/contactless and mobile events and never loses any event in case of conflict (events triggered at the same time). For instance, if an SMS is received in the middle of a NFC transaction, the SMS must not be lost and should be displayed to the user as usual.

Mobile NFC places certain requirements when accessing NFC service data.

Service providers can update their NFC applications and service data via OTA mechanisms using the same process as for the initial installation of the service. There is also a requirement for service providers to be able to suspend NFC services, and then re-instate them at a later time.

Service providers may also allow their users to access applications and update service data outside a contactiess transaction.

Likewise when removing an NFC service, both service providers and users are able to initiate the termination of a service. There are two options to consider here. The service provider can initiate the deletion of the NFC application and service data (complete removal) or alternatively the NFC application is upgraded whilst the service data is kept and migrated.

The key NFC services have been identified as public transport ticketing, payment, loyalty and event ticketing.

For public transport, tickets or tokens are stored in the NFC application and users can request access to the transportation system by swiping their mobile. The use of contactless cards for public transport is an established service and a mobile NFC solution would have to function with a similar behaviour and improved user experience.

Another challenge is that the NFC transaction should be fast and also function when the phone's handset's battery is low or zero.

A mobile NFC payment transaction is achieved by swiping the mobile over an NFC reader at a point of sale. The payment application on the SIM should behave similar to an existing credit/debit card. Mobile phone handset features and connectivity may be included to enhance user experience and security levels.

The increasing number of loyalty cards in wallets, discourages users from using them and from subscribing to additional cards. These loyalty cards can be stored in the SIM and accessed by the brand distributors through the NFC contactless interface. The terminal handset display can optionally provide a branded interface to those cards. NFC Contactless loyalty cards when linked with mobile advertising could increase the potential value to service providers.

NFC applications contain the application logic and data for a NFC service. In order to guarantee a high and consistent level of security the SIM should be the only execution environment hosting the security functionality and sensitive data for NFC applications.

Conveniently, the card applications will conform to a non-proprietary technology that works across SIM platforms: for example JavaCard technology. New JavaCards APIs have been defined to support the introduction of NFC functionality.

As the expected size of NFC applications will be relatively small, the standard ISO interface on the SIM can still be used for application download. Alternatively the recently agreed "Hi-Speed" IJSB SIM interface may be used.

One component of the terminal in Figure 1 is the contactless front end (CLF).

The CLF handles contactiess RF functionality.

The CLF is a new element in the handset that provides NFC contactiess radio functionality and handles most of the ISO/IEC 14443 parts. The CLF and SIM exchange application level messages (e.g. APDUs) as defined in ETSI HCI specification. This split in functionality provides a separation of concern and optimizes response times over the NFC contactless radio interface. The SWP defines the lower layers (physical and link layers) between the CLF and SIM. Further study is needed into the support of legacy contactiess RF technologies as these may requires different approaches because of their stringent timing constraints.

In card emulation mode the CLF may power the SIM card in order to support a low or zero battery.

The architecture shall support NFC applications in reader and card emulation mode.

ISO/IEC 14443 type A and B shall be supported.

* Standard contactiess applications are compliant to ISO/IEC 14443 parts 2, 3 and 4.

* Non-standard contactiess applications may have a proprietary extensions of ISO/IEC 14443 part(s) 3 and / or 4.

In order to support legacy readers, MIFARE and Calypso shall be supported in card emulation mode by the handset and depending on local market conditions by the SIM card. In order to support legacy readers, the following non-standard NFC applications shall be supported in card emulation mode MIFARE and Calypso.

Figure 1 also shows certain components of the smartcard including the SCWS.

NFC applications require access to the terminal handset in order to interact with the end user through e.g. keypad and screen. In addition the NFC application may want to trigger terminal handset or connectivity functions.

The command set of CAT and USAT is appropriate for the interaction with network elements (sending SMS, setting up a call, BIP etc.), for managing the mobile execution environment (provide local information, timers, events etc.) or for providing user interaction (menus, display text, request user input through the keyboard etc.).

However the CAT and USAT command sets are somewhat restrictive in terms of user interface.

When rich user interfaces are required two options are supported: 1) The handset's browser (or other application supporting an HTTP client) that interacts with the SCWS Serviets combined with static WML/HTML pages will be used. The JavaCard Webserver API is preferably supported on the SIM.

2) A MiDlet that interacts with the S1M using JSR 177 [see Mobile NFC technical guidelines; vl.O; April 2007, GSM Association http://www.gsmworld.com/documents/gsma_nfc_tech_guide_vsl.pdf I The administration mechanisms of SCWS (as defined in OMA SCWS specification) manage static content, mapping of card Applets to HTFP URLs and administration of access control policy (ACP).

Whether data constitutes static content or dynamic content, similar conditions apply to the administration of data stored on the SCWS.

An administrative agent is only able to download static content (or map and unmap a JavaCard Applet) to a URL that hangs from a URL already owned by the agent. The only exception to this rule occurs when the requested URL does not hang from any URL already owned by any agent. In this case, the first level of the requested URL becomes owned by the administrative agent that received the command. The owning agent is the only one which can add or delete static content (or map or unmap JavaCard Applets) in the tree defined by this first level URL Furthermore, an administrative agent is only allowed to map/unmap JavaCards Applets that are associated either to the agent's security domain (SD) or to a service to provider security domain (SPSD) that is associated to the agent's SD. The only exception to this rule is the agent associated to the ISD that shall only be allowed to map/unmap applications associated directly to the ISD.

An owned first level URL will be freed when all the content hanging from that URL is either deleted (static content) or unmapped (dynamic content). Any other administrative agent can use the mechanisms described above to own the URL afterwards.

The SCWS contains at least two configuration resources: * /config/admin_settings, the default configuration resource; and * /configlimei_change that contains data used by the SCWS to contact the MNO when the UICC is moved into a new handset.

The update of the access control protocol (ACP) is enforced when the UICC is moved into a new handset. This ensures that ACP can be modified before the SCWS outputs any content to the new handset.

Implementing user interaction on the SIM only (i.e. via the SCWS and SIM servlets) has several advantages over an approach that splits the application between the SIM and the terminal: * portability of applications and data (i.e. when the SIM is put in another terminal) * simplified (remote) application lifecycle management * challenges that are caused by differences in rendering across handsets will be minimized when the NFC applications are not distributed SIM Serviets shall be able to request the terminal to instantly start a proactive session using the I-IC! connectivity event.

Conveniently, Mobile Network Operators (MNOs) operate secure remote SIM management systems and processes that can be leveraged to manage the whole life cycle of NFC services.

In addition to more traditional MNO and Service Provider roles, Mobile NFC requires a Trusted Service Manager (TSM) role to facilitate the business relationships between MNOs and NFC service providers. This is needed to encourage existing and new service providers to adopt Mobile NFC. There is a consequent need to support multiple TSMs in the market.

The TSM role allows Service Providers to delegate application lifecycle management and personalisation to the TSM, thus avoiding the need to establish trusted relationships with every MNO.

A typical TSM will have responsibilities including: * Remote management (installation, update, activation and removal) of NFC applications.

* Securely provisioning application data to installed NFC applications.

* Testing, verification and certification of NFC applications prior to their installation.

Depending on local market needs the TSM can be managed by one MNO, a consortium of MNOs or by independent trusted third parties. There will be a need to support multiple TSMs in one market.

As a result of a user request, service providers will be able to initiate, via the TSM, the secure OTA download of an NFC application directly to a user's S1M. Users will be informed of the download, and can be prompted for acceptance. The choice of message displayed to the user will be at the service provider's discretion (i.e. customisable system messages).

Service data may be delivered together with the application or separately using OTA mechanisms.

It is worth emphasising that SIM security is based on global, well-established standards (ETSI, GlobalPiatform and 3GPP) covering application execution and storage, "over the air" (OTA) management and the entire life cycle management. It is not considered within the scope of the present discussion to explain these mechanisms in further detail.

The security framework of the SIM ensures the privacy and integrity of a service provider's NFC applications & services. No other functionality can access application data or invoke functions of installed NFC applications. Memory quotas per TSM and per service provider application are enforced during the card's operation in order to ensure the overall integrity of the SIM.

As a matter of practical importance, users should also be able to swap between NFC-enabled mobiles, NFC SIMs and across MNOs and still receive the same NFC services (assuming, of course that the service is supported by the MNO).

Figure 2 illustrates the basic method for implementing remote administration of the SCWS.

Both SMS and GPRS via BIP shall be used as OTA channels for remote management over the standard ISO interface. The SIM shall support both TCP and CAT_TP via BIP.

Security domains as defined by GlobalPlatform shall be used to support multiple businesses sharing the same SIM resources.

The MNO owns the keys for the card's Issuer Security Domain (ISD), which is where the MNO's applications, e.g. (U)SIM, are stored. The MNO can also act as a TSM.

Every TSM owns the keys for its respective security domain (TSD). The MNO grants the TSM the facility to remotely manage card applications using either authorised or delegated management as defined in GlobalPiatform v2.2.

A service provider that requires strict confidentiality for managing its applications and/or data (so that not even a TSM sees the data) shall be assigned its own security domain (SPSD). A service provider's security domain shall be associated with one TSM security domain, or the Issuer security domain. Using confidential card content management, a service provider can install and personalize applications using the MNO's or TSM's OTA infrastructure.

For security reasons all security domains are pre-loaded during card production and may be activated over the air. The keys provisioned in the TSM or service provider security domains are never accessible to the MNO but kept securely by the card manufacturer and distributed directly to the TSM and/or service provider upon MNO request. OTA installation of security domains is left as a future extension.

Memory quotas, limiting the amount of memory that is available to each defined TSM, prevent one TSM using more SIM space than has been allocated by the MNO, both in the TSM's own security domain (TSD) and in any associated service provider's security domains (SPSDs). The MNO can also completely erase all content that has been loaded into a TSD and all associated SPSDs simply by reducing the TSM's quota down to zero.

In an embodiment of the invention, remote administration is permitted from >1 administrators/service providers.

The SCWS and the standard administrative agent are associated to the ISD. The UICC shall support additional administrative agents associated to TSDs. It shall be possible for the ISD to create these new agents using over the air mechanisms, but not the keys that the agents use.

The following aspects are supported by each administrative agent: * Download of static content: the memory consumed by static content downloaded through one agent shall be charged against the quota of its associated SD.

* POST requests with the special administration commands to map/unmap a JavaCard Applet.

* POST requests with the special administration commands for the management of protection sets and users. Each administrative agent shall have its own collection of protection sets and users. These shall be independent of those of other administrative agents. Each administrative agent shall only be able to apply a protection set to content that hangs from a first level URL it owns.

* The Lightweight and the Full Administration Protocol, as defined in the

OMA SCWS specification

The following administration actions are reserved for the standard administrative agent associated to ISD: * PUT request for updating the ACP information * POST request with the special administration commands for http/s on/off * Updating of the content under /config The invention improves service providers' ability to offer portability of NFC services when a mobile user switches to a new mobile terminal. Application data and logic are available when the SIM is inserted into a new handset terminal. For solutions that use a MIDlet for user interaction, the MIDlet also needs to be reinstalled on the new handset.

The CLF and SIM may need to be reconfigured in order to accommodate the new setup. Different mechanisms are supported in order to detect that the SIM has been moved to a new handset: * Generic CAT: A card Applet may verify the handset's IMEI at start-up.

* NFC specific: SyncID in SWP and Session Identity in HCI Card application management and selection There shall be a central management application on the SIM that facilitates the life-cycle management of contactiess applications.

* The management application is responsible for configuring the CLF during the life-cycle of NFC applications (e.g. provisioning the proper RF settings).

* Remote activation of contactiess applications from the service provider shall be possible through the management application.

* In situations where automatic triggering of one NFC application is not possible the management application may request the user to manually select the desired behaviour.

* In addition the handset shall provide a button or a menu option that allows the user to switch on or off NFC functionality globally.

Acronyms APDU Application Protocol Data Unit API Application Programming Interface BIP Bearer Independent Protocol CLF Contactiess Front CLT Contactiess Tunnel CAT Card Application Toolkit HCI Host Controller Interface ISD Issuer Security Domain IMEI International Mobile Equipment Identity MNO Mobile Network Operator

NFC Near Field Communication

OTA Over The Air SCWS Smart Card Web Server SIM Subscriber Identity Module SWP Single Wire Protocol TSM Trusted Service Manager USAT USIM Application Toolkit UICC Universal Integrated Circuit Card

Claims (10)

1. CLAIMS: 1. A method for remotely managing content on a web server, the web server being hosted in a storage device with an architecture consisting of a plurality of security domains and the web server being managed through a plurality of administrative agents, each agent using one or more corresponding administrative protocols, the method including: securing the administrative protocol processed by each administrative agent by a cryptographic keyset containing at least one key; and preventing any given administrative agent from using the keys of any other administrative agents.
2. 2. The method of claim 1, wherein the cryptographic keyset used by each administrative agent is implemented in a corresponding one of said security domains, thereby ensuring there is a unique mapping from administrative agent to security domain.
3. 3. The method of claim 2, wherein said corresponding security domain has an owner outside the storage device, the owner managing content on the webserver using the administrative protocol and the cryptographic keyset.
4. 4. The method of any one of the preceding claims, wherein the security domains are implemented in accordance with Global Platform specifications.
5. 5. The method of any one of the preceding claims wherein the web server is a Smart Card Web Server.
6. 6. The method of any of claims I to 5, wherein the administrative protocol is an OMA Full Administration Protocol.
7. 7. The method of any of claims I to 5, wherein the administrative protocol is an OMA Lightweight Administration Protocol.
8. 8. The method of any one of the preceding claims, wherein the managed content includes static content accessible at one or more URLs
9. 9. The method of any one of the preceding claims, wherein the managed content includes executable applications accessible at one or more URLs.
10. 10. The method of claim 9 wherein at least one of the executable applications is a contactiess application. I011. The method of claim 9 wherein at least one of the executable applications is an NFC application.12. The method of any one of claims 8 to 11, further including enforcing a hierarchical ownership pattern of URLs, in which only the administrative agent which owns a URL pattern is permitted to manage content within the URL tree defined by the pattern.13. The method of claim 12, further including granting ownership of an unused URL pattern to an administrative agent when the agent is the first administrative agent to load content to a URL under that pattern.14. The method of claim 12 or claim 13, further including deleting all content under a previously used URL pattern, thereby rendering said pattern unused.15. The method of any of claims 8 to 14, further including partitioning access control rights concerning web server content by ownership of URL patterns, only the administrative agent that owns a URL pattern being pennitted to apply access control niles to URLs under that pattern.16. The method of claim 15, wherein said access control rules consist of OMA SCWS protection sets.17. The method of claim 15 wherein said access control rules consist of extended versions of OMA SWCS protection sets.18. The method of any one of the preceding claims, further including subjecting the content managed by at least one of the administrative agents to a memory quota.19. The method of claim 22 wherein the quota is managed by an overall administrator of the storage device.20. The method of claim 23, wherein the overall administrator is a Mobile Network Operator.21. The method of any of claims 22 to 24, further including reducing the quota to zero in order to erase all content managed by said at least one administrative agent.22. A system for remotely managing content on a web server, the system including a storage device with an architecture consisting of a plurality of security domains, the storage device hosting the web server, wherein the web server, in operation, executes the method claimed in any one of claims 1 to 21.23. The system of claim 22 wherein the web server is implemented within a component of a mobile terminal.24. The system of claim 23 wherein the component is removable.25. The system of claim 23 or claim 24, wherein the component is a storage device.26. The system of any one of claims 22 to 25, wherein the storage device is a smart card.