The following assumptions contributed to the design of the security mechanism and ensured ample flexibility in its implementation:
MIDlets do not need to be aware of the security policy except for security exceptions that may occur when using APIs.
A MIDlet suite is subject to a single protection domain and its permissible actions. (See Section 18.3.3, "Protection Domain," for an explanation of protection domains.)
The internal representation of protection domains and permissions is implementation specific. (See Section 18.3.1, "Permissions," for an explanation of permissions.)
The user interface for presenting configuration settings and the results of authentication attempts to the user is implementation-dependent and outside the scope of the MIDP Specification version 2.0.
The device must protect its security policy and its information on protection domains so that they are safe from viewing or modification except by authorized parties.
If the security policy for a device is static and disallows use of some functions of the security framework, then the implementation of unused and inaccessible security functions may be removed.
Security policy allows an implementation to restrict access but must not be used to avoid implementing security-sensitive functionality. For example, unimplemented protocols under the Generic Connection framework must throw a ConnectionNotFoundException, not a security-related exception.
