Ping Identity principal engineer Brian Campbell last week submitted a draft specification to the Internet Engineering Task Force (IETF) for bridging between the SAML world and the IETF’s emerging OAuth 2.0 specification.

This is the type of advanced work I have been hinting at lately in this blog that Ping is doing internally and in the identity community to help define and support a future identity infrastructure that will stretch from consumer to enterprise.
The spec Campbell authored with Chuck Mortimore of is titled “SAML 2.0 Bearer Assertion Profile for OAuth 2.0.”
Now that might be a techie title, but Campbell explains the value this way. “It allows enterprises to use their SAML investments – both the technical aspects and the trust relationships with partners – and leverage that into using the emerging standards.”
You can listen to him explain it in his own words on the Ping Identity TV web site.
The OAuth 2.0 specification, which is still working its way through the IETF, includes a place that allows for the exchange of an arbitrary token type for an OAuth token.
OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords, according to an introduction to the spec printed on the hueniverse blog.
Campbell says the spec he has co-authored profiles the specific use of a SAML 2.0 bearer assertion in requesting an access token. So in essence, a specifically structured SAML token can be exchanged for OAuth.
“In some ways it is bridging the gap between more enterprise centric technologies and emerging social centric technologies,” says Campbell.
The full text of the specification is available on the IETF Web site.
Follow John on Twitter and check out our Identity-Conversation Tweet list


This writeup skips the hard parts of the SAML-Oauth integration issues:
a) How will a client (e.g. a iGadget) retrieve a SAML assertion
b) Timeout
c) Renewal of SAML assertions

The scope of the draft is intentionally limited to the details of the SAML for OAuth exchange between the client and the authorization server because that's the piece that needs to be tightly specified to ensure cross domain interoperability. You are correct that getting and refreshing the assertion are "hard" parts of SAML-OAuth integration, however, there are numerous ways of doing them (WS-Trust, self issued, OAuth variant/extension, proprietary, etc.) and it will generally be more of a local integration issue which suggests that there's not as pressing of a need for a formal specification.

* Required Fields