Shibboleth Developers

Get our your (virtual) red pen.......

GOALS
	- no manual intervention required for the regular operation 
of the federation

	- we expect to see several iterative implementations of the 
processes and management software. So... implement minimal 
functionality quickly, make v1 available sooner rather than later, 
and evolve as we gain a better understanding of (the real) 
requirements

	- start with NO security -- anyone can edit anything  in the 
metadata..... (see previous point,and see the name  of this 
Federation). See  how people behave......

	- start with NO validation at registration time (we could 
validate that some service is listening at the entered url's -- our 
experience is that people often don't have these running when they 
register; we could validate that the email addresses that are entered 
are working and that someone responds -- but the machinery for this 
is probably too complex for v1, and the tickle mechanism  will catch 
them  anyway....)

FUNCTIONALITY

web site -- metadata maintenance forms
        add/register an Idp or SP site

        delete an existing site

	edit an existing site (add entry  to transaction log, 
maintain last N copies of metadata files, email  the contact's  on 
every change....)

regular maintenance
	tickle  -- every (period), email  the contacts, tell them 
that to keep their entry  active they have to visit  the metadata 
entry web site and do something that updates the "date last changed" 
on their  entry.

	tickle delete -- remove entries that are stale (ie whose 
owners haven't updated their "date  last changed")

items to publish
        - WAYF
        - a testing page
        - InSecure policy

web site - administrative  functions

        - revert to previous version of metadata file
        - inspect previous metadata file
        - inspect transaction log


QUESTION -- how do we want to handle cert's in the trust file? have 
everyone generate a self-signed cert, operate a negative LoA CA, 
something else?