Shibboleth Developers

[Scott Cantor <>]

> each distinct origin would send its own name (DNS or URI) and the uri 
> for the federation(s) that its a member of.....

Well, my proposal is that we stay with the basic model of using the Subject 
NameQualifier as the origin site name, to be assigned by
the federation. That can be DNS (like now) or URI (better). The Audience 
would continue to probably carry something akin to
federation URI, but that would stay somewhat informal for now.

> the target would use the origin name to locate the appropriate sites 
> file entry.... (must be a unique match)

Yes. I would do as now, but load any number of site files into memory, with 
data keyed by site name/URI. The existing SiteGroup
schema permits grouping sites together to associate them with the TrustList 
to use, so I can map from the site to the appropriate
metadata, and the level of aggregation is open to whatever we find is useful.

Initially, we would probably see each federation signing and supplying a 
single collection of sites and trust data. All a target
would have to do is add each file to its system, and set up a job to 
download/verify each one as needed with a siterefresh tool.

> and then verify that the federation uri from the sites file was in 
> the audience element...

Yes, but I would probably leave this out of the sites file except maybe in 
some optional informal way, and probably not tie it to
the Audience field. Currently, the origin and target each configure the 
audience values and the system just looks for an overlap. I
think we can stay with that informal approach until more experience is gained.

> and then use the federation's list of trusted CA's, and other policy 
> components (eg AAPs)

Well, I assume AAPs are a local target issue, not a federation one. A fed 
could publish a template that includes the attributes it
wants to define, but that's about it.

> are there other federation related policies implemented in the target 
> side code?

No, and what policy exists is not based on anything I would call a 
federation. I'd like to keep it that way as much as I can, which
is why I feel more comfortable staying with a site-driven model, where policy 
is based on the origin site.

> do we need any origin side modifications to support this model?

No, though Walter's proposed approach to handling things like different 
signing keys would. My approach for now is just to duplicate
the webapp with a different configuration, whereas his approach is to 
actually do runtime determination of configuration out of one
webapp. Obviously that would be fine, I just don't consider it essential.

URIs as site identifiers work today in both codebases. The only reason it 
doesn't work in 0.8 is the auto-scoping of attributes we
used to do, and we don't do that any more.

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