SCHAC Plan

Introduction

SCHAC, the Schema for Academia, has been running for several years as part of TF-EMC2.

In the last year, however, it became obvious that a more sustainable plan to maintain and run SCHAC is needed. REFEDS could offer not only a better structured home for SCHAC, but also funding could be allocated to secure a SCHAC caretaker.

At the end of 2012, the REFEDS SC approved the proposal to host SCHAC.

SCHAC Tasks

• T1. discuss about the document (and schema): what to change, what has to be added, .... and produce the new release (current, since 20130805)
• T2. discuss about the governance (define a process for handling change and getting it approved) (future)
• T3. update all existing web pages in order to reflect previous decisions (future)

SCHAC Todo List

Due to the lack of proper maintainance of SCHAC in the last 15 months, there are a number of issues that should be fixed. Namely:

Harmonise SCHAC information on the TERENA website

(And/or move the content under REFEDS)

There are currently two registries running in parallel:

Old Registry: SCHAC Registry Information. A static web page managed by TERENA (A reference to the new registry has been added, however a decision should be taken on which registry to use)

New Registry https://urnreg.terena.org/.  The URL is referenced by the SCHAC RFC A dynamic web page where anyone can register values. The new registry offers an API (Is this used by anyone? What could it be used for?) and a dynamic web interface. The web interface currently has the drawback that it does not allow to create direct links to a particular SCHAC attribute (and also breaks navigation with the web browsers back-button). This would however be very useful. Most likely the interface could be expanded if self-registration of values is needed at all.

• Note: There is a discrepancy in the OID assignments between the old and new registry, hopefully there is no serious intention to change the already assigned and deployed OIDs:
  • New reg assigns 1.3.6.1.4.1.25178.1.1 for "Attributes that have been accepted as official in SCHAC"
  • New reg assigns 1.3.6.1.4.1.25178.1.2 for "SCHAC attributes that are being tested or were tested at some point in time."
  • Old pages assign 1.3.6.1.4.1.25178.1.1 for "Branch for SCHAC LDAP object classes"
  • Old pages assign 1.3.6.1.4.1.25178.1.2 for "Branch for SCHAC LDAP attributes"

Namespace urn:schac documentation update

At the end of 2011, the new RFC-defined SCHAC namespace urn:schac was approved. This means that the old namespace urn:mace:terena.org:schac would be deprecated. The sunset period as agreed in the TF-EMC2 meeting in Bologna (Oct 2011) would end in Jan 2013. Cf. https://www.terena.org/mail-archives/schac/msg00549.html

There should be a new revision of the SCHAC documents currently located at

• SCHAC schema IAD 1.4.1 (Main spec, PDF)
• SCHAC schema IAD 1.4.1 (LDAP, TXT)

with a revision listing the new namespace and a URL for the registry.

