InCommon Library Services

[Steven Carmody <>]

Hi,

This list, and this group, has been quiet for a while. But, there has 
been activity behind the scenes!

Thomas Howell from Northwestern has developed a Registry application 
which we can use to share information about SAML-enabled resources, and 
to share implementation details among universities who would like to 
integrate with specific SAML-enabled vendor resources. This Registry is 
planned to be a community-driven resource -- a place were all of us can 
share what we know and learn from what others know. The goal is to 
provide information on some of the details and quirks of particular SAML 
implementations, as well as describing any additional useful features 
provided by the SP. We hope it will become a one-stop-shopping site for 
information on features, functionality, configuration, quirks, contact 
information, and anything else that the community would find useful.

The current implementation is a prototype. I think we all owe Thomas a 
big "thank you" for starting this effort. We all expect, though, that 
the functionality in the Registry will continue to evolve, as our 
understanding of the problem grows, and as our needs for additional 
information continue to evolve. But, it seems "functional enough" today 
to begin the process of rolling it out to the community.

The Registry is a database-driven application; data entry won't be free 
form (as on a wiki) but rather data will be entered into pre-defined 
fields. This email is an effort to list the fields available in the 
current implementation, and seek comments, feedback, and suggestions on 
any additional fields that people feel are important to include in the 
short term. We expect the Registry to continue to evolve, so this isn't 
the last opportunity to ask for additional functionality. So, the 
question is "what would be important to add right now".

Once we hear feedback and act on it, we'll be announcing the Registry 
and how to use it.

The current list of fields includes:

   1. Vendor: vendor's name
   2. Resource: the particular resource in question, since many vendors 
have multiple platforms
   3. Status: vendor/resource's status of Shibboleth implementation. 
This may even be that the vendor does not intend to implement Shibboleth
   4. Shibboleth-enabled: whether or not the resource is 
Shibboleth-enabled, also what version of Shibboleth service provider
   5. InCommon Member: whether or not the vendor is an InCommon member
   6. WAYFless support: whether or not the vendor has implemented 
WAYFless URLs
   7. Direct Linking support: whether or not the vendor has implemented 
Shibboleth-authenticated direct links to resources
   8. URL syntax: example syntax of shibboleth-authenticated WAYFless URLs
   9. Shibboleth Attributes: if there is a standard set of attributes 
resource expects, it will be identified here
  10. Features: a place to list features such as personalization features
  11. Contact: contact information
  12. Document: links to configuration information or how tos
  13. EZP Example: EZP config examples used by institutes
  14. Common-lib-terms Support

Please send any comments, thoughts, and suggestions to this email list.

And thanks for your help!