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?

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.

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

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

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

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.

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

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

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

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

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

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

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 <ssuit@washington.edu>  tech-contact:  Bob Geek <vader@washington.edu>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.comorigin-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

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

Target Policy Decision Points

the Club level (basic firewall level)

at the target resource level

at the origin attribute authority

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

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)