The REFEDS Attribute Registry is a registry of abstract "above-the-wire" user attributes. An abstract attribute is used to unambiguously specify attribute requirements in deployment profiles or in SAML metadata. For example, the precise attribute requirements of the Research & Scholarship Category are:

1. refedsNonPrivateUserID
2. refedsPersonName
3. refedsEmailAddress

Note that the concept is similar to the notion of "scope" in OpenID Connect.

OpenID Connect (OIDC) offers an Authentication protocol similar to SAML. Many of the participants in REFEDs use the well know eduPERSON and SCHAC schema to express attributes when using SAML
OIDC has a similar ability, with the use of claims. A standard set of claims is defined by OICD, however this set is not compatible with eduPERSON and SCHAC.

To effectively use OIDC in R&E it would be nice if some guidelines would exist how to deal with this difference.

This activity investigates the best way to deal with the differences between definitions in attributes and claims. Next to participants from REFEDs the activity will try to engage relevant parties including MACE-DIR, SCHAC and OIDC standardisation bodies

(Lack of) Attribute release is the single-most important issue for Service Providers. An area where this is especially hurting is in eSciences where collaborative organisations are struggling to get something, anything even, useful from Identity Providers.

The technical mechanisms (Research and Scholarship attribute bundle) are in place and have been field tested by some federations. We now need a massive PR campaign to provide federations with materials to inform their IdPs and the decision makers at these institutions to release these attributes now. Extra challenge here is that the people typically involved in REFEDs are probably not the best ones to execute this work package.

Out of scope for this activity are:

• Discussing the R&E bundle itself

In many cases a national federation is considered as a trusted third party, who is responsible for registering and vetting entities. However, in an interfederation (like eduGAIN) there is no direct trust between the entities and the registrar. Beyond all the benefits and opportunities of such a worldwide collaboration, a couple of security questions and challenges may arise, for example:

• if you cannot fully trust every registrar in your metadata, is it still possible to do interfederation?
• what safeguards can be implemented both at interfederation and at federation level for protecting entities against rogue / abused registrars?
• how to handle entityID clashes? (for scopes, see my other proposal)
• what requirements are necessary for incident response?
• ...

A couple of eduPerson attributes (such as ePPN and ePSA) use scopes in attribute values to scope information to specific administrative domains. Moreover, in certain applications, scopes play a key role for authorization decisions and access control.

Based on the proprietary shibmd:Scope metadata extension, Shibboleth and SimpleSAMLphp SPs are able to verify whether an entity is entitled to use a scope in attribute values or not. However, if a registrar fails to scrutinize the domain of the scope element, attackers managing to register a rogue IdP/AA entity might impersonate identities at SP software, which is one of the Worst Things.

To mitigate this, it is possible to write a standard for using DNS TXT records to declare which entityIDs are entitled to a domain name in scope. Based on DNS, an SP can verify scope information more securely and without relying on the trust of the registrars. It is very much similar to the Sender Policy Framework with email.

The Committee on Institutional Cooperation (CIC, Big 10 plus) Identity Management Taskforce has created a set of best practices for vendors and IDP operators working with SaaS cloud service development/deployment. The cookbook, which can be found at https://carmenwiki.osu.edu/x/nLdCAg, is being used by, among others, Internet2 for developing TIER and Net+ standards. The document, atmidedly, has some slant toward InCommon on federation-related topics.

As Interfederation grows, crafting best practices that reach beyond a single federation is increasingly important. Feedback from Refeds members on the cookbook will help adjust the current recommended best practices into something more federation-ignostic and, in turn, help those using the cookbook.

Keith Wessel and Keith Hazelton

Communications, efforts, a bit of reading time, and probably no unicorns, but a flying reindeer or eight.