Shibboleth Developers

[Jennifer Vine <>]

Hello all,

I have a more complete mockup for Monday's conference call:

http://www.stanford.edu/~jvine/shibboleth/mockups/7/main.html

It's semi-interactive - that is, any link will take you to an example 
of what that page would look like, but doesn't show actual data, or 
reflect any changes that you make. Note that there's just one example 
of each page - so no matter which resource you click on, you'll see the 
same resource page, and so on. There's also a bit of explanation at the 
bottom of each page.

Below is a broad overview that I'd like to send to the focus group next 
week, along with the mockup - I'd like your feedback on it before I 
send it out, to make sure I'm not saying anything that directly 
contradicts reality as you know it.

Thanks
JV

==============================
An institution would use Shibboleth as a member of a federation (such 
as InCommon). The federation may have a role in negotiating contracts 
with vendors, but it will also have a role in defining, collecting, and 
maintaining metadata from vendors.

Individual libraries within the institution would be defined as 
"owners". An owner might be any organizational unit that manages vendor 
contracts and access policies. For example, the Campus Facilities 
department might be set up as an owner to manage access to door-code 
maintenance for building managers.

An attribute release policy (ARP) is created for a resource, at the 
level of granularity at which the vendor provides access to that 
resource. For example, if the vendor allows libraries to license a 
single journal title, and provides a URL unique to that title, a 
library might have an ARP for that title. If the vendor provides a 
package of titles accessed through a single portal or entry page URL, a 
library would have an ARP for that package.

A single resource can have more than one service level, with a 
different ARP for each. For example, if the general campus community 
has access to a subset of a resource, while the Law School has access 
to all the content of that resource, these would be represented by 2 
service levels, with an ARP that applies to each.

A library will typically set up a default attribute release policy that 
applies to *most* contracts. If an individual vendor requires release 
of different or additional attributes, or needs to be limited to a 
different population, the library would set up a specific ARP for that 
vendor.

Most ARPs will be created from templates. To set up an ARP for a new 
resource, the user would select the vendor's template for that resource 
from the list of templates maintained by the federation, then complete 
the template with any required information (like selecting the user 
population, or providing a contract number) and save it; that resource 
would then appear in the owner's resource list. If there's no template 
available, the user will be able to create a custom ARP.

The template is maintained separately from the saved ARP - so the 
vendor can change the template, but cannot directly change your ARP. 
The UI will alert you when there's been a vendor update to the template.

Users will be able to see ARPs maintained by other owners - there may 
be overlap in the populations served, and occasionally duplicate 
resources under different contracts. However, in the first iteration, 
there will be no access control by ownership - that is, someone who can 
view and change ARPs for one owner will be able to view and change ARPs 
for all owners.

==============================