Shibboleth Developers

[Scott Cantor <>]

> > Well, so far, I've presented a first draft that requires:
> >
> > a) one sites file
> 
> I'm trying to understand this too.  I'll admit to not being 
> that familiar with the existing sites file schema.  Is the 
> intent that SiteGroup represents what we call a federation?  
> How is the SiteGroup structure reflected in the code?

Well, currently it's not reflected anywhere in my code. It was really more of 
a WAYF thing when I included it, but in the interest
of not making huge changes, I was planning on using that element as a way to 
group sites around a TrustList, and to the extent that
that's a federation...

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.

> I guess there are choices here regarding XML objects, 
> signatures, XML documents, and files (or does one file = one 
> XML document?).

Yes, by definition, but it's more of a multiple source thing. If the same 
source is producing metadata for two groups of sites, one
file is no big deal. If not (the common case), then it's an issue.

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

Roughly what Liberty seems to be doing, though I'm not clear on who's signing 
their metadata. I get the sense it's not done that
way...a provider signs its own metadata, and a relying party is hand-cranked 
with the keys to trust.

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

Right, you can do just about anything, and given a pluggable implementation 
that knows what to do in each case, it can work. I'm
just trying to start with something reasonable, but the single file 
restriction is probably not a problem to fix.

This is very distinct from the more fundamental question of site 
identification in the system as a whole, and how data from multiple
sources of metadata get merged into one view of the asserting parties.

> Seems to me like a model where federations issue a 
> singly-signed document listing their (origin) sites, 
> standalone origins can do the same, and targets can stick all 
> these documents in one place (much as they do with CA roots) 
> in order to rely on them, is straightforward.

That's roughly where we are, once the single file is fixed. But it still 
requires answering the question of what happens when
osu.edu is listed in both files.

My inclination is to acknowledge that URIs are better, and have 
mace:urn:InCommon:osu.edu and mace:urn:osu.edu:ClubBuckeye

This seems to me to "just work" in the 1.0 code. The 0.8 code relies on site 
names for auto-scoping of attributes, but that is
finally gone in 1.0.

The cost is duplicate policy (one set of rules for each URI that might say 
the same thing). But if you have to bring the federation
URI into the picture anyway, then you still have duplication, and it feels 
even more awkward to me.

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