On 29/30th September, I went to the OASIS Identity Management 2009 forum, the theme of which was ‘Transparent Government: Risks, Rewards and Repercussions’. It was my first time at an OASIS event, and befitting the organisation and the location (it was hosted at NIST), the content was pretty in-depth and technical.
I’d really hoped to convert my scrawled notes into a series of posts on the topics covered, but time has escaped me and so I thought I’d at least post some of the notes I’d taken in rough form so that they didn’t get completely lost… So here are the notes from Day 1. If I get time, I’ll come back and post on some of these topics in more detail!
(There are also plenty of notes from other folks on the event’s Twitter stream, #idm09.)
OASIS IDM 2009 – Day 1
Session 1 – Use of Open Identity Technology In Government
– Leverage existing, open identities for government applications
— New government 2.0 initiative
— Using OpenID / InfoCard vetted providers
— 10 providers -> Can choose which provider / id (Google vs Equifax, for example)
— GSA defining ‘profiles’ – sets of standards at specific versions, guaranteed compatible
— Also ‘levels of assurance’ – criteria for various strengths/token types, according to risk/impact of incident
— Not building again, mapping publicly available identities against government assurance levels
–New concept of open trust framework to certify IdPs
— Jointly presented by OpenID, InfoCard foundations
— Outreach to OpenID, InfoCard, InCommon, Liberty and Kantara
–> Open Trust Framework
— Doesn’t presume any existing circles of trust (vs SAML)
— User controlled identity management
— Open, reusable
Anyone can become an IdP, but need to be vetted.
ICAM profiles force private sector IdPs to be precise, to meet the government-specific requirements
It’s a win for the government, industry and the public:
– Govt doesn’t build in a silo
– Industry gets tighter specs to focus on, and drive wider adoption
– Users get reduced numbers of identities, at government levels of assurance
– No verification of assertion attributes, just that attributes are present (e.g. email attribute not checked to be a valid email)
SAML Profile: Already exists, based on existing SAML use cases in govt.
ICAM OpenID Profile:
– Only for sites at LOA1 thus far
– Based on OpenID 2.0
– SSL enforced on all endpoints
– “Directed Identity” approach, i.e. identity appears different to each RP, so no tracking
– Other restrictions defined in profile too, to ensure appropriate security
– acceptable at LOAs 1-3 (maybe 4)
– Focus on the UI, digital ‘card in wallet’ – card selector in browser
– Can have varying underlying auth methods
– Only supports Managed Cards, IdP issued
– Card auth mechanisms are un/pw, X509, Kerberos, etc
— Truly user-centric would be self-managed
Don Campinella (Equifax)
Spoke about ‘persona control’ – multiple personas for a given identity
Attribute use assurance
Verification of claims
Suggested that a commercial IdP gives experience, data, scale, trust
Better fraud protection and privacy (some liability?)
Discussed at LOA1 use of pairwise unique IDs, pseudonymous: reusable unique identifier given to each RP, but can’t be traced back to the user unless the user shares attributes. Each pairwise identifier can be revoked from the RP.
Quoted that 20% of Medicare/Medicaid fraud is at the service provider, not the user, so we need to authenticate the service providers as well as consumers. This creates the need for a standalone IdP, outside of the RP.
Session 2 – Mary Ellen Callahan (CPO of DHS) & Ari Schwartz (COO – Centre for Democracy & Technology)
MEC on the baseline of govt idm tech – “It’s got to work for my mum” – what happens if something goes wrong? Not just a data breach, but how do you interact with the individual and manage the problem.
– Should have a plan, since nobody’s infallible
– Elements of redress
– Harm-based analysis
– Not just financial loss, but also reputation, etc.
– Maybe even public safety (location data, etc)
-> All about trust of government
Overall message: “Make it as secure as can be, but also plan for the worst. Have a policy to a) deal with it and b) prevent it recurring”
AS – Test of ‘user-managed identity’ is not in the user interface or the technology, but whether the user is on an equal footing with the IdP and the RP.
Session 3 – John Tolbert (Boeing)
Using XACML and ODF for Export & IP controls
Need to have resource (classification, ECCN, USML) & subject (nationality, location, US person) attributes
For IP controls, there’s an OASIS-XACML-IPC profile.
By using XACML, there’s a simpler, quicker adoption
-> Government can push out standard policy in XACML format to be used in a central decision engine at each org
-> Facilitates quick updates, easier audit – using standardised XACML means standardised rules (though relies on accurate metadata)
Extending this to ODF document control profiles, to match the XACML-IPC profile. This gives end-to-end authorisation, not just at the point of distribution.
Gives the organisation a single set of policies / rules to manage.
Breno de Medeiros (Google)
Drivers for federated identity standards in Google are predominantly credential reuse and social graph sharing
– Social sites ask for passwords for data harvesting
– This is bad! Users are trained then to share passwords (see Linked In, Dopplr, etc)
More reputable sites are less likely to implement APIs for authorisation/delegation as an RP, since they have little to gain. To succeed, providers should give a rich authorisation/delegation API, and a good UI!
Example of Plaxo & Google – OAuth and OpenID combined, but with friendly simple UI. Google account can be used to login to Plaxo, then OAuth allows for sync of contacts.
UI: Per-attribute authorisation is difficult, every additional checkbox makes the UI more complex and prone to rejection by the user. Also noted that users expect a ‘generated’ ID to be pairwise, but a social site ID, or manually created by the user, to be a global, shared identity. Need to be careful as PII could be exposed in URLs (email address, other correlatable data)
Current UI for OpenID that hides the ID is good (‘use your Google/Facebook/Live ID to login’) but isn’t scalable. There needs to be a good browser interface (like InfoCards) for IdP discovery in a privacy-aware way.
Session 4 – SAML 2.0 in government
Karen Higa-Smith (DHS programme manager)
Discussion around use of SAML2 for data sharing.
Authentication is already handled by the PIV smart card.
“Profile” created – this is a set of specs at particular levels along with guidelines and implementation documentation for use within government departments. It’s not a ‘standard’, since building these is slow and expensive.
Programme to manage ‘backend attribute exchange’ (BAE).
– Built a deployment profile and documentation
– Build a proof of concept BAE reference implementation, using synthetic data, to show interoperability between multiple vendor products following the BAE profile
– Idea was to document the profile but not to reinvent the wheel, instead to use commercial or free products and existing standards. Programme should allow for multiple approaches and technologies, but to ensure interoperability.
– Encouraging COTS vendors to provide out-of-box support for the US government BAE profile.
Explained two models
1- Direct Attribute Exchange
2 – Brokered Attribute Exchange
In the first case, a simple data exchange using SAML from point-to-point
In the second, smaller departments can use shared infrastructure from a larger department – but the data should be encrypted so that the shared infra provider can’t read the data. This was successfully accomplished using existing SAML standards.
– Specification of supported attributes, name identifier, encryption standards, etc are all specified within the SAML exchange.
– Also integration with the CA, so that user identities can be mapped to those on PIV cards or other certificate issuance.
– Flexible name identifiers, so that there’s no enforcement of a specific unique identifier.
Session 5 – Social Identity
Burton: Leveraging relationships & managing social identity
Discussed benefits of social identity (profiles, social graphs, etc) within the enterprise
e.g. Establishing social data in enterprise portals (skills, expertise, interests)
Leverage within blogs, wikis, forums – munge this data for display on portal -> activity feeds
Allow for ‘following’ of employees, subjects of interest
‘Facebook for enterprise’ – already have business dashboards, sales dashboards – why not a social dashboard?
Supports strategic talent, encouraging interaction, reflects generational shift towards social interactions
– problems of profile proliferation across multiple internal sites (and external)
– solve this with federation/sharing – but then problems of data leakage?
– Also automated activity stream causes sensitivity issues (e.g. posting on a gay forum, completing a sensitive deal)
– Resolve through access management, but then this risks losing serendipity. Creating a balance of access restrictions and openness is a big challenge.
-> Becomes an even bigger problem when trying to merge social graphs between internal and external tools (Facebook, Linked In)
– Breaking boundary between “work me” and “citizen me”. Is it acceptable for your boss to contact you about work issues on Facebook? Should they know about your out-of-work activities?
– Enterprise roles are well defined, though centred around access control
– Social roles proposed, e.g. “News filter”, “wiki gardener”
–> Social ‘talent management’, mining within the enterprise?
IDology (Jodi Florence) – identity verification provider
Anakam – government to citizen verification – a sliding scale from anonymous through to vetted proof with liability
Privo (Denise Tayloe) – Parental consent for managing a child’s identity and data sharing