As I’ve been developing an STS code library I’ve noticed a few inconsistencies around how people assume PPIDs work. If you’ve never read the interoperability specification now is a good time to start.

If you’ve implemented Information Card support on your web site you’ll be aware of the Personal Private Identifier (PPID) claim. It’s generally described as a unique ID that identifies a combination of an information card and the relying party the claims are being sent to. Vittorio, as ever, has more details.

On the surface the usual description indicates that each relying party gets an individual PPID, and this is true, however what is a relying party? The typical assumption is that it is a web site, however this is not the case; this  isn’t helped by demos and diagrams in PowerPoint which indicate it as such. Caleb emailed me the best description he could find, from, who define a "party" as

A natural person or a juridical entity.

This isn’t an individual web site, it’s the entity owning that web site; for example Microsoft, Google, or even myself. So for multiple web sites owned by the same party the PPID issued for self issued cards should be identical.

An identity selector generates a PPID using the card identity and relying party details taken from the RP’s SSL certificate (or failing that the FQDN); and the PPID is recalculated every time it is requested. For managed cards the identity selector will send a suggested PPID as part of the request, in a ClientPseudonym element.

The details used to identify the party are detailed in Section 8.6.1 of the interoperability specification.

Certificate Type Details used in PPID Generation
Extended Validation Certificate for organisational identifiers The organisational information contained within the certificate, for example


Note that the subject identifier (usually the web site FQDN ) is not used.
Non-EV Certificate with organisational identifiers Start as with an EV certificate, but the navigate up the certificate chain prefixing our details with the subject of the certificate, for example

|ChainElement="OU=Contoso Trust, Inc., O=Contoso Corporation, C=US"
|ChainElement="OU=Contoso Internet Authority" |O="Microsoft"|L="Redmond"|S="Washington"|C="US"|
A certificate with no organisational identifiers The certificate public key.
No SSL certificate The FQDN of the relying party.

So what does all this mean? It has two effects;

  1. As you can see from the table above in the first two cases PPIDs will be common across organisations (and most SSL cerificates will match one of the first two cases). 
  2. If any of the information specified above changes then the PPID generated will change; i.e.
    • if the organisational information in an EV certificate changes.
    • if the organisational information in an non-EV SSL certificate changes or the organisation information in the signing chain changes.
    • if the public key for an SSL certificate containing no organisation information changes.
    • if the FQDN name of non SSL relying party changes.
  3. Additionally for self issued cards each PPID will have a unique signing pair used to sign the token.

As relaying parties we tend to use the PPID (and part of the signing token) to identify users, and we believe PPIDs are immutable. As you can see it is dependant upon the type of certificate you have on your web site (or indeed the lack of a certificate). If you want to guarantee that the PPIDs an identity selector sends to you will never change then you should use an extended validation certificate, and never change your organisational information (which in the days of google and microsoft buy-outs of web 2.0 companies is a whole other challenge). If you cannot afford, or cannot get an EV certificate then you can minimise the risk by purchasing a certificate which does not use intermediate signing certificates, such as those from the main providers, Verisign, Thawte etc; providers that have and issue under a root certificate trusted by your browser/operating system. By having fewer elements in the organisation information (by having a shorter signing chain), the risk of change lessens. If you are using an SSL certificate without OU identifiers then you must follow your certificate provider’s renewal process in order to keep the same public key and thus keep the same PPIDs. If you’re not using SSL then don’t ever change your machine and domain name.

Of course with managed cards all bets are off; they are free to do as they like, if they choose to support that claim; they can used the PPID suggested by the identity selector in each request, or ignore it and go their own way, hopefully providing a more stable, robust and immutable PPID.

If you really want to guarantee a PPID that will never change then you need to take control of the entire authentication story, becoming your own security token service, issuing your own managed Information Card and only ever accepting your own cards.