Shibboleth Developers

["Scott Cantor" <>]

> I admit I don't understand this attribute, but it's in every metadata
> file you distribute so how can you get away with not using it here?

If I had my way, it wouldn't appear in any XML files or schemas that we
distribute, as I think it's an evil thing for various reasons, some fairly
metaphysical pertaining to what schemas are. Some people want to use XML
editors that don't provide any other schema resolution mechanism, and still
validate the XML they edit. That's not how I do things, I validate after the
fact in most cases. Not least because most editors have totally broken
validators.

In any case, the code never under any circumstances uses schemaLocation for
any purpose and it never will. Try it and see, put whatever you like in the
location hint and see if anything breaks.

> Suppose I'm an IdP trying to use this tool.  Since the Name attribute
> is only of use to the SP, I agree the tool should not bother to
> include it.

Name is used by the IdP if you set policy based on EntitiesDescriptor
membership, same as in the SP.

>  But the SP will almost certainly be using the Name
> attribute to refer to a group of IdPs (if not, it should be) so the
> EntitiesDescriptor element produced by the tool is of no use to the
> SP.  So why produce an EntitiesDescriptor element at all?

I agree. I keep saying that. Where did I say to generate one? If I misspoke
in my response to Nate, sorry, but my intended comment was "don't bother
generating an EntitiesDescriptor, but rather make this XML instance
self-contained and valid".

> There will have to be documentation telling a metadata consumer what
> to do with the metadata received from a partner.  Are you going to
> suggest the RelyingParty element refer to a Name (as opposed to an
> entityID)?  I think you would want to do that, right?

I think I would in general hope that there is no need for a RelyingParty
element, and since this whole "tool" is for people doing proof of concept
testing to understand what's involved, I think I can safely assume that. But
if not, I would disagree with you. I'd probably assume a RelyingParty based
on the entityID for illustration that the relationship is point to point.

This is not like GridShib where one might expect any sort of coherent set of
assumptions across partners, but it's basically impossible to say because I
don't know what the actual relationship is. RelyingParty elements are for
overriding default configuration. I can't know what the user would need or
want to override, so it's quite possible every partner has its own settings.
If so, why bother creating a group of one?

> Actually, you could provide an EntitiesDescriptor stub in the
> distribution itself.  Appropriate MetadataProvider and RelyingParty
> elements that read this stub could even be included in the
> distribution.  If you'd rather not pollute the config, that's fine,
> but an EntitiesDescriptor stub could be provided so that the metadata
> consumer could just plug in one or more EntityDescriptor elements.

I suppose that's possible, but I don't think it's anything we have to
provide. If people want to wrap their partners that way, that's fine. Such
wrapping is also orthogonal to what RelyingParty elements are used. I can
group them just to save on MetadataProvider elements without grouping them
for policy purposes.

> Unless I'm missing something, I don't think the tool should emit an
> EntitiesDescriptor element.  I think it should emit (signed)
> EntityDescriptor elements only.  These would then be plugged into a
> stub provided in the distribution.

I don't think it can or should sign anything, that's getting into areas this
thing has nothing to do with. I do think it should emit only
EntityDescriptor elements, and that we should describe how one might sign
it. As for where it goes, we can't know enough to document that.

-- Scott