Shibboleth Developers

[Scott Cantor <>]

> A couple of comments on the above document. 
> 
>    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

Agreed, but there are some possibilities, for example you could derive
the values that apply to the person in real time and display only those.

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

Agreed. The best reason I can think of for having the ability is to
prevent students from shooting themselves in the foot and locking
themselves out of web sites like WebAssign. Work for grades takes
precedence over privacy?

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

FWIW, I more or less agree with you for the reasons you stated. The
stated reason for * only was to insulate the SHAR from the needs of the
RM.

-- Scott

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

    http://archives.internet2.edu/

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