OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-leaders message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Minutes of 18-19 April 2001 Security Services TC F2F #2

At 05:10 PM 5/14/01 -0700, Platt, Darren wrote:
>Hi all-
>The 'only' action I got coming out of F2F2 was:
> > ACTION: Darren Platt to update the requirements document to
> > reflect F2F #2 decisions and publish as a consensus draft ASAP.
>I just want to make sure that I have the same idea as to what this means as
>everybody else.  I only see one thing in the minutes which requires a change
>to the requirements doc, so I wanted to double-check with you.  It's related
>to the session requirement - basically to apply the sentiments of the group
>represented by the following polling:
>I think the only clear results are in the last poll, and the best way to
>reflect that would be to basically take option 3 and represent it as a goal,
>and options 4 and 5 as non-goals.  Here's a shot at it:
>[R-UserSessionLogin] The SAML specification shall include support for the
>Login scenarios described in Scenarios 1-1, 1-2, and 1-3 of the requirements

It feels a little weird to have forward references to actual scenarios in 
the requirements.  Would it be acceptable to say "[R-UserSessionLogin] The 
SAML specification shall include support for Login functionality" and be 
done with it?

>[R-UserSessionLogout] In creating the SAML specification the TC will do the
>prep work to ensure that logout, timein, and timeout will not be precluded
>from working with SAML later, and commit to doing these other pieces "next"
>after SAML 1.0.

I would stop after ", and commit to...".  This is process stuff rather than 
requirements, and we can put that in the introduction to the spec somewhere.

>[R-UserSessionsWillNotScrewThePooch] The TC will not design timeout/logout
>mechanisms for the September release date because of schedule risk.


I wouldn't make this a non-goal; we've got a whole subcommittee working on 
a draft design in order to satisfy the requirement above...

>I will also need to change the second Scenario 1-3 to be 1-4 :).  I didn't
>think I should remove the logout from this scenario (which will now be
>called 1.4), as I believe that part of the work which needs to be done to
>satisfy the second requirement above.  I realize that there may be other
>opinions, though, and so ask for your feedback.

Perhaps you could add some text that makes part of the scenario clearly 

The other thing that's important to do is to indicate up front somewhere 
that this is a draft that has gotten the approval of the TC.  This is a big 
deal (to me, anyway), and once the draft is available in the doc 
repository, I'd like to send out notice of it to various places (the OASIS 
chairs list, internal Sun review lists, etc.).  We might even get some 
press out of it.

Perhaps we should let the leaders review it for a couple of days (or even 
the whole TC) before putting it in the repository.  If we keep the review 
cycle short, it shouldn't get in our way too much.

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC