Typically this would be implemented by having a set of predefined elements in the XSD (name, email, etc...) and also an 'additional' element that has a list of "Any" as the children. Easy!

E.g.:

    <claims>
        <nameid>[email protected]</nameid>
        <givenname>Foo</givenname>
        <surname>Bar</surname>    
        <extensions>
            <myCustomClaim>010231239dfadsf</myCustomClaim>
        </extensions>
    </claims>

It's also possible to use namespaces for extensibility, and this can even be used to guarantee that the tag names don't conflict.

So instead of this garbage:

    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>

You'd have standard namespaced and extensible elements such as:

    <claims xmlns:saml="urn:oasis:names:tc:SAML:2.0:ac:classes" xmlns:adfs="urn:com:microsoft:ADFS">
        <saml:nameid>[email protected]</saml:nameid>
        <saml:givenname>Foo</saml:givenname>
        <saml:surname>Bar</saml:surname>    
        <adfs:securityId>S-0-1-52534-12362341234-12312315</adfs:securityId>
        <adfs:objectGuid>47e3a2d3-266a-48ad-b080-b785b4d0b45f</adfs:objectGuid>
    </claims>

This would enable clients to validate the claims they do understand and ignore the claims they don't. Similarly to how X.509 does it, elements could be added to "must process" or "optional" parent elements to ensure correctness and security even in the face of a wide range of client capabilities.

This is common in the XML world, but SAML had to invent its own wheels.