RE: Guidance and Rationale

["Orchard, David" <dorchard@jamcracker.com>]

The SAML "constellation" of specifications ;-)

Dave

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> Sent: Thursday, March 22, 2001 6:43 AM
> To: Security-Services
> Subject: Re: Guidance and Rationale
> 
> 
> At 06:50 PM 3/21/01 -0800, Darren Platt wrote:
> >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.
> 
> There are definitely two schools of thought on this.
> 
> Stephen F. was saying at the F2F that he wants to avoid delivering a 
> "brick" of a document.  I believe that rationale material is 
> a great thing, 
> but nearly all of it doesn't belong in the spec proper 
> because it is hard 
> to keep the normative and non-normative (rationale) material 
> straight, and 
> because it swells the size of the spec.  If we have any 
> rationales written 
> up, I would very much like to publish them, but as an accompanying 
> document, not as part of the "real" spec.
> 
> The usual exception is in an introductory section where 
> you're motivating 
> the scope of the spec as a whole.  Introductions don't have a lot of 
> normative stuff in them anyway, and providing a bit of conceptual 
> background/bias is useful.
> 
> >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.
> 
> Again, this sounds like a great candidate for an additional 
> document.  (Unless the non-requirement ends up being a 
> "SHOULD" instruction 
> in the spec anyway, which does have a normative meaning...)
> 
> We should feel free to produce tutorials, best practices 
> documents, etc. in 
> addition to "the one true SAML spec."  I think breaking it 
> down like this 
> will help readers anyway, because each document is less to swallow.
> 
> My n cents,
> 
>          Eve
> --
> Eve Maler                                             +1 781 442 3190
> Sun Microsystems XML Technology Development  eve.maler @ east.sun.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
>