Shibboleth, as a general specification, relies on a pair of published SAML specifications and some additional guidelines, outlined in the Shibboleth Protocol Specification, the latest version of which can be found in the TechnicalSpecs topic.
As a practical matter, basic interoperability is not fully addressed by that specification because of gaps in the SAML specification and extensions defined by the Shibboleth implementation to address value-added features.
Herein, we define the additional assumptions, behavior, and supported features of the Shibboleth software itself.
Schema Extensions
The schema currently supported by ShibOnedotThree is in the namespace urn:mace:shibboleth:metadata:1.0 and is defined by this document.
At this time, it is expected that ShibTwodotZero will also support this schema, and will not define additional extensions.
<shibmd:Scope>
Formerly <OriginSite> / <Domain> in older Shibboleth versions, this element is found in the <md:Extensions> element of an attribute-supplying role descriptor ( <md:IDPSSODescriptor> , =<md:AttributeAuthorityDescriptor>=)
Each element identifies a permissible attribute "scope" for the role. Scope is an attribute-specific concept used in Shibboleth to enhance the functionality of the AttributeAcceptancePolicy features.
<shibmd:KeyAuthority>
Formerly <Trust> / <KeyAuthority> in older Shibboleth versions, this element is found in the <md:Extensions> element of the <md:EntitiesDescriptor> and <md:EntityDescriptor> elements.
Each element represents a set of input to a certificate path-building operation during transactions involving the roles or system entities contained within the parent element. Each <ds:KeyInfo> element represents a single trust anchor for such operations, generally an X.509 certificate.
The VerifyDepth attribute controls the maximum path length to allow, using the PKIX-specified definition of path length (which is basically one less than the actual chain length?)
KeyInfo Syntax
SAML MetaData uses the XMLSignature-defined <ds:KeyInfo> element to represent "keys" in an abstract sense. Keys can take the form of public keys, X.509 certificates, or various indirect key "identifiers" such as certificate subject names. The actual use of keys or certificates is not the domain of MetaData itself, but is a component of how the software uses MetaData to perform TrustManagement.
However, the MetaData implementation in Shibboleth is responsible, to some degree, for processing the <ds:KeyInfo> element so that its contents can be used by the TrustManagement layer. In ShibOnedotThree, the actual responsibility for this is somewhat shared by the MetaData and TrustManagement components. In ShibTwodotZero (at least in C++), the functionality has been isolated to a new component called a KeyResolver, which turns KeyInfo information into various concrete objects, such as a key, a chain of certificates, or a CRL.
In documenting the supported syntax here, keep in mind that the semantics are a separate issue. For a complete picture of how the information gets used by the implementation, refer to the TrustManagement topic, and the specific topics that describe the TrustEngine implementations.
ShibOnedotThree
The following syntaxes are supported in some fashion.
<ds:KeyName><ds:KeyValue>/<ds:RSAKeyValue><ds:KeyValue>/<ds:DSAKeyValue><ds:X509Data>/<ds:X509Certificate><ds:X509Data>/<ds:X509CRL>
ShibTwodotZero
The following syntaxes are supported in some fashion.
<ds:KeyName><ds:KeyValue>/<ds:RSAKeyValue><ds:KeyValue>/<ds:DSAKeyValue><ds:X509Data>/<ds:X509Certificate><ds:X509Data>/<ds:X509CRL><ds:RetrievalMethod>with same document references to any supported element