grouping attributes in consent UI

[Peter Schober]

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?

E.g. showing "Name" where the $attribute.id would be e.g. "givenName",
"surname", "displayName?  Clicking on Name would then show name,value
pairs with the $attributeDisplayNameFunction.apply($attribute) and
$attribute.values, maybe in something like a collapsed accordion
(https://jqueryui.com/accordion/#collapsible)?
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 seems to satisfy those who would like to keep the consent UI as
simple as possible (to the point of using tou instead), as well as
those who would like to offer all the attributes incl. their
mysterious values (such as service-specific opaque identifiers).

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?
Neither seems a clean match from the data model, so grouping of
attribute ids may need to happen elsewhere, plus the groups need a
displayName itself (probably referenced from message properties then)?
No idea how one wold add such a structure to e.g.
conf/intercept/consent-intercept-config.xml?

Whether such grouping is easily combinable with per-attribute consent
I don't know (though that seems only to be a matter of UI design and
CSS/JS hackery), but since (last time I checked) per-attribute consent
had no way of making some of those per-attribute checkboxes
preselected and read-only (e.g. when isRequired="true" for an attr or
it's part of the R&S attribute bundle for an R&S SP) I feel
per-attribute consent is unusable atm.
So currently I always leave allowPerAttribute=false in order to
prevent people shooting themselfs in the foot by not releasing stuff
we already know the SP cannot work without.

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?

Ideas, suggestions?

-peter

PS: I have more stupid HTML + form processing questions for the
    consent screen, should I post them here or on user (or not at all
    ;))?