Shibboleth Developers

[Scott Cantor <>]

Tom Scavo wrote:
>   A Shibboleth identity provider MUST include the 
>   <md:IDPSSODescriptor> element in its metadata.

The purpose of these requirements are clear to me...any entity trying to 
represent itself with metadata *has* to include a set of required roles 
or the software won't work. I don't see why that's unreasonable.

> In what metadata?  Any given "IdP" may produce and distribute multiple
> metadata "snapshots" of itself.

Ok. If one of those doesn't offer the IdP role, then for the purposes of 
that peer, it's not an IdP. It's circular, I guess, but it's just 
self-evident to me. "IdP" is in fact a role, not a state of objective 
being. I'm an IdP because I can act as one.

> What if no metadata
> file produced by this "IdP" has an <md:IDPSSODescriptor> element? 
> (Farfetched, but why should that disqualify an "IdP" from being or
> becoming a Shibboleth IdP?)

How can it not?

I am within my rights as an implementation that consumes metadata to 
throw a "no IdP role found" error when I get an assertion from it. If I 
can do that and still claim to be conformant, then it stands to reason 
that the peer giving me the metadata has violated a requirement by not 
including the role.

If you're not using metadata at all, that's another matter, but unlike 
SAML itself, we require support of metadata to be conformant. Is it 
testable? Nothing is, we don't have a conformance test, but the Liberty 
guys seem convinced that metadata conformance can be tested, and they 
know this testing stuff more than I do. It's still OPTIONAL in SAML, but 
if you claim to support it, they seem to think it can be demonstrated in 
some way.

> What if some metadata file has an
> <md:IDPSSODescriptor> element but no Shibboleth SP consumes the
> metadata?  (How would you know that anyway?)

This MUST (and pretty much all of them) is a requirement on publishing 
the information, not consuming it. Again, I'm not going to argue about 
testability. I don't know if I even believe it's testable, but the 
people that assign Liberty's brand do. All I'm saying is if you "publish 
metadata", that it MUST be in this form, and MUST include certain 
elements to be usable in Shibboleth. If it has other stuff or you offer 
other formats, that's fine too.

> Having an <md:IDPSSODescriptor> element in metadata (whatever that
> means) is neither necessary nor sufficient for an "IdP" to be a
> Shibboleth IdP (as defined by you).

It is definitely not sufficient, no. It is entirely necessary unless the 
SP is using something other than metadata to figure out what to do. 
That's up to the SP, but a conformant SP can *require* metadata from its 
partner to function, and in fact mine does. That doesn't mean it can't 
be hand edited and entered by the SP admin, but the requirement 
stands...if I don't enter an IdP role, it won't work.

Of all people, I don't expect you to be arguing about why metadata is 
useful, and if it is, how can it work if we don't have any requirements 
on what goes in it? Why even have a schema?

> I think you're putting
> unreasonable restrictions on the kind of metadata a Shibboleth IdP can
> produce.

Explain to me what use allowing a Shibboleth IdP to produce metadata 
that cannot be expected to enable an SP to interact with it would be.

I *think* you're arguing that an entity that is a Shibboleth IdP can't 
also be a GridShib AA because of these MUSTs, and I disagree with that. 
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. If you 
have multiple instances lying around, one of them reflects the entity's 
capacity to be an IdP and one doesn't.

-- Scott