InCommon eduGain and release policies

[Jeffrey Crawford]

Jeffrey E. Crawford
ITS Application Administrator (IdM)
831-459-4365
jeffreyc at ucsc.edu

Both pilots and IT professionals require training and currency before
charging into clouds!
---------------------------------------

On Fri, Jan 29, 2016 at 12:35 PM, Tom Scavo <trscavo at gmail.com> wrote:

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


​This may be an artifact of how I've got things configured currently,
however if I only rely on the absence of "registered-by-incommon" I'll pick
up​

​our local metadata as well, which has yet another default release policy.
Part of this config is in relying-party.xml (nameidPreference) and it has a
"first match" behavior, so I need to be specific that id came from
InCommon-metadata.xml and it is either registered-by-incommon or not
(Several entities have no attributes).

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


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

​other than the fact some eduGain entities specifically have transient
listed first​

​but I think they request attributes as well but I only spot checked.​

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

​Does REFEDS R&S have more attributes than InCommon does? I'm sure it's
documented somewhere but I didn't find it quickly.


> > As a side note, we plan on treating all research and scholarship the same
> > way so we should be good there.
>
> Good idea.
>
> Tom
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160129/1543c215/attachment-0001.html>