ZoRoNa's profileZoRoNaX' blogBlog Tools Help
    9/8/2006

    MSNP15

    With the release of Windows Live Messenger 8.1 BETA build 0064 today, the MSNP15 protocol has been enabled. This protocol introduces a new authentication scheme called RPS "Relying Party Suite". Where TWN "Tweener" authentication is used on protocol versions 14 and below, RPS authentication will be used on protocol versions 15 and above. Furthermore, users are now able to show their location in Messenger.
     

    RPS Authentication

    When a user wants to authenticate, not much values have to change. The sequence looks a lot like the Tweener authentication except that it uses SSO as name of the authentication system. Note that only the ticket is sent to the server, because the system is only used for authentication and thus the profile is obsolete.
     
    Abstract
    Client: USR <TrId> SSO I <email>\r\n
    Server: USR <TrId> SSO S <policy> <base64 encoded nonce>\r\n
    Client: USR <TrId> SSO S <ticket> <base64 something>\r\n
    Server: USR <TrId> OK <email> <verified> 0\r\n
     
    Example
    Client: USR 10 SSO I buddy@live.com\r\n
    Server: USR 10 SSO S MBI 0Xb2iqDOU4LeVUCUCWAQt6aYYz+xmobpwEDV9IshEaWUDUyyZ3KG961MHI3mKPYW\r\n
    Client: USR 11 SSO S t=... HAAAAAEAAAADZgAABIAAAA...\r\n
    Server: USR 11 OK buddy@live.com 1 0\r\n
     
    If you look at the above sequence, you'll see that the response command after the initial command has an extra parameter to hold a nonce and that the policy has MBI as value. The value of the policy field should be used to authenticate against the Passport STS service (just like you had to do with the Tweener authentication: ?id=...&tw=...&ct=..&..). The nonce is, together with a couple of more values responsible for the the new base64 encoded parameter which is sent back with the ticket. I'm sure we'll find out later how to do that exactly.
     
    Because of the new authentication system, we have to add a new token request to the SOAP authentication request. I assume that you are familiar with the SOAP authentication request, so I'll only explain some of the values. 
     
    Example
    <wst:RequestSecurityToken Id="RST1">
      <wst:RequestType>http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue</wst:RequestType>
      <wsp:AppliesTo>
        <wsa:EndpointReference>
          <wsa:Address>messengerclear.live.com</wsa:Address>
        </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wsse:PolicyReference URI="MBI" />
    </wst:RequestSecurityToken>
     
    The value of the Id attribute in the RequestSecurityToken element may vary from RST1..RST<N> (where N is a number higher or equal to 1). The value of the URI attribute in the PolicyReference element has to be taken directly from the policy field in the received USR command. Furthermore, you have to specify the service target messengerclear.live.com for the moment. However, this may change in the future.
     
    The response to the above request looks like the following response.
     
    Example
    <wst:RequestSecurityTokenResponse>
      <wst:TokenType>urn:passport:compact</wst:TokenType>
      <wsp:AppliesTo xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
        <wsa:EndpointReference>
          <wsa:Address>messengerclear.live.com</wsa:Address>
        </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wst:LifeTime>
        <wsu:Created>2006-09-08T12:24:14Z</wsu:Created>
        <wsu:Expires>2006-09-08T20:24:14Z</wsu:Expires>
      </wst:LifeTime>
      <wst:RequestedSecurityToken>
        <wsse:BinarySecurityToken Id="Compact1">t=...</wsse:BinarySecurityToken>
      </wst:RequestedSecurityToken>
      <wst:RequestedTokenReference>
        <wsse:KeyIdentifier ValueType="urn:passport:compact" />
        <wsse:Reference URI="#Compact1" />
      </wst:RequestedTokenReference>
      <wst:RequestedProofToken>
        <wst:BinarySecret>...a base64 encoded value...</wst:BinarySecret>
      </wst:RequestedProofToken>
    </wst:RequestSecurityTokenResponse>
     
    I won't go into detail, but the value of the BinarySecurityToken with Id="Compact1", should be used as value in the final USR command sent to the server.
     

    Locations

    Another new item is that persons are now able to set their geographical location in their PSM, which has been done by adding the element LOC to the Data element of the XML in the UUX payload. Now your UUX command could look like this:
     
    Abstract
    UUX <TrId> <Size>\r\n
    <Data>...<LOC>\0Location\01\0<String formatting>\0<Value 1>\0&lt;msnobj Creator=&quot;buddy@live.com&quot; Type=&quot;14&quot; SHA1D=&quot;...&quot; Size=&quot;...&quot; Location=&quot;0&quot; Friendly=&quot;...&quot;/&gt;\01\0</LOC>...</Data>
     
    Example
    UUX 12 ...\r\n
    <Data>...<LOC>\0Location\01\0Somewhere\0Somewhere\0&lt;msnobj Creator=&quot;buddy@hotmail.com&quot; Type=&quot;14&quot; SHA1D=&quot;+k0sN0ojrTqOlpbDezJUFG/0Yz0=&quot; Size=&quot;218&quot; Location=&quot;0&quot; Friendly=&quot;UwBvAG0AZQB3AGgAZQByAGUAAAA=&quot;/&gt;\01\0</LOC>...</Data>
     
    The format of the value in the LOC element looks a lot like the value for the current song playing aka Music. The <String formatting> field should have the Location name as value, just like the <Value 1> field. Followed by a MSNObject with Type=14 (Location) and with the Location name as friendly name, which is in turn base64 encoded.