That Ol

1
That Ol STP Stuff (Security, Trust,
Privacy)Kenneth J. Klingenstein and Mark A.
Luker
2
Topics

• Shibboleth
• Shib in the News
• Substance
• Shib Basics
• Comparisons to WS-Fed and Liberty likely
  outcomes
• Federations, InCommon, etc
• USHER and some PKI initiatives
• Other Security, Privacy, Trust stuff
• Whats important
• Leverage
• Integration
• Understanding the new privacy
• P2P trust

3
Unified field theory of Trust

• Bridged, global hierarchies of identification-orie
  nted, often government based trust laws,
  identity tokens, etc.
• Passports, drivers licenses
• Future is typically PKI oriented
• Federated enterprise-based leverages ones
  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.
• Distinguishing P2P apps arch from P2P trust
• Virtual organizations cross-stitch across one of
  the above

4
The Udell column 7/23/04

•  http//www.infoworld.com/article/04/07/23/30OPstr
  ategic_1.html
• COLUMN   Strategic DeveloperFederating
  identityWeb sites ask for too much information.
  Instead, federated sites should share just
  enough By  Jon Udell July 23, 2004 
• In last weeks column, I suggested that
  individuals and corporations should be the
  authoritative sources of basic information about
  themselves. That way, if an application needs my
  name, address, and phone number, I can refer it
  to a source that I control and guarantee to be
  correct. But how many applications really need my
  name, address, and phone number? Capturing the
  identity of individuals, along with personal
  information about them, has become a habit. In a
  climate of increasing concern about privacy, its
  a bad habit we must learn to resist.

5
Udell, continued

• Consider a transaction at a liquor store. To
  prove your age, you present your drivers license
  the all-purpose credential. The card displays
  two items the clerk requires your picture
  (biometric proof of identity) and your birth date
  (proof of age). It also displays facts that the
  clerk doesnt need to know your name and
  address. A printed card cant selectively
  disclose only the required facts. But an
  electronic identity token can.
• Last week, at a PKI summit hosted by Dartmouth
  College, I heard quite a lot about Shibboleth, an
  approach to federation of identity thats rooted
  in the idea of selective disclosure. Little-known
  in the commercial world, Shibboleth a project
  of the Internet2 consortiums Middleware
  Architecture Committee for Education is gaining
  real traction in the realm of higher education.
  The most widely publicized deployment enables
  students at Penn State University to use their
  home credentials to log in to Napster.

6
Udell, continued

• Shibboleths protocols overlap in many respects
  with those of the Liberty Alliance Project. And
  in the latest round of specs, Liberty moves
  closer to the Shibboleth philosophy that users
  should control the release of their attributes.
• How do they differ, then? The Shibboleth model is
  simpler because access to resources is granted by
  institutional role, not by individual identity.
  .
• Its true that we often need to establish
  individual identity. But beyond cross-university
  resource sharing, there are plenty of cases where
  role-based access, certified by a remote
  authority, will suffice. Look for them, because
  the best way to sidestep liability for collecting
  too much information is to avoid capturing it in
  the first place.

7
Global Justice Information Sharing
InitiativeSecurity Architecture Committee
(SAC)August 18, 2004

• 830 a.m. 845 a.m. Introductions, Welcoming
  Remarks, and Recap From Last Meeting Gerry
  Coleman Chair
• 845 a.m. 900 a.m. The National Criminal
  Intelligence Sharing Plan Update Chief Daniel
  Oates Global Intelligence Working Groups (GIWG)
  Connectivity/Systems Committee Chairman
• 900 a.m. 930 a.m. E-Authentication
  Terminology Briefing John WandeltGeorgia Tech
  Research Institute
• 930 a.m. 1000 a.m .Discussion Topic There
  are intelligence information sharing systems
  already in place. What is architecture in
  these real-life examples? Do different
  implementations share a common architecture?
• Group Discussion 1000 a.m. 1100 a.m. Burton
  Group Briefing Dan Blum Research Director, Burton
  Group Doug Moench Senior Consultant, Burton Group
  
• 1100 a.m. 1200 Noon Shibboleth and OpenSAML
  Briefing Scott Cantor Ohio State University
• 1200 Noon 100 p.m. Question and Answer
  Working Lunch Scott Cantor and Burton Group

