Attributes in a SAML Assertion are identified by a name string. The name string is either assigned by the SAML issuer context or scoped by a namespace (for example, a URI or object identifier (OID)). This means that the same attribute can have different name strings used to identify it. In many cases, but not all, the federation agreements will determine what attributes and names can be used in a SAML statement. This means that the RP needs to map from the SAML issuer or federation name, type, and semantic to the name, type, and semantics that the policies of the RP are written in. In other cases, the Federation Substrate, in the form of proxies, will modify the SAML Assertions in transit to do the necessary name, type, and value mappings as the assertion crosses boundaries in the federation. If the proxies are modifying the SAML Assertion, then they will remove any signatures on the SAML Assertion, as changing the content of the SAML Assertion would invalidate the signature. In this case, the technical trust is the required mechanism for validating the integrity of the assertion. (The proxy could re-sign the SAML Assertion, but the same issues of establishing trust in the proxy would still exist.) Finally, the attributes may still be in the namespace of the originating IdP. When this occurs, the RP will need to get the required mapping operations from the federation agreements and do the appropriate mappings itself.