Evolving Attribute Release Policies for campuses
kwessel at illinois.edu
Wed Apr 6 10:34:01 EDT 2016
I, too, am rather bothered by the apparent contradiction for attribute release for R&S category SPs. I'm told to release the whole bundle of seven attributes, but then an R&S SP enters RequestedAttributes into metadata which may or may not be the same seven. Which am I supposed to follow? Do I send attributes that the SP may not want just because their R&S and I'm supposed to release the entire bundle? Or do I only send what they've marked as requested, which I think technically breaks my obligation as an R&S-adopting IDP.
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
Sent: Tuesday, April 05, 2016 7:18 PM
To: users at shibboleth.net
Subject: Re: Evolving Attribute Release Policies for campuses
* Cantor, Scott <cantor.2 at osu.edu> [2016-04-06 01:59]:
> >(But recent discussions have shown that some even consider only
> >sending ePTID to be sufficient for an IDP's claim to R&S support...)
> That's the part that just isn't right, so that really does bug
> me. The text is 100% clear that the "minimal" subset of the bundle
> is NOT just that one attribute. The wiggle room is around *who* you
> might release the full subset for, but if it's not a substantial
> population, there just isn't any leg to stand on here. If that's
> becoming any kind of widespread view, we should work in REFEDS to
> stamp it out and soon.
I was certainly surprised to learn some people consider that a valid
interpretation. I did proposed the smalles possible change to take
care of that (replaing "a" with "the" in: "The following attributes
constitute a minimal subset of the R&S attribute bundle:"), but so far
that didn't get sufficient traction to motivate a revision.
We should revisit that discussion, though, and on the REFEDS list this
time, where the appropriate people can comment. (Which was pointed out
even back then.)
> I just wish the category had not required that SPs include requested
> attributes in metadata. I don't remember why we did that and it was
> a mistake. We'd be in relatively fine shape if the spec actually
> precluded it. The work of making that useful should have landed on
> something other than R&S.
You could still claim valid reasons for not doing it (it's a SHOULD),
e.g. if your tool chain (or the registrar's) doesn't allow it.
But from the discussion referenced above it was clear if there was a
revision of the R&S text people wanted /more/ emphasis on
isRequired="true", not less RequestedAttribute. So that's definitively
something needing work.
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users