Token Policy and STS

If you are familiar with PKI projects you are probably know about Certificate Policy (CP) and Certificate Practice Statements (CPS). Both based on published RFC and usually required in most PKI implementations. CP specify the policy for PKI and CPS specifies how this policy is implemented by each CA in your PKI solution. Usually it is written to satisfy certain requirements and mapped to some known or desired requirements. CP is also written to show what level of trust relying parties can put into certificates issued from CA. When user gets a certificate and uses it to sign e-mail, encrypt messages or authenticate, the relaying party must have some level of assurance that the person who uses the certificate is actually the right person who claims to use it.

So what about Security Token Service used in Claim Based Authentication and the trust that relaying party should give to it? STS issues a token to subscribers with certain claims and then the subscriber presents this token to the relaying party, ie resource provider. Without common standards and framework that provides policy and practical guidelines for STS implementation, the relying parties accepting tokens from STS have no way to know if the token presented by user have the right information and if it is coming from the valid user. As more and more relaying parties decide to use STS, how would they know about policies and levels of assurance that this STS can provide? Without adopted and commonly used Security Policy that specify how STS should operate we’ll have no way to reliably trust this STS.

So I’d argue that, similar to PKI implementations, any Claim Based Authentication implementation must have a policy, I’ll call it “Token Policy” TP, that describes how STS should be implemented and then every STS should potentially have Token Practice Statement (TPS) describing how TP is enforced for a specific STS.