1. Administering the Mesh/s of Trust: Old Whine in New Battles

2. Agenda unified theory of trust
global identity
federated-enterprise
P2P
untangling the concepts (trust/risk/liability/security/privacy)
update on current events (InCommon, InQueue, Usher, HEBCA)
trust and authorization - the Stanford approach
discussion

3. Trust fabrics Exists in almost every transaction between entities
Works in complex fashion
E.g. in an end-user-enterprise-target transaction,
user trusts enterprise to release attributes according to user preferences
Enterprise trusts user to protect their security credentials
Enterprise trusts target to properly dispose of attributes once they are used
Target trusts enterprise to faithfully provide attributes about the user
Trust itself is personal and subjective, though laws and contracts affect that.
One size didn’t fit all and proved intractable; several sizes seem more comfortable and may prove more tractable

4. Unified field theory of Trust
Bridged, global hierarchies of identification-oriented, often government based trust – laws, identity tokens, etc.
Passports, drivers licenses
Future is typically PKI oriented
Federated enterprise-based; leverages one’s security domain; often role-based
Enterprise does authentication and attributes
Federations of enterprises exchange assertions (identity and attributes
Peer to peer trust; ad hoc, small locus personal trust
A large part of our non-networked lives
New technology approaches to bring this into the electronic world.
Virtual organizations could leverage any of these fabrics

5. Federations and Classic PKI
They are very similar
Both imply trust models
Federations are a enterprise-enterprise PKI
Local authentication may well be end-entity certs
Name-space control is a critical issue
And they are very different
End user authentication a local decision
Flat set of relationships; little hierarchy
Focus as much on privacy as security
Web Services only right now: no other apps, no encryption
We get to define…

6. Update on current activities
Federations
Federation basics and federating software systems
InCommon and InQueue – Shibboleth-based federations
Other Shibboleth-based federations
USHER-C4 and USHER-Basic certificate services
HEBCA

7. What are federations?
Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions
Built on the premise of
Initially “Authenticate locally, act globally”
Now, “Enroll and authenticate and attribute locally, act federally.”
Federation provides only modest operational support and consistency in how members communicate with each other
Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision.
Over time, this will all change…

8. The good
Very flexible – easy to establish and operate; can work for 2 or 2000 members
Very customizable – tailored to fit the precise membership
Address the whole problem space – security, data schema, privacy, security, transport – of inter-realm collaborations
Are relatively simple to install and operate, both for enterprises and for end-users

9. The bad They aren’t real, yet They don’t do everything
Are web services based right now
Will hit scaling walls in several dimensions; we don’t see clear answers yet…

10. The unknown The scaling walls How reality will unfold
The convergence of the various federating software solutions
Users’ willingness to manage their privacy and security

11. Three Types of federation
Internal federations are occurring among the many subsidiaries of large companies, especially for those companies with more dynamic aggregations.
Private federations occur among enterprises, typically within a market sector, that want to facilitate a specific set of transactions and interactions. Many will be bi-lateral, short-term or otherwise constrained.
Public federations address more free-standing, long-term, general-purpose requirements, and need to be more open about rules of engagement. Public federations face significant scaling issues and may not be able to leverage contractual relationships that private federations can.

12. Requirements for federations
Federation operations
Federating software
Exchange assertions
Link and unlink identities
Federation data schema
Federation privacy and security requirements

13. Federating Software Liberty Alliance Shibboleth WS-*
V 1.1 of their functional specs released; 2.0 under discussion
Federation itself is out of scope (see PingID et al)
Semi-open source under development
Current work is linked identities
Shibboleth
V1.1 released; 2.0 under discussion
Most standards-based (though Liberty has said that they will turn their enhancements into standards organizations)
Pure open source
Current work is attribute release focused.
WS-*

14. WS-* Work by Microsoft, with participation from IBM and BEA et al
Complex framework, consisting of 9 areas, which can form a whole cloth solution to the problem space, but which need to closely interact with each other to do so.
Several of the specifications areas still unreleased
Standards process very unclear; significant IPR issues exist
No implementations yet; indeed a lofty set of abstractions that will need considerable convention and detail to resolve into a working instantiation
Can Shibboleth/InCommon be a working instantiation within WS-*? Good question. Once MS has all the areas defined, if someone wants to see whether the existent Shib/InCommon (or Shib/someotherfed) fits into WS-*, we’d certainly be curious…

15. Interoperability among federations
Or, more precisely, interoperability between two members of distinct federations
Ability to pass each other assertions
Protocols and architectures
Ability to understand each other’s assertions
Syntax and semantics of objectclasses and schema
Ability to trust each other’s assertions
Er……

16. Shibboleth-based federations
InQueue
InCommon
Club Shib
SWITCH
NSDL
State networks
Medical networks
Financial aid networks
Life-long learning communities

17. The Research and Education Federation Space
REF
Cluster
InQueue
(a starting point)
InCommon
SWITCH
The Shib
Research Club
Other national nets
Other clusters
Other
potential US
R+E feds
State of Penn
Fin Aid Assoc
NSDL
Indiana
Slippery slope
- Med Centers, etc

18. InQueue The “holding pond”
Is a persistent federation with “passing-through” membership…
Operational today. Can apply for membership via InQueue Federation guidelines
Requires eduPerson attributes
Operated by Internet2; open to almost anyone using Shibboleth in an R&E setting or not…
Fees and service profile to be established shortly: cost-recovery basis

19. InCommon A persistent, multipurpose federation for US R&E
Two stage set up process
Direction setting group to establish InCommon
Chaired by Greg Jackson, includes 5-6 campus CIO’s, 1-2 target CTO’s
Decisions on organizational structure, membership, management
InCommon going forward
Management group
Storefront and backend; fees
Operations
Operational date within a month or two

20. InCommon key issues
Who is the membership? Origins? Targets? Univ? Application or Content Service Providers?
How is membership packaged and priced?
How are membership covenants enforced?
How is InCommon operated?
What kind of entity is InCommon?

21. Trust pivot points in federations
In response to real business drivers and feasible technologies
increase the strengths of
Campus/enterprise identification, authentication practices
Federation operations, auditing thereof
Campus middleware infrastructure in support of Shib (including directories, attribute authorities and other Shib components) and auditing thereof
Relying party middleware infrastructure in support of Shib
Moving in general from self-certification to external certification

22. The CA formerly known as CREN
Lots of discussion for a looong time – HEPKI-TAG, HEBCA-BID, PKI Labs
Plan is finally emerging
A few related certificate services
USHER-C4 - soon
USHER Basic - start detailed planning for implementation
USHER CP
Others if warranted, eventually
All operate on high levels of assurance in I/A of the institution, and in their internal operation
Place varying degrees of pain, and power, to the institutions
Helping on a packaging of open-source low-cost CA servers
Work with EDUCAUSE on their related initiatives

23. Usher-C4
Modeled after Federal Citizen and Commerce CP/CPS (
Issues only institutional certs
Those certs can be used for any purposes
CP will place few constraints on campus operations
User identification and key management
Campus CA/RA activities
Will be operated itself at high levels of confidence
Will recommend a profile for campus use
Good for building local expertise, insuring some consistency in approaches among campuses, and may be suitable for many campus needs and some inter-campus uses
Will not work for signing federal grants, etc…
Operational soon

24. Usher-Basic Modeled after FBCA Basic level CP
Issues only institutional certs
Those certs can be used for most purposes
CP will place more constraints on campus operations
User identification and key management
Campus CA/RA activities
Will be operated itself at high levels of confidence
Will recommend a profile for campus use
Good for many campus needs, many inter-campus uses, and many workings with the federal government
Will peer at the HEBCA
Detailed planning now starting; stand up sometime mid-next year

25. HEBCA A higher education equivalent of the Federal Bridge
Constructs policy mappings and cross-certificates among peers
Peers are assumed to be commercial CA’s, the FBCA, higher ed hierarchies, campus CA’s…
Operates at the highest level of confidence, can accommodate high assurance certs
Developed by the HEBCA-BID
Managed by the HEPKI Council, Jack McCredie Chair…
EDUCAUSE project

26. Overall Trust Fabric

27. Early version
HEBCA
FBCA
USHER-BASIC
USHER
-C4