2.11 Attribute Authorities

TAS³ network may contain various attribute authorities. Every Identity Provider may act as an attribute authority by including <AttributeStatement>, see [SAML2core], in the single sign-on assertions that it emits. This constitutes an attribute push mechanism.

Problem with a push mechanism is knowing which attributes to push. A possible solution is for the Front End to express its attribute needs using a SAML extension, such as [Kellomaki08]. However, usually a better solution is to implement pull model Attribute Authority, i.e. the attribute authority is simply a web service.

There are several ways of implementing a data web service. [SAML2prof] specifies AttributeQuery protocol, but does not adequately specify the transport binding and peer authentication. TAS³ attribute authority SHOULD support [SAML2prof] AttributeQuery protocol using TAS³ SOAP binding, see section 2.3.2.

Other data web services, such as ID-DAP [IDDAP] over TAS³ SOAP binding, MAY be supported. A deployment may also make local or proprietary arrangements for accessing a non TAS³ attribute authority, e.g. using LDAP [RFC2251] or WebDAV with file containing attribute certificate or SAML attribute assertion.