InCommon eduGain and release policies

[Tom Scavo]

On Fri, Jan 29, 2016 at 3:17 PM, Jeffrey Crawford <jeffreyc at ucsc.edu> wrote:
> Now that I've studied the preview metadata I'm starting to get the IdP ready
> for eduGain. Hopefully without breaking existing InCommon stuff.

Thanks for being on top of this.

> 1. There is a point in the getting ready guide that says use entity
> attributes instead of the urn:mace:incommon "Group" name. However the
> preview has that still included.

It is there for backwards compatibility. It will never go away.

> For various reasons I'm trying to
> distinguish between an InCommon identity, eduGain identity, and local
> identity which has it's own group name. Is the following logic going to work
> and be stable?:
> (eduGain = group::urn:mace:incommon & (!attr::registerd-by-incommon))

When you disaggregate the metadata (as in per-entity metadata), the
group name disappears, so anything based on it will break. So, no,
don't rely it if you don't have to (and I don't think you have to).

Per-entity metadata is coming. IdPs will be the first to benefit.

> 2. There have been many discussions about what "identifier" is used in the
> larger eduGain space. Since there is some local concern about releasing eppn
> internationally, I'm planning on releasing persistant-id without eppn to
> eduGain entities via nameIDFormatPrecedence and keep the current eppn +
> transient-id combo in incommon. Do we risk large scale interoperability
> issues with not releasing eppn for eduGain? I've seen many that have
> transient as NameIDFormat listed first, and requested attributes, which we
> will still honor via the consent page. But I'm worried there may be many
> with transient requested and no AttributeRequests.

Are you talking about Research & Scholarship specifically? There you
have no choice, ePPN is strictly required.

More generally, SAML2 Persistent NameID should be just fine. It can be
difficult to deploy but if you already have it deployed, by all means
use it. It has the best privacy preserving properties of any
well-known identifier.

I was going to "announce" this on the InCommon participants list on
Monday but the Default Attribute Release wiki page has been totally
overhauled due to community feedback:
https://spaces.internet2.edu/x/RYH4Ag

Take a look and tell me what you think. Comments welcome (but on the
participants list please).

> 3. The reason we've been able to open the service up to wider SP's has been
> the consent page. I have a pretty good handle on what can be "requested" on
> the incommon side, but it looks like eduGain has requested attributes are
> all over the map, does anyone have a list of "good to support" attributes
> not covered by InCommon that should be considered in eduGain?

That's a hard question, best asked on the REFEDS mailing list, I
think. That said, the easiest thing to do is craft a policy that
releases any attribute in a bundle that you choose to define (like
R&S). The composition of the bundle is the intersection of the
attributes you support with the attributes you feel comfortable
asserting to anyone (subject to consent).

> As a side note, we plan on treating all research and scholarship the same
> way so we should be good there.

Good idea.

Tom