8
PESC Assembly on the State of E-Authentication
8/20/04

• Topics to be discussed include
•        Federal Government to e-Authentication
         Electronic Authentication Partnership
         Shibboleth        Liberty Alliance
         Transitive Trust        Project Meteor
         SAML and OpenSAML        PKI, Digital
  Certificates and NSC Services

9
PESC

• State of e-Authentication in Higher Education
  Assembly
• In continuing its focus on standardizing student
  authentication, the Postsecondary Electronic
  Standards Council (PESC) is pleased to announce
  its Assembly on the State of e-Authentication in
  Higher Education. In hosting this Assembly on
  e-Authentication, PESC is bringing together
  various leaders and experts within the higher
  education and technology communities. Over the
  coming year, higher education institutions,
  service providers, systems vendors, state and
  federal agencies, and all supporting suppliers to
  higher education will be making serious
  investments and commitments to online services.
  With the number of emerging technologies,
  standards, specifications, and frameworks, PESC
  is looking to ensure that information is shared
  and communicated so that decision makers have
  solid, reliable information on which to make
  informed decisions. Speakers for the State of
  e-Authentication in Higher Education include
• David Temoshok Director of Identity Policy
  and Management, U.S. General Services
  Administration who will provide an update on
  the various federal government activities and
  initiatives related to e-Authentication. As Mr.
  Temoshok is Co-Chair of the Electronic
  Authentication Partnership (EAP), he will also
  provide an overview and update on activities
  related to the EAP.
• - David Yakimaschak Chief Technology Officer,
  JSTOR who will discuss the general state of
  authentication and JSTOR's implementation of
  various authentication protocols, and introduce
  attendees to the newly formed federation called
  InCommon.
• Howard Gilbert Senior Research Programmer,
  Yale University who will discuss portal
  authentication issues, activities, and
  authentication implementation at Yale University.
• Robert Morley Associate Registrar, University
  of Southern California, and Board of Directors
  member of both AACRAO and PESC who will discuss
  authentication from the admissions and registrar
  perspective.
• Scott Cantor Senior Systems Developer, Ohio
  State University and Shibboleth Architect and
  Core Developer, Internet2 who will discuss SAML
  and communicate the future roadmap for Shibboleth
  including relationships between various
  projects, how they might evolve over the next
  12-24 months, and the interoperability and/or
  certification work that Shibboleth will be
  initiating in order to raise the level of
  interoperability.
• Adele Marsh Vice President, E-Commerce
  Initiatives, AES who will update attendees on
  the Meteor Network, the standards and processes
  it uses, and discuss the future enhancements to
  Meteor.
• Mark Jones Vice President, Marketing and
  Business Development, National Student
  Clearinghouse who will address high level
  business issues related to PKI and some of the
  specific challenges for higher education.
• Bernie Gleason Executive Consultant, IBM
  who will discuss the weakest portion of
  authentication security -- password security and
  poor user practices -- and explore ideas how to
  transition stronger authentication practices for
  all customers and all interactions across the
  entire institution. Included will be a look at
  the way in which security tokens and biometrics
  may be deployed in the future.
• The Assembly on the State of e-Authentication in
  Higher Education is being held in partnership
  with the US Department of Educations Office of
  Federal Student Aid (FSA).

10
Eduserve News July 2004

• Interoperability the catchword!
• Eduserv Athens has confirmed its plans to develop
  full interoperability between its existing Athens
  services -
• one of the largest federated access management
  systems in the world - and Shibboleth origins and
  targets.
• In addition, Eduserv reiterates its commitment to
  common standards and to the development of Athens
  in
• compliance with new standards and future user
  needs.
• Eduserv CTO Ed Zedlewski commented, "We think the
  Shibboleth architecture is likely to become the
• international standard for academia, and
  therefore we will be offering an access
  management service, both in
• the UK and beyond, incorporating that
  architecture".

11
Federal government

• Federal E-Authentication has a number of pilots
  under way. One of them is now Shib.
• Phase 1 and Phase 2 efforts funded, with
  deliverables due over the next six months
• Potential phase 3 and 4 would include working on
  a federal federation and peering with Higher Ed
  and other federations.

12
Phase 1 and 2 Deliverables

• Phase 1 Deliverables
• Analysis Doc on SAML profiles and futures for
  e-Auth and Shib
