From:  David Walker <dhwalker@ucdavis.edu>
To:  Federated Authentication Project Team <UCFEDAUTH-L@LISTSERV.UCOP.EDU>
Subject:  Tomorrow's conference call
Date:  Tue, 14 Dec 2004 17:06:21 -0800

People,

As was the case two weeks ago, much of the activity for this project is currently with UC management to resolve our business standards issues, but let's spend some time talking about that issue, as well as the metadata sharing issue that I mentioned in the attached.  FYI, I've attached a small risk assessment that I'd like to include in the discussion of business standards.

As usual, the call information is: 
Date and Time:   Wednesday, 12/15/2004, 9:00a-10:00a
Call-in Number:  866-740-1260
Access Code:     9870500
David




Email message/mailbox attachment, "Forwarded message - Tomorrow's conference call canceled"

From:  David Walker <dhwalker@ucdavis.edu>
To:  Federated Authentication Project Team <UCFEDAUTH-L@LISTSERV.UCOP.EDU>
Subject:  Tomorrow's conference call canceled
Date:  Tue, 30 Nov 2004 16:30:15 -0800

Everyone,

A number of us at UCOP have a conflict tomorrow morning, so I'm canceling tomorrow's call.  Our next call will be December 15.

In lieu, here's some status.

  1. As most of you probably know, the ITLC decided that we should not proceed with a version of the UCFY/Shib interface that prompts for the UCFY password.  While this will cause some delay, I hope it will not be long, and the result will be a stronger UCTrust.  As the result of this, Kris will be asking the Council of Vice Chancellors of Administration next week to designate a group of people to resolve the business issues.  We're working on a statement of those issues that I will share with all of you, probably early next week.
  2. I've been doing some research into the issue of how we can share metadata about UC-only targets.  The issue is we will receive regular updates of an XML file from InCommon containing a <SiteGroup> object that, in turn, contains <OriginSites>s and <DestinationSite>s.  Our targets would be <DestinationSite>s.  I think we have the following alternative strategies we could follow:
  3. Distribute UC-only <DestinationSites>s separately and write a program that merges UCTrust sites into the list provided by InCommon.  That merge program would need to be executed after updates of either InCommon files or UCTrust files.
  4. Register UCTrust targets in InCommon.
  5. Treat UCTrust as a completely separate federation.  I don't like this one as well, as it probably means a separate WAYF, requiring people (or their portals) to declare their origin sites twice, once for InCommon and once for UCTrust.
    6. Assuming we end up with a lot of UC-only targets, option A is probably best.  While we have only a few targets, B is a lot less work.  I'm leaning toward B for now, reassessing in the future; how do others feel?

David




HTML page attachment (UCTrustRisks-2004-12-02.html)