Shibboleth Developers

[Scott Cantor <>]

> well, let's start there, with the WAYF -- if the target is in two 
> federations, how does it know which WAYF to send the user to? present 
> the user with a list, and let them choose?

Hmm, does it matter? If 

 as asserted by InCommon OSU is the moral equivalent of 

 as asserted by OSU
OSU for the target's purposes, then the only requirement is a WAYF that got 
me to an OSU HS trusted by the target. Doesn't matter
which one.

As a question of UI, obviously it might be better to use one or the other, 
but it's not a trust issue. If I can't get to OSU from
both WAYFs, then there's a different set of issues in play anyway.

This conflicts with the other part below though...

> OK -- so there we have a groundrule.... we have multiple 
> federations. Targets are in multiple federations. Origins are in 
> multiple federations. But a specific origin-target pairing can only 
> be in one federation?

This is what would create the WAYF problem, I see. So maybe there's a way out 
if I can eliminate this restriction somehow, but I
need to think about it some. I suspect the answer is the Audience. If I can 
modify the mapper interface and the SHIRE's evaluation
of the assertion to take into account what the Audience is, maybe the code 
can distinguish between two federations and one origin
site.

It seems entirely clear to me that using a federation URI as a SAML Audience 
is both reasonable, and consistent with what we
currently do.

> I'll grant you -- it sounds very sensible. Once we start to see an 
> explosion of federations, tho, I'm  not sure how we could enforce 
> this, or even how we would detect it.....

I don't want to enforce anything, I just need the code to do the right thing 
based on what the policy is. The sites file(s)
represent the policy.

> it might be easier to manage if its a specific 
> origin-(target-application-domain) pairing.....

I'm skeptical that adding in more granularity will ever make this easier to 
manage. Liberty in contrast treats a ProviderID as
representing an entire company's web presence, for example. Their concept of 
policy granularity is massively broad. Our per-site
approach is fairly off the beaten path, and is directly driven by more 
traditional web-iso approaches. SAML and Liberty focus on the
company A to company B transition, which is why it's so easy to overlook the 
overlap with web-iso.

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