Shibboleth Developers

[(Nate Klingenstein)]

This document has evolved from several conversations, notes, sets of
minutes, and readings of the arch-doc.  I welcome all comments and
criticisms of the document and hope it can start a discussion about Club
Shib -- especially those aspects for which I had to place ????'s as they
had not yet been discussed or concluded -- so we can get this document
ready to move forward.

Thanks,
Nate.


                            Club Shib

1.     Clubs

1.1    Shibboleth Clubs in General

    A Shibboleth club is a crucial part of the underlying trust required for
function of the Shibboleth architecture.  A club is a group of
organizations(universities, corporations, content providers, etc.) who agree 
to
exchange attributes using the SAML/Shibboleth protocols.  In so doing, they 
must
implicitly or explicitly agree to a common set of guidelines.

The common functions a club must provide to be operational for its community
include:

    a.  A registry to process applications and distribute club membership
        information
    b.  A URI that provides information on local authentication and
        authorization practices
    c.  A set of agreements or best practices agreed upon within the group on
        policies and business rules governing the exchange and use of
        attributes.
    d.  Definition of syntax and semantics for a common set of attributes for
        frequent exchanges.
    e.  A WAYF service that allows users from origin sites to select their
        security domain upon visiting any SHIRE within the club.

1.2    Club Shib

    Club Shib is a particular club operated by Internet2 intended to be a
