Transcript Slide

www.incommon.org
A View into the Mi$t
RL "Bob" Morgan
University of Washington
Co-chair, InCommon Technical Advisory Committee
1
www.incommon.org
The 2 Poles of Identity
Accountability
Expression
www.incommon.org
Big Data: Whose Data?
www.incommon.org
Consumer-scale
• Number of Google Apps domains: 2 million?
• Number of Facebook Connect RPs: 3 million?
• An inconvenient truth: the consumer web is
supported by the aggregation, processing, and sale
of the personal information of billions of people.
• Consumerization of web identity technology driven by
consumer services industry
www.incommon.org
NSTIC Vision and Strategy
• Individuals and organizations utilize secure, efficient,
easy-to-use, and interoperable identity solutions to
access online services in a manner that promotes
confidence, privacy, choice, and innovation.
• An Identity Ecosystem of solutions that are
– privacy-enhancing and voluntary
– secure and resilient
– interoperable
– cost-effective and easy to use
• Public/private partnership
www.incommon.org
NSTIC Operations and Governance
• NSTIC Steering Group
– promote creation, maintenance of Identity Ecosystem consistent
with Strategy
– privately-led, all stakeholders represented
– promote standards adoption
– accredit ecosystem components
– bids out now for secretariat organizations
– forming of Steering Group may involve some ... politics
– will it rule a realm that anyone is interested in?
www.incommon.org
Open Identity Exchange - OIX
• Formed in 2009 as federation for consumer IdPs
– participating in FICAM TFP certification
• Now supporting general Trust Framework development
• Representing industry in NSTIC deliberations
• Offering alternative views on ecosystem ...
• Attribute Exchange Network WG
– create trust framework for AX, policies and tech pilots
– separate IdPs from Attribute Providers, via brokers
– support monetizing providing of attributes, brokering
www.incommon.org
A World of Web Services
• A WWW of browsers -> a world of software
• Every web/cloud-based company has "API"
• Design patterns emerge: REST, JSON, OAuth
www.incommon.org
OAuth 2.0
• Authorization or "valet key" protocol
– eliminate "password anti-pattern": web sites asking for your
password to act as you to get to your stuff
– you ("resource owner") authorize something ("client") to access
your stuff ("resources") somewhere ("server")
– client can be web app, desktop/phone app, JS in browser
– right-to-access represented as access token
• Right to access ... what?
– very easy for user to grant access to gmail inbox, say, to many
sites/apps
– limited scopes? who wants to have limits?
www.incommon.org
OpenID Connect
• OpenID 1.0 (2006) promoted simple, web-based SSO
– a little too simple, too geeky, too idealistic
• OpenID 2.0 (2008) better, more complex
– widely deployed by consumer IdPs, not so many SPs,
not very interoperable, generating proxy industry
– large consumer IdPs became only IdPs ...
• OpenID Connect (2012)
– focus on simplicity for SPs; based on OAuth 2.0;
supports data channel
– finally FTW? supported by all the big (consumer) players
still consumer-IdP focused: bilateral, no metadata (yet)
www.incommon.org
Account Chooser
• OpenID Foundation project (formerly Google)
– "An open standard and interface guidelines for the next
generation of web sign in"
– provide transition-from/coexistence-with local signon and
federation; easy to deploy JavaScript
– visual representation of accounts, handle multiple accounts per
client machine; protocol-agnostic (OIDC, SAML, other)
– similar to work in federated space: ULX, DiscoJuice
– could support federated IdP discovery/search? Could ...
– best experience depends on centralized service ...
www.incommon.org
www.incommon.org
UMA
• Kantara initiative project to support controlled sharing of
personal info: person-self, person-other, person-org, in a
fully multi-lateral way
• element (perhaps) of "personal data ecosystem"
• driven by many use cases
– consumer sharing (e.g. photos, calendar)
– health/financial personal data management
– employer/employee data sharing
• profile, extension of OAuth2
• open-source implementations; any deployments?
www.incommon.org
www.incommon.org
Brave New World?
• Web service access will happen ... via OAuth
– and be enabled in the context of existing federation;
OAuth2 includes spec for SAML tokens
– develop enterprise OAuth infrastructure services,
OAuth support in federations, use in apps e.g. LMSes
• More use of, integration with consumer identities
– HE already good at providing attributes ...
• HE/VO support of "personal" data management
– combine user and institutional control?
– will involve consumer services, will still require community-based
trust, standards (Net+, yes!)