Shibboleth Developer's Meeting, August 22, 2014
Call Administrivia
10:00 Central US / 11:00 Eastern US / 16:00 UK
Normal schedule is to skip next Friday as it's the last Friday of the month. Any reason to vary that?
60 to 90 minute call window.
This week's call will use the Lync system at OSU on an experimental basis. To participate, call:
- +1 (614) 688-1800 (please use if possible)
- +1 (800) 678-6114 (use only if you're charged for the 614 number)
The Conference ID is: 738127#
International participants should be able to access the 800 number without charge through Skype.
Fallback Call Details
If the above doesn't work out, we will fall back to the previous system at 15 minutes past the hour.
Attendees:
Brent
Daniel
Ian
Scary warnings in the MDA documentation. Tone them down?
Rod
Kicking the wheels on windows installer. Watching Bárðarbunga.
Scott
Tom
Talk about next steps for uApprove. Some comments :
I guess I really had not done my homework regarding consent. Until about mid-week, I had just looked at uApprove v2 and the v3 port. I mocked up a very simple flow and view. I felt it would be reasonably easy to emulate the uApprove v2 UI, so the work would mostly be porting to our v3 APIs and converting JSP to VTL, oh, and of course storage including client-side cookies.
I was curious how uApprove v2 looked on a small screen, so I spent some time fooling with my test environment, and the v2 UI was workable as long as I rotated the screen to have a longer horizontal aspect ratio like a desktop would. On the last call we said it would be reasonable for the number of attributes and values to be released to be in the tens, rather than ones or hundreds, but I wondered whether the UI would need to support pagination, which is probably only really relevant for a desktop UI. So I spent a little time researching SWF and VTL pagination, and yes there is a Velocity PagerTool, but I have not tried it. So, I added issues of "mobile" and "pagination" to my uApproveNotes page.
Getting back to the consent flow mock up, I thought I would work through adding checkboxes to the attribute values displayed to the user to play with per-attribute consent. A long time ago, I wrote a similar UI which displayed name-value pair records with checkboxes, so I was comfortable with the general approach, but that was before smartphones and adding checkboxes to the name-value pairs did not make anything render better on a small screen. The resolution I had was to make the attributes and values themselves toggleable, to avoid presenting the checkboxes, in other words, make the attributes and values themselves the checkboxes. That way, it would be possible to select and deselect groups of attributes or values, even perhaps by relying party on somesort of administration or management UI.
However, I was confused as to what "rejecting" consent would mean on a per-attribute basis, what the timeline would be for asking for consent again, etc, so I posted a quick note to the dev list, and that led me to the PrivacyLens and GakuNin forks. I also did some quick internet searches for "user attribute consent" and realized that quite a bit of work has been done already, the document that made me feel the "best" was this one, which says that IdPv3 will NOT include a per-attribute consent GUI. For other projects with consent UIs, see SimpleSAMPphp and Cirrus Identity et al. I liked this page because it displays a matrix for required vs optional attributes and a UI, for which I wonder how it would look on a small screen. I was also pretty clueless until now, and still really am, regarding REFEDS Attribute Release Recommendations.
...
Other