Shibboleth Developers

> 1. Introduction to InQueue


we've got to state somewhere that these are "interim guidelines".....

> InQueue is an elementary 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 is not intended to be a 
> production federation

I'm not sure the readers will understand the term "production 
federation".... or "elementary federation". we seem to be saying that 
I2 will operate IQ and support it, so what's not production about it? 
Do we mean that campuses should NOT deploy production services that 
rely on IQ? Why not? What bad things might happen?

It might be helpful if we could list what IQ does NOT provide? or guarantee?

- sites do not formally apply for membership, and requests are not 
"fully vett'ed" before being approved. Consequently, an entity 
asserting that it it is "brown.edu" is likely to be run by someone 
from brown, but may not be acting on behalf of the campus, and its 
good faith agreement that the attributes it is asserting are 
"correct" must be understood in that context.

- the trust.xml file distributed by the IQ federation includes root 
CAs that operate under non-existent CPs and CPS's. This means.....

I'm certainly uncomfortable including "what IQ is not" style info in 
the IQ doc. However, this whole federation space is currently such a 
blank slate that sites have NOTHING to compare the IQ doc against, in 
order to make their own determination of what IQ is not... 
Consequently, I think that, during this interim period, we're 
somewhat obligated to help them understand.....

Once we stand up IC, and there's a comparison point, I'd be agreeable 
to removing these kinds of statements.....

Also:

At 2:55 PM -0400 6/9/03, Scott Cantor wrote:
> The only thing to add might be any PKI issues surrounding the SHAR and
> AA. A target in a federation has to use a shar key signed by
> a CA that the AA will trust.


> , and organizations will be expected to progress from InQueue to an 
> appropriate federation.
>
> 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.

maybe sentences 2 and 3 should be put in a section titled 
"Requirements for Membership", as a way of indicating that we're 
serious about them?

for origins, what level of "institutional commitment (or intent)" do 
we want to require?

> InQueue does not specify a specific set of trusted certificate 
> authorities; however, consultation of the guidelines on certificate 
> authorities for federations the site intends to join is recommended.

ummm...IQ will distribute a trust.xml file...... with a set of root CAs......

> To join InQueue, origins must submit a basic application to 
>  containing the following information:
>
> *       Domain Name of the origin site (e.g., Ohio State's is "osu.edu")

this must also be entered into the origin.properties file as the value for 
BLAH

> *       Complete URL to access the HS

this must also be entered into the origin.properties file as the value for 
BLAH


> *       The CN (usually the hostname) of the HS's certificate's subject

I'm not having much luck finding the appropriate thread in my 
mailbox, but I think there are constraints linking the 
origin.properties issuer value, the CN, and this value (which appears 
ultimately in the sites.xml file). The constraints may be different 
depending on whether the origin supplied a cert to IQ or is using a 
cert signed by one of our trusted CAs. Scott and Walter know the 
details.....

> *	Any shorthand aliases the WAYF should support for the origin 
> site (e.g., Ohio State, OSU, Buckeyes)
> *       Contact names and addresses for technical and administrative issues.

email addresses

Additionally:

-- a url for the origin site "error page" (see blah for more info -- 
where should this requirement of origin sites be described? is this a 
requirement for ALL federations, or just IQ/IC?)

optionally, the cert corresponding to the signing key used by the HS 
(if its not signed by one of the root CAs accepted by IQ)

> To join InQueue, targets must submit a basic application to 
>  containing the following information:
>
> *       The name of the organization
> *	Contact names and addresses for both administrative and 
> technical purposes

SHAR must use a cert signed by a CA in the CA-bundle.....

Based on another thread, and Nate's question, should IQ define a set 
of attribute names (and, in some cases) corresponding values)? Use of 
these attributes when using IQ's policy uri MUST be consistent with 
IQ's definitions....?

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--