Allow null implementation of APDUand JCRMI optional packages
the SATSA Specification version 1.0, it is written that the APDU and
JCRMI optional packages define interfaces for communication of J2ME
applications with applications on a smart card. But specification does
not clarify situations when smart card reader is not present at all.
The main point of proposed change is to process properly the situations
when device doesn't have a smart card reader . It allows to develop
safe and flexible J2ME applications.
Add clarifications for PIN Entry mechanism
Id and PIN type terms are used for PIN Entry mechanism in the SATSA
Specification version 1.0.
The values of these terms and their mapping to external specifications (e.g. PKCS#15 ) should be clarified.
Add clarifications for SIM, USIM, UICC related to APDU structure used
by the APDUConnection interface
terms are used all together in the SATSA Specification version 1.0. The
definitions of these terms are not clear . It should be clarified.
The restriction on SAT connection in the SATSA specification needs to
be corrected in Appendix B such that it allows access from MIDlets in
the handset manufacturer's domain. The security policy defined in
Appendix B is a recommendation and is not a "must have"
with MSA specification which requires access to SAT from handset
Add clarification to remove any ambiguity regarding affecting of SAT
support to APDU connections.
SATSA specification version 1.0 doesn't specify how SAT support affects
|6) Clarify in the specification
for APDU and
JCRMI connections that any READ/WRITE/READ_WRITE modes can be used to communicate with SE.
|In the SATSA Specification
version 1.0 for javax.microedition.io.Connector class, it is written
that "The validity of these flag settings is protocol dependent". The
protocols, APDU and JCRMI, however, do not specify how these flags
might be used when opening a connection to the SE.
|7) Fix typos and broken links.
||There are some typos in the
version 1.0 which should be fixed.