Summary: The model currently specifies that _set_policy_overrides(), and
get_policy() apply to the particular object reference.

That would mean that the policies applied to accessing Current.
I suggest that we aliviate this discrepancy by putting a
CORBA::PolicyManager get_policy_manager() on the Current interface.
The PolicyManager is currently part of the new Async Messaging Specification
and would be a good interface to do this with.

Summary: Using SecurityOpaque causes needless buffer copying. I suggest
a buffer interface.
Using a sequence<octet> for tokens going in and out of
SecurityReplaceable::Vault and SecurityContext imply
(at least in the Java) maps it to an array of fixed length.

This causes the implementations to constantly recopy entire
arrays just to get the length attribute set correctly.

Summary: Okay, I"ll give you there is a need for security features
provided they are only looked at for supported features of
credentials and contexts. Not for setting.
These should be done via setting assoication options and setting the
delegation mode;

To simplfy the semantics of SecurityFeatures and using them,
the spec should specify a good programing model. Otherwise,
examining them and manipulating them becomes ineffcient.

Summary: As I lamented before. I fear that to make much implemenation
sense out of the "replaceability of the module I believe
SecurityReplaceable should have Credentials and PrincipalAuthenticator
as well.

Note: This does not proclude security level 2 from having
Credentials and PrincpalAuthenticator, just that SecurityReplaceable
should have them as well.
.

Summary: It would appear since the SecurityContext must hold onto the
Credentials object, that the Credentials object must appear
in SecurityReplaceable as well, since there is no factory
for generation of credentials in an independant way.

Perhaps a "Server Context should have a list of
security attributes instead of a list of credentials.
That way an orb using a replacable module can create a local
credentials object and put the security attributes in it.

Summary:

Each security context, at least at the SECIOP/GIOP levels each
have a client and target orientation. This is not reflected
in the SecurityContext interface.

Also, using the same context for both, is misleading, in the
sense that "received_credentials" does not make sense for
a context on the client side:

Summary: Credentials do not have a mechanism specification, a delegation mode,
specification, and an origin specification.

I believe the credentials object may be used to hold the means
necessary to support a security mechansim. It would be much less
confusing, and easier to specify, if there is one credentials
object per mechanism.

We should state that one credential object supports one
mechanism type.

Summary: We need a delegation directive policy in order to convey on an
object reference, and elsewhere, that whether the credentials
beign used are to be delegated or not.

Summary: Semantics of the Mechanism Policy is not defined well.
There are different semantics if it is applied to a
client object reference than to a server object reference.

On the server side, the mechanism list stipulates which
mechanisms can be used to handle the requests. This may
stipulate which mechanisms are advertised in the IOR.

However, since there is an order, and order preference should
be specified. If a client wishes to invoke on said object and
two mechanisms support the requested features, the first one
that does so in the IOR should be said to be selected.

To support multiple mechanisms on the client side, one would
have to inquire which one was used and in which order to
use them. This can also be implied by the order of the list.

However, the semantics of such should be specified.

Summary: Inconsistent Spelling between Security and SecurityLevel2

Summary: Operations regarding Security Features are too vague, unclear,
can be inconsistent, and most likely, not fully implementable.

Summary: Duplicate DelegationMode(s) in Security and SecurityLevel2

Summary: const EventType AuditObectjCreation = 7;

should be

const EventType AuditObjectCreation = 7;

Summary: I believe there is a typo in 98-01-02 p.15-277. The line
const AssociationOptions DetectReply = 8;
should read:
const AssociationOptions DetectReplay = 8;