Date: Fri, 29 Mar 2024 07:59:18 +0000 (UTC) Message-ID: <689477429.21.1711699158323@wiki-prod.refeds.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_20_566523013.1711699158322" ------=_Part_20_566523013.1711699158322 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
NEEDS WORK
Page to be archived
SCHAC, the Schema for Academia, has been running for several years as pa= rt of TF-EMC2.
In the last year, however, it became obvious that a more sustainable pla= n 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.= p>
Due to the lack of proper maintainance of SCHAC in the last 15 months, t= here are a number of issues that should be fixed. Namely:
This item has been completed as of January 2015 as part of the SCHAC= Harmonisation Project.
(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 refer= enced 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 u= sed 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 SCHA= C attribute (and also breaks navigation with the web browsers back-button).= This would however be very useful. Most likely the interface could be expa= nded if self-registration of values is needed at all.
This item has been completed as of January 2015 as part of the SCHAC= Harmonisation Project.
At the end of 2011, the new RFC-defined SCHAC namespace urn:schac was ap= proved. This means that the old namespace urn:mace:terena.org:schac would b= e deprecated. The sunset period as agreed in the TF-EMC2 meeting in Bologna= (Oct 2011) would end in Jan 2013. Cf. https://w= ww.terena.org/mail-archives/schac/msg00549.html
There should be a new revision of the SCHAC documents currently located at
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 sin= gle 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 nam= e as part of the value, a practice which should also be reconsidered) = as in SAML Schac attribute names are commonly expressed as OID-bas= ed URNs on the wire (e.g. urn:oid:1.3.6.1.4.1.25178.1.2.10, following the e= xample of the MACE-Dir= SAML Attribute Profiles). However in the old registry the attribute-de= finitions still use name-based URNs.
Work still pending
As pointed out on the SCHAC mailing list (Reference?), = the SCHAC spec and LDAP schema both provide some example values for SCHAC a= ttributes 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 schac= HomeOrganizationType. Different Identity Federations already use/would like= to use agreed upon international values. The results of short survey of what homeOrganisationType va= lues are used and where is available in the REFEDS wiki.
For schacHomeOrganizationType one finds different values in the old regi= stry, the new registry, the PDF specification and the LDAP schema file. Thi= s is very confusing and should be harmonized and kept consistent. The easie= st way to achive this is to have a single version (i.e., document) of the s= pec, also containing relevant bits from the LDAP-schema.
This item has been completed as of January 2015 as part of the SCHAC= Harmonisation Project.
Governance should be defined for adding to or changing the spec, e.g. di= scussuing and finalizing amendments on the SCHAC mailing list and proposing= them to the REFEDS SC for approval.
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 "pro= duction" branch (thereby changing the attribute's formal name, essentiallyl= creating a completely different, new attribute).
Work still pending
According to the RFC defining the new urn:schac namespace<= /a>:
TERENA will create an initial series of immediately subordinate naming auth= orities, and will define a process for adding to that list of authorities. = [...] Each country with a representative in SCHAC will be invited to design= ate a naming authority. Country-specific namespaces based on the country In= ternet Top-Level Domain (TLD) will then be assigned to the designated autho= rity. The subordinated namespaces int and eu will remain under TERENA autho= rity, controlled by the SCHAC activity members, for entities of global, int= ernational, or European interest.
This item has been completed with the 1.5 release = of SCHAC.
One could argue that any one of the following attribute names correctly = represents the SCHAC attribute "HomeOrganizationType" when used inside a SA= ML attribute assertion:
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 attr= ibute.