Shibboleth Developers

[Ian Young <>]

Simon McLeish wrote:

> In terms of metadata publishing, what about having the equivalent of a
> Z39.50 explain function (but usable, obviously), which would be a
> request to an IdP or SP that would get back some human readable,
> configurable data (such as "If you want to use these services, your IdP
> must release at least the following attributes" and service
> descriptions) and some machine readable data that would be at least the
> basis of metadata (i.e. basically what you'd need to add a unique
> identifier to to get metadata). This may be included in Tom's suggestion
> (depending on what metadata consumption means, I guess).

Someone will no doubt correct me if I'm wrong, but I believe that there 
is already a defined facility in the SAML 2.0 metadata format for an SP 
to express this, the AttributeConsumingService element.  From the spec, 
line 778 et seq:

> The <AttributeConsumingService> element defines a particular service
> offered by the service provider in terms of the attributes the service
> requires or desires.

There is human-readable and machine-readable stuff in there.  The 
service is described for humans, the attributes are described as 
(slightly extended) SAML Attribute elements.

One of the things on my list for the SDSS federation metadata is to 
start publishing this information for SPs in our federation, where we 
know it (we already publish it here: 
http://sdss.ac.uk/wiki/wiki.pl?AttributeUsage).

> If you could more or less cut and paste the output of such a query into
> a metadata file, then it would definitely save one of the major causes
> of Shibboleth errors.

Of course, cut and paste wouldn't be possible at present because the ARP 
format is just not the same as the AttributeConsumingService format. 
And that's even if it were advisable to make it so easy for people 
running IdPs to put no thought into their attribute release policy, 
which I think some people would argue it isn't.

So, some tools are required in this area either way.  My feeling is that 
tools are more likely to come about if there are some real examples of 
AttributeConsumingService available for tools to chew on.  Hence my plan 
to start including that stuff.

        -- Ian