• Analysis Doc comparing InCommon and e-Auth
  concepts, terminology, etc.
• Proof of concept demonstration of a Shibboleth
  federation inter-operating with the
  E-Authentication architecture
• Phase 2 Deliverables
• A document that identifies how the Shibboleth
  demonstration was set up, including lessons
  learned
• A white paper providing recommendations to both
  the E-Authentication PMO and U.S. Higher
  Education Shibboleth federations on continued
  policy convergence between the communities based
  on the findings of this pilot

13
Shibboleth AA Process
WAYF
Users Home Org
Resource Owner
Resource
14
Shibboleth Architecture
15
Shibboleth Architecture -- Managing Trust

• Federation

Shib engine
Attribute Server
Target Web Server
Browser
Target Site
Origin Site
16
Milestones

• Project formation - Feb 2000 Stone Soup
• Process - began late summer 2000 with bi-weekly
  calls to develop scenario, requirements and
  architecture.
• Linkages to SAML established Dec 2000
• Architecture and protocol completion - Aug 2001
• Design - Oct 2001
• Coding began - Nov 2001
• Alpha-1 release April 24, 2002
• OpenSAML release July 15, 2002
• v1.0 April 2003
• v1.1 July 2003
• V1.2 April 2004
• V2.0 likely end of the major evolution

17
Shibboleth Status

• Open source, privacy preserving federating
  software
• Being very widely deployed in US and
  international universities
• Target - works with Apache(1.3 and 2.0) and IIS
  targets Java origins for a variety of Unix
  platforms.
• V2.0 likely to include portal support, identity
  linking, non web services (plumbing to
  GSSAPI,P2P, IM, video) etc.
• Work underway on intuitive graphical interfaces
  for the powerful underlying Attribute Authority
  and resource protection
• Likely to coexist well with Liberty Alliance and
  may work within the WS framework from Microsoft.
• Growing development interest in several
  countries, providing resource manager tools,
  digital rights management, listprocs, etc.
• http//shibboleth.internet2.edu/

18
GUIs to manage Shibboleth
19
SysPriv ARP GUI

• A tool to help administrators (librarians,
  central IT sysadmins, etc) set attribute release
  policies enterprise-wide
• For access to licensed content
• For linking to outsourced service providers
• Has implications for end-user attribute release
  manager (Autograph)
• GUI design now actively underway, lead by
  Stanford
• Plumbing to follow shortly

20
End-user attribute release manager(Autograph)

• Intended to allow end-users to manage release
  policies themselves and, perhaps, understand the
  consequences of their decisions
• Needs to be designed for everyone even though
  only 3 will use it beyond the defaults.
• To scale, must ultimately include extrapolation
  on settings, exportable formats, etc.

21
Privacy Management Systems
22
Personal Resource Manager
23
Federating Software Comparison

• Liberty Alliance
• V 1.1 of their functional specs released 2.0
  under discussion
• Federation itself is out of scope
• Open source implementations not emphasized
• Current work is linked identities
• Shibboleth
• V1.2 released 1.3 and 2.0 under development
• Most standards-based pure open source in
  widening use
• Current work is attribute release focused
  linking identities in 2.0.
• WS-
• 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.
• Standards process and IPR issues uncertain
• Will need considerable convention and detail to
  resolve into a working instantiation

24
WS-Fed and Shib

• Verbal agreements to build WS-Fed
  interoperability
• Contract work commissioned by Microsoft, executed
  by Shib core development contracts executed by
  mid-September, but work likely not til Spring
• Discussions broached, by Microsoft, in building
  Shib interoperabilty into WS-Fed
• Devils in the details
• Can WS-Fed-based SPs work in InCommon without
  having to muck up federation metadata with
  WS-Fed-specifics?
• All the stuff besides WS-Fed in the WS- stack
• The best way to do Shib over SOAP
• etc

25
Liberty, SAML and Shib

• Liberty is also SAML-based.
• Liberty 1.1 has an open-source implementation
  by Ping-ID that is not quite open
• SAML 2.0 extracts much of the best of Lib and the
  best of Shib. It leaves a lot of Shib (the
  privacy management) and not much of Liberty
• Shib will be refactored
• Does Liberty move on to the apps (calendaring,
  presence, etc) or declare victory and go home?

26
Shib Issues going forward

