Separating: ID, Credential, and Attribute Management
Session: Tuesday Session 4 Space I
Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes
Convener: Jim Fenton, Cisco Systems
Notes-taker(s): Jari Koivisto, Cisco Systems
Tags: Identity system, attribute, relying party, identity provider, authentication, assertion
Notes: Short presentation and discussion
Introduction
Terminology
A basic identity system
- e-commerce site
- IdP
- User
Elements of identity management
- Authentication (establishing who the Subject is)
- Credential managemen (prove to relying parties who the Subject is)
- Attribute management (provide information about the subject)
User trust
- User trust in their IdP is fundamental
- An ecosystem of IdP is required
Authentication
Authentication methods
- Methods useful for user authentication are situation-specific
- Problem: Many existing ID systems are bound tightly to IdP
Authentication Strength
- Relying party knows how good the authentication should be
Authentication endpoint
Security opportunities
- Users that authenticate frequently at a given service are more likely to detect anomalies
- IdP providers can detect anomalous user behavior
- Similar to detection of fraudulent credit card transactions
Credential management
Credential management: functions
- Act as a "key cabinet" for the user
- Support directed ID
- Enforce secure use of credentials
Directed identity
Security and availability issues
- Security
- High value target
- Availability
- Failure of an ID manager may have severe impact on its Subjects
Attribute management
Distributed attributes
- Self-asserted attributes have limited utility
- Authoritative sources for different attributes come from different places
- ID system has a role in locating trustable sources of attributes
- Attributes delivered as signed assertions
Attribute distribution: Example
- Example of Alice buying wine online
- Alice
- Wine merchant
- IdP
- DMV or Healthcare provider
Attribute trust
- Federation: Prearranged trust relationsships
- Accreditation: indirect federation
- Financial institutions, schools
Identity provider trust
- IdP has fiduciary responsibility
- To the Subject:
- Must use credentials only for the proper Subject
- To RPs:
- Must associate attribute request and responses reliably
- IdP may coincidentally funtion as an attribute provider
Observations
- Scaling is critical
- etc.
Discussion:
- RPs have different views what is identity
- Identity vs. Identity information
- Different IdPs give different sets of attributes
- What is the question that RP needs to ask (over 18/21 vs. birth day)
- Attributes of the Subject, e.g. Subjects attibute is: Subject is Cisco employee
- User -> RP -> User -> IdP -> User -> RP
- Yes User is >18
- Discussion about: Is it IdP who user trusts to get the attributes, or should User be the one who makes the decision
- Discussion about the assertions, e.g. State assertion does not mean that it is necessary better than self assertion. Address as an example.
- Federated trust frameworks, level of assurance (1, 2, 3, 4)