moderated by Hans and Rainer
Notes by Brook and Peter
Attendees: 25
What are we trying to solve?
What is the problem?
We don't have a solution but lets better define the problem.
Scaling to multiple entities isn't the only problem. There is also dealing with multiple federations. This is implied rather than expressed in the scaling.
Dynamic vs static.
This isn't an issue unique to SAML. This will be a problem with OpenID Connect.
The description of SAML end points doesn't convey trust.
If the SAML metadata is signed by a trusted 3rd party then it is trusted.
OpenID may have more self asserted end points.
PKI is used a lot in this model and does work. Why would this not work?
four solutions at hand:
static metadata aggregation (using PKI certificates)
Proxy (Hub and Spoke federations)
PKI for endpoint authentication
PGP web of trust model
Do SAML fed and OpenID connect fed have the same problem? They are at least similar.
METADATA X
PROXY
PKI
or
SAML
OIC
--> SAML/MDX eduGAIN layered trust starting at technical trust. Then there are additional layers on top. There can be different behavioral patterns on top. SPKI attempt in the IETF tried to solve the problem In eduGain the group chooses whether a new member can join. The completendes of the metadata is checked. Two phases technical checking first and organizational agreement then. It is a relative homogeneous group in higher ed, thus trust routing is easy The business community has a different pattern with bilateral, multilateral and consortia agreements. Tennis club example. in Network world (BGB) you state from whom you accept packages. Such a model just works for one club. In the industry orgs are member of many federations, its not ine club but a bunch of clubs. There are two levels: Contracts and technical issues (SAML protocols, semantics of attributes) Could a broker be a solution (federation as a business). Third trusted party. A technical proxy will not scale world wide. On the organizational level it might. TTP can standardize and make sure to have a code of conduct. Problems addressed here is things like certificate renewal, expired keys etc. Initial technical and organizational pains will be there anyway. In REFEDS a new approach is discussed: when joining a federation you just give a pointer where the federation can retrieve the metadata. Choice of registration authorities We cannot solve the problem of global trust. O'Reilly Safari online participates in many federations. But the members of safari aren't in the same club. Is that a problem? The members don't need to communicate. Is it a problem for safari to manage these relationships. Costs for establishment of relationships. Sample from CISCO: have 600-800 federation-like vendor relationships; each costs avg. 40,000$ Services need to join a "SkyTeam Alliance" for common participation on technical level. Metadata isn't fixed. Cert rollover or URL changes for end points. Federation membership doesn't necessitate metadata publishing. That can be sourced from a RA. REFEDS PEER and the service REEP. http://reep.refeds.org Multiple federations will exist. The federations will be like Star Alliance. Step 1. Delegated authN (was federate). Step 2. Standardise. Step 3. Alliances. (Sectors) Step 4. Interfederate (peers) Integration costs are high. Verification is likely to be an activity of the certificate vendors. Sector wise MDX to converge over time (for technical trust in DNS-like hierarchy) N*M vs N+M but this isn't global. (N+M)+(N+M) global (these are peers) vs DNS which is a hierarchy. Interfederations can be a model. (group of star alliance). Standardization is essential. Breaking down federation in different services: membership registration metadata aggregation certificate management change management … How can the single clubs interoperate? Either by many peers, or in a more hierarchical DNS like model (DNS sec of course). Metadata structures and policies may differ too much to connect two clubs. Big companies could force their suppliers to join a federation (using the same TTP). SAML and OIC would both work (just like different MIME types) A common technical implementation base is needed. Technical details might bring problems There is a Geant3 work package on trust model lead by Roland, that could take up this work. WAYF.dk have a costing system. There costs are low in comparison with enterprise because they are always doing this integration. Does OpenIDConnect vs SAML require multiple trees? No. The opposite. The technologies are different but the payload is similar. Do we need a global group? Not yet. Local and sector specific groups need to work on this and then come together for a common forum. Summary: There will not be a single global metadata exchange facility. So first start with sector wise Metadata exchange to converge over time. TTP could be a viable business model since it could make the membership in federations cheaper. For technical trust the DNS model might be doable, but the hierarchy must not be global initially (discussion cont' in lunch break)
