RE: Guidance and Rationale

[Krishna Sankar <ksankar@cisco.com>]

Hi,

	I support the idea of a guidance section and think it could be part of the
conformance group's responsibility. The guidance also would include what to
implement and at what conformance level.

	The rationale is more nebulous. We definitely cannot do a rationale section
in the end. It is good to have such a section, but can we count on the sub
groups to note the rationale as they come up and pass it on to the editor ?

cheers

|-----Original Message-----
|From: Darren Platt [mailto:dplatt@securant.com]
|Sent: Wednesday, March 21, 2001 6:51 PM
|To: Security-Services
|Subject: Guidance and Rationale
|
|
|On the Use Cases and Requirements working group concall this
|morning we came
|up with a couple of issues that we thought we should open up to the TC at
|large for discussion.   Both issues are about adding new sections
|or content
|to the specification.  I will try to represent what was discussed, but I'm
|sure I'll miss some of it ...
|
|1. Rationale.  It was thought on the call that a section for
|rationale would
|be useful to people who review and/or implement our standard.  It was
|pointed out how Bruce Schneier recently criticized the IPSEC specification
|for not explaining why certain decisions were made.  It was also
|pointed out
|that the TC has limited bandwidth and writing up rationales may not be the
|most expedient use of our time.  Perhaps it would be useful to explain the
|rationale for only a few key areas.
|
|2. Guidance.  It was thought that this may be a solution for requirements
|which are not made part of our specification.  There may be some
|requirements which do not make it into the spec, for example R-Disclosure,
|that we would like to make sure are not made impossible by the
|specification.  In the example of R-Disclosure, we may not make it a
|requirement that all implementations only disclose the attributes about a
|user which the user has given them permission to disclose.  We do, however,
|want this type of functionality possible in a given implementation.  The
|guidance section would describe how such requirements could be implemented
|'on top of' SAML.
|
|Regards,
|
|Darren
|
|
|Darren Platt
|Principal Technical Evangelist
|Securant Technologies
|345 California St., 23rd Floor
|San Francisco, CA 94104
|tel - (415) 263-4976
|fax - (415) 764-4949
|http://www.securant.com/
|-----------------------------
|
|
|
|------------------------------------------------------------------
|To unsubscribe from this elist send a message with the single word
|"unsubscribe" in the body to:
|security-services-request@lists.oasis-open.org
|