grouping attributes in consent UI

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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
    ;))?
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: grouping attributes in consent UI

Cantor, Scott E.
> 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

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: grouping attributes in consent UI

Tom Zeller-3
In reply to this post by Peter Schober
> 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.

In addition to per-attribute consent we could consider
per-attribute-value consent, for example, not releasing a particular
group membership. But I thought there was work being done on consent
and all its wonder elsewhere, not sure what happened.

> 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?

Maybe a map would be better than a list (of attributes in order) and
the keys could be the "groupings".

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: grouping attributes in consent UI

Cantor, Scott E.
> In addition to per-attribute consent we could consider per-attribute-value
> consent, for example, not releasing a particular group membership. But I
> thought there was work being done on consent and all its wonder elsewhere,
> not sure what happened.

I think it's still going on but I'm not sure how much is TIER and how much is just Duke continuing to work on something they wanted to do anyway. Rob Carter would be the person to reach out to about it.

Without trying to speak for anybody, I know that people get frustrated that they can't find out about these kinds of projects very easily and understand what's happening, but Shibboleth didn't spring into being as something with a web site and a big wiki full of history and lots of well-defined formal processes and leadership. It's something that happens if a project matures and becomes (relatively) successful or it doesn't because the energy's not there, but it's hard to put the cart before the horse.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: grouping attributes in consent UI

Rod Widdowson
In reply to this post by Cantor, Scott E.
> 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.

Somewhat off topic for this thread, but absolutely on-topic for V4:  I'm keen to see this develop.  It starts (for me) with
encoding, but you then rapidly fall into the space-time-vortex that is the difference between Attributes from a DataConnector and
Attributes from AttributeDefinitions.  

Having display information in there to (to an arbitrary granularity) is another dimension that hadn't occurred to me.  Are there
other dimensions I've missed?  Filtering?

Also one you drop down from 100kft its not obvious what the dictionary looks like - I could postulate a few things but I'm unsure.
I suspect that's because I'm not Radius-aware....

I guess that the end goal is that the deployer "just" defines a few attributes with well known names and the Federation supplied
information controls the rest (encoding, display, filtering and so on).

But in a way that allows for easy over-ride and local control.

/R



--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: grouping attributes in consent UI

Cantor, Scott E.
> I guess that the end goal is that the deployer "just" defines a few attributes
> with well known names and the Federation supplied information controls the
> rest (encoding, display, filtering and so on).

The basic idea is to provide a separate recipe for as many attributes and their metadata as possible, and then just "connect" up the attributes from the resolver with those definitions, either by assuming the IDs line up by convention or by just attaching the ID to the attribute in the resolver some how that's not confusing. I haven't really worked it out beyond the general idea that anything that's currently "inside" the <AttributeDefinition> element at the top level would be something we'd want to factor out.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: grouping attributes in consent UI

Peter Schober
In reply to this post by Peter Schober
* Peter Schober <[hidden email]> [2018-05-23 16:15]:
> 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?

FYI, I've now implemented this within the Velocity template. It's not
pretty and depends on the internal ids of the attributes as defined in
the local resolver, but it works:

Within the iteration over all attributes within
views/intercept/attribute-release.vm:

#foreach ($attribute in $attributeReleaseContext.getConsentableAttributes().values())

I simply test each individual $attribute.id to see what "attribute
(display) group" it's part of and assign a grouping-specific CSS
properties to the HTML.
I.e., I currently repeat the existing tr and td generation (unmodified
except for the CSS class) and also the
  #foreach ($value in $attribute.values)
loop within every of those if/else occurances.

  ## NAMES
  #if ($attribute.id == "givenName" || $attribute.id == "surname" || $attribute.id == "displayName")
    <tr class="collapse names"> ## etc.
  #end

  ## EMAIL
  #if ($attribute.id == "mail")
    <tr class="collapse mail"> ## etc
  #end

  ## IDENTIFIERS
  #if ($attribute.id == "uid" || $attribute.id == "eduPersonPrincipalName"
    || $attribute.id == "eduPersonUniqueId"
    || $attribute.id == "subjectID" || $attribute.id == "pairwiseID")
    <tr class="collapse id"> ## etc
  #end

  ## AFFILIATION
  #if ($attribute.id == "eduPersonScopedAffiliation"
    || $attribute.id == "eduPersonEntitlement" || $attribute.id == "schacHomeOrganization")
    <tr class="collapse affil"> ## etc
  #end

So these are my 4 categories based on what my own IDP has defined.
(YMMV, of course, esp if you do lots of one-off vendor integrations.)
I should probably turn these into if/elseif/else so that in case I
later add more attributes these will fall through to the else section
gracefully, instead of not appearing at all.

The rest is then simply adding a bit of CSS/JS and clickable elements
to expand/collapse the desired section (or all sections at once, "Show
details"; which I'd still like to implement).

If I manage to polish up the UI a bit I can send a screenshot.

-peter
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: grouping attributes in consent UI

Peter Schober
In reply to this post by Cantor, Scott E.
* Cantor, Scott <[hidden email]> [2018-05-23 18:29]:
> I think it's still going on but I'm not sure how much is TIER and
> how much is just Duke continuing to work on something they wanted to
> do anyway. Rob Carter would be the person to reach out to about it.

OK, armed with the above info I was able to find this:

https://people.duke.edu/~mkm16/projects/consent/
and
https://spaces.internet2.edu/display/CAR/
and
https://spaces.internet2.edu/display/ScalableConsent/

Seems quite a bit of work has gone into this, on conceptual and UX
levels, but also implementation (at least judging from the videos
linked from the latter).

For my humble use-cases (and with an eye on deployer simplicity) this
all seems massively over-engineered, but I'll need to take a closer
look at their use-cases.
I didn't see any mention of CAR within any TIER web sites or wiki
pages, though, so I guess it's not yet part of any TIER efforts per
se.

(To some degree that work also shows just how much of a mess even the
best UIs become if you really see per-attribute through consistently,
but that won't surprise anyone here, of course.)

Thanks for the pointer!

-peter
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: grouping attributes in consent UI

Cantor, Scott E.
> I didn't see any mention of CAR within any TIER web sites or wiki pages,
> though, so I guess it's not yet part of any TIER efforts per se.

It was entirely TIER, so if it's not on their pages, I don't know why that would be. I'm sure it hasn't reached the stage of mass consumption or even packaging, so that's probably why.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]