MIFARE4Mobile - Architecture
MIFARE4Mobile - Architecture V 2.1
Doc Rev 2.1 Final — 31 Jul 2013
Application or an application with CONTACTLESS_ ACTIVATION privilege, which shall expose
CRSApplication.processCLRequest(), is mandatory and shall always grant the activation
request of a VC/Service Manager.
The display control information (e.g. URL, picture, Application family) [GP_AmdC] shall be stored in the
GlobalPlatform registry and shall be personalized with the GlobalPlatform INSTALL command.
CREL Applications may be referenced by one or multiple Service Managers. CREL applications are
notified by the COS as described in section 3.10.2 of [GP_AmdC]. This mechanism may be used by
Service Providers to implement specific business policies
If the GlobalPlatform CRS Application is not instantiated, then another application with the
CONTACTLESS_ACTIVATION privilege should be installed in the SE, implementing at least the
following commands:
Command exposing the same functionality than the GET STATUS command of the CRS
Application specified in [GP_AmdC]. The command shall at least return the following data:
Application Lifecycle, Display Control, Application Counter, CREL Application AID list,
Application discretionary data as specified in [GP_AmdC].
Command exposing the same functionality than the SET STATUS command of the CRS
Application specified in [GP_AmdC]. The command shall support at least the activation and
deactivation of a contactless application and return the same information as returned by the
SET STATUS response of the CRS Application specified in [GP_AmdC].
In this document, a CRS Application refers to an application with CONTACTLESS_ACTIVATION
privilege which exposes the functionalities of the GlobalPlatform CRS Application specified in
[GP_AmdC].
The CRS Application is an optional Application. However, it is strongly recommended that a CRS
Application is instantiated to properly manage the activation of contactless applications, among others
the VC/Service Managers. If there is no CRS Application, then a Wallet will not be able to retrieve the
list of contactless applications having conflicting protocol parameters with the contactless application
being activated and be able to solve the conflict(s) with or without the involvement of the User.
The Application Activation Policy specified in section 8.2 of [GP_AmdC] shall be implemented by the
COS and the CRS Application. When a VC/Service Manager is activated through the CRS Application,
the OPEN checks that the VC/Service Manager accepts the activation request by calling the
acceptActivation() method specified in [GP_JC_CL]. If the VC/Service Manager rejects the
activation request, then the CRS Application shall retrieve the list of policy conflicting application
information, i.e. the reason and a list of conflicting Application AIDs, by calling the
getNextApplicationConflictInfo() method of the VC/Service Managers.
Even though a VC/Service Manager may be activated or deactivated using the SET STATUS command
implemented by the VC/Service Manager in [M4M W-P-U JC API] or using the setCLState() method
in its Wallet shareable interface, the functionality is reduced when compared with the SET STATUS
command of the CRS Application. If the activation of the VC/Service Manager fails:
The VC/Service Manager returns the reason of the conflict and a list of conflicting applications
due to policy reasons, but it is not able to return the list of conflicting applications due to a
protocol parameter conflict.
The CRS Application is able to return the complete list of conflicting applications.
To avoid that an unauthorized entity retrieves the list of the contactless applications instantiated in the
Secure Element and activates/deactivates a contactless application, it is recommended that the CRS
Application rejects all commands received on the Contactless Interface.
The Amendment C features Cumulative delete, Cumulative granted memory, Display Required
Indicator, Application Selection Priority, Volatile Priority over Contactless interface and the Token
Identifier Blacklist are not required for the deployment of MIFARE4Mobile Framework.