Category: Federation Page 3 of 4

First Release Candidates for final OpenID Connect specifications

On October 15, 2013

In Claims, Federation, JSON, OAuth, OpenID, Specifications

I’m pleased to announce that the first release candidate versions for final OpenID Connect specifications have been published. The complete set of specifications has been updated to resolve all issues that had been filed against the specs being finished.

Please review these this week, in time for the in-person working group meeting on Monday. Besides publishing the specs in the usual formats, I’ve also created a Word version of the core spec with tracked changes turned on to facilitate people marking it up with specific proposed text changes. If you’re in the working group, please download it and make any corrections or changes you’d like to propose for the final specification.

The release candidate spec versions are:

Also, two implementer’s guides are also available to serve as self-contained references for implementers of basic Web-based Relying Parties:

Thanks to Nat Sakimura for the early feedback. The structure of Core has been changed somewhat since -13 to adopt some of his suggestions.

OpenID Connect Specs Nearing Completion

On October 13, 2013

In Claims, Federation, JSON, OAuth, OpenID, Specifications

Based on feedback from developers, the OpenID Connect working group decided to replace the OpenID Connect Messages and OpenID Connect Standard specifications with a new OpenID Connect Core specification that combines the contents from both of them before finishing OpenID Connect. The content has also been restructured to separate Authentication from other features such as Claims and to have separate Authentication sections for the different OAuth 2.0 flows. No changes to the protocol were made. The publication of this new spec is another major step towards finishing OpenID Connect.

Please review this and the other OpenID Connect specifications in the coming week. While a few local changes will still be made this week to address issues that have been identified since the approval of the Implementer’s Drafts, I fully expect that the working group will decide at the in-person working group meeting just over a week from now that it’s time to publish proposed final specifications.

Thanks to Nat Sakimura for producing a proof-of-concept document restructuring that the structure of the current OpenID Connect Core spec is based upon. And thanks to Torsten Lodderstedt for convincing us that the specs will be clearer by better separating the descriptions of logically distinct features while combining previously separate descriptions of highly interrelated functionality.

Proposed Second OpenID Connect Implementer’s Drafts Published

On June 7, 2013

In Claims, Federation, JSON, OAuth, OpenID, Specifications

Today marks another significant milestone towards completing the OpenID Connect standard. The OpenID Foundation has announced that the 45 day review period for the second set of proposed Implementer’s Drafts has begun. The working group believes that these are stable and complete drafts. They are being proposed as Implementer’s Drafts, rather than Final Specifications at this time, because of the dependencies on some IETF specifications that are still undergoing standardization — primarily the JSON Web Token (JWT) specification and the JSON Object Signing and Encryption (JOSE) specifications underlying it.

An Implementer’s Draft is a stable version of a specification intended for implementation and deployment that provides intellectual property protections to implementers of the specification. These updated drafts are the product of incorporating months of feedback from implementers and reviewers on earlier specification drafts, starting with the previous Implementer’s Drafts, including feedback resulting from several rounds of interop testing. Thanks to all of you who have been working towards the completion of OpenID Connect!

These specifications are available at:

Fourth Release Candidates for OpenID Connect Implementer’s Drafts

In Claims, Events, Federation, JSON, OAuth, OpenID, Specifications

A fourth set of release candidates for the upcoming OpenID Connect Implementer’s Drafts has been released. Changes since the third release candidates mostly consist of editorial improvements. There were only two changes that will result in changes to implementations. The first was replacing the “updated_time” claim, which used a textual date format, with the “updated_at” claim, which uses the same numeric representation as the other OpenID Connect date/time claims. The second was replacing the “PKIX” JWK key type with the “x5c” JWK key member (a change actually made this week by the JOSE working group).

These are ready for discussion at Monday’s in-person OpenID Connect working group meeting. All issues filed have been addressed.

The updated specifications are:

These specifications did not change:

Thanks to all who continued reviewing and implementing the specifications, resulting in the improvements contained in this release. I’ll look forward to seeing many of you on Monday!

