Nat Sakimura has written a valuable post describing how to write an OpenID Connect server in three simple steps. It shows by example how simple it is for OAuth servers to add OpenID Connect functionality. This post is a companion to his previous post OpenID Connect in a Nutshell, which described how simple it is to build OpenID Connect clients. If you’re involved in OpenID Connect in any way, or are considering becoming involved, these posts are well worth reading.
Archive for the 'Documentation' Category
Nat Sakimura has written a valuable post describing OpenID Connect in a nutshell. It shows by example how simple it is for relying parties to use basic OpenID Connect functionality. If you’re involved in OpenID Connect in any way, or are considering becoming involved, his post is well worth reading.
A new set of open identity protocols is emerging that utilizes JSON data representations and simple REST-based communication patterns. These protocols and data formats are intentionally designed to be easy to use in browsers and modern web development environments.
I hope you’ll find it worthwhile reading. I’m looking forward to discussing it with many of you at the workshop!
Microsoft has published the fifth in a series of step-by-step guides on configuring AD FS 2.0 to interoperate with partner products. This guide describes how to configure AD FS 2.0 and IBM Tivoli Federated Identity Manager to federate using the SAML 2.0 protocol. The guide is available in HTML format and soon also Word and PDF. Thanks again to author Dave Martinez for making this series a reality!
Microsoft has published the fourth in a series of step-by-step guides on configuring AD FS 2.0 to interoperate with partner products. This guide describes how to configure AD FS 2.0 and Ping Identity PingFederate to federate using the SAML 2.0 protocol. The guide is available in Word and PDF formats and also HTML. Thanks again to author Dave Martinez, and special thanks to Ping Identity for sponsoring this guide.
Microsoft has published the third in a series of step-by-step guides on configuring AD FS 2.0 to interoperate with partner products. This guide describes how to configure AD FS 2.0 and Shibboleth to federate using the SAML 2.0 protocol. There is also an appendix on federating with the InCommon Federation. The guide is available in Word format and HTML. Thanks again to author Dave Martinez.
Microsoft has published the second in a series of step-by-step guides on configuring AD FS 2.0 to interoperate with partner products. This guide describes how to configure AD FS 2.0 and Oracle Identity Federation 184.108.40.206, as delivered in Oracle Identity Management 220.127.116.11, to federate using the SAML 2.0 protocol. The guide is available in HTML and Word formats. Thanks again to author Dave Martinez.
Microsoft has published the first of a series of step-by-step guides on configuring AD FS 2.0 to interoperate with partner products. This guide describes how to configure AD FS 2.0 and CA Federation Manager r12.1 to federate using the SAML 2.0 protocol. The guide is available in HTML and Word format. Thanks go to author Dave Martinez for his expert and detailed treatment of the topic.
This morning at the RSA conference, Scott Charney announced that Microsoft has licensed the U-Prove technology under the Open Specification Promise and released sample implementations in C# and Java under the BSD license. Implementers will be interested in two specifications: the “U-Prove Cryptographic Specification V1.0”, which documents U-Prove’s cryptographic operations, and “U-Prove Technology Integration into the Identity Metasystem V1.0”, which documents how to use U-Prove tokens with WS-Trust. These specifications are intended to enable interoperable implementations.
The U-Prove technologies enable two key properties: minimal disclosure and unlinkability. For more about U-Prove and today’s Community Technology Preview (CTP) release, see the Microsoft U-Prove site, the post announcing the release, and Vittorio’s post (with links to videos).
Today Microsoft announced the availability of new releases of several identity products: Active Directory Federation Services (AD FS) 2.0, the Windows Identity Foundation, and CardSpace 2 (which collectively were formerly referred to as “Geneva”), as well as Federation Extensions for SharePoint. See Announcing the AD FS 2.0 Release Candidate and More and Announcing WIF support for Windows Server 2003 for the release announcements as well as links to numerous step-by-step guides, samples, docs, and video. Thanks to all those who did interop work with us (including at Catalyst, Liberty, and pair-wise) to help ensure that these releases will work well with other’s implementations.
I’m thrilled to announce that the Identity Metasystem Interoperability Version 1.0 specification has been approved as an OASIS standard, with 56 votes in favor and none against. This standard benefitted substantially from the input received during the process. Numerous clarifications were incorporated as a result, while still maintaining compatibility with the Identity Selector Interoperability Profile V1.5 (ISIP 1.5) specification.
While this is often said, this achievement is truly the result of a community effort. While by no means a comprehensive list, thanks are due to many, including the OSIS members whose diligent efforts ensured that Information Cards are interoperable across vendors and platforms, the Information Card Foundation members for their adoption and thought leadership work, and the IMI TC members, including co-chairs Marc Goodner and Tony Nadalin, and Mike McIntosh, who was my co-editor. Paul Trevithick and Mary Ruddy get enormous credit for starting and leading the Higgins Project, as does Dale Olds for the Bandit Project. Kaliya Hamlin and Phil Windley were instrumental behind the scenes by running the IIWs. Axel Nennker has been a tireless force, producing both ideas and software, as has Pamela Dingle. Jamie Lewis, Bob Blakley, and Craig Burton all provided insightful guidance on the practical aspects of birthing a new technology. Arun Nanda deserves enormous thanks for doing the heavy lifting to produce the ISIP 1.0 spec. And of course, none of this would have occurred without the leadership and vision of Kim Cameron. Thanks one and all!
Microsoft published a knowledge base article today giving examples of intermediate data values produced when generating actual PPID, ClientPseudonym, and Signing Key values. These examples use the algorithms specified in ISIP 1.5 to go behind the scenes of specific OSIS interop computations.
In particular, the article shows how to correctly generate the PPID and Signing Key values for the test Selector_Constructs_Site-Specific_Identifiers_for_Self-Issued_Cards and how to generate the ClientPseudonym value for the test Selector_Support_for_Non-Auditing_Cards. These examples are also highly relevant to the tests Selector_PPID_Construction_for_RP_using_EV_SSL, Selector_Support_for_Auditing-Optional_Cards, and Selector_Support_for_Auditing_Cards.
Thanks to Toland Hon of the “Geneva” test team for writing this useful article.
Relying Parties often identify subjects using the Private Personal Identifier (PPID) claim and Signing Key values sent by an Information Card. Thus, it is important that the PPID and Signing Key values produced by a card be stable and long-lived.
Unfortunately, the PPIDs and Signing Keys generated by self-issued (a.k.a. personal) Information Cards using the algorithm originally shipped with Windows CardSpace (and documented in ISIP V1.0) for sites using regular certificates were not stable under several important conditions. Therefore, after considering industry feedback on the long-term problems that this continued instability would cause, and in consultation with other Identity Selector authors, a decision was made to change these algorithms in a way that will provide much better long-term stability of these important Subject identifiers for Relying Parties. The new algorithm is documented in the Identity Selector Interoperability Profile (ISIP) V1.5.
This change shipped with the version of Windows CardSpace in the .NET Framework 3.5 Service Pack 1. This service pack will be installed by Windows Update on systems with the .NET Framework 2.0, 3.0, and 3.5 in the coming months. I know that the Bandit and Higgins projects have implemented the new algorithm as well.
Unfortunately, this change means that the PPIDs and Signing Keys for self-issued cards used at existing Relying Parties that employ standard SSL certificates will change after this installation.
What Sites Need to Do
Sites need to ensure that they have tested mechanisms in place to enable their users to re-associate their Information Card with their account when the card’s PPID and Signing Key change. The good news is that these mechanisms are likely already in place in the form of “lost card” handling procedures.
When the card is used after the update, it will appear to be an unrecognized card. Just as sites’ lost card procedures can be used today to associate a new Information Card with their account, these same procedures can be used to re-associate the existing card with the account after these changes.
These lost card procedures will typically involve sending the user a message at the e-mail address of record for the account. This message contains a link that enables them to associate an Information Card with their account. This flow is nearly identical to the “lost password” flows often found on sites. Best practices for lost card handling are documented in the “Enabling Information Card Recovery” section of Patterns for Supporting Information Cards at Web Sites: Personal Cards for Sign up and Signing In.
Additional Steps Sites Could Take
In the short term, sites could also choose to add text to their Information Card login pages warning users that their existing cards will not be recognized as being associated with their accounts after the .NET update, and directing them to use the “lost card” feature of the site to remedy this situation.
EV and no-SSL Sites Not Affected
None of this affects sites using Extended Validation (EV) certificates or sites not using SSL certificates. These algorithms were already stable and have not changed. No action is required in these cases.
Background on the Problem
Because the original PPID and Signing Key algorithms used the entire certificate chain, these values could change under several circumstances:
- First, as sites renew their certificates, it is common for the certificate chain for the new cert to differ from the old one. This would change the PPID, breaking the user’s self-issued cards at those sites. And of course, the chain always changes if the site changes its certificate provider.
- Second, because the algorithm for converting the bytes of the chain certificates into characters was not fully specified by ISIP V1.0 for some OIDs, for some kinds of certificates, different Identity Selectors produced different results for the PPID claim, Signing Key, Client Pseudonym PPID, and IP Identifier values.
- Finally, in ISIP V1.0, the PPID for a site using a non-EV certificate is different than the PPID for a site that uses an EV certificate, even in the case where the non-EV leaf cert content meets the EV issuance criteria. This means that when a site upgraded to using an EV certificate, user’s cards would stop working at that site.
Overview of the Solution
To address these issues, the computation of the PPID and Signing Key for sites using regular certificates has been changed to no longer include information from the certificate chain, but only information from the leaf certificate. This will provide stability both when certificates are renewed and when a certificate is obtained from a new issuer.
Furthermore, the new algorithm generates the same PPID values for sites using EV and non-EV certificates with the same leaf certificate information, while generating different Signing Keys. This will help enable a smooth migration path for sites upgrading from non-EV to EV certificates because the PPID remaining the same can be used as evidence that the same card is being used before and after the certificate upgrade.
More about the specifics of the algorithm change can be found in Section 8.6.1 of ISIP V1.5 and additional guidance and commentary can be found in the corresponding section of the ISIP V1.5 Guide.
IBM and Microsoft just published the specification “Application Note: Web Services Addressing Endpoint References and Identity” at http://schemas.xmlsoap.org/ws/2006/02/addressingidentity/. This specification is referenced by the Identity Selector Interoperability Profile (ISIP) and is covered by Microsoft’s Open Specification Promise (OSP). This completes the publication and licensing under the OSP of all specifications that Information Cards based upon the ISIP depend upon.
Note: While ISIP 1.5 references the addressing identity extension using a date of July 2008, it was actually published in August. This is an erratum in the ISIP that resulted from the publication of the extension taking longer than anticipated – not a reference to a different document. Both consistently use the URL http://schemas.xmlsoap.org/ws/2006/02/addressingidentity/.
I am pleased to announce the publication of the Identity Selector Interoperability Profile V1.5 and companion guides. The ISIP (as it’s come to be called) documents the protocols and data formats used by Windows CardSpace so as to enable others to build compatible Information Card software.
Version 1.0 of these documents corresponded to the.NET Framework 3.0 version of CardSpace. Version 1.5 corresponds to CardSpace as of .NET Framework 3.5 Service Pack 1. Like the previous version, ISIP 1.5 is licensed under Microsoft’s Open Specification Promise.
Significant new content covers:
- Relying Parties without SSL certificates
- Use of WS-Trust 1.3 and WS-SecurityPolicy 1.2
- Relying Party STSs
- More stable PPID algorithm
- Specifications for computing ic:IssuerId and ic:IssuerName
- Token references by Identity Providers via wst:RequestedAttachedReference and wst:RequestedUnattachedReference elements
- Custom issuer information in cards
- Custom error messages
- Clarification that an ic:MasterKey is required for managed cards
- Plus numerous of clarifications that were found by others building Information Card software – especially during the OSIS interops
The three new document versions are:
- Identity Selector Interoperability Profile V1.5 by Arun Nanda and yours truly, which provides normative specifications of the protocol elements and data interchange formats employed by CardSpace-compatible Identity Selectors and other interoperable Information Card components,
- An Implementer’s Guide to the Identity Selector Interoperability Profile V1.5, co-authored by Microsoft and Ping Identity, which provides informative advice and commentary on how to use the ISIP specifications when building interoperable Information Card software, and
- A Guide to Using the Identity Selector Interoperability Profile V1.5 within Web Applications and Browsers, also by yours truly, which provides informative advice and commentary on how these specifications are used by Web sites that accept Information Cards and by Web browsers when communicating with these sites.
Thanks to the literally dozens of you who provided comments on ways to improve the ISIP and companion docs and who reviewed drafts of this material. This version of the docs benefited substantially from your detailed knowledge of and experience with the previous spec gained through implementing interoperable Information Card software.
Finally, I’d like to thank the members of the CardSpace team who diligently documented many of these features on the CardSpace Team Blog in advance of their publication under the ISIP. Your work let the industry gain early experience with implementing these features and was a tremendous resource to me as I was producing these versions of the documents.
Microsoft recently created a Consumer Website for CardSpace to educate end-users about Windows CardSpace and Information Cards. This complements the developer-focused information at the MSDN CardSpace site and the CardSpace Community Site.
No, it’s not the kind of content targeted at regular readers of this blog – especially the short video – but then, that’s kind of the point. :-)
The ANSI-BBB Identity Theft Prevention and Identity Management Standards Panel recently issued its final report. Quoting from the report announcement:
Launched in September 2006, the IDSP was established by the American National Standards Institute (ANSI) and Better Business Bureau (BBB) to identify and catalog existing standards, guidelines, and best practices related to identity theft prevention.
Panel members considered the entire life cycle of identity management: from the issuance of identity documents by government and commercial entities, to the acceptance and exchange of identity data, and to the ongoing maintenance and management of identity information. Hundreds of documents – including the applicable laws, regulations, proposed legislation, white papers, and research studies and reports – are identified in the catalog.
The report also includes recommendations for business and government agencies to:
- enhance the security of identity issuance processes to facilitate greater interoperability between the government and commercial sectors;
- improve the integrity of identity credentials;
- strengthen best practices for authentication;
- augment data security management best practices such as the use and storage of Social Security numbers;
- create uniform guidance for organizations on data breach notification and remediation;
- increase consumer understanding of ID theft preventative strategies, including the benefits and limitations of security freezes.
This report provides one of the most comprehensive looks to date at the problem of identity theft and the fraud that accompanies it. It both surveys the current identity landscape and makes recommendations for business, government, and consumers to mitigate these threats both in the offline and online environments.
Understanding Windows CardSpace: An Introduction to the Concepts and Challenges of Digital Identities by Vittorio Bertocci, Garrett Serack, and Caleb Baker, is now in print!. As I wrote for the “praise page” of the book:
Chock full of useful, actionable information covering the “whys”, “whats”, and “hows” of employing safer, easier-to-use, privacy-preserving digital identities. Insightful perspectives, on topics from cryptography and protocols to user interfaces and online threats to businesses drivers, make this an essential resource!
Come ’n get it!
This morning at the Internet Identity Workshop, the OpenID Foundation announced that the OpenID 2.0 Specification and a set of related specifications are now complete. Furthermore, Intellectual Property Contribution Agreements have been executed by all the contributors to these specifications.
Here’s a camera-phone photo of Dick Hardt of Sxip Identity, Josh Hoyt of JanRain, and David Recordon of Six Apart making the announcement. Congratulations to the OpenID community on this significant accomplishment!