CSIV2 — Multiple Privilege Authorities and Supported Naming Types

Multiple privilege authorities and multiple naming types yield
combinatorial problems for the client.

Discussion:

This issue is sort of in the same regards to Issue 3973 where Ron thinks
that having multiple target_name(s) in the AS_ContextSec is a bad idea, of
which I agree.

The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec
structure sequence<ServiceConfiguration>. It suffers the same problem,
especially when combined with multiple supported naming types.

It is completely hard to determine having multiple privilege authorities
and the names that must be used to assert the identity for the privileges.
In fact, the client may get back an AuthorizationToken that he doesn't
understand, but will need to assert an identity for it's use, quite
possibly with endorsement. Having multiple naming types supported per
privilege authority is fine, but combine that with multiple ones, and you
may get a decision problem for the client.

It is better to be able to specify a one-to-one correspondence, locking
down the combinations that a server will accept, and the client doesn't
have to do any mucking about deciding what will work.

Proposed Solution:

Singularize the privilege authorities field.

Unfortunately IDL has a hard time making a singular field become optional
without doing something bizzare, such as:
switch(boolean)

which requires a new type, etc.

I have two proposals:

Proposal 1:

We signularize the field in name, i.e. "privilege_authority". Keep the
sequence definition. However, stating in the specification at most one
must be contained. This can be hinted at as well in IDL.

struct SAS_ContextSec

;

Proposal 2:

We specify a ServiceConfigurationSyntax tag for "none", and specify that
the sequence of octet associated with it is empty.

// Corresponding ServiceName for the SCS_None Syntax should be an empty
// sequence octets.
const ServiceConfigurationSyntax SCS_None = -1;

struct SAS_ContextSec

;

For efficiency I'm in favor of the second approach, because I can just
look a the ServiceConfiguration::syntax field and know what to do. The
first proposal causes me to look at the length first, index to the first
element in the array, and then look at the syntax field.

As an aside, I also wouldn't mind changing the sequence<Security::OID>
type into a Security::OIDList, but that can be the subject of another
issue. Also note, to be specific with the document I am pointing to, I
used the "Security" definitions. Hopefully, we will follow one proposal to
change the Security::AssociationOptions to CSIIOP::AssociationOptions and
Security::OID and Security::OIDList to CSI::OID and CSI::OIDList
respectively.

Close issue with revised text.