Evolving Attribute Release Policies for campuses

[Peter Schober]

Not convinced this is the best place to discuss any of this this, but
hey...

* Scott Koranda <skoranda at gmail.com> [2016-04-06 00:56]:
> But there is no consensus across federations or IdP operators on
> what "required" means for an attribute

One of the differences you might encouter is the handling of cases of
acceptable alternatives, one of which you do in fact require.
>From the semantics of "required" it's clear that you can't mark both
(assuming we have 2 alternatives) with isRequired="true" and would
therefore not mark both of them (or with false).
(A per-attribute consent UI also wouldn't let you "untick" a required
attribute, IMHO.)
But some registrars may still mark both with isRequired="true" (but we
could certainly work to change this, if it were really important and
would drastically improve the situation, which I doubt), which works
as long as no IDP starts failing the transaction because it has no
intention (or consent) of releasing one of the acceptable alternatives
(even if it would release the other) and since both are marked
isRequired="true" the IDP would be entitled to abort right there.
(A behaviour ScottK has commented on critically elsehwere, I'm
aware. We just differ in our views on how well SPs are generally
prepared to handle such errors themselfs in a reasonable way.)

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

It is clearly optional as the service will function without it just
fine. There's not even an argument from you or Keith to the
contrary. (I challenge you to find a registrar for an eduGAIN member
federation that claims otherwise, which should be easy enough. ;))

Which is not to say that I wouldn't accept an explanation how a
trustworthy stable email address is essential for the VO or project
and that as such both should be marked required.

The UX will suffer if the subject has to provide it herself (and check
back mails and click some activation URL), yes, and the data
quality/reliability (assurance, if you will) might, too. On the plus
side you have a chance to ask for an email address the subject herself
prefers, not the one her institution does.

And of course this is silly when IDPs are putting the exact same
string value in both attributes. ;) But I digress even further.

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

I would claim that consent was never intended to help attribute
release, but to enable institutions cover their behinds
risk/liability-wise, by putting the blame squarely on the
unsuscpecting subject, usually the weakest link (i.e., with the least
bargaining power) in the chain.  Think click-through licensing.

But in cases where the institution would otherwise flat out deny
release of any attributes (unless for enterprise applications and
stuff they have contracts in place) this still has the potential of
being a huge improvement. (If only because the bar is so low what
constitutes an improvement.)

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

Well, R&S says SPs "SHOULD" request needed attributes, so there's an
argument to be made that IDPs might feel it's the SP not living up to
the spec.  But R&S does not ever mention required, and proper R&S
implementation rules should definitively NOT evaluate isRequired at
all.  Personally I look at requested attributes for R&S SPs as mere
"optimization" (@ScottK: "pessimisation"?): If the SP doesn't even
bother to request it it probably doesn't need it. But I can certainly
live with sending the whole bundle (or the minimum subset) to R&S,
that's the whole point of having a bundle, after all.
(But recent discussions have shown that some even consider only
sending ePTID to be sufficient for an IDP's claim to R&S support...)

-peter