Shibboleth Developers

[Scott Cantor <>]

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

I do, but since I have no real commitments, it's not precisely a requirement. 
I'm just fairly certain that one global CA list is not
going to work for anything beyond the library pilot, so I'm trying to fix it 
now, at least in limited fashion.

> 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?

Possibly not, but it's also the easiest thing to fix. Please, ignore that for 
the purposes of this discussion.

The sites file is very likely to change a lot. That will affect 
compatibility, but since multiple files can be created with
different formats, and it's easy to drop in a new schema to accommodate those 
changes at a target, I'm not very worried about it.
Especially since the generation of the file can be automated, so we can 
generate fifty different versions if need be (no, I don't
propose that). But yes, I'd like to try and head off the obvious stuff now.

> >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.

They're competing suggestions, or at least orthogonal. Using a URI for sites 
is a way to avoid having to bring federations into the
discussion. If one site is in two feds, but has different URIs, then at a 
basic level, it looks like two different sites to the
target. Which fed is involved becomes a fairly internal matter for the code, 
and doesn't have to be exposed in a way that seems to
me fairly premature, since we don't fully understand feds yet.

I believe I can build a pretty workable multiple federation/trust engine by 
next week if I can simply disambiguate sites by name in
all cases. Then I have a pretty routine set of additions, and not many 
changes to make.

FWIW, I changed shib2's "site name" to urn:mace:InCommon:pilot:shibdev.edu

Nothing broke (except for my AAP, which had to change to reflect that site 
name, of course). We can do this any time at any pace,
and it's not even an issue until you have one logical site with two sets of 
policy or trust data.

So I suggest we handle multiple sites files, but require that site names be 
unique across them. If that doesn't require URIs in the
short term, fine, but they can be used w/o any trouble or switched to in the 
future without code changes.

-- Scott

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

    http://archives.internet2.edu/

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