RE: Agenda for Security Services TC 20 March 2001 telecon/Comments onUC Domain Model

["Eve L. Maler" <eve.maler@east.sun.com>]

I'm really pleased about the level of comments I've been seeing on the 
models.  It feels like we're getting somewhere good!  Thanks to Krishna for 
making some specific doc suggestions below.  Here are some responses from 
me (chair hat mostly off).

At 03:53 PM 3/17/01 -0800, Krishna Sankar wrote:
>         0.      The top-level/driving document would be the Architecture
>Document(a.k.a.Core group V model)

Keep in mind that at F2F #1, we agreed to put an "architectural model" 
chapter before the Core Assertions chapter.  The conceptual/model 
information is global to the entire specification.

>         1.      The UC Domain Model should contain the sum of all actors 
> and all relevant entities from the use cases.

So you're suggesting that the UC Domain Model should be the "base" on which 
we should work, to reflect any modifications suggested by the other 
diagrams?  We can see how the group feels about this today.

>         2.      It also should contain *ALL* the assertions which are 
> exchanged between these entities. As Hal/David pointed out, this gives us 
> all the assertions we need to model.
>
>         3.      Then the Hal/David diagram would be added to Section 3. 
> of the
>Architecture document (a.k.a. Group V Model)
>         3.a.    At this point, we would need to have a single glossary, and
>definitions.

I agree about folding all definitions together.  I have to say I also agree 
with the several comments (and the F2F #1 instructions) suggesting that the 
glossary should get rid of peripheral terms.  I'll post my belated 
suggestions along these lines in a moment.

>         4.      We would need to add text to define and explain the 
> relationships and the assertions at an Architecture level in Section 3. 
> The current Section 4 would be consumed as a sub-section here.

I'd want to move some of the Section 3 stuff into the "conceptual 
chapter."  I suspect that Chapter 4 (Constraints) should become part of the 
separate Requirements document!

>         5.      The protocol section (a.k.a Protocol group model) 
> (Section 5) then elaborates the protocol for these exchanges, including 
> the acks and other biz signals, as required. (Now I see the rationale 
> behind the two groups merge more clearly (duh !))

I tend to agree with this.  The Protocol chapter can introduce a few more 
concepts that are specific to its layer.

>         6.      We would need to merge the Model sub-section of the 
> protocol group document in Section 2/3 of the Architecture Document. The 
> Architecture doc now does not have the concept of security domains and so 
> we should be
>able to do a straightforward merge.
>
>         7.      The data structures in the Protocol group Model document 
> (model section) need to be reconciled with the assertions in the UC 
> domain model. After all, we are concerned about these data structures and 
> their manifestation.

We'll be discussing this today: Should we pick one model as a base, and 
modify to incorporate all the good ideas of the others?  Or is it useful to 
have multiple "views"?  (After doing a more thorough review, I tend to 
agree that folding into a single one is a good idea.)

>         8.      Of course, we would merge the Group V model and example 
> documents.

Yes, I would think so.


>         9.      At this point, we should have one combined document, 
> which could be version 0.1 of the SAML specification.

We should all (in our subgroups and otherwise) be working towards 
contributing fresh sections to Bob Blakley so that we have a new SAML draft 
ready to review at F2F #2.  I suspect that we'll be coming out with drafts 
more often after that point.

>         10.     To tell the truth, now I am totally confused ;-) Hope it 
> all make sense

Not too bad! :-)

>         11.     I am sure all of us would have the documents in front of 
> us during the con call. I will also have a printed copy and could mark-up 
> the changes as the discussion progresses. (Not a good idea for all of us 
> to print copies - too many dead trees ;-0)

Since you'll be the designated "backup secretary" for Heather (as she's in 
a weird time zone for the call), you'll have the opportunity to do just 
that, and thanks for the offer.  Note that if the TC votes on any specific 
changes to documents owned by subgroups, they will be responsible for the 
changes.

         Eve
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com