Third Release Candidates for OpenID Connect Implementer’s Drafts

On March 27, 2013

In Claims, Federation, JSON, OAuth, OpenID, Specifications

A third set of Release Candidates for the pending OpenID Connect Implementer’s Drafts have been released. Like the first set, the second set of Release Candidates, which were published earlier this month, also received thorough review, resulting in a smaller set of additional refinements. The changes primarily made some the claim definitions more precise and provided more guidance on support for multiple languages and scripts.

Were it not for a set of pending changes about to be made to the JSON Object Signing and Encryption (JOSE) specifications, this set of specifications would likely actually be the Implementer’s Drafts. However, the OpenID Connect working group made the decision to have those (non-breaking) JOSE changes be applied before we declare that the Implementer’s Drafts are done. Expect announcements about both the JOSE updates and the OpenID Connect Implementer’s Drafts soon.

The new specifications are:

See the History entries in the specs for more details on the changes made.

Thanks again to all who reviewed and implemented the recent drafts!

The Emerging JSON/REST-Based Identity Protocol Suite

On March 15, 2013

In Claims, Cryptography, Events, Federation, JSON, OAuth, OpenID, Specifications

Last week at the Japan Identity and Cloud Symposium I gave a presentation on this topic: A new set of simple, open identity protocols is emerging that utilize JSON data representations and REST-based communication patterns, including OAuth, JSON Web Token (JWT), JSON Object Signing and Encryption (JOSE), and WebFinger. I’ve posted PowerPoint and PDF versions of the presentation.

Thanks again to the organizers of JICS 2013 for a great event!

Second Release Candidates for OpenID Connect Implementer’s Drafts

On March 6, 2013

In Claims, Federation, JSON, OAuth, OpenID, Specifications

I’m pleased to announce that a second set of Release Candidates for the upcoming OpenID Connect Implementer’s Drafts have been released. The first set of Release Candidates received thorough review, resulting in quite a bit of detailed feedback. The current specs incorporate the feedback received, making them simpler, more consistent, and easier to understand.

Please review these this week — especially if you had submitted feedback. The working group plans to decide whether we’re ready to declare Implementer’s Drafts during the OpenID Meeting before IETF 86 on Sunday.

The new specifications are:

See the History entries in the specs for details on the changes made.

Thanks again to all who did so much to get us to this point, including the spec writers, working group members, and especially the implementers!

An update on our war against account hijackers

On February 20, 2013

In Federation, Phishing Resistance, Security

I recommend reading Google’s post An update on our war against account hijackers. It describes the kinds of measures taken by professionally-run Identity Providers to defend against account takeover.

A message not stated but implied is that consumers and Web sites are far better off depending upon identities provided by organizations with the resources and dedication to successfully fight takeover attempts. Sites with their own username/password login systems without these defenses are vulnerable, and would be better off using federated identities from professionally-run Identity Providers.

Release Candidates for OpenID Connect Implementer’s Drafts

On January 23, 2013

In Claims, Federation, JSON, OAuth, OpenID, Specifications

I’m pleased to announce that release candidate versions of the soon-to-come OpenID Connect Implementer’s Drafts have been released. All the anticipated breaking changes to the protocol are now in place, including switching Discovery over from using Simple Web Discovery to WebFinger and aligning Registration with the OAuth Dynamic Client Registration draft. While several names changed for consistency reasons, the changes to Discovery and Registration were the only architectural changes.

Please thoroughly review these drafts this week and report any issues that you believe need to be addressed before we release the Implementer’s Draft versions.

Normative changes since the December 27th, 2012 release were:

