Shibboleth Developers

 wrote:
> Thanks for that useful summary of the state-of-play Stephen.
>
> We'd be quite interested in presenting something about FLAME at the Fall
> I2 meeting, if there's an appropriate session.  The Social Study of LSE
> users will only have just started then (but will have a quite detailed
> design of the study methods we're using).  The project should be
> completed (with results of the Study published) around the time of I2
> Spring 2009.
>   
I'm quite interested in this project -- I didn't know about it until 
recently. If you were to do a presentation in the fall, it sounds like 
it would be of the "this is what  we intend to do" variety? Or do you 
think you'll be further along by then?

I'm trying to figure out whether there would be enough content by  
October... what do you think? it sounds like we definitely want to 
include this in the spring agenda,  tho......
> We're plowing on doggedly with using Signet and Grouper together to
> implement Devolved Access and Virtual/Collaborative Organisations  - but
> the techies are finding it hard going!  ShARPe seems to be in better
> condition.
>   
There's a growing amount of experience with Grouper, both in the UK, and 
here at Brown.  ;-)

We've been running with course  groups for a year; we've just added 
community, demographic, and departmental groups.

Signet is somewhat behind Grouper... they're putting out a new release, 
tho, and I'm wondering how many problems they've managed to address.
> Re your use-case:
>   
> > 8) Steve thinks this use case will have to be addressed:
> >
> > User uses Shib to access Elseveir. The default site policy 
> > releases only "this user is authorized to access this 
> > resource". However, the user also wants to release the 
> > optional attribute epTID; the user decides to not release 
> > their email address at this time. (If they did, then elsevier 
> > would send them a monthly news letter.)
> >     
>
> ...UK common practice seems to be releasing ePSA and ePTId, as default,
> and assuming that ePTId does not compromise user privacy under
> EU-compliant laws.  (Andrew Cormack may correct me if I'm being too
> sweeping, there ;->)
>   
We spent most of this week's shib call talking  about this topic. I 
think we're close to consensus, at least in this first round. We're 
trying to balance dealing with a great range of use cases, defining an 
approach that is doable in a reasonable amount of time, and defining an 
approach that has a high likelihood of succeeding in the operational 
space. I guess I meant to say that we're engineers. ;-)  Once its clear 
that we have consensus, I'll be bringing this  to a larger group.

We're talking about encouraging SPs to  publish (in their metadata) the 
set of attributes they want, and letting IdPs identify the set of 
attributes that "require user consent". A typical flow would have the 
IdP looking up the set of attributes that the requesting SP desires, 
filtering that thru the current ARP mechanism, and then, if one of the 
"consent" attributes is ticketed for release, triggering something akin 
to the current SWITCH ARPViewer. The user could say YES/NO to the whole 
lot, but not individual attributes.

I understand that this isn't ideal. Far from it. But, we're trying to 
make it easy for  both SPs and IdPs, while giving users some control and 
flexibility. And keeping it simple enuf that people could understand it.

I'd love to hear folks' thoughts......