Frequently Asked Questions

General Questions
What is the Liberty Alliance Project?
What is the mission of the Liberty Alliance Project?
What is the vision of the Liberty Alliance Project?
What is the objective of the Liberty Alliance Project?
What is network identity?
What is federated network identity?
What is a Circle of Trust?
What is Simplified Sign-On?
What are the business benefits of federated network identity?
How are the technical specifications developed within the Alliance?

Membership
Who participates in the Alliance?
What are the various levels of membership in the Liberty Alliance?
What are the benefits of membership?
What companies are on the Liberty Alliance Management Board?
What organizations have demonstrated interoperability of Liberty-enabled implementations?
How has the Liberty Alliance worked to address privacy and security concerns?
What does the Privacy and Security Best Practices document provide?
How do the Privacy and Security Best Practices and Privacy Implementation guidelines differ?
How does Liberty benefit consumers?
What specifications has Liberty Alliance Project released to date?
What are the Phase 1 specifications?
What are the Liberty Phase 2 draft specifications?
What is new in the Phase 2 specifications?
Does ID-WSF build off version 1.1?
How many services tracks may a member company participate in at the same time?

Technical questions
Cookie management for LEP Profiles
Relative URLs for LEP Profiles
Validation issues
What is required to demo ID-FF?
What namespace should ResourceIDs, and EncryptedResourceIDs be in?

Liberty Alliance SAML v2.0 OASIS Standard Interoperability Testing
Why is Liberty Alliance extending its program to include SAML 2.0 OASIS Standard interoperability testing?
How is Liberty’s SAML 2.0 OASIS Standard testing different from Liberty’s first wave of interoperability conformance testing?
How does the SAML 2.0 OASIS Standard relate to Liberty Alliance work?
How does Liberty’s Interoperable Logo Program for SAML 2.0 differ from testing programs that may be offered by OASIS?
Does Liberty Alliance offer a formal stamp or a designation of some sort?
When a company earns the Liberty Interoperable ä Logo Program mark, what exactly does it say to the market?
Have any companies been certified yet?
What about confidentiality?
It sounds like the Liberty testing process is really developer-friendly.
For companies that were certified on the Liberty ID-FF 1.1 and 1.2, will it be easier to pass this new test?
When are you going to start the program?
Do vendors need to do any specific preparation?
Is the interoperability test open only to Liberty members—or can other vendors out there in the marketplace participate?
How long does the process of certification take?
How are the tests graded?
What’s Liberty’s track record in interoperability testing?

Strong Authentication Expert Group
Why did Liberty Alliance form the Strong Authentication Expert Group?
What is strong authentication?
What types of strong authentication exist today?
Why is Liberty’s Strong Authentication Expert Group needed?
What is “universal strong authentication?”
How will Liberty’s Strong Authentication Expert Group speed the deployment of universal strong authentication?
Is Strong Authentication a new Liberty Alliance initiative?
What Liberty members are participating in this group?
Who will be most interested in ID-SAFE?
What kind of guidance did the US FFIEC issue?
Are other governments/countries looking to do the same thing?
Did the US FFIEC guidance influence Liberty’s decision to form the Strong Authentication Expert Group?
Why is Liberty qualified to lead the development of open specifications for interoperable strong authentication?
How is Liberty able to develop specifications so quickly?
Aren’t there other organizations already working to advance interoperable strong authentication?
Will Liberty be working with these groups?
What benefits will ID-SAFE bring to organizations?
What benefits will ID-SAFE bring to consumers?
How does the formation of the Strong Authentication Expert Group vary from what Liberty has been doing in federated identity management and Web services?
When will ID-SAFE be released?
When can we expect to see more news about ID-SAFE?
Where can we get more information on Liberty’s Strong Authentication Expert Group?

ID-WSF 2.0 Release Two
What is included in today’s release?
What is Liberty Alliance People Service?
What is a social application?
What is a federated social network?
What are the benefits of Liberty People Services in a federated social network?
What do you mean by more systematic enforcement of privacy policies?
What is an example of a consumer using Liberty People Service in a federated social network?
What is an example of Liberty People Service in the enterprise space?
How does Liberty People Services offer protection against identity theft and fraud?
Do Liberty People services work with other Liberty Web services applications?
Liberty People Service seems to focus on the consumer. Does this represent a new direction for Liberty Alliance?
Is Liberty People Service available now?
Where can we learn more about Liberty People Service?
Today’s Liberty Web Services release also includes support for additional open industry standards. Can you provide more details here?
Does Liberty Alliance typically work with other open standards bodies?
Are Liberty Web Services deployed now?
When will we see more news about Liberty Web Services?

IPR
What is a general description of Liberty’s IPR policy?