Use WebFinger for OpenID Provider discovery instead of Simple Web Discovery. This also means that account identifiers using e-mail address syntax are prefixed by the acct: scheme when passed to WebFinger.
Aligned Registration parameters with OAuth Dynamic Registration draft.
Added Implementation Considerations sections to all specifications, which specify which features are mandatory to implement.
Removed requirement that the “c_hash” and “at_hash” be computed using SHA-2 algorithms (for crypto agility reasons).
Refined aspects of using encrypted ID Tokens.
Finished specifying elements of key management for self-issued OPs.
Added “display_values_supported“, “claim_types_supported“, “claims_supported“, and “service_documentation” discovery elements.
Defined REQUIRED, RECOMMENDED, and OPTIONAL discovery elements.
Refined Session Management specification, including descriptions of OP and RP iframe behaviors.
Deleted “javascript_origin_uris“, which is no longer present in Session Management.
Added new “session_state” parameter to the authorization response for Session Management.
Added new “post_logout_redirect_url” registration parameter for Session Management.

Also, renamed these identifiers for naming consistency reasons:

user_jwk -> sub_jwk (used in self-issued ID Tokens)
token_endpoint_auth_type -> token_endpoint_auth_method
token_endpoint_auth_types_supported -> token_endpoint_auth_methods_supported
check_session_iframe_url -> check_session_iframe
end_session_endpoint_url -> end_session_endpoint
type -> operation (in Registration)
associate -> register (in Registration)
application_name -> client_name
check_session_endpoint -> check_session_iframe

See the History entries in the specifications for more details.

The new specification versions are at:

Thanks to all who did so much to get us to this point, including the spec writers, working group members, and implementers!

OAuth 2.0 and Sign-In

On January 2, 2013

In Federation, OAuth, OpenID

OAuth logo I highly recommend a piece that my friend Vittorio Bertocci wrote on the relationship between OAuth 2.0 and sign-in/federation protocols. While OAuth 2.0 can be used to sign in users and the term “OAuth” is often bandied about in identity contexts, as he points out, there’s a lot of details to fill in to make that possible. That’s because OAuth 2.0 is a resource authorization protocol — not an authentication protocol.

Read his post for a better understanding of how OAuth 2.0 relates to sign-in protocols, including a useful discussion of how OpenID Connect fills in the gaps to enable people to sign in with OAuth 2.0 in an interoperable manner.

OpenID Connect Implementer’s Draft Review

On December 23, 2011

In Claims, Federation, JSON, OAuth, OpenID, Specifications

OpenID Connect is a simple identity layer built on top of OAuth 2.0. It enables clients to verify the identity of and to obtain basic profile information about an end-user. It uses RESTful protocols and JSON data structures to provide a low barrier to entry. The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.

OpenID Connect is designed to cover a range of scenarios and use cases including Internet, enterprise, cloud, and mobile, to span security & privacy requirements from non-sensitive information to highly secure, and to span sophistication of claims usage, from basic default claims to specific requested claims to aggregated and distributed claims. It maximizes the simplicity of implementations by reusing existing OAuth 2.0, JWT, and SWD specs and employing a modular structure, allowing deployments to utilize only the pieces they need.

OpenID Connect has a number of key differences from OpenID 2.0. Among them are: support for native client applications, identifiers using e-mail address format, standard UserInfo endpoint for retrieving basic claims about the end-user, being designed to work well on mobile phones, use of JSON/REST rather than XML, support for encryption and higher LoAs, and support for distributed and aggregated claims.

Today marks a milestone in the OpenID Connect specification development: the OpenID Foundation announced that the current set of drafts is being reviewed for approval as Implementer’s Drafts. An Implementer’s Draft is a stable version of a specification intended for implementation and deployment that provides intellectual property protections to implementers of the specification. These drafts are the product of incorporating months of feedback from implementers and reviewers of earlier specification drafts, including feedback resulting from interop testing. Thanks to all of you who contributed to the development of OpenID Connect!

AD FS 2.0 Interop Step-By-Step Guide: IBM Tivoli Federated Identity Manager

On April 4, 2011

In Documentation, Federation, Interoperability

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!

AD FS 2.0 Interop Step-By-Step Guide: Ping Identity PingFederate

On November 22, 2010

In Documentation, Federation, Interoperability

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.

AD FS 2.0 Interop Step-By-Step Guide: Shibboleth 2 and the InCommon Federation

On October 21, 2010

In Documentation, Federation, Interoperability, Shibboleth, Software

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.

