RE: Issue Group 1 - SSO - Straw Ballot

[Darren Platt <dplatt@securant.com>]

Anders,

> I definitely like the text you have written regarding the
> different issues!

Thanks, and I should say that I got a lot of help from Evan.


> Regarding the interaction diagrams I am sort of lost both due to
> too limted
> information of what is carried around by the arrows, and to
> slightly inconsequent descriptions.

The limited info about what is being carried on the arrows is intentional,
as we are attempting only to capture requirements.  While interaction
diagrams are often used to capture the type of detail you mention, we use
them here at a higher level of abstraction - attempting only to capture the
interactions between the actors as a way to communicate requirements.  I
suspect what is on the arrows will be determined in the bindings and
assertions working groups.


> An example of the latter is UnknownPartner.png where there are
> some verify and auth decision steps
> that IMO are relevant to all Web-user inter-domain auth* cases.

There are common elements to some of the scenarios that we have
intentionally not factored out.  That step seems to be more of a design step
than an analysis one, and as such is best left to the bindings and
assertions groups.  There is also an isssue in the document format issue
group called ISSUE:[UC-0-01:MergeUseCases] that is related to this point,
and there has beens some discussion on the concalls about the appropriate
level abstraction for these diagrams.


> Is this a Shibboleth use case BTW?

Actually, this is a second attempt to capture the requirement that Scenario
3 in Straw 2 intended to capture, but really didn't get the job done.


> The there is a mix of push and pull models that are hard to
> follow.  And are
> there any pros and cons listed?  I like to see the tradeoffs
> before I take a stand.

That is exactly what we need the working group members to tell us right now.
The idea is if you are in favor (or against) an approach, you must have a
reason why.  We are asking people to share those reasons on the list now so
that we can decide issues with all factors considered.  It has been agreed
that we need to get the bulk of our work done in this way because debating
on the conference calls wasn't a productive use of time.  At some point we
do need to make a decisions about how to refine this specification - all we
can do is give people a fair opportunity to express their opinions before we
do.


> It is hard to belive that we really are ready to vote on
> Shibboleth issues given
> the limited dicussions on the consequences.  Personally I think the
> s.c. ARundgrenPush and a good Shibboleth design only have to
> differ in the initial steps.
> But this is not yet a fact as there may be things I don't know
> about Shibboleth.

We have broken the requirements added by Shibboleth into specific issues
which can be voted on, and attempted to be all inclusive.  If you feel that
we have missed some, the first issue of the ballot
(ISSUE[UC-1-01:Shibboleth]) is for you - please send in an argument about
why we should vote for potential resolution "2. Additional investigation of
Shibboleth requirements are needed."  I will include the argument in the
ballot, referencing your name if you like (so that others may follow up with
you).  What would be even better was if there were specific requirements you
had in mind, in which case we could potentially add them to the issues list,
reference them in the ballot, and then move forward with the voting.

I share your concern about the lack of discussion, on Shibboleth and some of
these issues.  Our only hope for such discussion is if the concerned parties
express their opinions on the mailing list.  If people do not express such
opinions we can only assume that they don't have any which have not already
been expressed.  Which is okay too perhaps - it should make for easier
consensus - as long as everyone has taken the time to have an informed
outlook.  People will be given ample notice (considering our tight schedule)
to express their opinions and become informed.

So now that I've said all that, I guess I'd better at least give my opinion
on the Shibboleth issue.  I feel that we did capture all of the requirements
related to Shibboleth, and plan to vote for Proposed resolution 1.

Regards,

Darren




> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Thursday, February 15, 2001 12:12 PM
> To: Darren Platt; UseCaseList
> Subject: Re: Issue Group 1 - SSO - Straw Ballot
>
>
> Darren,
> I definitely like the text you have written regarding the
> different issues!
>
> Regarding the interaction diagrams I am sort of lost both due to
> too limted
> information of what is carried around by the arrows, and to
> slightly inconsequent descriptions.
> An example of the latter is UnknownPartner.png where there are
> some verify and auth decision steps
> that IMO are relevant to all Web-user inter-domain auth* cases.
> Is this a Shibboleth use case BTW?
>
> The there is a mix of push and pull models that are hard to
> follow.  And are
> there any pros and cons listed?  I like to see the tradeoffs
> before I take a stand.
>
> It is hard to belive that we really are ready to vote on
> Shibboleth issues given
> the limited dicussions on the consequences.  Personally I think the
> s.c. ARundgrenPush and a good Shibboleth design only have to
> differ in the initial steps.
> But this is not yet a fact as there may be things I don't know
> about Shibboleth.
>
> Anders
>
> ----- Original Message -----
> From: "Darren Platt" <dplatt@securant.com>
> To: "UseCaseList" <security-use@lists.oasis-open.org>
> Sent: Thursday, February 15, 2001 20:13
> Subject: Issue Group 1 - SSO - Straw Ballot
>
>
> > Attached is a write-up of the issues related to SSO
> (IssueGroup1.txt), with
> > the goal of formatting them in such a way that it is possible to vote on
> > some resolution.  My goal is to vote on them on our call on
> Wednesday, where
> > people will be asked to choose one of the possible resolutions
> listed for
> > each issue (or abstain).  The attached issue group list is a
> text file, and
> > it contains references to the attached graphics.
> >
> > If there is some information or argument missing in these
> write-ups, please
> > let me know before end of day Friday so I can attempt to
> resolve it.  I hope
> > to then distribute a final 'ballot' on Monday which will
> contain writeups
> > for issue groups 1-SSO Variations, 3-Sessions, and 5-AuthC
> Protocols, which
> > we can then use to vote.
> >
> > I will be sending out a proposed subcommittee voting process
> for your review
> > today if possible - if not tomorrow.  If it seems workable to
> everyone, I
> > will propose this process on the call on Wednesday.  It would
> be great if we
> > could get most of the discussion out of the way on the list
> beforehand so
> > that Wednesday can be productive.
> >
> > Regards,
> >
> > Darren
> >
> >
> > Darren Platt
> > Principal Technical Evangelist
> > Securant Technologies
> > 1 Embarcadero Center, Floor 5
> > San Francisco, CA 94111
> > tel - (415) 315-1529
> > fax - (415) 315-1545
> > http://www.securant.com/
> > -----------------------------
> >
> >
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: security-use-request@lists.oasis-open.org
>