In this post, I'll be discussing the modifications required for the Microsoft's identity metasystem, to support OpenID Infocards. Identity metasystem consists of three parts. Identity Provider, Relying Party and the Identity Selector. Let's take one by one.
First, it would be better to identify the protocol flow under the OpenID Infocard scenario.
1.User acquires an OpenID Infocard from an OpenID Infocard enabled Identity Provider and installs it in his Identity Selector.
2.User browses to an OpenID Relying Party [RP]
3.User invokes an element on the page to send an OpenID token to the Relying Party. In this case user will be clicking on an image, just like the following – which says this RP accepts OpenID Infocards. [ Same as 'We accept American Express' in your nearest shopping mall]
4.Identity Selector detects the "application/x-informationCard" OBJECT element on the RP's login page, requesting an OpenID token. This is same as in the normal Infocard scenario. Basically type="application/x-informationCard" indicates to the browser that it has to invoke the underlying Identity Selector and passes the associated attributes to the Identity Selector. In the case of an OpenID Infocard we set the value of the parameter “tokenType” to “http://specs.openid.net/auth/2.0”
5. User selects an OpenID Information Card to use. In this case Identity Selector only presents the Inforcards which are of 'tokentype', “http://specs.openid.net/auth/2.0” for user selection.
6.Identity Selector sends a Request Security Token (RST) to the Security Token Service (STS) endpoint of the Identoty Provider that issued the card.
7.Identity Provider issues an OpenID Authentication Response, encodes that response in an OpenID token, and encapsulates the token in a Request Security Token Response (RSTR).
8.Identity Provider returns the RSTR to the Identity Selector.
9.Identity Selector POSTs the response back to the RP.
10.RP extracts the OpenID Authentication response from the OpenID token and returns to the normal OpenID verification flow.
Basically, in most of the cases the steps are exactly same as in a normal Infocard case. Only difference is, in each case we have to handle the OpenID token [instead of SAML token], as well as we also need to support OpenID Identifier claim type [http://schema.openid.net/2007/05/claims/identifier].
So, both the Identity Provider, as well as the Relying Party need to be able to identify and handle OpenID tokens, while the Identity Selector's behaviour is unchanged, since the tokens are opaque to Identity Selectors.
First, it would be better to identify the protocol flow under the OpenID Infocard scenario.
1.User acquires an OpenID Infocard from an OpenID Infocard enabled Identity Provider and installs it in his Identity Selector.
2.User browses to an OpenID Relying Party [RP]
3.User invokes an element on the page to send an OpenID token to the Relying Party. In this case user will be clicking on an image, just like the following – which says this RP accepts OpenID Infocards. [ Same as 'We accept American Express' in your nearest shopping mall]
4.Identity Selector detects the "application/x-informationCard" OBJECT element on the RP's login page, requesting an OpenID token. This is same as in the normal Infocard scenario. Basically type="application/x-informationCard" indicates to the browser that it has to invoke the underlying Identity Selector and passes the associated attributes to the Identity Selector. In the case of an OpenID Infocard we set the value of the parameter “tokenType” to “http://specs.openid.net/auth/2.0”
5. User selects an OpenID Information Card to use. In this case Identity Selector only presents the Inforcards which are of 'tokentype', “http://specs.openid.net/auth/2.0” for user selection.
6.Identity Selector sends a Request Security Token (RST) to the Security Token Service (STS) endpoint of the Identoty Provider that issued the card.
7.Identity Provider issues an OpenID Authentication Response, encodes that response in an OpenID token, and encapsulates the token in a Request Security Token Response (RSTR).
8.Identity Provider returns the RSTR to the Identity Selector.
9.Identity Selector POSTs the response back to the RP.
10.RP extracts the OpenID Authentication response from the OpenID token and returns to the normal OpenID verification flow.
Basically, in most of the cases the steps are exactly same as in a normal Infocard case. Only difference is, in each case we have to handle the OpenID token [instead of SAML token], as well as we also need to support OpenID Identifier claim type [http://schema.openid.net/2007/05/claims/identifier].
So, both the Identity Provider, as well as the Relying Party need to be able to identify and handle OpenID tokens, while the Identity Selector's behaviour is unchanged, since the tokens are opaque to Identity Selectors.