v3 consent to attribute release : half-thoughts on UIs

[Tom Zeller]

I have some incomplete thoughts regarding providing the underpinnings
for attribute consent UIs, I thought I would type them here and see if
it helps.

I believe the latest GakuNin fork of uApprove, and maybe PrivacyLens,
include a UI for managing a user's consent. The management page, at a
minimum, would display one or more relying parties and the attributes
(and values) that have either been approved or declined by the user
for release. Besides a reset button, the user could be able to toggle
approve|deny at the granularity of relying party, attribute, or
attribute value. If there are a large (or even small) number of
attributes and/or attribute values, checkboxes might be cumbersome,
especially on a small screen. I was thinking that instead of
checkboxes, the relying party, attribute, and attribute value elements
would be clickable to toggle consent, where toggling the attribute
element would apply to all of the attribute's values, for example. I
think that requires JavaScript in the Velocity template.

Regardless of the UI however, I'm wondering how to parse the request
parameters which represent the user's input. My half-thought is that
the request parameter values would be the JSON serialization of a Java
consent object, same as we would store as the value of a storage
record in the StorageService. Does that make sense ?

I've done a little sketching of what the Java consent object would
look like, here is what I've got so far, obviously the fields should
not be public :

/**
 * Represents consent to attribute release.
 */
public class Consent {
    /** Predicate that must be true for this consent to apply to an
attribute. */
    public Predicate<IdPAttribute> attributeActivationCondition;

    /** Predicate that must be true for this consent to apply to an
attribute value. */
    public Predicate<IdPAttributeValue> attributeValueActivationCondition;

    /** Function used to determine if consent is approved or denied. */
    public Function<IdPAttributeValue, Boolean> attributeValueApprovalFunction;

    /** Function used to determine the expiration date. */
    public Function<IdPAttributeValue, Date> attributeValueExpirationFunction;

    /** Function used to determine the attribute values matched by
this consent. */
    public Function<IdPAttribute, Set<IdPAttributeValue<?>>>
matchingValuesFunction;

    /** Predicate that must be true for this consent to apply to a
profile request. */
    public Predicate<ProfileRequestContext> profileActivationCondition;

    /** Predicate that must be true for this consent to apply to a
relying party. */
    public Predicate<RelyingPartyContext> relyingPartyActivationCondition;

}

and the fields of a default impl would look like the current uApprove
AttributeReleaseConsent object or PrivacyLens' AttributeReleaseChoice
:

/** Represents consent to release of an attribute. */
public class DefaultConsentImpl {

    /** The attribute id. */
    public String attributeId;

    /** Hash over all attribute values. */
    public String valuesHash;

    /** True if approved, false if denied. */
    public boolean isApproved;

   /** Expiration date. */
    public DateTime expiration;

  ...
}

In the Consent object I sketched out, I included several activation
condition Predicates : ProfileRequestContext, RelyingPartyContext,
IdPAttribute, and IdPAttributeValue. The are somewhat redundant, since
the profile context contains the other contexts, but I thought it
would be easier for deployers to customize by avoiding the need to
navigate the context tree, not a big deal.

The Consent object is somewhat like attribute filter
MatchFunctors/Matchers, in that it returns matching
IdPAttributeValues, for which approve|deny is determined by another
function.

In the Consent impl, like the current uApprove, the attributeId and
valuesHash might be a wildcard "*". Perhaps we should consider a
regular expression Pattern, which we might also use to match relying
party (entity) IDs, just a thought.

What I don't have in the default Consent impl is a relying party ID
field, not sure if that is going to be a key or value for the storage
service.

Just some thoughts, feedback on the Consent class sketched above is appreciated.

Thanks.