Trustmark Definition (TD):


Publication Date2015-07-19
Trustmark Defining Organization
NameGeorgia Tech Research Institute
Mailing Address75 5th Street NW, Suite 900, Atlanta, GA 30308
DescriptionThis Trustmark Definition specifies the conformance criteria and assessment process for Attribute Providers wishing to support the BAE SAML Attribute Query/Response Protocol.
Target StakeholdersOrganizations that have a vested interest in the U.S. Federal Identity, Credential, and Access Management (FICAM) program and specifically its BAE technical specifications.
Target RecipientsAttribute Provider Organizations that wish to provide attributes via the BAE Protocol.
Target Relying PartiesRelying Parties (IDPs/SPs/RPs) that wish to query for attributes via the BAE Protocol.
Target ProvidersAny organization that is capable of assessing the BAE protocol.
Provider CriteriaAny organization or business entity may act as a Trustmark Provider for trustmarks under this Trustmark Definition.
Assessor QualificationsAny individual employed or contracted by the Trustmark Provider may act as the assessor for trustmarks under this Trustmark Definition.
Trustmark Revocation CriteriaFor any trustmark issued under this Trustmark Definition, the Trustmark Provider must revoke the trustmark upon any condition whereby one or more Conformance Criteria cease to be satisfied.
Extension DescriptionThis Trustmark Definition requires no extension data.
Legal NoticeThis document and the information contained herein is provided on an "AS IS" basis, and the Georgia Tech Research Institute disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe any rights or any implied warranties or merchantability or fitness for a particular purpose. In addition, the Georgia Tech Research Institute disclaims legal liability for any loss incurred as a result of the use or reliance on the document or the information contained herein.
NotesThe Georgia Tech Research Institute (GTRI) has published this document with the support of the National Strategy for Trusted Identities in Cyberspace (NSTIC) via the National Institute of Standards and Technology (NIST). The views expressed herein do not necessarily reflect the official policies of GTRI, NIST or NSTIC; nor does mention of trade names, commercial practices, or organizations imply endorsement by the U.S. Government.

Conformance Criteria (10)

1: SAML 2.0

APs must use the SAML 2.0 protocol within Attribute Responses and consume requests using SAML 2.0.



APs must publish/provide a valid WSDL file for their BAE Endpoint. This WSDL should include valid URLs.


3: Verify Signature

APs must verify the digital signature on SAML Attribute Requests and on the SOAP Body when present.


4: NameIDPolicy

If an invalid or unrecognized Name ID arrives, the AP must respond with urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal.


5: Response Issuer

APs must populate the Issuer field of the Response with a valid value that was negotiated via Trust Fabric / Metadata exchange. It must match the content of the encrypted assertion if present.


6: Response Destination

APs must populate the Destination field of the Response with the value of the Requester. It must match the content of the encrypted assertion if present.


7: Encrypted Assertion

AP Responses must include a single EncryptedAssertion element for successful responses.


8: Assertion Signature

APs must digitally sign the SAML Assertion carried within the Response as an EncryptedAssertion.


9: Conditions

APs must include valid Conditions within SAML Assertions including NotBefore and NotOnOrAfter attributes constraining the attributes validity to a short time window to protect against replay attacks.


10: Attributes

APs must include a number of Attributes within a single AttributeStatement according to the attributes requested (the requested set may be pre-negotiated out of band and published within Metadata/Trust Fabric).


Assessment Steps (10)

This assessment is intended to be performed on Attribute Providers that wish to use the BAE Protocol. To adequately perform these steps the assessor must possess a test BAE Client that supports outputting detailed diagnostics. One such tool is the GTRI developed BAE Client:

The assessor's test client must be configured to trust the Attribute Provider being evaluated. Additionally, the AP being evaluated must be configured to trust the test BAE client.

1: The AP uses and supports SAML 2.0 (SAML_2_0_Check)

Does this AP support SAML 2.0? Please provide a sample SAML Response (as XML/Text).

Required Artifact(s)
  • Sample SAML Response

    Provide a full XML SAML Response as text or an uploaded XML file.

