1. Rethinking Privacy As Bob Blakley says, “It’s not about privacy, it’s about discretion.” Passive privacy - The current approach. A user passes identity to the target, and then worries about the target’s privacy policy. To comply with privacy, targets have significant regulatory requirements. And no one is happy... Active privacy - A new approach. A user (through their security domain) can pass attributes to the target that are not necessarily personally identifiable. If they are personally identifiable, the user decides whether to release them. Who will be happy?

2. Rethinking Privacy For access to controlled resources, there is a spectrum of approaches available. At one end is authorization approach, where attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach supports privacy. At the other end is the authentication approach, where the identity of a prospective user is passed to the controlled resource and is used to determine (perhaps with requests for additional attributes about the user) whether to permit access. Since this leads with identity, this approach requires the target to protect privacy.

3. Business Issues and Active Privacy When does a company want to know identity versus behavior? How many people register software? Does software support depend on the user or the attribute “have a registered copy of the software?” When a company wants to know identity, what will it take for the user to reveal it? Obvious business requirement Compelling ease of use for the user (A rubber squeeze toy) Think of how popular cash is despite the convenience of credit

4. The Continuum of Trust Collaborative trust at one end… can I videoconference with you? you can look at my calendar You can join this computer science workgroup and edit this computing code Students in course Physics 201 @ Brown can access this on-line sensor Members of the UWash community can access this licensed resource Legal trust at the other end… Sign this document, and guarantee that what was signed was what I saw Encrypt this file and save it Identifiy yourself to this high security area

5. Dimensions of the Trust Continuum Collaborative trust handshake consequences of breaking trust more political (ostracism, shame, etc.) fluid (additions and deletions frequent) shorter term structures tend to clubs and federations privacy issues more user-based Legal trust contractual consequences of breaking trust more financial (liabilities, fines and penalties, indemnification, etc.) more static (legal process time frames) longer term (justify the overhead) tends to hierarchies and bridges privacy issues more laws and rules

6. Interrealm Trust Structures Federated administration basic bilateral (origins and targets in web services) complex bilateral (videoconferencing with external MCU’s, digital rights management with external rights holders) multilateral Hierarchies may assert stronger or more formal trust requires bridges and policy mappings to connect hierarchies appear larger scale Virtual organizations Grids, digital library consortiums, Internet2 VideoCommons, etc. Share real resources among a sparse set of users Requirements for authentication and authorization, resource discovery, etc need to leverage federated and hierarchical infrastructures.

7. Shibboleth Trust Model Shibboleth/SAML Communities (aka Federated Administrations) Club Shib Club Shib Application process Policy decision points at the origin attribute authority at the club level, for target and origin at the target resource level Typical campus target management strategies

8. Shibboleth/SAML Communities (aka Clubs) A group of organizations (universities, corporations, content providers, etc.) who agree to exchange attributes using the SAML/Shibboleth protocols. In doing so they implicitly or explicitly agree to abide by a common set of by-laws. The rules and functions associated with a community include: A registry to process applications and distribute club information A willingness to share information on local authentication and authorization practices A set of agreements or best practices within the group on policies and business rules governing the use of attributes before and after transit. The set of attributes that are regularly exchanged (syntax and semantics). A mechanism (WAYF) to identify a user’s security domains Mechanisms to implement the community trust approach

9. Club Shib A co-op for higher education and its information providers Members can be organizations that are origins (IdSP’s), targets (student loan services, content providers) or both (universities, museums, etc.) Associated functions Registry service to be operated by I2, and open to all.. Campus account management practices Conventions on the management of exchanged attributes Attribute sets (eduPerson and eduOrg) to use to exchange attributes WAYF done via Wayfarer service PKI between institutional authorities

10. Club Shib In-laws Operational requirements system PKI certificate profiles install handle server at hs.yourschool.edu use SSL on the links etc Trust conventions targets don’t misuse attributes origins answer faithfully origins post their account management policies

11. Club Shib Registry service Receives and processes applications Operates Wayfarer (tm Jeff Hodges) origin sites are listed target sites can use Insures uniqueness of key identifiers among community members Houses PKI components of Shib institutional signing keys bridging if important

12. Club Shib Application Process Complete origin/target Shibboleth tech info as required Implement eduPerson and eduOrg Obtain appropriate PKI credentials for the institution Plug origins (campuses) into Wayfarer

13. Club Shib config file origin-site: washington.edu security-domain-list: u.washington.edu handle-service: shib.washington.edu handle-service-cert:... attribute-authority-list: aa1.washington.edu, aa2.washington.edu admin-contact: Sandy Suit tech-contact: Bob Geek origin-site: mit.edu security-domain-list: mit.edu, *.mit.edu handle-service: shibweb.mit.edu handle-service-cert:... attribute-authority-list: shibaa1.mit.edu, foo.outsource.com origin-site: claremont.edu security-domain-list: claremont.edu, harveymudd.edu, pomona.edu handle-service: handles.harveymudd.edu handle-service-cert:... attribute-authority-list: shib1.harveymudd.edu, shib1.pomona.edu

14. Campus Account Practices Authentications /authorizations are done appropriately Initial identification/password assignment process for accounts Authentication mechanisms for account use Policy on the reuse of account names (ePPN) Business logic for key attributes, as the need surfaces –“member of community” –primary affiliation

15. Target Policy Decision Points the Club level (basic firewall level) at the target resource level at the origin attribute authority

16. Campus Management Strategies Technical SHAR for general Club Shib access SHAR for more restricted sites (exclude origins with overly broad or sloppy practices) Cluster sites with similar restrictions in a web tree Policy Account management Directory and attribute management Setting the defaults Operating an attribute authority Clarifying the business rules

17. Multiple Clubs and their consequence Communities form clubs – Meteor, NDSL, Liberty by-laws and membership committees Within a club, members decide per-site policies that are consistent with the overall club policies and procedures Balancing where and what to manage Strength of I/A a repeated theme within and among clubs User interface issues attribute management levels of authentication – logging in and out A virtual Border Gateway Protocol (BGP)