• Doing OpenSAML 2.0
• Refactoring Shib
• Dealing with old code bases, security patches,
  etc.
• Organizing a Shibboleth Project
• International coordination on development
• Moving more into the Shib-related development
  (versus the current Shib-core focus)
• Promoting Shib-enhanced applications

27
Federations

• Associations of enterprises that come together to
  exchange information about their users and
  resources in order to enable collaborations and
  transactions
• Enroll and authenticate and attribute locally,
  act federally.
• Uses federating software (e.g. Liberty Alliance,
  Shibboleth, WS-) common attributes (e.g.
  eduPerson), and a security and privacy set of
  understandings
• 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.
• Several federations now in construction or
  deployment

28
Business drivers - corporate

• Need to link consumer identities among disparate
  service providers
• Link corporate employees through a company portal
  to outsourced employee services transparently
• Allow supply chain partners to access each others
  internal web sites with role based controls

29
Business drivers RE

• Given the strong collaborations within the
  academic community, there is an urgent need to
  create inter-realm tools, so
• Build consistent campus middleware infrastructure
  deployments, with outward facing objectclasses,
  service points, etc. and then
• Federate (multilateral) those enterprise
  deployments with interrealm attribute transports,
  trust services, etc. and then
• Leverage that federation to enable a variety of
  applications from network authentication to
  instant messaging, from video to web services,
  from p2p to virtual organizations, etc. while we
• Be cautious about the limits of federations and
  look for alternative fabrics where appropriate.

30
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.

31
Requirements for federations

• Federation operations
• Federating software
• Exchange assertions
• Link and unlink identities
• Federation data schema
• Federation privacy and security requirements
• Non web services can also leverage federations

32
Policy Basics for federations

• Enterprises that participate need to establish a
  trusted relationship with the operator of the
  federation in small or bilateral federations,
  often one of the participants operates the
  federation
• Participants need to establish trust with each
  other on a per use or per application basis,
  balancing risk with the level of trust
• Participants need to agree on the syntax and
  semantics of the information to be shared
• Privacy issues must be addressed at several
  layers
• All this needs to be done on a scalable basis, as
  the number of participants grow and the number of
  federations grow

33
Federal guidelines of relevance

• NIST Guideline on Risk Assessment Methodologies
• NIST Guideline on Authentication Technologies and
  their strengths
• Federal e-Authentication

34
US Shibboleth federations

• InQueue
• InCommon
• Uses
• Management
• Policies
• Shared schema
• Club Shib
• NSDL

35
InCommon federation

• Federation operations Internet2
• Federating software Shibboleth 1.1 and above
• Federation data schema - eduPerson200210 or later
  and eduOrg200210 or later
• Becomes fully operational August 15 or so, with
  several early entrants already in to help shape
  the policy issues.
• Precursor federation, InQueue, has been in
  operation for about six months and will feed into
  InCommon
• http//www.incommonfederation.org

36
InCommon Principles

• Support the RE community in inter-institutional
  collaborations
• InCommon itself operates at a high level of
  security and trustworthiness
• InCommon requires its participants to post their
  relevant operational procedures on identity
  management, privacy, etc
• InCommon will be constructive and help its
  participants move to higher levels of assurance
  as applications warrant
• InCommon will work closely with other national
  and international federations

37
InCommon Uses

• Institutional users acquiring content from
  popular providers (Napster) and academic
  providers (Elsevier, JSTOR, EBSCO, Pro-Quest,
  etc.)
• Institutions working with outsourced service
  providers, e.g. grading services, scheduling
  systems
• Inter-institutional collaborations, including
  shared courses and students, research computing
  sharing, etc.

38
InCommon Management

• Operational services by I2
• Member services
• Backroom (CA, WAYF service, etc.)
• Governance
• Executive Committee - Carrie Regenstein - chair
  (Wisconsin), Jerry Campbell, (USC), Lev Gonick
  (CWRU), Clair Goldsmith (Texas System), Mark
  Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan
  Perry (Mellon), Mike Teetz, (OCLC), David
  Yakimischak (JSTOR).
• Project manager Renee Frost (Internet2)
• Membership open to .edu and affiliated business
  partners (Elsevier, OCLC, Napster, Diebold, etc)
• Contractual and policy issues being defined now
• Likely to take 501(c)3 status in the long term

39
InCommon participants

