Re: Inputs to Strawman/Issue List - Group 2: B2B Scenario Variations

[Evan Prodromou <evan@outlook.net>]

>>>>> "OD" == Orchard, David <dorchard@jamcracker.com> writes:

    OD> There's options missing from each issue:
    OD> x) Drop this issue/scenario/requirement
    OD> y) Seek further clarification

If you check the issues list, you'll see that when I added these use
cases the option "Don't add this requirement" is included. I think
Zahid read the "Potential Resolutions" in the parliamentary sense,
e.g. "We, the Use Case and Requirements Subcommittee, do hereby
resolve....". Whereas I've taken it to mean -- and I think you meant
originally -- "Here's a list of things we can do to fix this problem."

I find the "seek further clarification" option kind of lame. I mean,
shouldn't we be clear before we go to a vote? If someone isn't clear
on an issue, then they should ask for clarification from the issue
champion before it even gets to the voting stage.

    OD> What I suggest is that the scenarios you propose should have
    OD> some clearly delineated sections so that we could vote on
    OD> portions. 

It'd be nice if we could try to maintain a one-vote-per-issue
effort. If there is more than one vote, then there should be more than
one issue. There's nothing holy about the issue numbers and names.

Zahid, if you don't mind, could edit the use cases so they don't do
credential exchange through SAML? If you look at the other use case
scenarios, they have kind of big blobby "Authenticate" steps that are
undefined.

That is, unless you strongly believe that SAML should have credential
exchange, and that your use cases won't work without it (I don't
agree). I'd predict if you stick to this, though, your very useful use
case scenarios won't get voted in to the document.

    OD> On the session mgmt, I broke them up - the general notion of
    OD> session management - and specific step sets.  Some people
    OD> wanted session with timeouts, some wanted session with
    OD> logouts, some wanted session with logouts and timeouts.

? My take away from your rewrite of Group 3 was that sessions were a
monolithic concept, and that doing separate requirements for logout,
timeout, and etc. were not required. Let me quote:

        "ISSUE:[UC-3-03:Logout] Should SAML support transfer of
        information about logout (e.g., a principal intentionally
        ending a session)? [DavidO: Isn't this covered in UC-3-1? I've
        kept here for backwards compatibility]"

So I'm not sure I get your point.

~ESP