AD FS 2.0 Interop Step-By-Step Guide: Oracle Identity Federation

On August 2, 2010

In Documentation, Federation, Interoperability, Software

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 11.1.1.2, as delivered in Oracle Identity Management 11.1.1.3, to federate using the SAML 2.0 protocol. The guide is available in HTML and Word formats. Thanks again to author Dave Martinez.

Using Consumer Identities for Business Interactions

On July 10, 2010

In Claims, Federation, OpenID, Software

Medtronic, PayPal, Southworks, and Microsoft recently worked together to demonstrate the ability for people to use their PayPal identities for participating in a Medtronic medical device trial, rather than having to create yet another username and password. Furthermore, the demo showed the use of verified claims, where the name, address, birth date, and gender claims provided by PayPal are relied upon by Medtronic and its partners as being sufficiently authoritative to sign people up for the trial and ship them the equipment. I showed this to many of you at the most recent Internet Identity Workshop.

From a technology point of view, this was a multi-protocol federation using OpenID and WS-Federation — OpenID for the PayPal identities and WS-Federation between Medtronic and two relying parties (one for ordering the equipment and one for anonymously recording opinions about the trial). It was also multi-platform, with the Medtronic STS running on Windows and using the Windows Identity Foundation (WIF) and DotNetOpenAuth, the equipment ordering site running on Linux and using simpleSAMLphp, and the opinions site running on Windows and also using WIF. A diagram of the scenario flows is as follows:

Identity Mash-Up Diagram

We called the demo an “identity mash-up” because Medtronic constructed a identity for the user containing both claims that came from the original PayPal identity and claims it added (“mashed-up”) to form a new, composite identity. And yet, access to this new identity was always through the PayPal identity. You can read more about the demo on the Interoperability @ Microsoft blog, including viewing a video of the demo. Southworks also made the documentation and code for the multi-protocol STS available.

I’ll close by thanking the teams at PayPal, Medtronic, and Southworks for coming together to produce this demo. They were all enthusiastic about using consumer identities for Medtronic’s business scenario and pitched in together to quickly make it happen.

Update: Also see related posts by Kim Cameron and Matias Woloski.

Identity Interop at Catalyst San Diego, July 2010

On July 8, 2010

In Federation, Information Cards, Interoperability, OpenID, Software

I’ll be participating in an Open Identity for Business Interop being held by OSIS at Catalyst in San Diego this month. This multi-protocol interop event includes exercising the US Government identity profiles developed as part of the Open Identity Solutions for Open Government initiative. Microsoft is hosting testing endpoints using AD FS 2.0 and the Card Issuance CTP. The public interop demonstration is on Wednesday, July 28th. Hope to see you there!

Catalyst North America 2010 Interop Banner

AD FS 2.0 Interop Step-By-Step Guide: CA Federation Manager

On July 7, 2010

In Documentation, Federation, Interoperability, Software

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.

AD FS 2.0 Has Shipped

In Federation, Interoperability, Software

Active Directory Federation Services (AD FS) 2.0 shipped today. In addition to supporting WS-Federation, as the first version did, this release also supports the SAML 2.0 and WS-Trust protocols.

At this milestone, I’d like to thank the numerous partners who did extensive interop testing with us as AD FS 2.0 was being developed, helping ensure that it works well with other’s products. Milestones along the way included early interop testing with Shibboleth, IBM, and Ping Identity during Beta 1, interop work with CA, Novell, and Sun during Beta 2, the Federation Interop at Catalyst in July 2009, the Liberty Alliance SAML 2.0 testing last summer, and the OASIS IMI interop at RSA in March. Plus, we’re grateful to the numerous customers who test-drove and gave us invaluable feedback on AD FS 2.0 and the other “Geneva” wave products as they were being developed. This release is far stronger because of all of your contributions!

Updated Federated Identity Product Releases

On December 18, 2009

In Claims, Documentation, Federation, Information Cards, Interoperability, Software, Windows CardSpace

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.

Powered by WordPress & Theme by Anders Norén