RE: [saml-dev] Con Call Tuesday 4/23

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

I agree with Prateek on this one.  I feel that proving interop just for Web
SSO is a fairly large task and we have relatively little time to complete
it.  I don't know about everyone else, but working on the interop is only
one piece of my and my team's job.

Hopefully, folks aren't underestimating the work required to make this
happen.  If we can do web SSO and use some attribute statements as well, I
think we will have been very successful, indeed.  Once we get this working,
we can evaluate whether there's time for anything more.  Perhaps some of the
attendees have an interest in demonstrating some additional, but optional,
interoperability features.  I don't object to that, but I wouldn't want it
to take time away from getting the key stuff going.

Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com


> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Monday, April 22, 2002 10:18 AM
> To: 'Don Bowen'; saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] Con Call Tuesday 4/23
> 
> 
> >>- Discuss the technical focus
> >>  - We have agreed that browser artifact is at least one
> >>aspect of the demo
> >>  - If we are going to do anything with authz decision
> >>assertions we will need a clear proposal and I think all of
> >>us would like to see this happen
> >>
> 
> I will like to express my serious reservations with a broad expansion of
> the
> demonstration described in the document draft-catalyst-interop-plan-
> 00.doc.
> I would view
> use of AuthZ statements AND inclusion of the PEP-PDP protocol as an
> extremely broad expansion.
> 
> The flows I have described in the plan are at a high-level. It will some
> work to make them concrete. We haven't done this work yet!!
> 
> Here are some issues that need to be addressed:
> 
> (1) What is the exact format of the SAML assertion transferred between
> "portal" and content-site?
> 
> In particular,
> 
> 	(a) Must certain optional SAML elements must be used?
> 
> 	(b) For the SAML elements which must be present, are there specific
> values or formats that must be used? Examples, include
> <AuthenticationMethod>, <NameIdentifier> etc,
> 
> 	(c) If attributes are present (and I think they should be!), what
> are they? What should their values be?
> 
> 	(d) Will we use a DSML2.0 version of a standard LDAP schema such as
> InetOrgPerson for the attributes?
> 
> (2) Which browser type and versions due we plan to test with?
> 
> (3) In Steps 4 and 5 of the browser/artifact profile, the content-site and
> portal must mutually authenticate each other. I would suggest that the
> portal site use SSL (with a certificate -- who is the issuer for this
> certificate?) and the content-site authenticate using a password
> (Basic/SSL).
> 
> Is this acceptable? Do people want a stronger or weaker security
> interaction
> between content-site and portal?
> 
> (4) Exactly what are the negative and positive flows we will demo? These
> need to be called out in full detail. Without negative flows (e.g.,
> content-site does not
> allow access to certain content) the general public is not going to
> appreciate the demo very much.
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>