RE: [security-services] RE: IBM charter position

["Conor P. Cahill" <concahill@aol.com>]

Maryann, 

My responses are below.  Of course this stuff is my opinion.  I don't
know how well I am speaking for the rest off the SSTC.

Maryann Hondo wrote on 11/17/2003, 3:04 PM:

>   on bullet one, will there be
> (or is
> there, and I missed it) some collection of the issues and requirements
> that have been collected?
There will be a
collection of issues and requirements.. That's what the ongoing
collection of use cases is all about.  However, it would be
inappropriate to list this set of issues/requirements in the charter
itself, so to specifically answer your question:  No, there will not be
such a list "on bullet one".
>         (Conor,
> this is what gets confusing........Is OMA one of these providers of
> issues
> and requirements?)
I believe that
only participants (not necessarily voting members) are providing the
issues/requirements. 
> on bullet 3, do we need to define or
> at least illustrate what the "various identity federation models"
> are or could be?
I would say not...
that the discussion of this should take place within the SSTC and voted
on as appropriate.
>         (
> In my previous life with SAML several years ago,  we started to address
> Kerberos & Passport.....is this still part of the models?  )
The models need to
be presented as use cases and, as necessary, voted on.  I would expect
that voting will take place around scoping and priorities.
> Bullet one says its dealing with "real
> world" implementations of SAML....are we looking for a real world
> federation model as well?
I don't believe
that any federation model would be refused out-of-hand as long as it's
being submitted to the TC.  Obviously federation models that are not
available to the SSTC would not be under consideration.
> Will we include the WS* work ? 
If it is submitted
to the SSTC it certainly would be considered.  As it currently stands,
being an IBM/MS/etc. owned document that hasn't been submitted with the
associated IPR statements, I can't see how it would be considered.

Of course, you could submit use cases that are solved by the stuff
implemented by those documents, but I don't think that would limit the
solutions to matching what's in the documents (the SSTC would be free
to come up with whatever solution was necessary to solve the use case,
presuming the use case made it through the prioritization process).
> Do we
> agree that a ubiquitous standard for federation is desirable? 
I certainly agree
that this is desireable, as would, I believe, everybody else on the
list.  However, as far as I am aware, the various players involved in
the various federation efforts (and I purposely don't say 'federation
standardization efforts') are not yet ready for that to occur for
whateverr reason.   At this point, given the current situation, the
SSTC needs to have a solution that at least works in the environment of
SAML assertions (which is what this group is all about). 
> and that
> considering non-SAML federation is practical?  
I would say that
it is not the SSTC's job to document a federation process that is used
by other security token environments.  The SSTC should be primarily
concerned with documenting/specifying how federation works with SAML
assertions.
> Or,  if non-SAML federation is
> not in scope of SSTC (as you suggest)
>   
>    than is the goal of the SSTC
> to
>  define a SAML to SAML identity federation model?
I think the goal
of the SSTC is define mechanisms to enable the use of SAML assertions
for SSO and related operations.   I believe that federation is simply
the process of two entities negotiating a shared handle to be used on
those assertions and therefore is an essential part of that process.

So, assuming that federation is needed (as it appears the majority of
the SSTC believes), the question comes down to what federation models
will or should be considered.    At this point there is only one model
that has been submitted to the group, so the choices for the group are
somewhat limited.   If others existed as accepted standards, or were
contributed to the SSTC, I think they would receive appropriate
consideration.

Conor