Better yet, all existing documents (the Specification PDF, the LDAP Schema and
all existing registries should be replaced with links to a single authoritative specification
containing all the necessary information. (e.g. in the newly federated TERENA wiki, which
provides access control for releases of the spec).

The URN change should affect only attribute values (since Schac attribute values often redundantly also contain the full attribute name as part of the value, a practice which should also be reconsidered) as in SAML Schac attribute names are commonly expressed as OID-based URNs on the wire (e.g. urn:oid:1.3.6.1.4.1.25178.1.2.10, following the example of the MACE-Dir SAML Attribute Profiles). However in the old registry the attribute-definitions still use name-based URNs.

• ACTION 0 (to be discussed): Reconsider use of structured attribute values for certain SCHAC attributes. What use-cases need the attribute name copied over to the attribute value (delegated namespaces, national/regional variants) and can we handle those differently?

• ACTION 1: Update SCHAC information on the TERENA website, including SCHAC documentation. Also a decision should be taken on whether we want to move SCHAC elsewhere (i.e. REFEDS).

• ACTION 2: Update the attribute-definition to list OID instead than URN http://www.terena.org/registry/terena.org/attribute-def/ or remove that page completely (what value that page provides is unclear) and replace with link to the SCHAC new specification document to be written.

Controlled vocabulary for attribute values

As pointed out on the SCHAC mailing list (Reference?), the SCHAC spec and LDAP schema both provide some example values for SCHAC attributes but do not provide any rules on how to assign values (e.g. applicability/eligibility for schacHomeOrganizationTypes).

This is particular relevant for the international values (:int) of schacHomeOrganizationType. Different Identity Federations already use/would like to use agreed upon international values. The results of short survey of what homeOrganisationType values are used and where is available in the REFEDS wiki.

• ACTION 3: Create a definitive (unified) version of the spec outlining what attributes and what values are part of the SCHAC specification (and which are not)
• ACTION 4 (Follow-up work): Agree on a set of needed/missing values that would cover the most common institution types and would work on the whole international scale

For schacHomeOrganizationType one finds different values in the old registry, the new registry, the PDF specification and the LDAP schema file. This is very confusing and should be harmonized and kept consistent. The easiest way to achive this is to have a single version (i.e., document) of the spec, also containing relevant bits from the LDAP-schema.

Governance

Governance should be defined for adding to or changing the spec, e.g. discussuing and finalizing amendments on the SCHAC mailing list and proposing them to the REFEDS SC for approval.

• ACTION 5: Define a process for handling change and getting it approved.

The existence of the "experimental" SCHAC branch should be reconsidered. Relying Parties should be spared the configuration work (changing the OID or formal attribute name for a given attribuet) only because it was decided that it turned out to be useful and hence has been copied over to the "production" branch (thereby changing the attribute's formal name, essentiallyl creating a completely different, new attribute).

• ACTION 6: Reconsider the experimental OID branch for SCHAC attributes

Identifier Assignment

According to the RFC defining the new urn:schac namespace:

TERENA will create an initial series of immediately subordinate naming authorities, and will define a process for adding to that list of authorities. [...] Each country with a representative in SCHAC will be invited to designate a naming authority. Country-specific namespaces based on the country Internet Top-Level Domain (TLD) will then be assigned to the designated authority. The subordinated namespaces int and eu will remain under TERENA authority, controlled by the SCHAC activity members, for entities of global, international, or European interest.

• ACTION 7: Should this be done? How? Why? (X.500 naming all over?)

Attribute Profiles for SAML and other usage

One could argue that any one of the following attribute names correctly represents the SCHAC attribute "HomeOrganizationType" when used inside a SAML attribute assertion:

• schacHomeOrganizationType (using "basic" naming in SAML)
  • or maybe only homeOrganizationType, to make things worse
• urn:schac:homeOrganizationType (using URI naming with new namespace)
• urn:mace:terena.org:schac:homeOrganizationType (URI naming with the deprecated namespace)
• urn:oid:1.3.6.1.4.1.25178.1.2.10 (OID-style URI naming, via RFC3061])

Clearly a SAML Service Provider shouldn't need to handle (i.e., manually configure) all these variants only to be able to process a single attribute.

• ACTION 8: Create a profile for SCHAC usage within SAML (and potentially other protocols)

Comments from Feide

• schacHomeOrganizationType: We need a value for primary and secondary schools as well. We can define those as national value(s), but perhaps it could be useful for other countries so it should be in the "urn:schac:homeOrganizationType:int:" namespace.
• one of the main reasons we are trying to get our institutions to use "schacPersonalUniqueID" is the possibility to use unique identification numbers from other countries. We can define the name space for Norway, but the added value for us is really when there are name spaces defined for all (or most) other countries.
• How can we encourage other countries to define their namespaces (even though they are not using the attribute themselves…)?
• And how about countries outside of Europe? Can Terena/Refeds define part of this on behalf of countries that
  • do not have a federation
  • do not want to define their own namespace