Call - December 10 - 2009

1) Roll

Scott Cantor
David Chadwick
Paul Madsen
Hubert Le Van Gong
Conor Cahill
Peter Davis
George Fletcher

2) Update on quorum management

We have completed the initial quorum management poll in order to note the starting quorum of the group.

Additionally, we are now tracking attendance in order to allow us to manage quorum

Status maintained at http://kantarainitiative.org/confluence/display/idwsf/Participant+Roster

3) Approve minutes from Nov 30 call

http://kantarainitiative.org/confluence/display/idwsf/Call+November+30+2009

Approved

4) WSF Discovery Service enhancement request

David summarizes his two-fold request for WSF enhancement

1. Addition of an LSAggregation Attribute
When we perform attribute aggregation, we use a Linking Service (LS) that holds links to a user’s various IDP accounts. When the user is redirected to an authenticating IDP by a SP, the authenticating IDP optionally returns a Referral to the SP along with the user’s attributes. This referral points to a Linking Service that knows about the user’s other IDP accounts. This referral is encoded as an EPR which points to the Discovery Service of the LS which holds links to (some of) the user’s other IDPs. When the service type of an EPR is Discovery Service, the EPR’s <ds:ServiceType> element is set to the urn for a discovery service. The ServiceType is a required attribute in all EPRs as it tells the SP what protocol to query with. The SP uses this to construct a Discovery Query message to the LS.
The LS uses the EPR to look up the user in its database, and obtain details of the linked IDPs. The LS may perform attribute aggregation itself or the SP may wish to do it itself. In the former case the LS returns a response containing the EPR of its own attribute service. The standard SAML attribute authority urn is used as the service type. In the latter case, the LS returns Referrals to the linked IDPs as the Discovery response. The standard Discovery Service type urn is used as the service type. The SP now knows whether to construct additional Discovery Query messages to the linked IDPs or a SAML attribute query to the LS.
In order to correctly drive the LS, the enhancement we require is the addition of a LSAggregation Boolean to the Discovery Query message. This Boolean is optional and has the default value of False. When set to True it tells the LS to perform the attribute aggregation itself (in which case the LS returns the EPR of its AA aggregation service). When set to False or missing it tells the LS to let the SP do the aggregation (in which case the LS returns the EPRs of the linked IDPs).
When the SP contacts the discovery services of the linked IDPs, these IDPs return the EPRs of their AAs, so that the SP then creates a SAML attribute query to them. If the LSAggregation Boolean is absent from the request the IDP will behave as now. If the LSAggregation Boolean is present (with value true or false), the IDP will ignore it since it is not a Linking Service. In this way, the SP does not need to know if it is talking to a LS or IDP since they both respond in the same way.
2. Combination of Discovery Query message and Attribute Query message
The current design requires two round trip messages between the SP and LS or SP and IDP. This is time consuming and expensive (as anyone who tries our demo will find out). It is also unnecessary since the EPR returned to a Discovery Query points to the local AA which is then contacted in the next message with an attribute query. What would be nice is a way to combine a discovery query message and an attribute query in one message. In this way we can halve the number of message exchanges with a consequent improvement in performance. The new Disco Attribute Query message would ask the Discovery service to ask its internal attribute authority to pick up a set of attributes, and these would be returned in the Disco Attribute response message.

After discussion, group requests David send to list full sequence diagrams

5) AOB

Next call Thursday Dec 07 at 10 am EST