2: The AP provides a correct WSDL file (WSDL_Step)

Does the AP provide a WSDL file with all appropriate URLs, bindings, and protocols specified?

Required Artifact(s)
  • WSDL File

    Please upload a copy of their WSDL file. If it is available online, also include the URL at which the file is found.

3: Signature Verification on Attribute Query (Signature_Verification_Step)

Does the AP verify all of the XML digital signatures in an Attribute Query (both the SOAP signature and the SAML Request signature)? To do this step, the assessor needs to perform a series of queries with untrusted and/or unsigned queries and compare the results to properly signed queries.

Required Artifact(s)
  • AP Signature Results (Errors and Success)

    Please provide a series of log file exerts showing various error conditions and success conditions encountered.

4: Appropriate Handling of Invalid NameIDs in Request (NameID_Error)

Does the AP properly return an error when an invalid or unrecognized name identifier arrives in a query?

Required Artifact(s)
  • SAML Response - Error

    Please provide in XML a copy of a SAML Response where a status of UnknownPrincipal is returned.

5: Issuer (Issuer)

Does the AP include the correct value for the Issuer within the Response? Does it also include this value correctly within the EncryptedAssertion when present?

6: Destination (Destination)

Does the AP include the correct value for the Destination within the Response? Does it also include this value correctly within the EncryptedAssertion when present?

7: Encrypted Assertion (Assertion)

Does the AP include an Encrypted Assertion in every non-error Response?

Required Artifact(s)
  • SAML Response with Encrypted Assertion

    Please provide in XML a copy of a SAML Response with the Assertion as an Encrypted Assertion.

8: Assertion Digitally Signed (Signed_Assertion)

Does the AP digitally sign the SAML Assertion correctly using XML Digital Signature and signing with the certificate registered with the trusted requester?

Required Artifact(s)
  • SAML Assertion

    Please provide an XML artifact of a sample assertion (must be decrypted) that includes a valid XML Digital Signature.

9: Valid Conditions (Valid_Conditions)

Does the AP populate the SAML Assertion with valid conditions (this must include NotBefore and NotOnOrAfter attributes appropriately populated)?

Required Artifact(s)
  • SAML Assertion

    Please provide an XML artifact of a sample assertion (must be decrypted).

10: Attributes (Attributes_Present)

Does the AP include the requested attributes formatted correctly?

Required Artifact(s)
  • SAML Assertion

    Please provide a sample SAML Assertion with a valid Attribute Statement.

Issuance Criteria


Sources (1)

Terms (26)


An account is used to associate transactional records with an end user or organization. Presence of an account does not necessarily mean that there are credentials (e.g., username and password) associated with the account.


To make a statement about the properties of a user or user's act of authentication.

Authentication Session

Period of time that an end user remains trusted after the end user authenticates. That is because an IDP typically does not require an end user to re-authenticate for every page requested. Each IDP defines its own authentication session duration. If an end user returns to the IDP and an earlier authentication session has expired, the IDP re-authenticates the end user even if single sign-on is in effect.

Backend Attribute Exchange ( BAE )

BAE is an attribute exchange protocol published by ICAM based on the SAML Attribute Query Response protocol.


Mappings of SAML request-response message exchanges onto standard messaging or communication protocols.

Consolidated Metadata

A single XML file containing a top-level root <md:EntitiesDescriptor> containing multiple <md:EntityDescriptor> and/or <md:EntitiesDescriptor> elements.

Credential Service Provider ( CSP )

For the purposes of SAML SSO, they are synonymous with Identity Providers.

Digital Encryption

Private key data encryption that converts data into a form that cannot be easily understood by unauthorized people. Decryption is the process of converting encrypted data back into its original form, so it can be understood. Within the FICAM SAML Profile, encryption pertains to SSL v3 or TLS 1.1 (and higher), encryption and/or XML encryption, depending upon the Level of Assurance.

Digital Signature

An asymmetric key operation where the private key is used to digitally sign an electronic document and the public key is used to verify the signature. Digital signatures provide authentication and integrity protection.


