Refeds


Subject Re: RFC: scoped semantics profile for edupersonEntitlement attribute values.
From "Cantor, Scott" <cantor.2@xxxxxxx>
Date Thu, 16 Oct 2014 14:08:14 +0000

On 10/16/14, 8:02 AM, "Niels van Dijk" <niels.vandijk@xxxxxxxxxx> wrote:
>
>The eduPerson schema does provide an attribute called
>eduPersonEntitlement [EDUPERSON.edupersonEntitlement] in which the value
>of the entitlement indicates a set of rights to specific resources. The
>structure of the value itself is however completely semantically free,
>which introduces challenges when using this attribute in multi-domain
>scenarios, like for example interfederation.

I very much disagree with that premise. If a unique URI doesn't address
that challenge, nothing does. The value is 100% self-defining in every
sense. If it matches, it means everything that value is meant to mean, and
if not, it means none of that. You can't get more clear than that.
Introducing structure creates inherent processing complexity and that is
always worse for interop and for interfederation IMHO.

I think it's worth pointing out that there are a lot of reasons why
federated authorization has gone nowhere, but this set of issues isn't on
the top of that list. There are structural limitations that I think will
prevent that model from ever working well. Most people aren't willing to
delegate this control (outside the library case) and most people aren't
willing to accept the responsibility to manage access to services they
don't own. Both sides seem to hate the idea, basically.

I think it would be worth talking about this issue since it is the one
thing we invented this stuff to do and the one thing that Google won't
ever do. But I don't think attribute structure is really core to the issue.

>* Includes the authoritative source for its value(s).

URIs already do this. That's the one part of the entitlement that can be
reliably parsed without introducing any new structure.

>* Prevents clashes between attribute values for different services.

Unique URIs already do this. If you reuse an existing value, you can't do
that by accident. And honestly, it's not up to you. If I want to reuse a
value for my service, I can do that, as long as I don't change its meaning.

>* Allows for easy filtering, both for adhering to attribute release
>policies by the Identity Provider as well as quickly determining
>authorization by the Service Provider.

While it might be superficially "simpler" to filter release based on a
regex, that's not precluded by the existing attribute (that really is up
to the peple crafting the values), and it's always straightforward to just
generate and publish rules for release anyway.

>* Allows for fine-grained authorization at the Service Provider.

I don't see what this adds to that use case.

-- Scott