RE: SAML InterOp Datasheet

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Hi Carol - I don't hae anything to add to Steve's comments re: the iop
flyer.

One comment on the datasheet for the bags:  Technically, SAML v2.0 is
not YET an "OASIS Standard".  The Committee Draft has been submitted for
a standardization vote, but unfortunately, that vote will just be
starting around the start of the conference and will end at the end of
Fed.. 

Rob Philpott
Senior Consulting Engineer 
RSA Security Inc. 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com


> -----Original Message-----
> From: Steve Anderson [mailto:sanderson@opennetwork.com]
> Sent: Thursday, January 13, 2005 4:03 PM
> To: Philpott, Robert; Carol Geyer; Dee Schur; samldemotech;
> samldemomktg@lists.oasis-open.org;
samldemoprimary@lists.oasis-open.org;
> prateek mishra
> Subject: RE: SAML InterOp Datasheet
> 
> Note that I didn't touch the FAQs, which need updating.
> --
> Steve Anderson
> OpenNetwork
> 
> 
> > -----Original Message-----
> > From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
> > Sent: Thursday, January 13, 2005 3:55 PM
> > To: Carol Geyer; Dee Schur; samldemotech; samldemomktg@lists.oasis-
> > open.org; samldemoprimary@lists.oasis-open.org; prateek mishra
> > Subject: FW: SAML InterOp Datasheet
> >
> > Thanks Steve!
> >
> > Hi Carol - I haven't had time to look at the sheets, but Steve was
> able
> > to.  I'll let you know if Eve comes back with any comments.  I can't
> get
> > to this myself until tomorrow or the weekend.
> >
> > -----Original Message-----
> > From: Steve Anderson [mailto:sanderson@opennetwork.com]
> > Sent: Thursday, January 13, 2005 2:18 PM
> > To: Philpott, Robert; Eve L. Maler
> > Subject: RE: SAML InterOp Datasheet
> >
> > The datasheet looks fine.  The flyer is obviously last year's, and
> needs
> > wholesale updating.
> >
> > I expect that Carol can update the description of the event and
> > participants herself.  Here's a pass at updating the scenario
> > descriptions:
> >
> >
>
------------------------------------------------------------------------
> > ---
> >
> > The main scenario being demonstrated is a combination of Web Single
> > Signon, and Single Logout.
> >
> > During Signon, the user authenticates at a chosen Identity Provider
> and
> > is granted access to resources at various Service Providers without
> > needing to reauthenticate.  The actual flow of this part of the
> scenario
> > can take one of three different forms:
> >
> > 1.  The user starts at an Identity Provider.  After logging in, the
> > Identity Provider site displays a portal page containing links to
> > external resources.  When the user clicks one of those links,
identity
> > information flows from the Identity Provider to the specific Service
> > Provider, and the Service Provider will authorize and provide the
> > requested resource according to its security policy.
> >
> > 2.  The user starts at a Service Provider.  The Service Provider
needs
> > to identity the user, and offers either local login or a list of
> trusted
> > Identity Providers.  The user selects an Identity Provider,
> > authenticates with that Identity Provider, and returns to the
Service
> > Provider with identity information.
> >
> > 3.  The user starts at the eGov portal.  The user selects an
Identity
> > Provider and a Service Provider from the portal page, and is
> redirected
> > to the Service.  The Service can automatically redirect the user to
> the
> > previously chosen Identity Provider to authenticate.  Identity
> > information flows back to the Service Provider, and the resource
> request
> > is processed.
> >
> > During Logout, the Identity Provider will propagate the Logout
request
> > to all Service Providers that have been given identity information
for
> > the user in the current session, allowing them to cleanup any local
> > session data.  The actual flow of this part of the scenario can take
> one
> > of two different forms:
> >
> > 1.  The user logs out at the Identity Provider.  The Identity
Provider
> > notifies all affected Service Providers, and then terminates the
user
> > session at the Identity Provider.
> >
> > 2.  The user logs out at a Service Provider.  The Service Provider
> > terminates the local user session, and then propagates the logout
> > request to the Identity Provider that authenticated the user.  The
> > Identity Provider notifies all other affected Service Providers, and
> > then terminates the user session at the Identity Provider.
> >
> > An additional scenario being demonstrated by some participants shows
> the
> > steps of federating and defederating accounts.
> >
> > Federating accounts is generally a first-time setup step.  The user
> > initiates the federation operation (at the Service Provider, in this
> > demonstration), authenticates at both the Identity Provider and the
> > Service Provider, and then the two sites negotiate a unique
identifier
> > for the user, which isn't reused at any other site.  Subsequent
> sessions
> > for that user to flow just like the main scenario.
> >
> > When the user defederates accounts (at either the Identity Provider
or
> > Service Provider), the relationship between the user's account at
the
> > Identity Provider and the user's account at the Service Provider is
> > eliminated.
> >
> >
>
------------------------------------------------------------------------
> > ---
> >
> > Feels a bit verbose for the target medium, but we can talk more
about
> > that.
> > --
> > Steve Anderson
> > OpenNetwork
> >
> >
> > > -----Original Message-----
> > > From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
> > > Sent: Thursday, January 13, 2005 10:40 AM
> > > To: Eve L. Maler; Steve Anderson
> > > Cc: Philpott, Robert
> > > Subject: FW: SAML InterOp Datasheet
> > >
> > > Would you guys have time to look these over and provide feedback?
> > >
> > > Thanks!
> > >
> > > Eve - I hope to get the SAML specs to you for a review in a couple
> of
> > > hours.  I was working very late last night (um - this morning) and
> > just
> > > couldn't quite finish them up.
> > >
> > > Rob Philpott
> > > Senior Consulting Engineer
> > > RSA Security Inc.
> > > Tel: 781-515-7115
> > > Mobile: 617-510-0893
> > > Fax: 781-515-7020
> > > mailto:rphilpott@rsasecurity.com
> > >
> > > -----Original Message-----
> > > From: Carol Geyer [mailto:carol.geyer@oasis-open.org]
> > > Sent: Thursday, January 13, 2005 9:29 AM
> > > To: 'Dee Schur'; 'samldemotech';
samldemomktg@lists.oasis-open.org;
> > > samldemoprimary@lists.oasis-open.org
> > > Cc: Philpott, Robert; 'Mishra, Prateek'
> > > Subject: RE: SAML InterOp Datasheet
> > >
> > >
> > > I've drafted a basic SAML datasheet
> (OASIS-saml-datasht-ltr-04-12-21)
> > > that we might want to include in the package. Rob, Prateek,
> > > please review and send me edits. Whether or not we use this at the
> RSA
> > > Conference, I'd like to post it on the OASIS site, so people
> > > can download it.
> > >
> > > We also have the OASIS InterOp sheet that was prepared for the RSA
> > > proceedings bags (SAML-RSA-InterOp-05-01-04). It lists all the
> > > participants, but doesn't say much about the scenario.
> > >
> > > It would be great to have something along the lines of last year's
> > flyer
> > > (SAMLinterop-flyer). If someone can send me content, I'd be
> > > happy to lay it out.
> > >
> > > Thanks,
> > > Carol
> > >
> > > -----Original Message-----
> > > From: Dee Schur [mailto:dee.schur@oasis-open.org]
> > > Sent: Wednesday, January 12, 2005 8:13 PM
> > > To: 'samldemotech'; samldemomktg@lists.oasis-open.org;
> > > samldemoprimary@lists.oasis-open.org
> > > Cc: Carol Geyer (Carol Geyer)
> > > Subject: SAML InterOp Datasheet
> > >
> > > Hi,
> > > The technical call today was extremely productive. One task that I
> > > failed to mention was the general SAML datasheet that will be
> > > presented during the press event (in a package with all vendor
> product
> > > collateral) and available to the general public during the
> > > demo. This datasheet will describe the Standard and the InterOp
> > > scenario.
> > > This is a great tool but someone must take on the responsibility
to
> > > create this piece to be vetted by the OASIS SSTC and the OASIS
> > > Director of Communications.
> > > Please contact Robert Ciochon and Andy if you would like to create
> > this
> > > document.
> > > Thanks!
> > > Dee
> > >
> > >