Process of an end user finding a IDP and/or RP.

Extensible Markup Language ( XML )

XML is a specification developed by the W3C that enables the definition, transmission, validation, and interpretation of data between applications and between organizations. In a nutshell, XML describes data and focuses on what data is. XML facilitates technical interoperability, and is used in identity management standards such as SAML (e.g., to convey information in a SAML assertion).

Federal Identity, Credential, and Access Management ( FICAM )

Federal Identity, Credential, and Access Management (ICAM) requires a mechanism to assess the identity management standards against applicable federal requirements, policies, and laws.

Holder-of-Key Assertion

A holder-of-key assertion contains a reference to a public key (corresponding to a private key) or a symmetric key possessed by the end user. The RP requires the end user to prove possession of the private key or secret that is referenced in the assertion. In proving possession, the end user also proves that he or she is the rightful owner of the assertion.

Identity Provider ( IDP )

For the purposes of SAML SSO, they are synonymous with Credential Service Providers. A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers (relying parties) within a federation, such as with web browser profiles.

Locally Unique Identifiers ( LUID )

The unique identifier used for attribute resolution by Attribute Providers / BAE Responders.


Information shared between endpoints (e.g., RP, IDP) necessary for technical interoperation.

National Identity Exchange Federation ( NIEF )

The National Identity Exchange Federation (NIEF) is a collection of government agencies and other organizations in the U.S. that have come together to share sensitive information, subject to applicable access controls, under a common, well-defined, standards-based trust framework.


Ability to maintain data.

Protected Session

A session wherein messages between two participants are encrypted and integrity is protected using a set of shared secrets called session keys. A participant is said to be authenticated if, during the session, he, she or it proves possession of a long term token in addition to the session keys, and if the other party can verify the identity associated with that token. If both participants are authenticated, the protected session is said to be mutually authenticated. One way to implement a protected session is SSL/TLS, which is required for this Profile.

Pseudonymous Identifier

Private end user pseudonym that will only be used with one site. The site will always know it's you when you come back, but it won't be able to look up any other information about you, or correlate your profile with other sites.

Relying Party ( RP )

A system entity (i.e., stand-alone system or group of applications that rely on a central authentication system) that decides to take an action based on information from another system entity. For example, a SAML Relying Party depends on receiving assertions from an asserting party (e.g., a SAML Identity Provider) about a subject. A Relying Party is also referred to as a Service Provider.

Security Assertion Markup Language ( SAML )

The set of specifications describing security assertions that are encoded in XML, profiles for attaching the assertions to various protocols and frameworks, the request/response protocol used to obtain the assertions, and bindings of this protocol to various transfer protocols (for example, SOAP and HTTP). SAML addresses web single sign-on, web services authentication, attribute exchange, authorization, non-repudiation, and secure communications. SAML defines assertion message formats that are referenced in Liberty Alliance, Shibboleth, WS-Security, and other specifications. SAML has become the standard web SSO identity management solution. Several versions have been released to date, including SAML 1.0, SAML 1.1, and SAML 2.0. The Organization for the Advancement of Structured Information Standards (OASIS) oversees SAML.

Security Token Service ( STS )

An STS provides a standards-based method of converting security tokens across different formats.

Service Provider ( SP )

For the purpose of SAML SSO, they are synonymous with Relying Parties. Service Providers generate SAML AuthnRequests, provide users with discovery interfaces, consume SAML Responses, and generally provide some sort of service or capability for a user.

Signature Verification

The process of checking the digital signature by reference to the original message and a given public key, thereby determining whether the digital signature was created for that same message using the private key that corresponds to the referenced public key.

Single Sign-on ( SSO )

Once an end user has authenticated their identity at an IDP, he or she may, by their choice, move among RPs that interoperate with the IDP without re-authenticating. In other words, the end user is seamlessly logged into any other RP that interoperates with the IDP. For privacy considerations, end users must take explicit actions to opt-in to SSO. In addition, SSO is in effect only for the duration of the end user's current browser session and authentication session.