These FAQs address a variety of technical issues related to our specifications.
- What is a general description of Liberty’s IPR policy?
- Can you explain Cookie management for LEP Profiles?
- Can you explain relative URLs for LEP Profiles?
- Are there validation issues to be aware of?
- What is required to demo ID-FF?
- What namespace should ResourceIDs, and EncryptedResourceIDs be in?
What is a general description of Liberty’s IPR policy?
As a condition of membership, each Liberty member by default agrees to grant to anyone, member or nonmember, a royalty free license to patents required to develop, sell, or otherwise distribute 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 patent owner, and all others, a reciprocal royalty free license.
While the default policy was created to foster ubiquitous adoption and benefit all those implementing the final Liberty specifications, the policy also offers a degree of flexibility and protection to ensure member companies concerned with protecting their existing IP portfolio may 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 specific 45-day IP review periods during the specification development process and not thereafter. As an additional protection to implementers of Liberty specifications, any such withdrawal to RAND must be accompanied by a detailed necessary claims chart that must include: details of the patent(s) involved in the claim, the portion of the specific specification where the withdrawing member believes an infringement would arise and an explanation of the nature of the infringement, which includes a claim chart mapping each element of the necessary claim with the corresponding element of the specific specification portions identified. These claims are made available to the public.
As you can see, the Liberty Alliance is essentially a royalty free organization with very few RAND exceptions which are clearly documented and made available to the public. We believe this is an industry best practice which has been responsible for allowing large RAND-oriented organizations to participate in the specification develop while simultaneously fostering mass adoption of the specifications.
The Liberty Alliance has made contributions to other standards bodies. Our work with OASIS on the SAML 2.0 specification has been instrumental to driving convergence and adoption. Information regarding known SAML IPR statements and declarations is available here.
Can you explain Cookie management for LEP Profiles?
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.
Can you explain relative URLs for LEP Profiles?
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.
Are there validation issues to be aware of?
There are a number of cases where issues such as tool discrepancies can cause strange validation errors. This is by no means 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#”
< import namespace=”http://www.w3.org/2000/09/xmldsig#”
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 manuallyupdating the local soap.xsd file (sometimes found in ./schemas/wsdl/soap.xsd).
What is required to demo ID-FF?
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.
What namespace should ResourceIDs, and EncryptedResourceIDs be in?
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.