1. Internet identity: Forward in All Directions Dr Ken Klingenstein, Director, Middleware, Internet2

2. kjk@internet2.edu Topics Why Now North – Federated Identity South – Social Identity West – PKI East – Anonymous Credentials At the center, integration Final thoughts

3. kjk@internet2.edu Why Now The increasingly urgent need for Internet identity The erosion of security and privacy At least two initiatives per government The prospect of a marketplace

4. kjk@internet2.edu Federated Identity (north) The now classic SAML 2.0 based meta-data driven trust federation, typically with a specified schema (eduperson+), perhaps LOA, perhaps certifying services Thousands of applications now, from content-distribution to outsourced services, from access to supercomputers to access to national research grants, from student aid to student travel, from wikis to cloud services Started in R&E, but now has crossed over to health and medical, real estate, government, international electronic banking, and more. Continues to drive policy if not technology The infrastructure to provide leverage for other forms of identity

5. kjk@internet2.edu Key Directions in Federated Identity

6. kjk@internet2.edu Federated Identity – Key Directions Higher Assurance, Multifactor Authn and Silver Scaling Access Control and Privacy Interfederation A whole set of other challenges – Non-web apps, provisioning, discovery, single logout The marketplace

7. kjk@internet2.edu Higher Assurance and Silver Many applications require higher levels of assurance of authentication – financial transactions, health care, government, etc. We are changing from “post your policy” to “comply with this” Stronger identity proofing, better authn (e.g. 2FA), better processes up the federated trust path For InCommon, Silver includes a review of institutional audit (by InCommon or Kantara), better metadata processing, and an additional fee

8. kjk@internet2.edu Scaling the Access Control and Privacy Too many sites, too difficult to release the right attributes, too little policy to satisfy privacy issues. Remedies being created Attribute bundles Application categories SP Codes of conduct Ever growing need for federated groups The nature of collaboration To scale access and to preserve privacy

9. kjk@internet2.edu Interfederation PKI is globally scalable Unfortunately, its not locally deployable… Federation is locally deployable Can it scale globally? Inter-federation Like BGP, only 1000 times harder

10. kjk@internet2.edu Interfederation Connecting autonomous identity federations Critical for global scaling, accommodating local federations, integration across vertical sectors Has technical, financial and policy dimensions Several operational instances – Kalmar2 Union, eduGAIN, ad hocs (UC Trust, Texas) Use cases now numerous, across sectors, within sectors Short-term and long-term approaches If its called the Internet, shouldn’t the marketplace start talking about “interfederated identity”

11. kjk@internet2.edu Interfederation: Short-term/long-term Long-term is starting to be worked, mostly technically, some ad hoc policy Short-term has happened and should continue, but be informed/inform by long-term Both short-term and long-term need to address same buckets of issues Long-term has potentially disruptive service models

12. kjk@internet2.edu Buckets of interfed issues Both short-term and long-term approaches must address: Exchange, and massage, of metadata Policy alignment Alignment of payloads (attributes) Operational issues – error handling, incident handling, legal and contractual, etc

13. kjk@internet2.edu UK Access Federation Metadata processing

14. kjk@internet2.edu Future metadata flows in Interfederation Org Registrar Aggregator Local trust oracle

15. kjk@internet2.edu Multiple trust contexts in interfederation Org Registrar Aggregator Application auditor Local trust oracle

16. kjk@internet2.edu Trust and Metadata Technically trusting that the metadata was provided by an authorized entity Secure deposit Technically trusting that the “organizationally vetted” metadata is correct Self-certified Behaviorally trusting that the “externally vetted” metadata is true Certified apps E.g. an app listed as R&S is in fact right

17. kjk@internet2.edu Emerging key software and protocols MDA – metadata aggregator PEER – metadata registry management software There may be multiple PEER services instances MDX – the query protocol(s) to request metadata; return via normal publishing protocols Improved discovery services – accountchooser, discojuice, embedded discovery services End-entity categories – an important new type of metadata, allowing for certified apps and IdP’s.

18. kjk@internet2.edu Meta-meta-data Metadata has its own metadata – e.g. who supplied it, when, terms of use, etc. Meta-meta-data may be contained in metadata stream, peeled off to help processing the other metadata, then reinserted as regular metadata into products No real discussions yet on normalizing meta-meta-data Likely little or no need for meta-meta-meta-data, thankfully…

19. kjk@internet2.edu Interfed policy areas Federation operations Legal status and bone fides Operational issues – signing key and metadata protection, incident handling, etc Federation to member relationships Contractual Vetting of members and delegation of metadata Community standards LOA End-entities and vetting values Attribute bundles IdP-SP direct relationships What issues do they work directly? If they have a contract? If they don’t

20. kjk@internet2.edu Interfed policy areas – status/need Federation operations Legal status and bone fides – normative format Operational issues – REFEDS Ops or ? Federation to member relationships Contractual – normative format+normalization Vetting of members and delegation of metadata - normalization Community standards LOA – basic ok. Silver and Bronze need normalization End-entities and vetting values – good informal start; registry and best practices Attribute bundles - good informal start; registry and best practices IdP-SP direct relationships - ???? Privacy, consent, etc handled somewhat by above

