that ol’ stp stuff: (security, trust, privacy) kenneth j. klingenstein and mark a. luker
Post on 23-Dec-2015
215 Views
Preview:
TRANSCRIPT
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…
top related