Bootstrap

Discovery is a common challenge for identity systems. Fundamentally, requestors need to know where a bit of identity is located on the network so that a request can be sent there.

In SSO, when a User visits an SP, the SP needs to discover who and where the User's IDP is so that an authentication request can be delivered there. For the SP, the discovery question is 'Where should I redirect the user for them to authenticate?'.

OpenID solves the issue by allowing/requiring the User to provide either a specific identity URI at an IDP, or merely the URI of the IDP (directly or indirectly through delegation). SAML supports a variety of mechanisms (including the 'user-provides' model of OpenID) but standardizes a cookie-based option. Cardspace has the requestor present its identity needs to Cardspace, which then effectively 'discovers' appropriate IDPs.

When moving beyond SSO to attribute sharing, unless the desired attributes happen to be available from the same IDP as made the authentication assertion, discovery rears its head again. For an SP receiving an SSO assertion bu desiring additional attributes, the question becomes 'from which attribute provider can I obtain attribute X?'

The Liberty Alliance has always referred to this switch from the SSO to attribute sharing world as the 'bootstrap', and the bootstrap mechanism as the support that the SSO world can provide to the SP to facilitate this switch and subsequent discovery requirement. For the bootstrap from SAML & ID-FF based SSO to ID-WSF, we defined how the SAML SSO assertion carries the appropriate information (endpoint of a service at which the network location of the relevant user's various identity attributes and credentials to use there) for the SP to use should it wish to discover additional identity attributes.

But, other bootstraps are possible as well. Fundamentally, it's theoretically possible between any SSO protocol and a server-to-server attribute sharing protocol. For instance, you could define a boostrap mechanism from WS-Federation to ID-WSF if you were so inclined.

John Kemp explores mechanisms for boostrapping from OpenID to SAML (and then into ID-WSF). John provides two alternatives by which the OpenID RP could use SAML to retrieve an assertion to supplement the identity that flowed to it through the OpenID protocol. John doesn't mention emphasize subsequent bootstrapping into ID-WSF in his post, but the assertion that John's SAML mechanisms would retrieve could carry the necessary bootstrap information. Graphically

#1 is OpenID SSO, #2 is SAML Assertion retrieval, and #3 is ID-WSF Service discovery and query - now that's convergence! There must be a way to throw in Cardspace for good measure.