Shibboleth Developers

["Michael A. Grady" <>]

> Date: Mon, 8 Apr 2002 13:01:20 -0400
> To: 
> 
> From: 
> 
> Subject: reminder - shib design call  today - 4/8

> 2) Creating, managing ARPs. There was a lot of discussion about this, 
> via email and last week's call. I've tried to write down my 
> understanding of what we agreed on. Its available at:
> 
> http://stc.cis.brown.edu/~stc/Projects/Shibboleth/UI/UI_Functionality.html
> 
> NOTE: section  1.1 is taken  from  Scott's Arch doc; sections 1.2 
> thru 1.4 have  been  edited - during today's call, I'd like  to 
> ensure that we  agree on the contents of these sections. I've 
> noticed a few minor  discrepancies -- I'll save those for the call.
> 

A couple of comments on the above document. 

 - for a multiply-valued attribute with a limited controlled vocabulary,
   (e.g. eduPersonAffiliation) a web interface showing all possible values
   with a checkbox is feasible. But for an attibute like 'memberOf',
   or 'enrolledCourse', or 'eduPersonEntitlement', you'll need a
   text box to enter a value, for:
   
     - there will be no way to know all possible values
     
     and/or
     
     - the list would be prohibitively long
 
I'm not totally convinced that it should be possible for the institution
to force the release of an attribute for a user, but having the capability
certainly doesn't hurt anything. But note that the display for an individual
user will need to indicate (somehow) elements of all ARPs that end up 
applying to them at that given moment, whether or not it is a Site-level
or delegated-level (resource or group) ARP.

And thinking about attributes like a 'memberOf/enrolledCourse' type
of attribute really makes me wish that the Shibboleth model had accommodated
someway of indicating in the request to the AA from the SHAR what value
of what attribute it was looking for. If Shibboleth and the sharing of
course resources ever really took of on a large scale, then:

   - we have about 4000 courses a term, with about 11,000 sections
   - if we don't want to release all values for an individual of their
     'enrolledCourses' to a given SHAR/url, but only the specific one
      applying to the section of the course they are taking that is using
      that resource, then that means we actually have to manage as many
      or more ARPs as we have courses/sections.
      
      If, instead, we were setting a policy that said a general pool
      of SHARs (Club Shibboleth, for example) could ask the specific
      question of whether a given user was taking a specific
      term/course/section (e.g. a directory 'compare' operation), it
      might be possible to have a very limited number of Site/delegated
      ARPs covering such.

      
Finally, I assume there is nothing specific about the initial design of the
ARP repository that necessarily ties it to a relational database versus
storing the ARPs in an LDAP directory?
      
--
Michael A. Grady                             

Senior Research Programmer                   http://ljordal.cso.uiuc.edu 
Computing & Communications Services Office   (217) 244-1253  phone
University of Illinois at Urbana-Champaign   (217) 265-5635  fax
Rm. 103, MC 680, 2212 Fox Drive, Suite C     Champaign, IL 61820

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--