The "credentials" object represents the "principal". It was defined with a number of different possible underlying security mechanisms in mind - which might use (PK) attribute certificates, Kerberos/DCE service tickets etc. Strictly, credentials can contain both unauthenticated and authenticated attributes (see 15.3.2) - the unauthenticated case being used mainly for "public" where the principal has no authenticated id, so only has access to public information.
CORBA Security defines the interfaces, not the architecture, in line with other OMG standards. As a security person, I clearly want to know if the credentials can have been tampered with, but that is a feature of the implementation, not the interfaces. So we said CORBA Security implementors must define "assurance" information about their products, including threat information, and users have to check that. Would the OMG rules allow statements about the level of authentication of the id and other attributes? If so, it would be nice to clarify this, though I'm not sure how easy it is to define. (The current spec allows different levels of security here and elsewhere).
Security attributes were intended to include both identities and privilege attributes - both seem needed. Therefore a "principal" definition which does not allow privilege attributes would seem a retrograde step.
We did not define the syntax of possible name types, though, as Nick says, this seems a good thing to add into the standard. The problem was that different underlying mechanisms use different name types e.g. X.509 names, DNS ones, operating system ones, so applications which need to be portable between different mechanisms should be able to work with different types.
We wanted to allow a range of access control mechanisms, including roles, groups, clearances etc, and also ones specific to particular organisations (for which we had seen requirements). Hence having privilege attributes as well as identities in the credentials. Specifying standards for more families, types, associated value syntaxes etc in the OMG standard would be good. (However, a quick look at the ietf draft of GAA_API seems more restricted than CORBA Security, and also includes an access decision interface which CORBA Security already has.)
The application sees a credentials list (rather than just a single credential) in cases where the delegation model used can provide both the credentials of the "initiating" principal and also credentials for one or more intermediates. The initiating principal is the one whose attributes will be used for access controls, auditing etc. However, the target application may not want to use these unless they have come via trusted intermediates (and may want to control access based on the intermediate's attributes in some cases). We discussed whether we could specify a recommended delegation model for CORBA Security, but there were several delegation models in existing implementations, all of which had pros (as well as cons). There did not seem any generally market preferred model, and we felt these delegation models were still immature, so we specified an application interface which allowed for the delegation models in a number of products, both secret and public key based ones - the ones we looked at included Kerberos, DCE, SESAME and Tivoli, all of which were different, hence the delegation variants defined in 15.3.6.3 etc. (We also looked at "reference restriction" forms of delegation such as Sun were implementing, but could not get an agreed definition, so did not include in the formal definiton). The semantics of the credentials list was not defined, as it is dependent on the mechanism (e.g. simple delegation would only provide a single credentials object, where composite and traced delegation would give a list), but the initiating principal's credentials are always first (the only ones wanted in many cases). OK, this was a bit of a cop-out, but is there yet a delegation model which is generally agreed enough yet (and being implemented) to include in CORBA Security as the standard?
... For the intial CORBA Security spec, delegation was discussed at length, and we found different models suited different requirements, but there was no one model which satisfied most requirements and was easier enough to administer. Simple delegation was the nearest (as it meets the ease of admin requirements, if not some of the control ones).