The following is an example of a claims-based system.

The previous diagram shows a claims-aware Web service (the relying party application) and a smart client that wants to use that service. The RP exposes a policy that describes its addresses, bindings, and contracts. But the policy also includes a list of claims that the RP needs, such as user name, e-mail address, and role memberships. The policy also tells the smart client the address of the STS from which it should retrieve these claims. After retrieving this policy (1), the client now knows where to go to authenticate: the STS. The user presents credentials (2) and the smart client makes a web service request (3) to the STS, requesting the claims that the RP asked for in its policy. The job of the STS is to authenticate the user and return a security token that gives the RP all of the claims it needs. The smart client then makes its request to the relying party (4), sending the security token along in the security SOAP header. The RP now receives claims with each request, and simply rejects any requests that don’t include a security token from the issuing authority that it trusts.