...
Work Item 6 | Protocol specific markup | ||||||
|---|---|---|---|---|---|---|---|
Date Added / Date Completed | Discussed on Schema Editorial Board Notes, 7 February 2020, Schema Editorial Board Notes, 12 March 2020 | ||||||
| Description | Reformat the specification to include new markup that would make it easier to extract mechanically extract the examples into a protocol appropriate set | ||||||
| People | Proposed by Alan Buxey | ||||||
| Approved by the Schema Board |
Work Item 7 | Expand Attribute Values | ||||||
|---|---|---|---|---|---|---|---|
Date Added / Date Completed | Discussed on Schema Editorial Board Notes, 7 February 2020, Schema Editorial Board Notes, 12 March 2020 | ||||||
| Description | Check for some possible notes from Internet2's Tech Ex 2019. Affiliations, in particular, could use potential expansion (though maybe groups are a better way to handle the many variances of affiliation possibilities). This is something we should explore with the community to figure out what they need us to do. Some federations have done this on a federation-specific level. Board must reach out to learn more about what federations that are doing this on a local level are doing and why. | ||||||
| People | Proposed by Miro Milinovic | ||||||
| Approved by the Schema Board | Alan Buxey and Heather Flanagan will put together a schema subcommittee to discuss and come up with a proposal |
8 | Update the SCHAC Schema |
|---|---|
Date Added / Date Completed | 21 April 2021 |
| Description | The community has identified schacGender as problematic, being very limited in definition. An informal survey went out to determine if and where this is being used. That survey indicated inquired about all SCHAC attributes. It looks like many of the attributes in SCHAC are not in common usage. The SEB should take a look at the schema overall and consider where and how it might be revised. |
| People | |
| Approved by the Schema Board |
Closed Items
| Change the opening paragraph in section 1.2 before the "glossary" style portion discussing identifier concepts to the following (it splits the text apart and inserts a discussion of protocol-specific IDs in the middle) | ||||||
|---|---|---|---|---|---|---|---|
Date Added / Date Completed | Proposed on 28 March 2019 | ||||||
| Description | "Among the most common and useful personal attributes are identifiers. An identifier is an information element that is specifically designed to distinguish each entry from its peers in a particular set. While almost any information in an entry may contribute to differentiating it from similar entries, identifiers are intentionally designed to do this. It is common for entries to contain several different identifiers, used for different purposes or generated by different information sources. Note that while the eduPerson specification includes a number of generic identifier attribute types, it is increasingly common for individual security protocols such as OpenID Connect and SAML to define their own "standard" subject identifiers and related functionality. In some cases (e.g., SAML) this material has been explicitly informed by, and is a reaction to, problems or limitations arising from the application of the eduPerson-defined identifiers to federated authentication. In most cases, it is advisable to defer to a particular protocol's specifications to understand what constitutes best practice in that particular context. It may often be reasonable to map usage of eduPerson Identifiers have a number of characteristics that help to determine appropriate usage. The following comments are offered to help clarify some points of definition for these various identifiers. These concepts are also referred to in various attribute descriptions." | ||||||
| People | Proposed by Scott Cantor | ||||||
| Approved by the Schema Board | The following change was approved by the Schema Board on the 3 June 2019 call: 1.2. Identifier Concepts Among the most common and useful personal attributes are identifiers. An identifier is an information element that is specifically designed to distinguish each entry from its peers in a particular set. While almost any information in an entry may contribute to differentiating it from similar entries, identifiers are intentionally designed to do this. It is common for entries to contain several different identifiers, used for different purposes or generated by different information sources. Note that while the eduPerson specification includes a number of generic identifier attribute types, it is increasingly common for individual security protocols such as OpenID Connect and SAML to define their own protocol-specific subject identifiers and related functionality. In some cases (e.g., SAML) this material has been explicitly informed by, and is a reaction to, problems or limitations arising from the application of the eduPerson-defined identifiers to federated authentication. In most cases, it is advisable to defer to a particular protocol's specifications to understand what constitutes best practice in that particular context. It may often be reasonable to map usage of eduPerson identifiers into a protocol, but be aware that there may be subtle differences to account for when mapping to multiple protocols such as SAML and OpenID Connect. Identifiers have a number of characteristics that help to determine appropriate usage. The following comments are offered to help clarify some points of definition for these various identifiers. These concepts are also referred to in various attribute descriptions. |
...
Work Item 8 | AcademicID | ||||||
|---|---|---|---|---|---|---|---|
Date Added / Date Completed | Discussed on Schema Editorial Board Notes, 7 February 2020, Schema Editorial Board Notes, 12 March 2020 | ||||||
| Description | Consider adding AcademicID to a schema (the way we have ORCID). Maybe this belongs in SCHAC? | ||||||
| People | Proposed by Miro Milinovic | ||||||
| Approved by the Schema Board | The Schema Board does not accept this proposal at this time. The group consensus is to deal with requests for new unique identifiers on a case by case basis; will reconsider if we see a number of requests coming in. |
Work Item 7 | Expand Attribute Values | ||||||
|---|---|---|---|---|---|---|---|
Date Added / Date Completed | Discussed on Schema Editorial Board Notes, 7 February 2020, Schema Editorial Board Notes, 12 March 2020 Committee was closed September 2020 - see eduPersonAffiliation subcommittee | ||||||
| Description | Check for some possible notes from Internet2's Tech Ex 2019. Affiliations, in particular, could use potential expansion (though maybe groups are a better way to handle the many variances of affiliation possibilities). This is something we should explore with the community to figure out what they need us to do. Some federations have done this on a federation-specific level. Board must reach out to learn more about what federations that are doing this on a local level are doing and why. | ||||||
| People | Proposed by Miro Milinovic | ||||||
| Approved by the Schema Board | Alan Buxey and Heather Flanagan will put together a schema subcommittee to discuss and come up with a proposal |