RE: The Hal/David model

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

Marc,

I think that there is some confusion on the purpose of the model.  From a
draft I'm working on: 

"
This domain model provides a description and categorization of the domain
that SAML solves problems in.  People, software, data, interactions, and
behavior are described in the abstract, without binding the specification to
a particular implementation.  It provides a standardized or normalized
description of concepts for the purposes of further discussion in
requirements, use-cases, etc.  It covers material out-of-scope for the
specification in order to show the context that the specification solves
problems in.  It does not describe implementation information such as API
details, Schema definitions and data representations.

A typical use-case for this document is: "We all agree what we mean by term
x and how entity y creates it and entity z consumes it.  Is x in scope or
out of scope for SAML?".  Another use case "We have created an OASIS TC
committee on functionality A.  A is the standardization of term x that is
out of scope for SAML". 

In the rational unified process, an artifact we are working on is the
logical view, http://www.rational.com/products/whitepapers/350.jsp#RTFToC2.
"


Hal's diagram does not use Rational notation, and I personally accept that.
I think his creation of a new type of model showing dependencies rather than
interactions is actually very insightful for our purposes. 

This is not an overall architecture document.  Neither Hal nor I are
presuming or attempting to become the architects of SAML.  We don't need
that head-ache.   To support scenarios, we need agreed upon semantics.
Semantics are defined by context.  Therefore we have to specify the context.
That is as far as we are attempting to go for the use case effort.  

I think there is the outstanding question of whether or not a subgroup owns
any portion of the "architecture" artifacts that will surely be created.
Our structure of assertions/bindings/protocols/use-cases/conformance doesn't
really have this construct in it.  

Cheers,
Dave

> -----Original Message-----
> From: Chanliau, Marc [mailto:MChanliau@netegrity.com]
> Sent: Monday, March 12, 2001 2:07 PM
> To: Eve L. Maler; security-services@lists.oasis-open.org
> Cc: Darren Platt
> Subject: RE: The Hal/David model
> 
> 
> In the proposed model, I think that there's quite a lot of 
> info represented
> that is not part of SAML (at least as we speak), such as the 
> objects called
> "policy" and "other". Also, what is referred to as "ancillary 
> processing"
> (and the useless arrows) is mentioned as not being part of 
> SAML, therefore
> it should not need to be represented in the graphic either. 
> On the other
> hand, there's no mention of protocol and protocol binding in 
> the graphic,
> which is part of SAML (as we speak). I don't think the 
> graphic represents a
> "working architecture" as advertized, but rather a kind of 
> workflow. Last
> but not least, I do believe that credentials should be scoped 
> in the SAML
> spec, and I'm not sure what the status is on this.
> 
> Marc Chanliau
> 
> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> Sent: Monday, March 12, 2001 3:48 PM
> To: security-services@lists.oasis-open.org
> Cc: Darren Platt
> Subject: Re: The Hal/David model
> 
> 
> The graphic has been rendered into a number of different 
> formats and given 
> a "proper" filename.  The GIF version is now here (and you 
> can find other 
> versions there as well):
> 
>  
> http://www.oasis-open.org/committees/security/docs/draft-moses
-arch-model-00
.gif

Sorry for any confusion,

         Eve

At 12:03 PM 3/9/01 -0500, Eve L. Maler wrote:
>People who attended F2F #1 will recall the diagram that Hal Lockhart drew
>up on the whiteboard.  It was something he and David Orchard came up with
>to help the use-case group settle on terminology and a rough model of the
>"things" we're discussing.  Fred Moses worked from his notes to create the
>following electronic version, which reflects a bit more of the discussion
>we had that day:
>
>    http://oasis-open.org/committees/security/docs/sstcach1.gif
>
>I'm sure we need more revisions to this diagram, but I would like to work
>towards consensus on the names for things and the relationships between
>them.  Please use this thread to discuss it, and we will take it up as a
>topic at the 20 March telecon.
>
>For starters:
>
>- On Tuesday, we discussed separating each box so that there's no hint of
>chronology.  This could mean, e.g., duplicating the "1" callout so that
>it's shown separately as the output of a credential collector and the input
>to an authentication authority.
>
>- I think the policy balloons should largely be in the "Not SAML" layer
>above.  Or is the XACML discussion precisely about whether some of these
>balloons should be in scope?  Can we give distinct names to the different
>types of policies?
>
>- What exactly do the input/output letters above refer to?
>
>- I think we *may* have consensus that the "SAML" box should cover more
>stuff to the left, e.g., it should cover the authentication
>authority.  Comments?
>
>- Do we have consensus that SAML should cover the PEP box?
>
>Thanks to Fred for making this version; I think Hal and David should now
>take up any revisions we ask for.
>
>         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

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-services-request@lists.oasis-open.org