21. kjk@internet2.edu Is interfederation getting harder? Or, as Ian says, do we just understand the problem better? In the old days, just exchange signing keys Now, do you understand my metadata? My attribute bundles? My application categories and how I assess apps? My policies And do I understand yours? And with more use cases every day…

22. kjk@internet2.edu South – Social Identity A very large and fragmented marketplace Some key players are more on the sidelines – Facebook, Twitter, etc Most other key players engage in OIX (OpenId Exchange) – Google, Yahoo, Microsoft Evolving protocol settling into OpenIdConnect Looking at partnerships for higher LOA, e.g. with mobile, postal service, etc. Exploring what the marketplace is In a landscape where each vendor wants to own it…

23. kjk@internet2.edu Key Directions in Social Identity

24. kjk@internet2.edu Social Identity – Key Directions Getting technical interoperability, including those not yet in Dealing with the new complexities, needs for profiles, etc Alliances for better LOA and attributes Mobile and IdP/email provider Banks and IdP/email provider Getting a proper marketplace for identity Marketplace for attributes - Monetization

25. kjk@internet2.edu A Proper Marketplace for Identity Who pays for services The service provider, the user directly, the user indirectly (perhaps through tracking and advertizing) Who competes to provide services Monopoly, big dogs, a marketplace Will set directions for interfaces, discovery, innovation, low barriers to entry Who sets the rules About security and privacy of data And what does it cost?

26. kjk@internet2.edu A Proper Marketplace for Attributes Some attributes can have broad monetary value, e.g. verified postal address, over legal age, current location Who owns these attributes? How are they verified? When is consent necessary to release them? What form does consent take? Who can “buy” them? What are the rules of use? Who makes money? First markets being tested now…

27. kjk@internet2.edu PKI (west) Classic continues to grow, slowly, in certain niches, and the PKI bridges in the US continue to get heavily used. Community PKI continues to grow modestly, e.g IGTF Certain uses are vital – eduroam, VPN, SSL, device authentication Federated PKI is becoming possible Not just for end-enterprise strong authn

28. kjk@internet2.edu

29. Key directions in PKI

30. kjk@internet2.edu PKI (key directions) There are still things that only PKI can do at scale (personal signing, encrypted email, VPN, etc.) Dealing with the multiplicity of devices is difficult Some hope around Incert as a general purpose tool What does “federated PKI” look like outside of end- user authn?

31. kjk@internet2.edu Anonymous Credentials (east) Special credentials issued by attribute authorities When queried by RP, will do minimal disclosure of encoded attributes E.g. Over 18, True/False on specific sets of attributes, such as citizen, medical, etc. Can be done so that IdP does not know either the values being released or the RP’s requesting information Deep crypto techniques underlie – e.g. Idemix. Ten year old research -> proprietary technology development ->open source capability No use of SAML but heavy need for SAML metadata

32. kjk@internet2.edu Anonymous Credentials Use Cases Medical records HMO can put attributes about patient medications into an IdP and have authorized RP query Student health can store information restricted to RP with a need to know, protected from general IdP. Citizen record Answer general official queries such as over legal age queries, citizenship, etc. Enable specific services such as parking by zones, privacy- preserving neighborhood discussions Private access controls By good and evil

33. kjk@internet2.edu Key Directions in Anonymous Credentials

34. kjk@internet2.edu Key Directions in Anonymous Credentials Radical new capabilities, but lacking any infrastructure at all to support deployment at scale Delivering credentials to user and storing Scalable query controls Audit and policy issues Metadata for informed consent Others Enter federated identity (north) Provides secure credential transport and storage Provides framework for discussion on policy Fills other deployment gaps

35. kjk@internet2.edu At the center, integration Across user contexts Across devices and platforms Across millions of users and sites Across federated and anonymous credentials Through portals and gateways Leveraging the common business processes Making the market

36. kjk@internet2.edu User Contexts Individuals do trusted Internet transactions in a variety of contexts The enterprise/federated use of identity well- established; may be enhanced with roles Consumer Citizen Geo-temporal Personal “wallet” – preferred language, accessability, etc Others? Same identity; different roles; different policies and governance on privacy, etc

37. kjk@internet2.edu Scalable privacy Small spanning set of attributes Extensible but end-user manageable Use of bundles to minimize complexity Rich metadata for trusted dialogue Defaults, learning to minimize dialogues Putting the informed into informed consent End user privacy manager with quality UI, some out of band consent, getting the defaults right Integration of federated and anonymous credentials

38. kjk@internet2.edu Portals and Gateways and Privacy Portals and gateways are very common, especially in the R&E community Portals and gateways create some security and significant privacy issues in the Internet identity world Security concerns around cross-channel or app snooping, differing LOA needs, etc. Privacy concerns around attribute release on a per application versus per portal basis Note that portals like to mix-in their own attributes to the final flow to the app When, where, and how is consent handled

39. kjk@internet2.edu Does it make a difference?

40. kjk@internet2.edu A personal comparison The original Internet was massively consequential but relatively technically thin Intentionally kept the technology simple Most of the work was in making the marketplace of equipment, applications and users, and businesses. This Internet identity stuff is very, very important but relatively rich in issues A result of working so close to the wetware, connecting people not machines How much work will making the marketplace be?

41. kjk@internet2.edu