Summary: The documentation states that the force_commit parameter given the value
of false will cause the privileges to be set at a later time. If so,
what does the out parameter "actual_privileges" return?
Is this valid only if force_commit was true and successful?

Also, boolean states a return value. I believe this should be
void, and state that exceptions will be raised with reasons for
failure.

Close Issue 1765: set_privileges

Summary: In trying to understand some problems we"re having on
our reference implementation development, I"ve run
across an inconsistency in the CORBAsec V1.2 spec.

On page 15-191, Section, 15.9.1, there is a figure
15-59 that shows the SECIOP protocol underneath the
IIOP protocol. This is contrary to my understanding
of the SECIOP architecture, which corresponds to
Figure 15-57 - where the SECIOP protocol is located
between the GIOP and IIOP protocols.

Hopefully, the problem is simply that Figure 15-59
should have "IIOP" replaced by "GIOP".

Close issue 1723: SecIOP Architecture

Summary: enum DelegationMode is defined in Security.idl and in SecurityLevel2.idl.
Both definitions are rather different:

Summary: Security 1.3 Service pages 15-87 5 Jan 1998

continue_authentication has the wrong in/out designations on
three of its four parameters. I have in, in, out, out.

It shoud be

continue_authentication(
in Opapue response_data,
inout Credentials creds,
inout Opaque continuation_data,
inout Opaque auth_specific_data
);

No Data Available

Summary: I believe the SecurityContext interface needs to be extended to properly
support the SECIOP::DiscardContext message.

:DiscardContext message.

Summary: Paragraph 19 of section 15.8.4.2 says:

"In this example if mechanism “mech 1” is used the target security name is “MBn1”
while the association must use integrity replay and misordering options. If mechanism
“mech 2” is used no mechanism specific security name has been specified and so
“Manchester branch” is used as the security name. The association options are
EstablishTrustInClient and Integrity."

The last sentence seems to imply that if "mech 2" is used the top-level
association options, and not the association options for "mech 2" are used.
If this is always the case, then it would seem pointless to bother
specifying association options for "mech 2" because they will never be
used. If this is the case (which would also be very strange) only when
a tag_sec_name is not present for "mech 2" this should be explained
more clearly.

Close issue 1633: Paragraph 19, section 15.8.4.2

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;