Shibboleth Developers

well, I sure am glad that we've finally managed to immerse ourselves 
in this multiple federation discussion... haven't had this much fun 
in a while   (-:

a small number of things seem clear:

- while we understand the problem better than we did a month ago, or 
six  months ago, we still don't understand it enuf to be making any 
definitive statements. At least I don't....

- we have this deadline looming over us... (shib v1); scope creep for 
v1 terrifies me

- in the short term (eg before sept?), we don't have any situations 
that require support for multiple federations...?

Consequently, my sense is that the item to worry about is 
compatibility between releases -- that old bugaboo. Do the best we 
can in the short time available... but worry about those points that 
might create compatibility problems.

I'm not at all worried about the sites file changing (as long as it 
doesn't change in ways that affect what gets sent over the wire....). 
For instance, resolving the one file,  multiple files issue doesn't 
seem worth worrying about in the short term?

Is this a reasonable way to look at our situation?

Reacting to some of  the comments from late yesterday, when I was 
disconnected:

At 4:42 PM -0400 5/14/03, Scott Cantor wrote:
> The one file thing is purely expediency. We used to pull the file 
> directly from one spot, so that's what was coded. I can obviously
> just extend the code to read in more than one, and I can even keep 
> them distinct in the system, but the point is, how does the
> target know which file/group/whatever to query for information when 
> an assertion is posted? Currently the input to that API is
> "origin site name".
>
> If that isn't sufficient (because we continue to use DNS domains, 
> but permit the same site to be in more than one set of sites),
> than the API has to change, and the second parameter has to be 
> available in all the places in the code where the API gets used. I
> probably could pull that second parameter from the Audience field, 
> but that leads to some questions when more than one Audience is
> present.
>
> I'm thinking we should use URIs for origin site names. Then the API 
> works as is, and if OSU is registered to InCommon and UnCommon,
> it's with a different URI.

these two suggestions (second parameter, URIs for origin site names) 
are starting to make sense for me, too.

yesterday, I started a thread asking about multiple WAYFs, but 
someone else later picked up the real question, point -- an osu 
origin might belong to two different federations that operate under 
different policy; the chosen policy (ie federation) has to be 
communicated from the origin to the target; this becomes quite messy 
and confusing if the target is also in multiple federations.

I don't think we're going to get this sorted out in the near term 
(even to the point of determining what the realistic scenarios are...)

but I think Scott's suggestion is a step toward reducing the confusion....

At 1:26 PM -0700 5/14/03, RL 'Bob' Morgan wrote:
> I guess there are choices here regarding XML objects, signatures, XML
> documents, and files (or does one file = one XML document?).  Given the
> underlying technology I guess things could be done any number of ways:  a
> federation authority could issue a bunch of little files, each containing
> a signed object containing a single Site element; or it could put out a
> big file/document with those signed objects in it; or it could have a big
> file with one signature over the set; etc.  And the target has some of the
> same choices:  merge objects into one file, etc.  I don't know how we
> decide what's reasonable here.

yes, we're going to have to  face all of this -- but I'd suggest 
deferring it past 1.0.....

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

   http://archives.internet2.edu/

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