InQueue Configuration and Policy Guidelines
Nate Klingenstein
17 June, 2003
Comments should be directed to

InQueue Federation Interim Configuration and Policy Guidelines

These are interim guidelines intended to allow InQueue to operate as a federation before full production requirements are known.

1. Introduction to InQueue

InQueue is a simple federation designed to support interoperability between origin and target sites as organizations become familiarized with Shibboleth and the federated trust model. It will provide basic federated services including maintenance of a WAYF and trust and metadata files. It will give a best effort to ensuring that all sites admitted are representative of their organizations. It will define a basic set of attributes to aid interoperability.

InQueue is not intended to be a production federation, and organizations will be expected to progress from InQueue to an appropriate federation. Using InQueue for production services is not advised due to the lack of a formal application and membership process, and the lowered level of assurance that a site is indeed representative of a community this brings. Additionally, InQueue recognizes many CA's, some of which do not maintain a CP/CPS or rigorous issuance standards.

2. Joining InQueue

Sites may join InQueue as an origin, as a target, or submit both sets of information to join as both a target and an origin. Origins must assert before joining that all attributes sent to targets in the federation to the best of their knowledge accurately represent information about the authenticated individual accessing the target resource. Targets must agree to dispose of all received attributes properly by not mis-using them, aggregating them, or sharing them with other organizations.

InQueue will distribute a set of trusted CA roots from whom certificates for architectural components are acceptible for InQueue membership. Additionally, sites with certificates not rooted in one of these trusted roots may have these certificates added to the appropriate trust file. Targets must have a certificate signed by an acceptible CA. The list of certificate authorities recognized by InQueue is:

* The certificates issued by this CA will expire fairly quickly and should only be used for testing.

To join InQueue, origins must submit a basic application to containing the following information:

To join InQueue, targets must submit a basic application to containing the following information:

3. Configuration for Using InQueue

Once your site is accepted into and added to InQueue, the following configuration parameters must be entered to ensure interoperability and compliance with federation guidelines. Consult the Shibboleth Deploy Guides for further information on these fields and on and shibboleth.ini.



Must be populated with a URI that will be assigned by InQueue when you are accepted into the federation.


This field must contain InQueue's urn:mace:inqueue URI, and may contain other federation URIs as well.



This field must be set to InQueue's simple WAYF at


This section must contain InQueue = urn:mace:inqueue, and may contain other federation name/value pairs as well.


The URL for the metadata.xml file for InQueue is The URL for the trust.xml file for InQueue is The signing certificate used for these files may be found at and has the fingerprint b4 42 6c 1e 8b 7d 8e b3 68 03 00 e4 c4 57 dd 74 89 f8 9a 80.

4. Attributes

In order to facilitate basic interoperability, the InQueue Federation is promulgating a set of Attribute definitions for use by its members. If a Federation member sends or receives an Attribute Assertion containing the InQueue policy uri and referencing one of the listed attributes, then the syntax and semantics of the associated attribute value MUST conform to the definitions specified in the EduPerson specification 2002/10

5. Sample Target

A sample shibboleth target is available for testing newly installed origin sites.