Evolving Attribute Release Policies for campuses

[Scott Koranda]

> As I also mentioned on the list, we'd love to turn on
> per-attribute consent, but only if we can identify which
> attributes are optional. An SP admin who contacted me
> off-list (I'll let that person speak up if they want to) has
> concerns about this. It might not be enough to tell a user
> that an attribute is optional; it'd be better to tell them
> what the SP plans to do with that attribute so they can make
> an informed decision: is the intended use a feature that the
> user care about enough to release that piece of their
> information? 

I think that was me.

As a SP operator I get one chance to publish the metadata
for an SP and have it pushed into eduGAIN (unless I want to
join each federation separately).

But there is no consensus across federations or IdP operators
on what "required" means for an attribute, and so any
attribute release policy or mechanism based on whether an
attribute is marked as required (or otherwise optional) leads
to a decrease in service functionality for my users.

A specific example is our use of authenticated enrollment
forms to onboard members of virtual organizations (VOs). We use
such forms to bind a persistent identifier (usually eppn) to
other information the VO will know and manage about a user. 

If an IdP can and does assert an email address during that
enrollment flow the form can auto-populate it for the user. We
can also record the value as "authoritative" and (usually) not
require the user to undergo a separate step to verify the
email address (depends on the VO's specific needs).

But if the IdP does not assert email, the enrollment flow and
the SP still function. The user just has to self-assert her
email and then go through an extra step to verify it.

So is email a required or optional attribute for this SP?

Some federation and IdP operators hear that argument and say
that email is optional. They insist that it be marked as such
in the metadata for the SP.

So I can do that--once, since I get one shot at publishing
that SP metadata into eduGAIN.

But then Keith configures his IdP to use consent while
examining the SP metadata and show his users a list of
attributes his IdP may assert to my SP. Since email is not
marked as required in the SP metadata his IdP's consent form
will show it as optional. His user (also my user) may see that
and decide, well if it is optional, then no, don't release it.

The SP enrollment form will not break in that situation, but
the user will have to self-assert email and go through the
email verification process later.

So the user loses out on a better experience at my SP and
attribute release is actually hindered rather than helped by
the consent page at the IdP.

Keith asked me what I wanted "in a perfect world"? My response
was that the IdP should allow me as an SP operator to
communicate what the user sees on the consent page, so that I
can explain to the user the implication of releasing (or not)
an attribute. The binary "optional/required" does not have
enough fidelity to really help the user understand how her
decision impacts her use of my service.

Better yet would be all IdPs to just release the full R&S
bundle to R&S SPs as I believe Keith plans to do. That,
however, seems unlikely to be the case for all IdPs.
Many IdPs appear to want to look at requested attributes and
their required/optional flags even for R&S SPs.

So instead I am left explaining to VOs that the best thing we
can do is design our SPs and applications to just ask for
eppn, nothing else, and plan on getting nothing else from
IdPs. 

Trying to make this most relevant to the Shibboleth users
list...

I do not see that IdPv3 consent, when configured in a
way that examines the SP metadata for requested attributes
and their required/optional flag, helps with attribute
release and interoperability in the eduGAIN context.

Thanks,

Scott K