Both Claim and ClaimSet are decorated with DataContract/DataMember attributes. This means they are made for serialization. And this makes sense – maybe you want to forward a claim set (server to server) or send a claim set from server to client (UI authorization).

But you will most likely run into problems when trying to serialize a claim set using the DataContractSerializer.

Known Types
DCS needs to ‘know’ all types that are involved in the serialization process. This involves every type in the inheritance chain down to ClaimSet (e.g. DefaultClaimSet or my DeferredLoadClaimSet) as well as all possible resource types. You either supply the known types via attributes/config (KnownType and ServiceKnownType).

Or you supply the types when newing up the DCS manually:

DataContractSerializer dcs = new DataContractSerializer(
    typeof(ClaimSet),
    new List<Type> { typeof(DefaultClaimSet), typeof(UIClaimResource) });

Circular References
Typical claim sets will have circular references – e.g. when the last issuer in the chain points to himself. DCS is not made for cyclic reference – but rather object trees (at least with the default settings). When you are trying to serialize objects with cyclic references you will get the following exception : “type contains cycles and cannot be serialized if reference tracking is disabled.”. In WCF traces you will see something like “message not logged because its size exceeds configured quota”.

When newing up a DCS you can opt for “preserving object references”. This will create ID/IDREF pairs in the serialized XML and allows for type references and thus cycles. (Aaron has an explanation of how that works).

DataContractSerializer dcs = new DataContractSerializer(
    typeof(ClaimSet),
    new List<Type> { typeof(DefaultClaimSet), typeof(UIClaimResource) },
    int.MaxValue,
    true,
    true,  // preserveObjectReferences
    null);

This is fine when you can control the DCS parameters. But you can’t easily do that in WCF. Sowmy has a sample on how to enable reference preserving in WCF. This will solve the problem!

[OperationContract]
[ReferencePreservingDataContractFormat]
ClaimSet GetClaims();

3.5 SP1 to the Rescue!?
Starting with 3.5 SP1 you can enable reference preserving on a DataContract like this:

[DataContract(Namespace = “…”, IsReference = true)]
public abstract class DeferredLoadClaimSet : ClaimSet

But there are two problems with this approach:

• You actually need access to the DataContract to change the attribute. In the claims case – you would need to change the framework’s DefaultClaimSet or your own ClaimSet-derived class.
• Every DataContract in the inheritance chain needs the IsReference attribute – otherwise you will get the following error: “Derived types must have the same value for IsReference as the base type”. Since all custom claim sets ultimately derive from ClaimSet – but this DataContract has no IsReference set, we are back to square one.

Conclusion
Keep these things in mind when serializing claim sets:

• supply all involved types as known types
• Set preserveObjectReferences to true on the DCS. The new attribute on DataContract in 3.5 SP1 is nice – but does not help with claim sets. Use the [ReferencePreservingDataContractFormat] attribute instead (find the code here).
• Reference preserving adds ID/IDREF attributes to the resulting XML. These attributes come from a Microsoft namespace. This may be a problem for interop scenarios. If you need full control over the XML, either use the DCS extensibility points for manual serialization, or don’t use the DCS at all (and use one of the alternative message generation mechanisms). Another option would be to use a more standardized serialization format for claims like a SAML token.
• WindowsClaimSet and X509CertificateClaimSet are not marked with [DataContract] at all – they are not intended for serialization.

HTH