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