Trust Anchors

Inclusion of the trust anchor is vital - without it credentials may be e=
xposed to malicious resource providers. This credential format is also used=
to secure communication between RP's, IdP's and trust routers.

You must use either the Certificate Authority (CA) root certificate or t=
he server certificate as trust anchor.

CA Root Certificate

Certificate Expiry

We recommend that a CA certificate is generated with a long expiry time =
(in years or decades), and that it is kept safe for subsequent server and u=
ser certificate generation cycles.

To use the CA root certificate as a trust anchor, you must populate the =
one or more of the following tags in the <trust-anchor> section:

<ca-cert>: The value of this tag is either a Base64-=
encoded version of the CA certificate in DER form, or the contents of ca.pem, excluding the BEGIN and END lines.This value is always required.

<subject>: The value of this tag is the CN value =
of the DN in the text representation of the server certifi=
cate. This value is required when <subject-alt>=
is not specified.

<subject-alt>: The value of this should be the DNS n=
ame, FQDN or the IP address information in the X509v3 information of the server certificate. This value is required when <subject> is not specified.

To retrieve either the subject or subject-alt =
information, dump the server certificate's text information. Use OpenSSL as=
follows:

Services

The optional services section is used to determine whi=
ch services the credential will be automatically used for - each service wi=
ll be contained in its own tag. For use with a trust router, it is better t=
o use the selection-rules section instead.

Selection Rules

The optional selection-rules section is used to restri=
ct which services the credential will be automatically used for - for use w=
ith a trust router identity, the service type is "trustidentity" for all se=
rvices. Wildcards are acceptable.