Shibboleth Developers

[Tom Scavo <>]

On 9/9/05, Scott Cantor 
<>
 wrote:
> 
> I *think* you're arguing that an entity that is a Shibboleth IdP can't
> also be a GridShib AA because of these MUSTs

Yes, thanks for reading through all the words ;-)

> and I disagree with that.

Well, what you're saying (in the spec) sure sounds overly restrictive
to me.  When you say a Shibboleth IdP (or SP) MUST have this or that
in its metadata, without qualification, I get nervous since my
metadata files are different than yours.  This is, of course, because
GridShib emphasizes certain functions of a Shib IdP over others.

> If you don't want to include the IdP role, then you don't have to, until
> you publish metadata designed to be consumed by a Shibboleth SP.

Here's a possible long-term scenario:

  GridShib IdP = Shibboleth IdP + GridShib extensions
  GridShib SP = Shibboleth SP + GridShib extensions

So in a sense GridShib is to Shibboleth as Shibboleth is to SAML. 
We're just building on each other ("the shoulders of giants...").

When an IdP interacts with a Shibboleth SP, the IdP dons the role of a
Shibboleth IdP.  To a GridShib SP, however, an IdP is seen as a
GridShib IdP.  It's the same physical IdP in both cases, acting in
different roles and obeying different profiles.  So there are two
logical IdPs with overlapping functionality and metadata.

I guess I'm trying to avoid having to rewrite the GridShib profiles
from scratch.  Our attribute exchange profile is a straightforward
extension of the Shibboleth Attribute Exchange profile, but it seems
our metadata profile will have to be written from scratch, on top of
the SAML 1.x Metadata profile.  I guess that's okay.  I wasn't
thinking along those lines until now.  Your wording in the Shib spec
has brought this point home.

Tom