2014-08-22

Shibboleth Developer's Meeting, August 22, 2014

Call Administrivia

10:00 Central US / 11:00 Eastern US / 16:00 UK

 

Normally we skip the last Friday of the month, but instead we are going to have a call on August 29 and then skip Sep 5.

 

Call Details

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.


Meeting Number: 24048131
 
Toll / Intl #: N/A
Toll-Free #: N/A

Attendees:
 

 

Brent

 

Daniel

 

Ian

Scary warnings in the MDA documentation. Tone them down?

Logging and subversion dependencies.

Out of town 29th to 1st.

Iceland: http://baering.github.io

 

Rod

Kicking the wheels on windows installer.  Watching Bárðarbunga.

Scott

Corrected code to handle Anonymous RP case, which we've decided to rename to ?Unverified?

  • Hit an issue with Rod's taglibs in at least Velocity case, unsurprisingly, haven't investigated, likely just something assuming metadata present.
  • General impression is that CAS' needs will be trivially met out of the box by existing Anonymous behavior e.g. attribute filtering, etc.

Added control point for deciding how to handle identity switches mid-session, a property now dictates whether it's an Event or not

Fixed up log dependency in testbed to get it working, not sure about integration tests

Finished, mostly, migrating trust engine config to final resting place and supporting default legacy behavior in Spring parser

Audit logging mostly done, still need to look for some additional audit fields we might want (but people have several injection points now for their own audit field extraction)

Next up: probably logout, but wondering about SOAP client capability...then again, this is probably message signing only anyway

  • Even back-channel's probably not trivial, we may want to spin up a thread for each SP or at least a pool of them

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

After a whirlwind tour through attribute release consent, I am left pretty much where I started, that I should port uApprove v2 to v3, leaving room for per-attribute consent, but defer UI work until later.

It seems that the Google UI for consent probably is the only way to display the relevant information on a small screen as well as a larger one, but it would probably take some work to come close to that, which boils down to summarizing attributes rather than displaying name-value pairs.

I'll note UMA, but did not find it directly applicable at this time due to scope.

 

Other