Shibboleth Developers

Title: shib design call, monday (3/17), 3:00 pm est, noon pst

Standard logistics:

Phone #:  800-998-2462
Pin #:  5601277

Agenda items:

1) status - 0.8 release

        - known issues/bugs?

                target side problems with compiled apache (RL Bob, report; same report formIJ at I2)

        - any cleanup required?

2) Next steps

        - version 1.0 contents -- see list of possibilities down below; I'm sure others have their own lists; please send other possibilities to this group before the call

3) Shib Agenda, I2 Spring Member Meeting

a) what "hot items" do we want to include in the "next generation demo"?

b) shib-related gatherings during the MM --

tuesday

        3-5 pm, closed shib working group meeting - agenda, lay out work plan for  next period -- post 1.0-- GUI, could include discussion of interoperatbility with PAPI)

        5:30 - 7 pm, open working group meeting - include pilot sites and vendors - use to review progress, devekop AIs? 

wednesday

        lunchtime demo (already nicknamed "eat shib...")

        4:45 federations

thursday

        lunchtime demo redux

        shib deployers and users panel - late pm

        weaving a trust  fabric - panel  - shib and pki

4) combined "target login and WAYF" page.....

this issue has come up in several recent conversations; sometimes it turns out to be fear that the WAYF isn't scaleable; other times, a target site feels that 95+% of their usage will be local, with a small amount of external usage, and they're trying to simplify the user experience. This example apparently came from Greg Wood, of I2:

At 12:03 PM -0500 3/11/03, George Brett wrote:

> For the moment you can see the InCommon
> sample login at
>  
> http://detective.internet2.edu/archive/login.html

thoughts...?

5) Post 1.0 -- see list down below -- 1.1 thru Version 2

----- Version 1.0 (April 03)

1) Improved error handling -- general issue; in addition, have origin send the target a url of a "customized origin error page".

2) Target robustness -- what, if anything, to do here....

3) AIs from PKI/Shib conversations

        opensaml - send authn type

        opensaml - (somehow) send authn strength

        browser user present cert to target; have target use cert as handle

4) AA - backend attribute plugins

5) AA - simple GUI (based on designs form Li Cao)

6) W2K - Apache (Aaron's work)

----- Version 1.1

1) tools to help manage the sites file (as I2 ramps up process and support for InCommon); wht should be in the sites files...

2) Support for Apache-2

3) Support for W2K - IIS

4) Collecting usage data. Define what this means, and implement it.

----- Version 2 (for oct 03)

1) UI/ Managing Attributes -- the UI work might quickly split into several very different threads..

        - the actual UI work, which is an art that supports ease of use

- the policy and cultural questions and issues triggered on seeing some of David M's scenarios. Leading to... which of these should we actually implement?

      - what do we want to implement in a real myAA interface?

        - delegated management of ARPs

        - dynamic attribute release (actually requested by the swiss!)

2) Extend the AA's functionality

        a) privacy manager/myAA/Autograph stuff. From David McDonald's work.

    b) allow entitlements based on "who you are" and where you are" (eg the Business School Library)

        c) Nugget from Ken's talk to UWash information school this morning:  project
on "informed consent" by UW prof Batya Friedman, co-PI Ed Felten of
Princeton, see


   http://www.ischool.washington.edu/research/projectdetails.cfm?ID=5

      d) there is active work at Uwash, sponsored by niso and dlf, on creating a uniform
xml schema or alternative db template which would record specific contract elements in a queryable
instantiation.  this is called an electronic resource management system.  see

http://www.diglib.org/standards/dlf-erm02.htm
http://www.niso.org/news/events_workshops/NISO-DLF-wkshp.html

        e) (from David W..) Consider generalizing the AA to serve campus applications that need "authorization support" services. We'd like to see - not a central authority that is required for authorization decisions (e.g. yes/no) but - a server that will provide reliable advice (which might be eligible/not eligible) based on campus business rules, directory information about the individual, etc. In this application, the semantics don't need to be understood externally, i.e. the meaning of ID tokens and eligibility information needs to be understood by campus applications but nothing outside campus. This could back-end a very nice white pages service that would allow people to manage release of their information both to internal and external entities, for example, including the ability for "externally connected" campus folk to get "campus only" information.

3) Personal resource manager or other resource manager discussions. This may get bundled with any XACML related work elsewhere in the NMI proposal.

4) Worry about scaling the WAYF and the Registry

-----  Version 3, for nmi-2. Work running from Oct 03 thru April 04; since this is mostly thinking, the conversations may start sooner than October

1) Federation of Identity
       - what is our strategy for this? liberty? federation/stitched directories?

      - "simple federation" -- one meta-directory process manages multiple directories (eg multi-campus university, with a central directory and campus based directories) - aggregate entitlements from memberships in both directories

      - "complex federation" -- the IEEE scenario

2) Multiple Clubs and Federations

    - maybe more on federation complexity
   - membership of a target site in multiple clubs/ federations

        - membership of an origin site in multiple clubs/federations