co-operative environment for higher education and its information providers'
use.  Members can be registered with Club Shib as origins(IdSP's) or
targets(content providers, student loan services, etc.), but may be registered
as both(institutions, museums, etc.).

Club Shib will provide the following functions to its members:

    a.  A registry service to allow organizations to apply for membership in
        one of the aforementioned categories, operated by Internet2.
    b.  An eduOrg pointer will be maintained to campus account management
        practices.
    c.  Targets will be required to not cache attributes excessively, not
        accumulate data about any particular individual, should not accept
        attributes from attribute authorities not associated with the scope of
        the attributes within(e.g. one institution asserting faculty member
        from another), and not pass on individuals' attributes unnecessarily.
        Origins must provide a reasonable degree of accuracy in exchanged
        attributes.
    d.  eduPerson 1.5 and eduOrg 1.0 must be implemented for attribute 
exchange
        within Club Shib, but are not exclusive to other attribute formats and
        standards.  The MACE URN should be used where appropriate.
    e.  A WAYF will be provided by Club Shib's Wayfarer service.  This 
utilizes
        a membership list which will include addresses and private keys of
        SHIRE's and HS's within the club and will be distributed as a flat 
file.

2.     Club Shib Application Process

2.1    Initial Application

    The initial application should be sent to ????.  An authorized party for
this submission is considered ????.

2.1.1  All applicant organizations will agree to:

    a.  Use an implementation of Shibboleth that:
            i. Complies with everything in the Shibboleth Architecture v4
            ii. Complies with the Club Shib Member Obligations
            iii. Uses SSL for all interactions between Shibboleth components,
                 including the AA, HS, SHIRE, SHAR, and the user.
    b.  Provide certificates that comply with Club Shib PKI certificate
        profiles, and trust the Club Shib specified roots.

2.1.2  An applicant origin will agree to:

    a.  State/post local account management practices(see Greg Jackson doc,
        follow on discussion), including:
            i. Initial identification/password assignment process for accounts
            ii. Authentication mechanisms for account use(i.e. cleartext)
    b.  State local policy for maintaining the eduPerson 1.0 AFFILIATION
        attribute(basically, state whether you populate AFFIL values in
        a manner that is consistent with eduperson 1.0 guidelines; what
        qualifies someone to be a MEMBER, etc)
    c.  State local policy on populating and recycling EPPN values
    d.  State local policy on Life Cycle Maintenance(LCM) of user object and
        attributes(basically, when someone *leaves* the community, do you make
        a best effort to remove their privileges...)
    e.  State that all assertions issued by your institution will be true to
        the best of the institution's knowledge
    f.  Implement eduPerson 1.5 and eduOrg 1.0(including campus account
        management procedures)
    g.  (place holder) Ensure that the RHS of your EPPN attributes IS the same
        as the value your AA is placing in the SecurityDomain element
    h.  Agree that you will only issue Assertions about your Security Domain
    i.  Provide the DNS and associated certificate of the origin's HS

2.1.3  An applicant target will agree to:

    a.  Not send on, use, or cache attributes inappropriately
    b.  Provide the DNS and associated certificate of the target's SHIRE

3.     Club Shib Functions and Obligations

    Once an organization has been admitted to Club Shib, there is a number of
things which must also be done to ensure the continued smooth functioning of 
the
club.  These mostly include maintenance of the information submitted when the
organization first applies and implementation of new members.  (How is the 
club
managed (by the members? how are decisions made about club policy?))

3.1    Club Shib Obligations

3.1.1  Organizations Already in Club Shib:

    a.  Must update any changes to the DNS information and server certificates
        provided for initial registration to the Club Shib registry
    b.  Must accept and implement reasonably quickly new distributed flat 
files
        of keys and names
    c.  Must support and implement XML signatures, but use is optional
    d.  Should perform all redirections through HTTP, not HTML
    e.  Must reference this document in the audience field of all assertions
    f.  Should use the MACE URN namespace whenever possible
    g.  Should use eduPerson 1.5 and eduOrg 1.0 whenever possible

3.1.2  Origins Already in Club Shib:

    a.  Must provide a means for users to regulate attribute release
    b.  Should be listed in the WAYF service
    c.  Should set an AA attribute lookup timeout of 30 seconds
    d.  Must use opaque handles to protect anonymity
    e.  Should set ???? basic default ARP.
    f.  Must meaningfully populate the authenticationMethod field in 
assertions
    g.  Must continue to provide a reasonable degree of accuracy for 
attributes

3.1.3  Targets Already in Club Shib:

    a.  Must support the WAYF service
    b.  Should not accept attributes from domains not associated with the
        security domain of the associated attributes

3.1.4  Club Shib Administration:

    a.  Will receive and process applications for membership and withdrawl
    b.  Will maintain the registry of keys and domain names and regularly
        distribute this file to Club Shib members
    c.  Will ensure uniqueness of key identifiers among community members
    d.  Will house PKI components of Club Shib, including bridging if 
necessary
    e.  Will operate Wayfarer(tm Jeff Hodges) which lists origin sites and
        target sites can utilize
    f.  Will respond to notifications of member non-adherance to rules

4.     Trust in Club Shib

    Trust in Club Shib is provided using a signed package of data that
associates names, organizations, and public keys in a searchable way.  These
data are signed and distributed by Club Shib in a format that is easily useful
for AA's and SHAR's.  The SHIRE, SHAR and AA should be configured with a set 
of
trusted roots to use in validating the certificates in the local database or
passed in exchange by SSL or XML signature envelopes.  Trust in the origin 
side
of the Shibboleth architecture flows primarily from the SHIRE's trust and
knowledge of the HS, and the HS is responsible for pointing only to 
appropriate
attribute authorities for appropriate handles.  Trust of the target side comes
primarily from the knowledge of the SHIRE and the trust of the SHIRE to not
accumulate or pass on attributes inappropriately and to not allow 
inappropriate
SHAR's to use it for attribute requests.  DNS will be leveraged to
look up local certificates using the CERT resource record and to verify the
subject names of SSL server or generic certificates.  AA's will use the
distributed list to preconfigure mappings between SHAR names and target URL
trees to allow users a simple means to evaluate and change ARP's.  SHAR's 
will,
by default, accept attributes such that attributes must be scoped by the 
domain
associated with the handle service or client certificate used to formulate the
initial query.

Appendix A - "Club Shib's" Implementation of Trust Between Various Entities
- Naming, and Verifying Identities

Appendix B - Shibboleth Glossary


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

    http://archives.internet2.edu/

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