[saml-dev] Minutes for Tuesday's call

Please send along corrections or additions!

Attendees (I'm sure I messed up the spelling for some of these - sorry):

Rob Philpott - RSA Security

Prateek Mishra - Netegrity

Hal Lockhart, Ryan Eberhard - Entegrity

Don Bowen, Bahazna Bhatnagar - Sun

Irving Reid - Baltimore

Jahan Moreh, Sayan Chakraborty - Sigaba

Charles Knouse - Oblix

Don Flinn - Quadrasis

Ken Yagen, Mingda Su, Andrew Fetterer - Crosslogix

Ben ? - Tivoli

ACTION ITEMS:

1. Prateek - Send out updated B/A Profile document

2. Don Flinn - Write up and send to the list a proposal for using SAML in the mid and back-end tiers.

3. Ken Yagan - If others are interested, work with those vendors and develop a concrete, detailed proposal for demonstrating authorization decision statements.

4. Hal - Write a proposal for displaying interesting info to show what's happening behind the scenes with SAML.

5. ALL Participants - Indicate on the mailing list whether they prefer all participants stick to just the core interop demo or whether they are fine if some subset of vendors demonstrate additional capabilities beyond the Browser/Artifact Profile.

6. RSA and Sun - Ensure that systems are protected from the internet during the dry run.

7. Bahazna Bhatnagar or Don Bowen - Follow up on whether Sun will participate in both dry runs.

8. ALL - Send dumps or traces of requests and assertions to the list. This will let folks check for ambiguities prior to the dry run.

AGENDA ITEMS:

> 1. Clarify all actions related to finalizing technical focus

> As Hal and I both have said in recent emails, we must start

> making final decisions on what will be tested and by who.

> This needs to be at a sufficient enough detail so that there

> are no doubts. I have a small fear that we might include too

> much, as Prateek warned in the beginning. However, I have a

> bigger fear that we won't include enough or that we will

> "agree" to include something, but because of the lack of

> detailed communication about what that means someone will be

> left out. We absolutely must avoid either of these

> scenarios. Personally I believe that browser profile is not

> enough, but discussions on other aspects have not been

> sufficient. I'm not even sure the browser profile details

> are sufficient. This is our highest priority.

Prateek published a document describing the Browser/Artifact Profile flows for the demo. Some comments were received and an update will be sent out soon.

There was quite a lengthy discussion of possible extensions to the interop demo functionality. This fell into several categories:

1. Using SAML in the mid-tier or between the mid-tier and back-ends.

Qaudrasis is interested in a scenario that involves using some vendor's B/A profile for authentication and then performing an AttributeQuery to another vendor's authority. Several interesting points were raised during the discussion:

a. The current B/A Profile proposal involves a single assertion containing both an AuthenticationStatement and an AttributeStatement.

b. Some vendors (Baltimore, Sun, etc) did not interpret B/A Profile as a 1-step process. They were planning to use a 2 steps. First they would use the artifact to obtain an assertion with a single AuthenticationStatement. They would then take the Subject from that assertion and make a separate AttributeQuery.

c. ? Doesn't the SSO assertion specify inclusion of attributes? No.

d. Rob - Will the 1-Step SAML Request include RespondWith elements identifying the 2 statements required by the response? Hal - yes.

e. Hal - If folks have a general SAML SOAP Binding responder, then the demo could be changed.

f. Some vendors (Entegrity, RSA, Netegrity) plan to eventually provide support for the 2-step approach, although they probably will not be ready by the interop date. They (and Tivoli) were in favor of keeping the 1-step exchange for the interop.

2. Support for Authorization Decision queries and statements.

a. Ken Yagen asked whether authorization queries will be supported. Very few vendors will have this ready. If this is desired, a concrete proposal is needed ASAP.

3. Providing visual feedback of the SAML activities going on behind the demos.

a. Hal - One idea would be to reserve a component of the screen to display info showing what is going on with SAML (e.g. where authenticated, your attributes, etc.) Hal will propose something more specific.

4. Using the Browser/POST profile

a. Sigaba is interested in B/P Profile.

b. Several vendors (Sun, Entegrity, RSA, Baltimore) have it in their plans, but don't expect to have it ready for the interop.

c. Prateek - Doing it without DSIG is dangerous and this greatly complicates the scenario.

> 2. Review dry-run configuration details as proposed by

> Robert Philpott from RSA

> There has just been too little of this thread for me to feel

> good, but I don't think it should take much to have

> something we can go with for both east and west coast

> dry-runs.

Looks fine.

Hal - We don't really need inbound traffic. It just opens our systems up to attack from the internet.

Rob - the systems will be behind a firewall and will be protected.

Irving - we're also running on a non-routing subnet so that limits our exposure.

> 3. Review which companies will attend and where

> This information is in the spreadsheet I've been

> maintaining, but won't hurt to review

Everyone needs to ensure that Don's spreadsheet is correct.

Rob - Has email (Aravindan Ranganathan [mailto:aravind@sun.com]) indicating Sun would like to participate in dry runs on both coasts. Need someone to confirm.

Systinet may have dropped out.

> 4. Check status on marketing progress

> I don't know that anything is going on in this area and that

> has to change quickly. I will talk to our marketing person

> this week, but we almost need a marketing point person. They

> don't have to know everything, just take responsibility to

> make sure discussions are taking place and sufficient

> progress is occurring to insure success for that element. If

> we fail here, we fail :-)

We're leaving this one for Don to follow up.

> 5. Review status on each vendor's SAML development

> Not a big deal, but we should just insure that dates in the

> spreadsheet and associated capabilities are still valid.

Post to the list making sure the supported functionality in the spreadsheet is correct.

> 6. Discuss internet testing, who may participate and how

Entegrity and Baltimore are trying it - should be another week before they're ready.

saml-dev message