grouping attributes in consent UI

[Cantor, Scott]

> I played around with Velocity a bit but is there any interest in providing an
> easier (or even out-of-the-box) way to group related attributes on the consent
> UI?

I think it's been discussed occasionally.

> So initially only the "attribute groups" (or meta attributes) would be shown,
> but they could be easily expanded in case someone wanted to see the details.

That's probably a bit more work than I have any appetite for, it feels like adding more complexity rather than reducing it. I always thought that it made sense to reduce the wasted detail the IdP would show and move that off to some other webapp that would be a "click here if you want to see all the gory details" kind of thing that can be maintained by proper web developers.

> As for how/where to configure that I could imagine doing that within the
> resolver config, by either expanding the DisplayName element (adding an
> displayGroupId and a displayGroupName to each DisplayName) or by adding a
> sibling element for DisplayNameGroup (or whatever) with an id and a display
> name for the group?

My thinking is that it's of a piece with the overall problem of pulling out more of the attribute "metadata" we want to have, for want of a better name call it an Attribute Service, and getting away from the "inline" configuration we have today.

So if we need a way to express these kinds of groupings, that's just more ontological data we need to capture there and provide a data dictionary syntax to express it (and obviously the idea is that it's shareable as a federation-delivered config).

We want to get it out of the resolver config, which is local to each site, and more like RADIUS' separate dictionary file.

> I guess the grouping also somewow relates to shibboleth.consent.attribute-
> release.AttributeDisplayOrder in conf/intercept/consent-intercept-config.xml,
> when attributes are no longer shown in a flat list ordered by this parameter.
> So I guess it would (need to) be another config option?

I think it demands more of a rethink of a lot of the original pieces to make it more flexible.
 
> PS: I have more stupid HTML + form processing questions for the
>     consent screen, should I post them here or on user

If it's about feature changes, here.

-- Scott