Issue 1757:  Operations regarding Security Features (sec-rev)
Source:  (, )
Nature:  Revision
Severity:  Critical
Summary: Summary: Operations regarding Security Features are too vague, unclear,
 can be inconsistent, and most likely, not fully implementable.
 

Resolution: 
Revised Text: 
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue
Discussion: 
 received issue
End of Annotations:=====
Return-Path: <www>
Date: Thu, 30 Jul 1998 16:52:58 -0400
From: www
To: juergen@omg.org, web-incoming@omg.org
Subject: WWW Form output

Name: Polar Humenn
Company: Adiron, LLC
Email: polar@adiron.com
Notification: Yes
Specification: Services (Security)
Section: 15.5.5.2
Formal #: who knows
Version: v1.2 draft 
Revision_Date: 5 jan 98
Page: 15-95
Nature: Revision
Severity: Critical
full_desc: Operations regarding Security Features are too vague,
unclear,
can be inconsistent, and most likely, not fully implementable.

First of all, Security Features come in a list of SecurityFeature.
This is an unordered list which makes efficiency of searching
the list go down the tubes. Nothing is said about the possibility of
having two of the same security feature, each with different
value attributes, in the same list.

As for possible inconsistency violations when setting security
features, for instance, what does it 
mean to "turn on" SecNoProtection, when
SecIntegrityAndConfidentiality,
is already turned on? Does that mean that SecIntegrity and
SecConfidentiality *must* be turned on as well? Nothing is said about 
this.

Security features should be an
interface gotten off a credentials object or a security context with
specialized queries. To take an intial stab at the idea just for 
illustration:

interface SecurityFeatures {
    Security::DelegationMode
    get_delegation_mode();

    Security::AssociationOptions
    get_assoc_options();
}

would seem to cover it. So, now I ask, what do we need these
security features for in the first place?

these operations can be placed directly on the security context
or credentials. (which I will get into later.)

PROPOSED SOLUTION:

Scrap the security features enum, values data type, policy, 
interface operations associated with, etc.

This is critical because there is really no good way of supporting
it with interoperable portable semantics.
    
submit: Submit Issue Report