• Two types of participants
• Higher ed institutions - .edu-ish requirements
• Service providers partners sponsored by higher
  ed institutions, e.g. content providers,
  outsourced service providers (WebAssign,
  Roomschedulers, etc)
• Participants can function in roles of credential
  providers and resource providers
• Higher ed institutions are primarily credential
  providers, with the potential for multiple
  resource providers on campus
• Service providers are primarily offering a
  limited number of services, but can serve as
  credential providers for some of their employees
  as well

40
InCommon pricing

• Goals
• Cost recovery
• Manage federation stress points
• Prices
• Application Fee 700 (largely enterprise I/A,
  db)
• Yearly Fee
• Higher Ed participant 1000 per identity
  management system
• Sponsored participant 1000
• All participants 20 Resourceproviderids
  included additional resourceproviderids
  available at 50 each per year, available in
  bundles of 20

41
Trust in InCommon - initial

• Members trust the federated operators to perform
  its activities well
• The operator (Internet2) posts its procedures,
  attempts to execute them faithfully, and makes no
  warranties
• Enterprises read the procedures and decide if
  they want to become members
• Origins and targets trust each other bilaterally
  in out-of-band or no-band arrangements
• Origins trust targets dispose of attributes
  properly
• Targets trust origins to provide attributes
  accurately
• Risks and liabilities managed by end enterprises,
  in separate ways

42
InCommon Policy Framework

• Federation-wide
• Charter
• Federation Operating Practices Statement (FOPS)
• List of common attributes
• The art of federation
• Participant-specific
• Submitting an application for participation
• Participant agreement
• Participant Operational Practices Statement (POPS)

43
InCommon Trust - ongoing

• Use trust ?? Build trust cycle
• Clearly need consensus levels of I/A
• Multiple levels of I/A for different needs
• Two factor for high-risk
• Distinctive requirements (campus in Bejing or
  France, distance ed, mobility)
• Standardized data definitions unclear
• Audits unclear
• International issues

44
Participant Agreement Highlights

• Agree to post policies
• Security
• Basic identity management
• Privacy
• Inform InCommon on a timely basis of key
  compromise
• Be responsible for ResourceProviderIds issued
• Be responsible for adhering to their POPS
  statement
• Shared idemnification

45
Participant Operational Practice Statement

• Basic Campus identity management practices in a
  short, structured presentation
• Identity proofing, credential delivery and
  repeated authn
• Provisioning of enterprise-wide attributes,
  including entitlements and privileges
• Basic privacy management policies
• Standard privacy plus
• Received attribute management and disposal

46
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

47
Balancing the operators trust load

• InCommon CA
• Identity proofing the enterprise
• Issuing the enterprise signing keys (primary and
  spare)
• Signing the metadata
• Could be outsourced
• InCommon Federation
• Aggregating the metadata
• Supporting campuses in posting their policies
• Less easy to outsource, especially the organic
  aspects

48
FOPS 1InCommon Federation Operations

• InCommon_Federation_Disaster_Recovery_Procedures
• An outline of the procedures to be used if there
  is a disaster with the InCommon Federation.
• Internet2_InCommon_Federation_Infrastructure_Techn
  ical_Reference
• Document describing the federation
  infrastructure.
• Internet2_InCommon_secure_physical_storage
• List of the physical objects and logs that will
  be securely stored.
• Internet2_InCommon_Technical_Operations_steps
• This document lists the steps taken from the
  point of submitting CSR, Metadata, and CRL to
  issuing a signed cert, generation of signed
  metadata, and publishing the CRL.
• Internet2_InCommon_Technical_Operation_Hours
• Documentation of the proposed hours of
  operations.

49
FOPS 2InCommon CA Ops

• CA_Disaster_Recovery_Procedure_ver_0.14
• An outline of the procedures to be used if there
  is a disaster with the CA.
• cspguide
• Manual of the CA software planning to use.
• InCommon_CA_Audit_Log_ver_0.31
• Proposed details for logging related to the CA.
• Internet2_InCommon_CA_Disaster_Recovery_from_root_
  key_compromise_ver_0.2
• An outline of the procedures to be used if there
  is a root key compromise with the CA.
• Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61
• Draft of the PKI-Lite CPS.
• Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21
• Draft of the PKI-Lite CP.
• Internet2_InCommon_Certificate_Authority_for_the_I
  nCommon_Federation_System_Technical_Reference_ver_
  0.41
