Subject Re: [eduGAIN-discuss] mari plan & next steps
From "Cantor, Scott" <cantor.2@xxxxxxx>
Date Wed, 29 Oct 2014 17:12:20 +0000

On 10/29/14, 12:52 PM, "Peter Schober" <peter.schober@xxxxxxxxxxxx> wrote:

>* Cantor, Scott <cantor.2@xxxxxxx> [2014-10-29 17:42]:
>> One reason RequestedAttribute still matters is that without a way to use
>> that approach, you can't signal required vs. optional, and there are
>> federations increasingly looking at per-attribute consent, rightly or
>> wrongly.
>Interesting. So meta-attribute names are really about reviving the
>isRequired="true|false" flag (and thereby reviving RequestedAttributes
>itself), which we've given up on -- mostly because of the inability to
>express multiple acceptable alternatives?

That's a significant aspect of it to me. For the specific cases where
category-based bundles exist, I'm less clear on what the "problem
statement" is other than driving consent UIs and perhaps just attribute
release policies more flexibly.

>I.e. the meta-names would need accompanying specification that would
>always say "At least one of the following attributes[1] needs to be
>released, if this meta-name is being requested"?

Yes, the meta-name is in that sense a SAML Attribute with a precise

>How about "ePPN only if it's not re-assigned, otherwise ePPN+ePTId"?

Yes. Harder to express in that case, but that's the idea.

>But then no, seems we cannot request ePPN ever, because the Danish
>don't have it?

I don't think it steps that far. I think you're right that if R&S says
"MUST EPPN" and I don't have EPPN, I'm out. But the meta-attribute
communicates the requirement explicitly rather than by inference.

>That would leave us with *many* such attribute names, though, all of
>which would need to be implemented widely at IDPs in order for any of
>that to make sense?

I noted to Leif that this wasn't getting the IdP end out of any work,
whether it was doing this kind of thing, or defining new attributes to fix

-- Scott