Shibboleth Developers

[Simon McLeish <>]

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

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.

Cheers,
Simon

Tom Scavo wrote:

>On 3/12/06, Velpi 
><>
> wrote:
>  
>
>>* resolver-ARP-metadata management UI (modular)
>>    
>>
>
>This is exactly what's needed.  Here is what it might do:
>
>- Produce IdP metadata from the underlying config (idp.xml, resolver.xml)
>- Publish metadata to a "well-known location" or a metadata repository
>- Consume SP metadata and ARPs, provide a UI to administratively merge
>the two, and produce new ARPs
>
>So a pair of tools are needed at the IdP, one for metadata production
>and another for metadata consumption.  Same is true at the SP.
>
>  
>
>>Question is: do you really want your metadata to be editable easily? I
>>guess not, but there are a lot of ways to prevent tampering.
>>    
>>
>
>A tool that manages metadata does not need to edit metadata.  The UI
>above leverages SP metadata to manage policy at the IdP.
>
>Tom
>
>  
>