Shibboleth Developers

At 11:24 AM -0400 5/15/03, Scott Cantor wrote:
>  > >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.

So, trying to paste together a somewhat complete description of how 
this would work, in v1.0..

Starting with some  of Bob's text:

At 11:28 AM -0700 5/14/03, RL 'Bob' Morgan wrote:
> So, to restate this so I can test my understanding:  if an origin needs to
> support distinct requirements of targets (eg what key/cert to use to sign
> an authn assertion), then it has to run distinct HS/AA instances, which
> specifically means distinct service URLs, aka entry points.  Seems
> reasonable to me, and as we've discussed, its acceptability depends
> somewhat on how many federations show up in practice.

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

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

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

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

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

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

where did I fall off the tracks?

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

   http://archives.internet2.edu/

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