Issue 1768:  SecurityFeatures still confusing! (sec-rev)
Source:  (, )
Nature:  Revision
Severity:  Significant
Summary: 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.
 
 
 

Resolution: 
Revised Text: 
Actions taken:
August 2, 1998: received issue
November 13, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <www>
Date: Mon, 3 Aug 1998 00:07:28 -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.7.2.3
Formal #: who-knows
Version: CORBAsec v1.2 Draft
Revision_Date: 5 jan 1998
Page: 15-89,15-275
Nature: Revision
Severity: Significant
full_desc: SecurityFeatures still confusing!

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.

Proposal one I feel is probably a good one.

typedef sequence<boolean> FeatureList;

interface SecurityFeatures { // Locality constrained
	readonly attribute boolean no_delegation;
	readonly attribute boolean simple_delegation;
	readonly attribute boolean composite_delegation;
	readonly attribute boolean no_protection;
	readonly attribute boolean integrity;
	readonly attribute boolean confidentiality;
	readonly attribute boolean integrity_and_confidentiality;
	readonly attribute boolean detect_replay;
	readonly attribute boolean detect_misordering;
	readonly attribute boolean establish_trust_in_client;
	readonly attribute boolean establish_trust_in_target;

	// Returns an ordered sequence of the 11 boolean values
	// in which the enum implies the index into the sequence.
	readonly attribute FeatureList feature_list;

	// For support of the orginal:
	// Returns an ordered sequence of the 11 SecurityFeatureValue
	// in which the enum implies the index into the sequence.
	readonly attribute SecurityFeatureValueList feature_list;
};

Proposal two would be to stay with the SecurityFeaturesValueList, but
strictly mandate that any sequence of security
features returned from a credentials or context be an entire
sequence of security features ordered in the order of the enum, no
more, no less, no duplicates.
submit: Submit Issue Report