Blog Home  Sign In RSS 2.0 Atom 1.0 CDF  

  def Softwaremaker() :
         return "William Tay", "<Challenging Conventions />"

  knownType_Serialize, about = Softwaremaker()
 

 Tuesday, November 21, 2006
« Government Ware 2006: Speaking on Federa... | Main | Vulcan's Innards »

Sergey Shishkin of newtelligence asked a very good question on the Microsoft Cardspace forums here. Basically, the current STS examples out there doesnt show a good sample of how a RSTR will look and be parsed on the client Cardspace selector before it is sent over to the Relying Party (RP) or website.

If you click on the "Retrieve" button on the Cardspace selector, while the RST<->RSTR takes place, somehow, the Cardspace selector doesnt show the credentials that will be sent to the RP from the STS, or more commonly known as the Identifying Party (IP).

The reason why was that the current STS samples out there ignores the RequestDisplayToken element value and therefore doesnt pump in the RequestedDisplayToken blob. Cardspace selector looks and parses those (RequestedDisplayToken) values as its treats the RequestedSecurityToken as an opaque object.

I took some time to figure out how to pump in those values and searching the web turns out a good resource here, surprisingly .

Following the stated schema and with a bit of push in the right direction from (my collegue now) Garrett Serack, I managed to hack out some snippets that can be written into the current STS sample (RC1) so that the following XML Blob appears in the RSTR back to the client Cardspace selector. Only then, the selector would be able to show the DisplayToken in the UI to let the subject decide if he/she wants to send the entire claimset over. (Laws of Identity Rule No 1: User Control and Consent)

<wsid:RequestedDisplayToken xmlns:wsid="http://.../ws/2005/05/identity">
<wsid:DisplayToken>
<wsid:DisplayClaim Uri="http://.../ws/2005/05/identity/claims/givenname">
<wsid:DisplayTag>First Name</wsid:DisplayTag>
<wsid:Description>http://.../ws/2005/05/identity/claims/givenname</wsid:Description>
<wsid:DisplayValue>William</wsid:DisplayValue>
</wsid:DisplayClaim>
<wsid:DisplayClaim Uri="http://.../ws/2005/05/identity/claims/surname">
<wsid:DisplayTag>Last Name</wsid:DisplayTag>
<wsid:Description>http://.../ws/2005/05/identity/claims/surname</wsid:Description>
<wsid:DisplayValue>Tay</wsid:DisplayValue>
</wsid:DisplayClaim>
<wsid:DisplayClaim Uri="http://www/ws/2005/05/identity/claims/emailaddress">
<wsid:DisplayTag>Email Address</wsid:DisplayTag>
<wsid:Description>http://.../ws/2005/05/identity/claims/emailaddress</wsid:Description>
<wsid:DisplayValue>abc@def.ghi</wsid:DisplayValue>
</wsid:DisplayClaim>
<wsid:DisplayClaim Uri="http://.../ws/2005/05/identity/claims/privatepersonalidentifier">
<wsid:DisplayTag>Site-specific card ID</wsid:DisplayTag>
<wsid:Description>http://.../ws/2005/05/identity/claims/privatepersonalidentifier</wsid:Description>
<wsid:DisplayValue>KDK-G7AC-SAW</wsid:DisplayValue>
</wsid:DisplayClaim>
</wsid:DisplayToken>
</wsid:RequestedDisplayToken>

p/s: You can use the writer.WriteElementString(Constants.WSIdentity.NamespaceUri.Prefix ...) to make sure the above XML blob is generated after you have written the RequestedSecurityToken (the SAML token) XML bits.

Tuesday, November 21, 2006 7:14:51 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions