That Ol’ STP Stuff: (Security, Trust, Privacy) Kenneth J. Klingenstein and Mark A. Luker.

That Ol’ STP Stuff:(Security, Trust, Privacy)

Kenneth J. Klingenstein and Mark A. Luker

Topics

Shibboleth• Shib in the News• Substance

– Shib Basics– Comparisons to WS-Fed and Liberty; likely outcomes

Federations, InCommon, etcUSHER and some PKI initiativesOther Security, Privacy, Trust stuffWhat’s important

• Leverage• Integration• Understanding the new privacy• P2P trust

Unified field theory of Trust

Bridged, global hierarchies of identification-oriented, often government based trust – laws, identity tokens, etc.

• Passports, drivers licenses • Future is typically PKI oriented

Federated enterprise-based; leverages one’s 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

The Udell column 7/23/04

 http://www.infoworld.com/article/04/07/23/30OPstrategic_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 week’s 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, it’s a bad habit we must learn to resist.

Udell, continued

Consider a transaction at a liquor store. To prove your age, you present your driver’s 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 doesn’t need to know: your name and address. A printed card can’t 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 that’s rooted in the idea of selective disclosure. Little-known in the commercial world, Shibboleth — a project of the Internet2 consortium’s 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.

Udell, continued

Shibboleth’s 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. ….

It’s 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.

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

8:30 a.m. – 8:45 a.m. Introductions, Welcoming Remarks, and Recap From Last Meeting Gerry Coleman Chair

8:45 a.m. – 9:00 a.m. The National Criminal Intelligence Sharing Plan Update Chief Daniel Oates Global Intelligence Working Group’s (GIWG) Connectivity/Systems Committee Chairman

9:00 a.m. – 9:30 a.m. E-Authentication Terminology Briefing John WandeltGeorgia Tech Research Institute

9:30 a.m. – 10:00 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 10:00 a.m. – 11:00 a.m. Burton Group Briefing Dan Blum Research Director, Burton Group Doug Moench Senior Consultant, Burton Group

11:00 a.m. – 12:00 Noon Shibboleth and OpenSAML Briefing Scott Cantor Ohio State University

12:00 Noon – 1:00 p.m. “Question and Answer” Working Lunch Scott Cantor and Burton Group

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

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 Education’s Office of Federal Student Aid (FSA).

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

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.

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

Shibboleth AA ProcessR

esou

rce

WAYF

Users Home Org Resource Owner1

SHIRE

I don’t know you.Not even which home

org you are from.I redirect your request

to the WAYF32

Please tell me where are you from?

HS

5

6

I don’t know you.Please authenticateUsing WEBLOGIN

7

User DB

Credentials

OK, I know you now.I redirect your requestto the target, together

with a handle

4

OK, I redirect yourrequest now to

the Handle Service of your home org.

SHAR

Handle

Handle8

I don’t know theattributes of this user.Let’s ask the Attribute

Authority

Handle9AA

Let’s pass over the attributes the userhas allowed me to

release

Attributes 10

Reso

urce

Man

ag

er

Attributes

OK, based on theattributes, I grant

access to the resource

Shibboleth Architecture

Target Web

Server

Origin Site Target Site

Browser

Shibboleth Architecture -- Managing Trust

Federation

AttributeServer

Shibengine

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

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/

GUI’s to manage Shibboleth

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

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.

Privacy Management Systems

Personal Resource Manager

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

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

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?

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

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

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

Business drivers – R&E

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.

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.

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

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

Federal guidelines of relevance

NIST Guideline on Risk Assessment Methodologies

NIST Guideline on Authentication Technologies and their strengths

Federal e-Authentication

US Shibboleth federations

InQueue

InCommon• Uses• Management• Policies• Shared schema

Club Shib

NSDL

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

InCommon Principles

Support the R&E 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

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.

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

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

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

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

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)

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

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

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

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

Balancing the operator’s 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

FOPS 1:InCommon 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_Technical_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.

FOPS 2:InCommon 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_InCommon_Federation_System_Technical_Reference_ver_0.41

• Document describing the CA.

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.

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

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

The Research and EducationFederation Space

REFCluster

InQueue(a starting point)

InCommon

SWITCH

The ShibResearch Club

Other national nets

Other clustersOther

potential USR+E feds

State of Penn Fin Aid Assoc

NSDL

Slippery slope- Med Centers, etc

Indiana

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…

Upper Slaughter, England

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

PKI Items

Multiple paths to trust

Libpkix is out, so is Steve Hanna, sigh…

Digicert

USHER

Multiple Paths to Trust

NIST/NIH/Internet2 4th Annual PKI Conference April, 2005

Inclusive scope

Particular interest in overlap issues• GUI• Policy• Technical

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)

What’s Important,in the long-termimho

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

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…