John Sebes (April, 1998):
Briefly, the answers are: transport of client ID data is performed by CORBA security mechanisms. One does not need to pass user IDs as parameters, and even if one did, there would still be the authentication issue. Authentication functionality is part of the CORBA security mechanism for transporting client ID. There is no CORBA Security Service Context in IIOP per se, because the context data is carried as part of a security protocol for IIOP- either SSL or SecIOP.
As an example of how such things are done today, consider a typical IIOP/SSL implementation. There is no identity or authentication data in IIOP at all. The SSL session setup protocol includes authentication and exchange of digital certificates that include identity information. Security-aware applications can obtain client identity information either: (a) via CORBASEC interfaces for accessing the "Current" object, or (b) proprietary or ORB-specific interfaces for accessing data in X.509 certificates passed via SSL.
This should answer your questions with respect to mechanisms. However, there are several open issues for actually using these mechanisms, for example: availability of FSP from ORB vendors, implementation of CORBASEC, SSL, and/or SecIOP; integration/bundling of public-key infrastructure elements (e.g. certificate management); facilities for trust management in certificate evaluation (how can you control which certificates you actually believe?)
In summary, the mechanisms exist, but may not be available in FSP, and in any case require some careful thought for safe and effective use.