Scalable Community Trust Infrastucture (1G)

Session Topic: Scalable Community Trust Infrastructure (T1G)

Convener: RL “Bob” Morgan

Notes-taker(s): Dave Burhop, RL "Bob"

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Bob led a discussion to describe motivations behind and benefits of the trust architecture used by the 30+ Research and Education federations around the world. These talking points were the discussion starters:

• Organizations exist in communities of similar or partner organizations; these are sometimes called verticals, or sectors, or industries.

• These communities have existing business trust relationships, and often have established trust-management organizations and processes.

• These relationships and processes are the obvious basis for building inter-organizational technical trust infrastructure, rather than creating new organizations and processes for this purpose.

• Commercial trust services (primarily public certificate authorities) have inherent weaknesses in providing appropriate trust services to these communities of organizations. Extended validations

• Research and education organizations in most industrialized countries have existing support institutions: national networking organizations, accreditation agencies. These institutions have stepped up to operate trust infrastructure for web SSO, certificate services, and wireless roaming.

• REFEDS.org (Research & Education Federations) is the consortium of organizations operating community trust infrastructures for R&E, in more than 30 countries world-wide.

• R&E federations have, starting in about 2005, set up quite similar national-level trust management systems for supporting web SSO and authorization. These systems securely create, maintain, and distribute SAML metadata describing all federation participants. Metadata contains keys, names, endpoints, capabilities, etc, and is consumed by participant server sites, enabling multi-way federation.

• Q: Have there been any security failures in this self-managed infra?
• A: It was noticed at some point that not having expiration dates on signed metadata files was a security problem. So now files are dated, and software rejects expired files.

• Q: Aren't these monolithic metadata files a scaling problem?
• A: Not really. InCommon Federation has 800+ entities, UK Federation has 1300+. We recognize that more scalable metadata distribution will be needed, and support is coming. MDX (MetaData Exchange) is a proposed protocol. An overall architecture similar to the DNS, with registrars, registries, publishers, and consumers is the vision. DANE/DNSSEC could be a supporting technology.

• All communities intersect in multiple ways, and organizations participate in multiple communities. So today some orgs join multiple federations, which works well enough but again isn't scalable. Building a global interfederation mesh is the next challenge. There are some early examples in Europe. The US and the UK are talking.

• As we know at IIW, it’s all about user claims/attributes, not (just) authentication. Part of R&E federation infra supports namespace controls for some attributes, so that, for example, the University of Washington can't successfully assert "student@mit.edu".

• Q: Is this compatible with NSTIC proposals?
• A: We think so.