General Questions

Q: What is the Liberty Alliance Project?
A: The Liberty Alliance Project (https://projectliberty.org) was formed in September 2001 to serve as the premier open standards organization for federated identity and identity-based services. The Alliance is delivering specifications and guidelines to enable a complete network identity infrastructure that will resolve many of the technology and business issues hindering the deployment of identity-based Web services.

Q: What is the mission of the Liberty Alliance Project?
A: The Liberty Alliance’s mission is to serve as the premier open standards organization for federated identity management and services.

Q: What is the vision of the Liberty Alliance Project?
A: A networked world in which individuals and businesses can more easily interact with one another while respecting the privacy and security of identity information.

Q. What is the objective of the Liberty Alliance Project?
A: To create open, technical specifications that (i) enable simplified sign-on through federated network identification using current and emerging network access devices, and (ii) to support and promote permission-based attribute sharing to enable a user’s choice and control over the use and disclosure of his/her personal identification.

Q: What is network identity?
A: Network identity refers to the global set of attributes that are contained in an individual’s various accounts with different service providers. These attributes include such information as name, phone numbers, social security numbers, addresses, credit records, and payment information. For individuals, network identity is the sum of their financial, medical, and personal data—which must be carefully protected. For businesses, network identity management creates the ability to have greater knowledge of their customers and constituents, and to interact with them in ways that bring greater value to both parties.

Q: What is federated network identity?
A: Federated identity allows users to link identity information between accounts without centrally storing personal information. Also, the user can control when and how their accounts and attributes are linked and shared between domains and service providers, allowing for greater control over their personal data. In practice, this means that users can be authenticated by one company or Web site and be recognized and delivered personalized content and services in other locations without having to re-authenticate, or sign on with a separate username and password.

Q: What is a circle of trust?
A: A “circle of trust” is enabled through federated identity and is defined as a group of service providers that share linked identities and have pertinent business agreements in place regarding how to do business and interact with identities. Once a user has been authenticated by a circle of trust identity provider, that individual can be easily recognized and take part in targeted services from other service providers within that circle of trust. It should be noted that this concept of trust-based relationships between organizations and their individual or joint customers has existed in the offline business world for years; two common examples would include travel alliances and affiliate business partnerships.

Q: What is simplified sign-on?
A: Simplified sign-on enables users to be authenticated within one domain and have their identity recognized by other domains or Web sites without having to maintain a myriad of user name/password combinations. Inside an enterprise, this would allow an employee to have access to hosted resources and applications without having to re-authenticate each time. In a circle of trust, it allows users to sign on with one member of an affiliate group and subsequently use other sites within the group without having to sign on again.

Q: What are the business benefits of federated network identity?
A: Organizations that implement Liberty Alliance’s federated network identity specifications can offer customers, business partners, or employees a far more satisfactory online experience with new levels of personalization, security, and control over their information. In turn, it enables businesses to more easily meet their business objectives through the creation of new relationships with each other, development more trusted relationships with their customers, and through substantial cost reduction and avoidance by lower implementation and maintenance costs.

Q: How are the technical specifications developed within the Alliance?
A: The Liberty Alliance Project develops specifications through the collaboration of three expert groups that are driven by the Liberty Alliance Management Board. The expert groups are: Business & Marketing, Technology, and Public Policy.

  • Business & Marketing: The Business & Marketing Expert Group drives the market requirements for the Liberty specifications and is also the central point for all of the Alliance’s communications and public relations efforts. Additionally, it is responsible for creating the business templates that will help drive business adoption of the specifications and enable circles of trust.
  • Technology: The Technology Expert Group creates the Liberty specifications and drives the development of sample implementations and interoperability tests.
  • Public Policy: The Public Policy Expert Group drives dialogue with government and nongovernment groups pertaining to identity and data management. It ensures that the Liberty specifications adhere to pertinent laws and regulations, and develops privacy best practice guidelines for Liberty implementers.
  • Services: The Services Expert Group is responsible for the definition and development of all services MRDs and specifications. Any member company is eligible for participation in the SEG.
  • Conformance: The Conformance Expert Group defines the testing process and procedures, and licensing requirements of the Liberty Alliance. They are also responsible for the monitoring and usage of the Liberty conformance logos.

Membership

Q: Who participates in the Alliance?
A: The Alliance has grown from under 20 companies in 2001 to more than 150 companies in early 2003. Alliance members represent a worldwide cross section of organizations, ranging from educational institutions and government organizations, to service providers and financial institutions, to technology firms, and wireless providers. For a complete member list visit https://www.projectliberty.org/membership /current_members.php.

Q: What are the various levels of membership in the Liberty Alliance?
A: There are four levels of membership in the Alliance: Management Board, Sponsor, Associate, and Affiliate.
Management Board is responsible for the overall governance of the Alliance and has the final voting authority for specifications.
Sponsor membership provides full participation in all of the Alliance’s three Expert Groups (Business & Marketing, Technology, and Public Policy) and participation in the quarterly face-to-face meetings.
Associate and Affiliate memberships are available to commercial companies, and nonprofit and government agencies, respectively, providing an opportunity to view and comment on draft specifications via the Web prior to public release. Associates and Affiliates may participate in the creation of new ID-SIS specifications.

Q: What are the benefits of membership?
A: Membership in the Liberty Alliance guarantees the ability to shape and impact the next phase of identity. By contributing to its development, Liberty Alliance members get a jump on the specifications being advanced as standards, and can roll that knowledge into their products and services for faster delivery to their end customers. Depending on the level of participation, membership allows for:

  • Participation in the development of market requirements, specifications, roadmaps, and other technical guidelines that guide the work and perspective of the organization
  • Networking across member organizations, to gain a better understanding of needs that exist across various vertical and horizontal sectors
  • Review of specifications and other materials before they are available for public consumption
  • Better understanding of, and an ability to contribute to, global public policy issues impacting network identity

Q: What companies are on the Liberty Alliance Management Board?
A: There are currently 13 companies on the management board. They are: AOL Time Warner, Ericsson, Fidelity, France Telecom, General Motors, Hewlett-Packard Company, IBM, Intel, Novell, Oracle, RSA Security, Sun Microsystems, and Vodafone.

Q: What organizations have demonstrated interoperability of Liberty-enabled implementations?
A: They include AOL, Communicator Inc., Ericsson, HP, Jabber Inc., Mycroft, NeuStar, Nokia, Novell, NTT, Ping Identity Corporation, Phaos Technology, PostX, Sigaba, SchlumbergerSema, Sun Microsystems, Symlabs, Trustgenix, Vodafone, and Waveset.

Q: How has the Liberty Alliance worked to address privacy and security concerns?
A: The Liberty Alliance specifications and business guidelines have been built from the ground up with privacy and security in mind. This is reflected by the Alliance’s Public Policy Expert Group, which engages governments, regulatory bodies, and consumer advocacy organizations on a global basis. As a result, the Liberty specifications and guidelines enable companies to implement identity strategies that adhere to consumer and data privacy regulations.

Q: What does the Privacy and Security Best Practices document provide?
A: It offers guidance to help companies build more secure, privacy-friendly identity-based services that can be in compliance with local regulations and create a more trusted relationship with customers and partners. It covers the following issues:

  • Perspective on privacy and tools built into the Liberty Alliance specifications to assist implementers in building trusted identity-based services
  • Brief overview of global privacy laws and fair information principals
  • Privacy and security recommendations for Liberty implementers, highlighting the importance of providing users with access, notice, choice, control, and protection over their information
  • Guidance on protecting against Internet and implementation vulnerabilities

Q: How do the privacy and security best practices and privacy implementation guidelines differ?
A: The privacy implementation guidelines are more technically oriented and meant to provide specific guidance to Liberty Alliance implementers. The privacy and security best practices leans more towards education.

Q: How does Liberty benefit consumers?
A: Consumers will benefit from Liberty in three ways: They will maintain control over their personal information; they’ll have more personalized and valuable Web-based services from which to choose; and they’ll have more convenience in conducting business online.

Q: What specifications has Liberty Alliance Project released to date?
A: Phase 1.0, Phase 1.1, and Phase 2.
Q: What are the Phase 1 specifications?
A: A set of specifications that provide organizations with the ability to implement and deploy federated identity networks.
Q: What are the Liberty Phase 2 specifications?
A: A federation network identity architecture which offers a technology blueprint for
organizations that want to create innovative identity-based Web services.

Q: What is new in the Phase 2 specifications?
A: Phase 2 introduces the following new elements to Liberty Alliance’s Federated Network Identity architecture:

  • Affiliations
  • Anonymity
  • Permissions-based attribute sharing
  • Identity discovery services
  • Interaction service
  • Security profiles
  • Extended client support
  • Liberty’s first service interface specification
  • Personal Profile Services specification
  • Employee Profile Services specification

Q: Does ID-WSF build off version 1.1?
A: ID-WSF is designed to operate in concert with a federated identity framework, such as ID-FF version 1.1 — and now 1.2.

Q: How many services tracks may a member company participate in at the same time?
A: Sponsor companies may participate in as many services tracks as they wish. Associates may participate in a single services track as a benefit of their membership. They may participate in a second track for an additional fee. Affiliates may participate in as many tracks as they wish.

Technical questions

Q: Cookie management for LEP Profiles
A: Frequently, IdPs and SPs use cookies to maintain the session of the
principal. In LEP profile SSO exchanges, HTTP requests to SPs can result
in the HTTP response coming from the IdP, such as in the case where the IdP
sends a challenge to the principal. Similarly, HTTP requests to the IdP can
result in the HTTP response coming from the SP, such as after the principal
logs in, and receives the SP’s welcome page. As a result, these “crossed”
HTTP request/response pairs cause the browser to send an inappropriate
cookie (e.g., the browser stores the cookie received from the IdP following
an HTTP request to the SP as linked to the SP).

One solution to this at the LEP level is to register every cookie from the
SP and IdP and to include them on the requests from the principal.

Another solution is for the IdP to maintain the session of the principal (at
least for LEP Profile sessions) using cookie-based session management
through the use of a principal ID or alias sent by the LEP.

Q: Relative URLs for LEP Profiles
A: Relative URLs in SP and IdP pages can induce incorrect page display on an LEP
profile user browser. An SP page might be displayed following a user
request to the IdP, or an IdP page might be displayed following a request to
the SP, particularly when the IdP needs to interact with the user. This can
result in pages not being found (or being served incorrectly), as relative
links for those pages will be built by the browser with the wrong path
value.

There are cases where this is not a significant issue:

  • Where the IdP only has a few pages to display to the end user (mainly the
    challenge request), where the IdP can easily set absolute URLs for those
    pages.
  • Where the SP has only a few pages that lead to an authentication request
    (login page), where the SP can easily set absolute URLs for those pages.However, cases where every (or most) SP pages can potentially lead to an
    authentication request are more problematic.In this case, the SP does not ask “Do you want to login via the IdP?” but
    rather automatically generates an authentication request to the IdP when a
    user tries to access the SP for the first time of this session, such as when
    using a bookmark to a particular Web page of this SP. This case can be a
    typical scenario for mobile customers, who generally want to minimize their
    number of clicks and loaded Web pages when accessing an SP. This can impose
    an undue burden on the SP, of using absolute URIs on every SP page.A solution is to do this programmatically on the SP side. Code should
    already be implemented in front of the SP pages to automatically generate
    authentication requests on the first user connection. This code can be
    extended to manage the SP’s relative URLs — e.g., it can insert a “base” tag
    in the beginning of the HTML code, specifying the path for the request
    (<BASE HREF=”path for the request”). This tag will force the browser to
    rebuild the relative URLs with this path, causing the links to be displayed
    correctly.Q: Validation issues
    A: There are a number of cases where issues such as tool discrepancies can
    cause strange validation errors. This is by no means a comprehensive list:
  • Duplicate definitions.
    Duplicate definitions can be reported where external schemas that actually
    are identical, are imported with different URLs. For example, the schemas
    retrieved from:
    < xs:import namespace=”http://www.w3.org/2000/09/xmldsig#”
    schemaLocation=”http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-
    core-schema.xsd”/>
    and:
    < import namespace=”http://www.w3.org/2000/09/xmldsig#”
    schemaLocation=”http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd”/>
    are actually identical.Some tools may be capable of recognizing this, while others are not. In
    general, the options are clear — either edit all schemas to use the same
    URL, fix or update the tool, or ignore the error (strongly discouraged). In
    several cases, updating to newer versions of included files will fix the
    problem.
  • A WSDL validation error of: “This file is not valid: Mandatory elements
    expected in ‘soap:header’ after ‘use’: (headerfault)” is reported.” is
    displayed.This was caused by a bug in the tool, where the soap.xsd file it was using
    (stored internal to its directory structure) was incorrect. This was
    attempting to require the option element headerfault.This can be fixed by updating to the latest version of the tool, or manually
    updating the local soap.xsd file (sometimes found in
    ./schemas/wsdl/soap.xsd).
  • A WSDL validation error of: “This file is not valid: Required attribute
    ‘parts’ of element ‘soap:header’ missing” is displayed.This is also caused by a bug in the tool, where it misspelled the line:
    < xs:attribute name=”part” type=”xs:NMTOKEN” use=”required” />
    with “parts”.This can be fixed by updating to the latest version of the tool, or manually
    updating the local soap.xsd file (sometimes found in
    ./schemas/wsdl/soap.xsd).Q: What is required to demo ID-FF?
    A: You actually only need two entities, the IdP and the SP, although a good SSO
    demo would typically have multiple SPs involved. These entities can be on
    the same system or on different systems (different systems eliminates the
    need to explain to the people you are demoing to that you are emulating
    different providers on the same server).Frequently, if you contact companies that have achieved conformance through
    the Liberty Alliance process, the companies will be glad to work with you.Q: What namespace should ResourceIDs, and EncryptedResourceIDs be in?
    A: They should be in the namespace of the service. These elements are defined
    in the DST schema with no targetNamespace, but that schema is included in
    the service schema (such as ID-PP or ID-EP), and therefore get that
    namespace.FAQ on Liberty Alliance SAML v2.0 OASIS Standard Interoperability Testing

    Q: Why is Liberty Alliance extending its program to include SAML 2.0 OASIS Standard interoperability testing?
    A: There are three reasons. First, interoperability testing promotes adoption of our specifications. Development of the specifications and then the testing of them are key strategic initiatives for Liberty’s Identity Web Services Framework (ID-WSF), a platform for securing identity-based Web services. The framework directly supports the SAML 2.0 OASIS Standard, so we expect many users will employ both specifications. Interoperability testing of this spec, therefore, is key to ongoing Liberty development efforts. Second, our members want interoperability tests; there is marketplace demand for it. After all, it is their enterprise customers who are deploying these technologies, and our members want assurance that systems will, in fact, work with one another. Three, the program builds on Liberty’s successful leadership in interoperability conformance testing.

    Q:. How is Liberty’s SAML 2.0 OASIS Standard testing different from Liberty’s first wave of interoperability conformance testing?
    A: The SAML v2.0 OASIS Standard has incorporated all Liberty profiles defined in Liberty ID-FF 1.2. Specifically, it involves pairwise testing of case studies that adhere to the modes defined in the SAML 2.0 OASIS Standard. As such, our new test builds upon our previously developed profiles, but makes them directly applicable to the SAML v2.0 OASIS Standard. We will continue to offer testing on ID-FF 1.0, ID-FF 1.1, ID-FF 1.2, as well as ID-WSF 1.0; this is just another testing profile in our offering.

    Q: How does the SAML 2.0 OASIS Standard relate to Liberty Alliance work?
    A: Initially, Liberty defined its Identity Federation Framework (ID-FF) on the base provided by SAML v1.x, layering additional functionality on top. Recognizing the value of a single standard for federated SSO, Liberty members submitted ID-FF V1.2 back into the OASIS Security Services Technical Committee as input for SAML v2.0 in November 2003, which was approved as an OASIS Standard in March 2005. Additionally, the Liberty Web Services Framework (ID-WSF) uses SAML assertions as the base security token for enabling secure and privacy-respecting access to Web services.

    Q: How does Liberty’s Interoperable Logo Program for SAML 2.0 differ from testing programs that may be offered by OASIS?
    A: The Liberty Interoperable Logo Program measures interoperability among vendor implementations against specified profiles and schema. The program requires that vendors interoperate with at least two other vendors. This process involves pairwise testing of case studies that adhere to the modes defined in the SAML 2.0 OASIS Standard. Liberty also captures the actual testing directly off the wire so that vendors can have an official record of their performance. Upon successful completion of the test, Liberty issues a logo to those vendors who have signed Liberty’s trademark agreement. The logo is issued to a specific version of a specific product—not to the product family—again, offering buyer assurance that individual versions of products are indeed interoperable in a stated manner.

    OASIS is developing a conformance testing program for SAML to assure that products conform fully to the complete SAML specification. Further details will be available soon from OASIS.

    Interoperability testing and specification conformance testing are complementary but different activities. Without conformance testing, it is possible that two SAML implementations might actually pass an interoperability test, but yet not properly conform to the SAML specification. This might occur if the products are based on a common underlying toolkit that improperly interpreted the standard. As the OASIS SAML conformance testing will be vetted by the authors of SAML themselves, the OASIS criteria are designed to catch these instances and provide assurances of future interoperation and scalability beyond a bilateral agreement with a defined trading partner.

    Q: Does Liberty Alliance offer a formal stamp or a designation of some sort?
    A: Yes, Liberty issues a logo to those vendors that have signed our trademark license agreement and successfully completed the testing process. Once a company is declared to have successfully passed the test, Liberty will issue a press release and say, “Acme Corporation, along with these ten others, has successfully passed the SAML 2.0 or ID-FF or ID-WSF.” In other words, the logo mark is specific to what has been tested and what version of the vendor’s product has been tested. The vendor may then choose at their discretion to sign a trademark license agreement and that trademark license agreement, allows them to use the Liberty interoperable logo on their marketing materials and product packaging. They’re not obligated to do that, but they may do so if they choose.

    Q: When a company earns the Liberty Interoperable ä Logo Program mark, what exactly does it say to the market?
    A: It says that vendors who have been through this program will, in fact, interoperate cleanly with one another. It raises the probability that their products can be deployed successfully. It also minimizes the finger-pointing that typically goes on in these kinds of environments where one vendor points at the other guy saying, “Well, he didn’t implement the specifications correctly.” This won’t happen. Vendors will have already proven that they can interoperate in a standards-based environment.

    Q: Have any companies been certified yet?
    A: Liberty Alliance has conducted a conformance program since 2003, and we’ve run three tests so far on our ID-FF and ID-WSF specs. There are 15 companies and more than 30 different products that have successfully gone through testing at this point. So we’ve got a track record in how to do interoperability testing successfully. And we know that the market values this test based on requirements for Liberty logos within RFPs being issued in the marketplace. The addition of the SAML 2.0 OASIS standard to our ID-WSF testing is a natural extension of our successful program.

    Q: What about confidentiality?
    A: Confidentiality is a priority. Vendors are naturally concerned about what happens if they come to this test and have problems. Liberty Alliance has a very rigorous nondisclosure policy in place for those who are participating in the program, and participating vendors are protected from any kind of potential embarrassing leakage. The only thing that can be stated is the fact that a vendor has passed the test. We don’t even talk about who signed up for the test because that would then lead a good reporter to say, “Well, ten people signed up but only nine came out of it. Who didn’t come out and why?”

    Q: It sounds like the Liberty testing process is really developer-friendly.
    A: Definitely, and we offer a very collegial environment. The developers are competitors when they come out of the test, but it is in our mutual interest to make sure that the products work with one another. So the developers do spend a good deal of their time during the testing program to make sure that they’re mutually successful. It’s in a developer’s interest to discover whether or not they have problems going into the test and if some other vendor is experiencing problems. It’s also in their interest to help them through it, or to help them understand the interpretation of the specification.

    Q: For companies that were certified on the Liberty ID-FF 1.1 and 1.2, will it be easier to pass this new test?
    A: “Easy” is a relative term. Yes, these first companies will have had experience with the testing—so we would expect them to get through the program without a lot of hassle. But surprises creep up in the middle of the tests. Sometimes it takes effort to get through them. It really depends on the vendor.

    Q: When are you going to start the program?
    A: It began in July 2005, and tests will be held quarterly.

    Q: Do vendors need to do any specific preparation?
    A: We want vendors to be successful, so we sponsor a dry-run event in advance of the formal test. It’s like a dress rehearsal. In a dry run, the results are not recorded. This helps to promote informal collaborative interoperability testing among the vendors. If something is not quite working correctly, they can then go back and fix it before they come to the real test event. This approach also improves quality and minimizes false starts. It improves the throughput of the test because the vendor is required to test with at least two other vendors in order to achieve the logo.

    Q: Is the interoperability test open only to Liberty members—or can other vendors out there in the marketplace participate?
    A: Non-Liberty members can participate. In fact, non-Liberty members have participated in the past. There is a slightly different fee for members versus nonmembers, but there is no restriction as to whether members or nonmembers can attend. Note that the same nondisclosure constraints do apply to all participants, whether or not they are Liberty members.

    Q: How long does the process of certification take?
    A: There’s a week for the dry run, and a week for the actual test event itself. Vendors are bound by a nondisclosure agreement for both events. So are all the participants, the proctors, and those who monitor the tests. Strict confidentiality is central to the process. The tests are run both in the United States and internationally. We anticipate that we’ll hold them three or four times per year as the market demands.

    Q: How are the tests graded?
    A: There are written test procedures that the vendors must successfully execute and, having executed those procedures, the proctor of the test and the participating vendors sign off on a sheet of paper that says, “We three have observed this test and it was successfully conducted.” We also have line “sniffers” that capture the data transfers during the course of the test and we deliver those data transfers on CD-ROM to the vendors after the test event. This way if a customer were to say, “Show me your test results,” the vendor can pull up the CD-ROM.

    Q: What’s Liberty’s track record in interoperability testing?
    A: Over the past year and a half, we’ve held three different events—so we have a decent amount of experience within this sphere. We are the only organization that’s doing this kind of interoperability testing for federation and single sign-on. But we are not the only organization that’s doing third party interoperability conformance testing overall. Liberty considers its interoperability conformance program to be a strategic initiative. It’s one of the most important things that we do outside of actually creating the specifications and delivering those specifications and guidelines to market. The program gives people who are deploying this technology a high degree of confidence that the technology will actually work.

    Strong Authentication Expert Group Q & A

    Q: Why did Liberty Alliance form the Strong Authentication Expert Group?
    A: Stronger authentication has become a top priority for many Liberty members as well as for organizations and consumers around the world. The formation of the Strong Authentication Expert Group is a natural addition to Liberty’s mission of addressing “all things identity” and was formed to speed the deployment of interoperable strong authentication on a global basis.

    Q: What is strong authentication?
    A: Today, many organizations rely on passwords alone as the primary form of authenticating users online. And while passwords serve as adequate protection in a variety of network scenarios, organizations and consumers now need more than passwords alone to protect against online fraud and identity theft. Strong authentication requires at least two forms of identity authentication for accessing a network or online application. This often means, combining something a user “knows,” such as a password, with something a user “has,” such as a code from a token, DNA, etc., to ensure secure online authentication.

    Q: What types of strong authentication exist today?
    A: Organizations have both deployed and are investigating many forms of strong authentication. These include hardware and software tokens, smart cards, SMS-based systems and biometrics. All of these systems offer strong authentication capabilities and are deployed within various organizations and vertical market segments around the world.

    Q: Why is Liberty’s Strong Authentication Expert Group needed?
    A: While many organizations have deployed stronger authentication technologies, many more are facing challenges as they move to meet the demand for increased security and identity protection. Most of today’s strong authentication solutions have been built using proprietary technologies and developed based on the requirements of specific vertical market segments. Many of these solutions have not been developed to interoperate with one another and can be costly to deploy. Liberty’s Strong Authentication Expert Group will aim to remove these barriers and help organizations in all vertical segments move to deploy universal strong authentication faster and more cost effectively.

    Q: What is “universal strong authentication?”
    A: This means providing strong authentication from any network and from any device, at any time. This “anywhere and anytime” functionality is what Liberty’s Strong Authentication Expert Group is working to deliver. With universal strong authentication, organizations can offer consistent strong authentication capabilities across networks, applications and vertical market segments. This far-reaching protection will help organizations and consumers dramatically reduce the threats that can lead to online fraud and identity theft.

    Q: How will Liberty’s Strong Authentication Expert Group speed the deployment of universal strong authentication?
    A: In order for universal strong authentication to become an industry-wide reality, an open framework is required to allow the varying types of strong authentication solutions to interoperate with one another. Liberty’s Strong Authentication Expert Group will develop ID-SAFE (Identity Strong Authentication Framework), a framework based on open standards that will allow strong authentication solutions such as smart cards, tokens and biometrics to easily interoperate across organizations, networks and vertical market segments.

    Q: Is Strong Authentication a new Liberty Alliance initiative?
    A: Many of our members, including those working in financial services, the global security market and various government sectors, have been working on strong authentication initiatives for quite some time. Liberty Alliance has also been working for the past year developing the market requirements for appropriately deploying strong authentication in a federated environment. With the formation of the expert group, Liberty is combining and leveraging this experience to begin the technical development process for building an industry framework and open specifications for interoperable strong authentication in additional user scenarios beyond a federated situation.

    Q: What Liberty members are participating in this group?
    A: Since Liberty formed the group in October, there has been exceptional interest among our membership. Some of the members currently participating in the Strong Authentication Expert Group include American Express, Axalto, BMC Software, Diversinet Corp., Falkin Systems LLC, Financial Services Technology Consortium, HP, Intel, Kantega AS, NEC, NTT, Oracle, RSA Security, US Department of Defense / Defense Data Manpower Center, Vodafone, VeriSign, Inc. and Wave Systems. Membership in the Strong Authentication Expert Group is open to all Liberty sponsor and board members interested in helping to drive interoperable strong authentication.

    Q: Who will be most interested in ID-SAFE?
    A: Any organization needing to implement stronger authentication will be interested in taking a close look at ID-SAFE and becoming involved in its development. While many organizations are moving to deploy some means of strong authentication, others may be compelled to do so based on customer demands, business requirements or some type of government regulation. The recent guidance issued by the US FFIEC is a good example of how governments are approaching strong authentication issues.

    Q: What kind of guidance did the US FFIEC issue?
    A: Last month the Federal Financial Institutions Examination Council (FFIEC) released “Authentication in an Internet Banking Environment.” Developed for banks offering Internet-based financial services, the guidance describes enhanced authentication methods that regulators expect banks to use when authenticating the identity of customers using on-line products and services. Financial institutions will be expected to achieve compliance with the guidance no later than year-end 2006.

    Q: Are other governments/countries looking to do the same thing?
    A: Yes, and while the type and extent of guidance issued by governments tends to vary from country to country, Australia, Belgium, Brazil, Denmark, Hong Kong, Singapore and the UK, are either requiring or promoting some degree of strong authentication in various vertical segments. We will undoubtedly see other governments implement similar requirements for stronger authentication during the coming months.

    Q: Did the US FFIEC guidance influence Liberty’s decision to form the Strong Authentication Expert Group?
    A: While there can be no doubt that the work of the group will help financial organizations around the world meet requirements for stronger authentication, the need for universal strong authentication is very real across all vertical segments around the world. Liberty formed the group to help all organizations meet the increased demand and requirements for stronger authentication.

    Q: Why is Liberty qualified to lead the development of open specifications for interoperable strong authentication?
    A: Liberty is modeling the ID-SAFE technical development process on the successes we have had in quickly developing open identity specifications for federated identity management (Liberty Federation Framework, ID-FF) and Web services (Liberty Web Services Framework, ID-WSF), resulting in rapid deployments and worldwide implementations. It took less than seven months from the time Liberty was formed in 2001 for us to deliver our first set of open identity specifications and we intend to replicate this pace with the development of ID-SAFE.

    Q: How is Liberty able to develop specifications so quickly?
    A: Liberty’s consistent approach to developing open identity frameworks and specifications always involves gathering market requirements before technical specifications are developed. This means working with members that include end users, governments, educational organizations and vendor members, to define specific use scenarios, and then submitting these tightly defined scenarios to a technology group for specification development. The result is specifications that are easily deployable and applicable “out-of-the-gate” to well defined end user needs.

    Q: Aren’t there other organizations already working to advance interoperable strong authentication?
    A: Yes, there are organizations that have been doing some preliminary work in interoperable strong authentication. But if the industry is to meet the growing demand for better online security and identity protection, a global effort spanning all vertical segments and worldwide regions is required. With members including government organizations, businesses and end users from around the world, Liberty has the experience and membership to speed the deployment of interoperable strong authentication on a global basis.

    Q: Will Liberty be working with these groups?
    A: Liberty Alliance regularly incorporates relevant work from other open standards bodies into its specifications and welcomes any open standards organization to participate in the development of ID-SAFE.

    Q: What benefits will ID-SAFE bring to organizations?
    A: ID-SAFE will drive the costs of implementing strong authentication down while allowing organizations to deploy better security and identity protection across all vertical segments. Widely deployed strong authentication will provide companies with opportunities to focus more on developing new business lines and e-commerce offerings without having to rely on passwords alone for identity protection.

    Q: What benefits will ID-SAFE bring to consumers?
    A: With Liberty strong authentication, consumers will have increased protection against identity theft and fraud, a seamless user experience across networks and advanced privacy protection – from anonymous to strong – based on individual user consent and controls.

    Q: How does the formation of the Strong Authentication Expert Group vary from what Liberty has been doing in federated identity management and Web services?
    A: Work stemming from Liberty’s new Strong Authentication Expert Group goes hand-and-hand with the work we have been doing in open, interoperable identity specifications. The key word here is “interoperable.” For example, one concern already cited in the financial sector is the emergence of “token necklaces,” requiring consumers to have multiple tokens for authenticating at the various financial organizations where they have accounts. ID-SAFE aims to enable these strong authentication mechanisms to interoperate, reducing costs, increasing security and improving ease of use.

    Q: When will ID-SAFE be released?
    A: Market requirement work for interoperable strong authentication has been ongoing for the past year and the group is leveraging this work to develop ID-SAFE. Based on our history in bringing open specifications to market quickly, we expect to make significant progress in 2006.
    Q: When can we expect to see more news about ID-SAFE?
    A: We see the first news surrounding ID-SAFE focusing on the release of the initial framework and draft specifications. Once Liberty releases a draft version of specifications, they are available to everyone – both Liberty members and non-members alike — for comment and review. The Strong Authentication Expert Group then works to incorporate input from the review into final specifications. The first draft of the ID-SAFE framework will likely be released publicly in mid 2006.

    Q: Where can we get more information on Liberty’s Strong Authentication Expert Group?
    A: Detailed information is available on our Web site at www.projectliberty.org.. Organizations and individuals interested in joining Liberty’s Strong Authentication Expert Group can contact Andrew Shikiar at Andrew@projectliberty.org.

    IPR

    Q: What is a general description of Liberty’s IPR policy?
    A: As a condition of membership, each Liberty member by default agrees to grant to anyone, member or nonmember, any royalty free license needed to develop and sell a fully compliant implementation of any final Liberty specification. This royalty free license may be made subject to the condition that those who seek licenses agree to grant the participant, and all others, a reciprocal royalty free license.

    While this default policy was created to benefit all those implementing the final Liberty specifications, the policy also offers a degree of flexibility to ensure that companies concerned with protecting their existing IP portfolio can still participate in the specification development process. To this end, members can elect to withdraw from the default royalty free license and instead offer Reasonable and Non-Discriminatory (RAND) terms. This election can only be made during IP review periods that are present during the specification development process.

LEAVE A REPLY

Please enter your comment!
Please enter your name here