• Document describing the CA.

50
FOPS 3 InCommon Key Signing Process

• 2. Hardware descriptions         a. Hardware
  will be laptop and spare laptop with no network
  capabilities, thumb drive, CDRW drive, media for
  necessary software 3. Software descriptions
          a. OS, OpenSSL, CSP, Java tools for meta
  data 4. Log into computer 5. Generation of the
  CA Private Root key and self-signing 6.
  Generation of the Metadata signing key 7.
  Generate CSR for Internet2 origin 8. Signing of
  new metadata sites and trusts files 9. Backup
  copies of all private keys and other operational
  backup data are generated. 10. Verify CD's and
  MD5 checksum 11. Write down passphrase and put
  in envelopes and sign envelopes 12. Securely
  store CA hardware and contents of local safe in
  safe 13. Log that these actions occurred on the
  log in safe and then close and lock the safe 14.
  Put thumb drive into secure db and copy data onto
  secure db 15. Take private key password archive
  and other contents to Private Key Password safe
  deposit box and record in log that this was done.
  16. Take operational data archive to Operation
  Data safe deposit box and record in log that this
  was done.

51
FOPS 4 InCommon Process Tech Review

• As a technical review group, we, the undersigned,
  reviewed the processes and the following
  components documenting the operations of
  InCommon, and discussed them with the Internet2
  Technical and Member Activities staff. To the
  best of our knowledge and experience, with no
  warranty implied, we believe the operational
  processes and procedures Internet2 provided are
  acceptable to begin the operations of InCommon.
• Scott Cantor, OSU
• Jim Jokl, UVa
• RL Bob Morgan, UW
• Jeff Schiller, MIT

52
The art of federation

• Prudence in ResourceProviderIds
• Use of targetedId (anonymous, persistent state)
• Original warnings
• Ability to request target amnesia/reset
• Diagnostics of fine-grain access control
• Overlapping and interacting federations

53
The Research and EducationFederation Space
Indiana
Slippery slope - Med Centers, etc
54
International federation peering

• Shibboleth-based federations being established in
  the UK, Netherlands, Finland, Switzerland,
  Australia, Spain, and others
• International peering meeting slated for October
  14-15 in Upper Slaughter, England
• Issues include agreeing on policy framework,
  comparing policies, correlating app usage to
  trust level, aligning privacy needs, working with
  multinational service providers, scaling the WAYF
  function
• Leading trust to Slaughter

55
Upper Slaughter, England
56
Next Steps

• Federated software alignment and interoperability
• Fully establishing persistent federations
• End-user ARP management tools (Autograph)
• Coordination of federation policy underpinnings
• Escalating levels of trust

57
PKI Items

• Multiple paths to trust
• Libpkix is out, so is Steve Hanna, sigh
• Digicert
• USHER

58
Multiple Paths to Trust

• NIST/NIH/Internet2 4th Annual PKI Conference
  April, 2005
• Inclusive scope
• Particular interest in overlap issues
• GUI
• Policy
• Technical

59
USHER and a PKI initiative

• USHER a progressive CA for
• Business face
• Technical Ops we hope Dartmouth
• Policy - InCommon PMA, PKI-lite CP/CPS
• An initiative
• Campus application package (PKi)
• A campus deployment approach with a business plan
• An evolutionary approach to interrealm and
  bridged use
• Consistency of profiles
• Consistency of policies
• Expression in InCommon attribute assertions
  (authncontext field)

60
Whats Important, in the long-term imho

• If Shib/InCommon succeeds, how can it be
  leveraged to
• Improve security, including PKI
• Increase LOA
• Simplification federated authn/authz
• Application driven PKI
• P2P trust and technologies
• Better understandings of privacy
• Anonymous non-trackable
• Anonymous trackable (subpoenable)
• Denial of privacy
• EU directives

61
Peer to peer trust

• A bedrock of human existence
• Completely intuitive, sometimes contradictory and
  soft around the edges
• Translation into technology is difficult
• PGP and webs of trust most successful
• X.509 Proxy Certs a new, odd option
• Issues over transitivity, integration into
  applications, user management are hard
• Some new technologies, embedded within MS
  Longhorn, present an option that will have a
  large embedded base