This document is an attempt to clarify the R&S specification to address issues that have arisen in its initial deployment by federations, particularly confusion over its relationship to other, unrelated mechanisms and regimes for attribute release facilitation. It also attempts to clarify what an SP and IdP are obligated or assumed to be doing, and moves some "implicit" guidance into formally suggested behavior.

While it represents a perception of some mild consensus on the REFEDS list and reflects wider discussion on one phone conference, it currently should be viewed as the author's opinion, pending further review.

Summary of Changes

Minor wording clarifications and larger explicit clarifications addressing points of apparent differing practice are included in green.

Suggested deletions of requirements that have led to confusion and differing practice are struck through.

The author believes the changes made would not cause any existing SP claiming the category to become unable to do so. It is a given based on discussion on the list that some IdPs claiming the category would become unable to do so.

Overview

Research and Education Federations are invited to use the REFEDS Research and Scholarship Entity Category with their members to support the release of attributes to Service Providers meeting the requirements described below.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [RFC2119]. This definition is written in compliance with the Entity Category SAML Entity Metadata Attribute Types specification [EntityCatTypes].

An FAQ for the Entity Category has been made available to help deployments [R&SFAQ].

1. Definition

Candidates for the Research and Scholarship (R&S) Category are Service Providers that are operated for the purpose of supporting research and scholarship interaction, collaboration or management, at least in part.

Example Service Providers may include (but are not limited to) collaborative tools and services such as wikis, blogs, project and grant management tools that require some personal information about users to work effectively. This Entity Category should not be used for access to licensed content such as e-journals.

Identity Providers may indicate support for Service Providers in this category (typically through self-assertion, though this is not required) to facilitate discovery and improve the user experience at Service Providers.

The following sections detail the requirements for both Service Providers and Identity Providers, in category membership and support respectively.

2. Syntax

The following URI is used as the attribute value for the Entity Category and Entity Category Support attribute:

http://refeds.org/category/research-and-scholarship

3. Semantics

By asserting a Service Provider to be a member of an Entity Category, a registrar claims that:

  • 3.1 The Service Provider has applied for membership in the Category and complies with the R&S registration criteria.
  • 3.2 The Service Provider’s application for R&S has been reviewed and approved by the registrar.

In possessing the Entity Category Attribute with the above value, a Service Provider claims that it will not use attributes for purposes that fall outside of the service definition.

In possessing the Entity Category Support Attribute with the above value, an Identity Provider claims that it will release attributes to R&S Service Providers as outlined in the “Identity Provider Attribute Release” section below.

4. Registration Criteria

When a Service Provider’s registrar (normally the Service Provider’s home federation) registers the Service Provider in the Entity Category, the registrar MUST perform at least the following checks:

  • 4.1 The service enhances the research and scholarship activities of some subset of the registrar’s user community.
  • 4.2 Service metadata has been submitted to the registrar and published in the registrar’s public metadata aggregate for publication.
  • 4.3 The service meets the following technical requirements:
    • 4.3.1 The Service Provider is a production SAML deployment that supports SAML V2.0 HTTP-POST binding.
    • 4.3.2 The Service Provider claims to refresh federation metadata at least daily.
    • 4.3.3 The Service Provider provides an mdui:DisplayName and mdui:InformationURL in metadata.
    • 4.3.4 The Service Provider provides one or more technical contacts in metadata.
    • 4.3.5 The Service Provider provides requested attributes in metadata.

R&S Service Providers MUST resolve issues of non-compliance within a reasonable period of time from when they become aware of the issue. Failure to do so MUST result in revocation of the entity’s membership in the R&S category.

5. Attribute Bundle

The mechanism by which this entity category provides for consistent attribute release is through the definition of a set of commonly supported and consumed attributes typically required for effective use of R&S services. The attributes chosen represent a privacy baseline such that further minimization achieves no particular benefit. Thus, the minimal disclosure principle is already designed into the category.

The use of the <md:RequestedAttribute> mechanism supported by SAML metadata is outside the scope of this category, and may co-exist with it in deployments as desired, subject to this specification's requirements being met.

The R&S attribute bundle consists (abstractly) of the following required data elements:

  • shared user identifier
  • person name
  • email address

and one optional data element:

  • affiliation

where shared user identifier is a persistent, non-reassigned, non-targeted identifier defined to be either of the following:

  1. eduPersonPrincipalName (if non-reassigned)
  2. eduPersonPrincipalName + eduPersonTargetedID

and where person name is defined to be either (or both) of the following:

  1. displayName
  2. givenName + sn

and where email address is defined to be the mail attribute,

and where affiliation is defined to be the eduPersonScopedAffiliation attribute.

All of the above attributes are defined or referenced in the [eduPerson] specification. The specific naming and format of these attributes is guided by the protocol in use. In the case of SAML 2.0 the [SAMLAttr] profile MUST be used. This specification may be extended to reference other protocol-specific formulations as circumstances warrant.

6. Service Provider Requirements

Service Providers SHOULD request a subset of R&S Category Attributes that represent only those attributes that the Service Provider requires to operate its service.

Service Providers SHOULD limit their data requirements to the bundle of attributes defined in Section 5, but MAY negotiate for additional data as required via mechanisms that are outside the scope of this specification.

Service Providers are strongly encouraged to support all of the specified alternatives for the shared user identifier and person name attributes described in Section 5 to maximize interoperability. Failure to do so will result in problems even when working exclusively with Identity Providers that claim support for the category. In the case of the eduPersonTargetedID attribute, this recommendation includes the ability to support SAML 2.0's "persistent" Name Identifier format, which is the recommended modern expression of the eduPersonTargetedID attribute in SAML 2.0.

In accordance with the requirements in Section 7, if an Identity Provider exhibits the R&S entity attribute in its metadata and no accompanying eduPersonTargetedID attribute is recieved, then Service Providers can rely on the non-reassignment of eduPersonPrincipalName values it receives from that Identity Provider.

Alternatively, Service Providers can obtain a non-reassigned shared user identifier by combining (e.g., concatenating) the eduPersonPrincipalName and eduPersonTargetedID values. If a given combination of the two values ever changes, Service Providers can assume that the eduPersonPrincipalName has been reassigned and now represents a different subject.

A Service Provider that conforms to R&S would exhibit the following entity attribute in SAML metadata:

An entity attribute for SPs that conform to R&S
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
  <saml:Attribute
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      Name="http://macedir.org/entity-category">
    <saml:AttributeValue>http://refeds.org/category/research-and-scholarship</saml:AttributeValue>
  </saml:Attribute>
</mdattr:EntityAttributes>

7. Identity Provider Requirements

An Identity Provider indicates support for the R&S Category by exhibiting the R&S entity attribute in its metadata. Such an Identity Provider MUST, for a significant subset of its user population, release all required attributes in the bundle defined in Section 5 to all R&S Service Providers without administrative involvement by any party, either automatically or subject to user consent.

An Identity Provider that does not release all of the required elements of the R&S attribute bundle (shared user identifier, person name, email address), for any reason, SHALL NOT exhibit the R&S entity attribute in its metadata. Exceptions, limiting the release of attributes to specific R&S Service Providers, may be permitted in the event of a security incident or other isolated circumstances.

For the purposes of effective access control, A persistent, non-reassigned, non-targeted identifier is REQUIRED. If the Identity Provider’s deployment of eduPersonPrincipalName is non-reassigned, and the organization believes in good faith that it will remain so, it will suffice. Otherwise the Identity Provider MUST release eduPersonTargetedID (which is non-reassigned by definition) in addition to eduPersonPrincipalName. In any case, release of both identifiers is RECOMMENDED. Likewise the release of all three person name attributes (displayName, givenName, sn) is also RECOMMENDED.

Identity Providers are strongly encouraged to release the entire attribute bundle (both required and optional attributes) defined in Section 5 to R&S category Service Providers, both to maximize interoperability and the scope of supported services. The only optional data element is affiliation, which while different in nature to the rest of the bundle, is important to many R&S services and is a particular differentiator for academic organizations.

An Identity Provider that supports R&S would exhibit the following entity attribute in SAML metadata:

An entity attribute for IdPs that support R&S
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
  <saml:Attribute
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      Name="http://macedir.org/entity-category-support">
    <saml:AttributeValue>http://refeds.org/category/research-and-scholarship</saml:AttributeValue>
  </saml:Attribute>
</mdattr:EntityAttributes>

References

[EntityCatTypes] Young, I, Johansson, L, and Cantor, S Ed., “The Entity Category SAML Attribute Types”, July 2014.

[R&SFAQ] Harris, N., “Research and Scholarship FAQ”, November 2014.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[eduPerson] Internet2 MACE Directory Working Group, "eduPerson Object Class Specification (201602)", February 2016.

[SAMLAttr] Internet2 MACE Directory Working Group, "MACE-Dir SAML Attribute Profiles", April 2008.

  • No labels

56 Comments

  1. Peter Brand

    +1 on most of the text, though I find

    An Identity Provider is said to "support" the R&S Category if,

    too weak, for no obvious reason: The IDP can only correcty claim to support (in metadata, by possessing the label) the category if it does (by releasing data). So it's not about regulating how we speak about IDPs (whether an IDP is said to "support" the category or not), but about whether the IDP has a right to claim that support?

    1. Scott Cantor

      I think I had already tweaked that text, can you review? I had reworded that passive, weaselly language with more normative speak.

  2. Mikael Linden

    Many federation deployments use eduPersonAffiliation instead of eduPersonScopedAffiliation. Would it be possible to support both; IdP releases either eduPersonAffiliation or eduPersonScopedAffiliation?

    1. Scott Cantor

      I don't really agree with ever using the unscoped version in a federated system, but leaving that aside, I don't believe we should change the attribute bundle unless the category itself is changed.

  3. Mikael Linden

    I would add the eduPerson(Scoped)Affiliation to the minimal subset, due to its potential value in coarse-grained authorisation in the SP-side. It's value "faculty" is relatively consistently interpreted in the federations (reference) and a good match for R&S services. It is difficult for an SP to retrieve a reliable affiliation value from any other source.

    1. Scott Cantor

      If you add eduPersonScopedAffiliation, then there is no subset, there's just the bundle. While I understand the appeal of that, are we prepared to absolutely dismiss any arguments about privacy as a result?

      Revealing affiliation is substantially different than revealing identity, and if you do both vs. just revealing identity, that's a piece of information that many (in fact, most) applications don't need. That's exactly where the RequestedAttribute mess starts to creep back in.

      I think if I really believed most R&S applications wanted that data or used it appropriately, I could see the argument, but that hasn't been my experience at all.

      1. Mikael Linden

        If Affiliation is not in the minimal bundle and if an SP cannot use requestedAttribute to indicate it would like to receive it, it gives the SP little hope to receive Affiliation, right?

        (Personally I'm in favor of SPs using requestedAttributes to indicate their attribute needs. That is a standard mechanism, why not use it?)

        How to convince you that Affiliation is important for research-focused SPs? In Europe, the major document listing research-focused SPs' needs is the FIM4R paper (link) which presents the following requirements (page 13):

        • Well defined semantically harmonised attributes

        • Flexible and scalable IdP attribute release policy

        • Attributes must be able to cross national borders

        If privacy of Affiliation release concerns you, what about a middle way and limiting the release to the eP(S)A value "faculty"? That is the value research-focused SPs are interested in. Quite many universities list their faculty members publicly in their website, anyway...

        1. Tom Scavo

          If Affiliation is not in the minimal bundle

          Adding Affiliation to the minimal bundle would break R&S. There are 120 IdPs in the InCommon Federation that wouldn't be very happy with me if I told them they had to change their configs again. 

          if an SP cannot use requestedAttribute to indicate it would like to receive it

          An SP can include any RequestedAttribute it wants but an R&S IdP is not obliged to honor it. In any case, Affiliation is an exception since the R&S attribute bundle is not easily represented by RequestedAttributes. Meta-attributes (sometimes called abstract attributes) are needed.

        2. Scott Cantor

          If Affiliation is not in the minimal bundle and if an SP cannot use requestedAttribute to indicate it would like to receive it, it gives the SP little hope to receive Affiliation, right?

          It means the SP will receive it from any IdP that's comfortable including it. Many are or will be, but the subset was defined so that the greater number of IdPs that might not want to include affiliation could still qualify. If we reopen that question, this isn't R&S any longer, it's something new.

          If we were to craft a new category, I would agree that limiting it to faculty would likely be useful, but most of us have felt that defining a new category so closely related would simply create confusion.

          As far as RequestedAttribute is concerned, the entire reason I'm writing this is that it did in fact break the contract we defined, and in fact does not work because of the aliasing problem. It happens to work in the specific case of eduPersonScopedAffiliation, but it came down to the desire to avoid complexity by creating special cases to accomodate it.

          I would note that your preference for allowing eduPersonScopedAffiliation OR eduPersonAffiliation would in fact break it again, since there would be no way to require one or the other, but not both.

  4. Tom Scavo

    Some comments:

    1. s/published in the registrar’s public metadata aggregate/and made available for public consumption/
    2. The first two paragraphs of section 5 belong in section 7.
    3. Affiliation should be required or removed. Since requiring affiliation breaks current deployments, I think it should be removed.
    4. s/if they make any of them available//

     

    1. Scott Cantor

      1 and 4 applied.

      I personally think the text works better in 5 to motivate the design/approach, but others may disagree.

      I don't think we can have a conversation about affiliation productively other than on a phone call. I think there are about a half-dozen opinions about it.

      1. Tom Scavo

        I personally think the text works better in 5 to motivate the design/approach, but others may disagree.

        I do disagree. I think it actually makes the argument less clear.

        I suggest you collapse sections 5 and 7 into one section. This will force a reorganization of the text on attribute release. Hopefully the result will be more clear.

        I don't think we can have a conversation about affiliation productively other than on a phone call. I think there are about a half-dozen opinions about it.

        There are only three possibilities (required, optional, removed) but I agree with you, there is no consensus.

        1. Scott Cantor

          You're arguing for making the subset and the bundle identical (i.e. have no subset). Certainly in that event the sections will change, with 7 becoming much simpler and shorter. But the text in 5 still wouldn't belong in 7, they aren't talking about the same thing. If we're going to get people to stop asking for RequestedAttribute in the picture, we have to motivate that by how the bundle itself is presented by explaining the privacy justification.

  5. Niels van Dijk

    4.2 Service metadata has been submitted to the registrar and published in the registrar’s public metadata aggregate made available for public consumption.

    What's the reasoning behind this proposed change? I assume we still want IdPs to use registrar metadata to learn about the service, not directly from the SP?

    1. Tom Scavo

      Thank you for asking. I struggled with that text. It definitely needs a fresh set of eyes.

      The phrase "metadata aggregate" does not include per-entity metadata. Federations are beginning to experiment with per-entity metadata distribution. We don't want this spec to rule that out as a potential distribution method.

      Given that background, suggestions are appreciated.

      1. Niels van Dijk

        Ok, I fully agree with your notion, however I feel the current wording may lead to other conclusions. I am wondering if it is relevant that we need to specify how the metadata gets distributed at all?

        1. Tom Scavo

          Okay, how about this?

          "4.2 Service metadata has been submitted to the registrar for publication."

          1. Niels van Dijk

            Yes

  6. Tom Scavo

    I just committed a rewrite of Section 7, primarily for clarity. Please review and revert if necessary.

    At least one problem remains but I don't know how to fix it. The minimal subset potentially includes eduPersonTargetedID, which is now a deprecated attribute.

    If we were starting fresh, I think we would be wise to exclude eduPersonTargetedID from this specification. The new eduPersonUniqueId is an obvious alternative.

    1. Scott Cantor

      The text needs work in this area because what it means by eduPersonTargetedID is NOT the SAML Attribute but the eduPerson attribute. In fact, that's how all the attributes are being referenced (that's why the short names are used).

      So this text does NOT mean "release it as a SAML Attribute" but rather "do what's apropriate for the binding in use", and if that's SAML 2, it means a persistent NameID.

      Peter and I both noted the need to work over that part of the spec, I was just focused on the more controversial bits first.

      As you say, if we were starting over, sure, I wouldn't use ePTID. Any change that leads to a new category would basically open up the floor for all kinds of changes.

      1. Tom Scavo

        The text needs work in this area because what it means by eduPersonTargetedID is NOT the SAML Attribute but the eduPerson attribute.

        Okay, so in that case we should be able to address this issue in the FAQ. I wouldn't clutter the spec with such details.

        1. Scott Cantor

          Maybe, but I wouldn't give up yet on some better text around this, even if it's just a sentence or two. I'll try and propose something.

  7. Lukas Hämmerle

    Some comments regarding "5. Attribute Bundle":

    • Should "3. eduPersonUniqueID" be added as third option of a shared user identifier? Sure, it's not yet widely deployed but that will change.
    • Should "3. cn (commonName)" be added as a third option for the person name? The difference to displayName is that this attribute might be multi-valued. I don't think cn is used frequently.

    1. Tom Scavo

      Should "3. eduPersonUniqueID" be added as third option of a shared user identifier? Sure, it's not yet widely deployed but that will change.

      +1 since that doesn't break anything.

      1. Scott Cantor

        Either of those are breaking changes. If an IdP is allowed to send only a new attribute in place of the older ones, then an existing SP won't recognize it. Just doesn't work.

        1. Lukas Hämmerle

          So which attribute do you consider as "old" and "new". Don't we have that issue already with two options?

          1. Scott Cantor

            The "old" ones are in the original text of the category and are the only ones my revisions include. Literally any other attributes would be "new".

            The full set of existing attributes are sn, givenName, displayName, mail, eduPersonPrincipalName, eduPersonTargetedID, and eduPersonScopedAffiliation. (Those are in terms of eduPerson, not SAML or OIDC or any specific protocol.)

            As I keep saying, if we're starting over, great. Then R&S is done and we're on to R&Sv2. Then we can literally do whatever we want, and talk about what the migration path would be. In that case, yes, adding new options to the old ones is a "safer" path to take.

            1. Thomas Lenggenhager

              Why not finish this revision first that does not break anything at the SPs?

              Once that is concluded we can either start with drafting R&Sv2 or a library or other entity category what ever seems most pressing.

  8. Thomas Lenggenhager

    I like this proposal a lot. Thank you for your efforts to streamline the complex discussions into an improved text!

    Is the following case something that should be documented in the R&S FAQ?

    Let's assume an SP possesses the R&S Entity Category Attribute and requires the eduPersonScopedAffiliation attribute for its service. To increase the chance to get the eduPersonScopedAffiliation attribute (it is not part of the minimal subset of the R&S attribute bundle), the SP is well advised to list the eduPersonScopedAffiliation attribute as <RequestedAttribute> with 'isRequired=true' in metadata, so that IdPs that only provide the minimal subset of the R&S attribute bundle might to also release the eduPersonScopedAffiliation based on the occurrence in metadata.

    1. Tom Scavo

      Is the following case something that should be documented in the R&S FAQ?

      Let's assume an SP possesses the R&S Entity Category Attribute and requires the eduPersonScopedAffiliation attribute for its service. To increase the chance to get the eduPersonScopedAffiliation attribute (it is not part of the minimal subset of the R&S attribute bundle), the SP is well advised to list the eduPersonScopedAffiliation attribute as <RequestedAttribute> with 'isRequired=true' in metadata, so that IdPs that only provide the minimal subset of the R&S attribute bundle might to also release the eduPersonScopedAffiliation based on the occurrence in metadata.

      I think that would be a fine thing to do (and you could do it now). The same would be true of any other attribute, I suppose, as long as we're careful not to imply or suggest that has something to do with the release of the R&S attribute bundle. The latter is independent of any requested attributes in metadata, which is a primary motivation for writing the clarification proposal in the first place.

      1. Scott Cantor

        Yeah, that's really my only concern is the obvious slippery slope back into where we started. I think the FAQ would have to be written carefully enough to try and explain the difference between requesting things on the SP side, but the IdPs claiming support not looking at it. That's a difficult line to split.

        There's no question that the subset design excluding affiliation was something that I think people overlooked until now, but it absolutely makes affiliation very much a sideline to R&S. It is unfortunate that wasn't understood at the beginning since it was quite deliberate. It may be that the justifications for that aren't good ones, I don't know.

  9. Nicole Harris

    "This approach is orthogonal to the practice of attempting to enumerate the specific attributes needed by a service, debate over whether those attributes are actually required or not, and the complexity inherent in attempting to curate and communicate them." <--- I find this a little verbose and does not really clarify the issue.  Would perhaps be tempted to delete and just have the sentence immediately following (without the specifically) or something more direct .

    1. Scott Cantor

      Fine with me, it was mostly a wordy attempt to justify why we're trying to get people to ignore RequestedAttribute here, but it's more arguing than clarifying. I'll shrink it down.

  10. Laura Paglione

    Hi – thanks for the discussion earlier today. There was one question I had about attribute requests that I'm still not sure I have complete clarity about. If I'm reading this proposed language correctly, the name (some form) & email address would be provided to R&S SPs even without request:

    Such an Identity Provider MUST, for a significant subset of its user population, release all required attributes in the bundle defined in Section 5 to all R&S Service Providers without administrative involvement by any party, either automatically or subject to user consent.

    There was a discussion on the email forum a while back about if an SP made an optional request for one of these attributes (for example, the email address), the optional attribute would not be released by the IdP, presumably because it deemed to not be needed because of the "optional" designation? (I admit, that didn't make much sense to me, so I may not have characterized the argument completely correctly.)

    I'm just wondering what to expect as an SP - would those attributes (name/email and maybe affiliation) be provided even if not explicitly requested? Does the story change if the attributes are requested as either required or optional?

    (and apologies for the probably obvious question - I'm finding that my definitions of required and optional may not be widely held - I consider required to mean that I can not operate the service if the attribute is not provided, and optional to mean that I can operate the service without it, but in providing it, additional benefits can be provided to the user, perhaps in reduced data entry, increased capability or other user benefit.) Thx for your help in sorting this out!

    1. Scott Cantor

      The mechanism that people are referring to when they talk about "required" or "optional" attributes is the RequestedAttribute metadata element that the text is now explicitly referring to as out of scope. When you see people discussing that on-list, that's generally what they mean.

      The problem we started out trying to fix with this proposal was exactly that issue, an IdP (UnitedID specifically, but could have been any) tagging itself but then only releasing an attribute if the SP's metadata requested it. So the new text is explicitly saying it's out of scope to do that, and removing all the requirements around SPs explicitly enumerating their requirements. By saying you're R&S, you're saying saying "my requirements are the bundle in Sec 5", as opposed to creating more fine-grained rules.

      Your definitions are the common ones. My use of the terms in the updated text in Sec 5 may prove to be impractical because it overlaps, we'll see. I'm trying to rationalize what Peter suggested with the text as laid out now but that may not work, and your reaction to it was sort of what I expected.

      The problem I have is that the terms here are referring to what's in section 7, but they show up in section 5, and I don't so far have a good idea on combining them.

      1. Laura Paglione

        Thanks, Scott. That's very helpful.

  11. Andrew Cormack

    It took me a couple of readings to work out what the following, in the third para of section 7, was talking about

    Exceptions for specific Service Providers may apply in the event of a security incident or other isolated circumstances.

    I'd suggest "Exceptions, limiting the release of attributes to specific R&S Service Providers, may be permitted in the event of a security incident or other isolated circumstances". Does that cover everything you had in mind?

    1. Scott Cantor

      Suggestion applied.

  12. Peter Brand

    Mostly editorial nits or +1s:

    The attributes chosen represent a privacy baseline such that further minimization achieves no particular benefit to a user.

    Maybe remove "to a user"? Or amend "to a user or organization" or "to a user or Identity Provider"? The user may not be the (only) beneficiary of data minimization, e.g. if the IdP org is responsible for attribute release, not the user (via consent).

    All of the above attributes are defined by the [eduPerson] specification.

    "Defined by eduPerson" may be a bit much for displayName, givenName, sn and mail, though? "are part of"? "referenced/detailed in"?

    +1 on the new part in section 6 wrt interop, except maybe for "alternative formulations". Maybe "specified alternatives"? It's the "formulations" that caused me to stop and think "What is this talking about?" for a second.

    +1 also on the new text wrt how affiliation is optional/different but may still be important to some (and therefore part of the "strongly encourage" complete bundle).

    Section 7: "Without further administrative involvement"? And is "either automatically or subject to user consent." sufficient to rule out IDPs only releasing data to SPs that carry, say, both CoCo and R&S (and still claim R&S support)?

    7 ctnd: Maybe add to "An Identity Provider that does not support all of the required elements of the R&S attribute bundle" the enumeration of those elements "(shared user identifier, person name, email address)", to avoid confusion between the elements of the bundle and the instantiation of those elements (eduPersonPrincipalName, etc.)? Also if "support all of the required elements" means "release" then maybe we should say so. An IDP can probably consider itself supporting stuff without necessarily meaning to release it to any given SP. Either way, it should be clear what "support" means for the IDP – arguably one main reason for the whole exercise!

    On that same topic: Earlier in the same section it's "release all required attributes in the bundle", later that becomes "support all of the required elements of the R&S attribute bundle". I think one variant should be used consistently (or the text shorted to one occurance of that statement. i.e., sentence/paragraph 1 and 3 overlap significantly currently.)

    7 ctnd:  Should we shorten "SHALL NOT claim support for this category; that is, the Identity Provider SHALL NOT exhibit the R&S entity attribute in its metadata." to just "SHALL NOT exhibit the R&S entity attribute in its metadata."?

    I thought before about having seperate sections for SP and IDP behaviour/conformance and also including the relevant XML in each section. Modulo the XML we're not far from that with new sections 6 and 7, so maybe it's just a renaming of those sections, esp if additional guidance of ePPN handling gets added to section 6. Maybe there's nothing to do here, I'd just like to have those sections be self-contained as much as possible in what R&S means for a given role as far as desired/expected/prescribed behavour is concerned.

    I'd remove the line breaks before and after the entity category value in the XML examples, and also replace R&amp;S in the comments with either "RandS" or "Research and Scholarship". Having entity references in comments is just silly.

    1. Scott Cantor

      These are all good. I applied almost all the wording changes, and moved the examples up along with renaming those sections.

      The exception is:

      Section 7: "Without further administrative involvement"? And is "either automatically or subject to user consent." sufficient to rule out IDPs only releasing data to SPs that carry, say, both CoCo and R&S (and still claim R&S support)?

      I seem to recall that the "further" term might have been in there originally when I rewrote that text. Maybe I'm wrong, but I seem to recall a suggestion to clean that up. But I guess the main thing is that I think what's there is pretty explicit and self-contained. Let's see what others think. I think it handles the case of CoCo, but maybe others see a loophole. If we need to, I think just adding an example like that outright is better than ratholing too much on the wording.

  13. Peter Brand

    Thanks. The XML comments now have both instances of R&S (above; not legal even in a comment, I think, unless we add a CDATA section around it, too, which of course is total overkill) and R&amp;S (below) each. I'd rather remove both comments from both examples?

    1. Scott Cantor

      I honestly thought it was legal in a comment, but no matter, comments are gone.

  14. Hannah Short

    Hi Scott, this looks so much clearer! The one thing that struck me as misleading is that, in the introductory sections you state that only SPs are candidates for R&S. Since both SPs and IdPs have requirements to fulfil in order to use the R&S Category, to my mind that makes them both "Candidates". Potentially you could call IdPs "R&S Candidate Supporters" or something similar. It is strange that IdPs are first mentioned in the "semantics" paragraph with no introduction.

    1. Scott Cantor

      See text I added.

      1. Hannah Short

        Perfect, many thanks

  15. Tom Scavo

    I hesitate to make a potentially disruptive comment at this late stage but if we don't get our arms around this now, it will come back to haunt us later.

    There is a small group working on OpenID Connect SAML mapping. The question has come up about how an OpenID Provider (OP) would support R&S. The proposed text above takes a giant step in that direction (by defining abstract attributes, or meta-attributes) but it stops short of actually adding OIDC claims to list of qualifying attributes.

    Before I dive into the details, let me ask: Should we go down this path? That is, should we expand the current proposal to include OIDC?

     

    1. Nicole Harris

      I think adding support for OIDC would have to represent a change to the current meaning and not a clarification, so really think this will have to wait for v2.  I don't think this is detrimental given the current low-level uptake of OIDC and the fact that a v2 discussion has already been agreed.

      1. Scott Cantor

        I don't necessarily think it's a change just because by definition it can't really be impacting any existing deployments, but I don't think it matters all that much if it's added now or not. I think we can profile it in once the work is done to leverage it, and I added the statements in to make that more palatable to do after the finalization of this round of text (and obviously this was why I suggested that).

        1. Nicole Harris

          Cannot agree that "current deployment effecting" is a good measure of whether something is a change or a a clarification as clarifications could indeed be deployment affecting...however as we agree on the action probably not worth arguing about that at this stage.

          1. Scott Cantor

            Well, I think it impacts the text I added. If people believe that we could not add a reference to specific OpenID claims post facto, then the text I added about that is not actually true and should be removed in favor of text that makes this explicitly SAML only.

            I don't think that's actually true myself, but I think it should be decided and clarified either way so that the follow on course of action at that time is clear.

            1. Nicole Harris

              Unless SPs can work with OIDC OPs without making any changes to their offering, I think it is a v2 issue - otherwise we will create a scenario where we have SPs saying they can work with SAML IdPs with R&S but not with OIDC OPs with R&S and that is a new but different headache for us....particularly considering the conversation we had last week about SPs not supporting all IdPs being "undesirable".

              1. Scott Cantor

                The signaling in SAML metadata is necessarily limited to the protocols advertised. That is, until/unless the metadata were to include the right information to be applicable to OIDC, there's no statement being made now that says an IdP or SP supports OIDC.

                It's even possible, albeit a really odd scenario, for an entity to have two EntityDescriptors in a piece of metadata with different roles. The one with a SAML role might include the R&S tag and the one with an OIDC role might not. Or vice versa. But the signaling would be clear.

                Not saying this is likely to be done, but there's no conflict or incompatibility in introducing a separate protocol, it's just something metadata was designed to handle.

  16. Andrew Cormack

    I'm afraid the "Pursuant to..." paragraph in Section 6 is too legalese for me to parse (sad) I think what you mean is:

    "The IdP requirements in Section 7 mean that if an Identity Provider exhibiting the R&S flag in its metadata provides only an eduPersonPrincipalName attribute and no accompanying eduPersonTargetedID attribute then Service Providers can rely on that eduPersonPrincipalName value not being reassigned to a different individual.

    Alternatively, Service Providers can obtain..."

    Is that (a) correct, and (b) clearer?

     

    1. Scott Cantor

      I think there was a grammar error, that didn't help. I rephrased.

  17. Peter Brand

    In the case of the eduPersonTargetedID attribute, this recommendation includes the ability to support SAML 2.0's "persistent" Name Identifier format, which is the recommended modern expression of the eduPersonTargetedID attribute in SAML 2.0.

    Thanks. I'm aware we're aiming at "abstract" attributes, but is the above sufficiently concrete to spell out that the NameID could have been transported in the Assertion's Subject element? (ePTID is defined to have a persistent NameID as value, so the above alone doesn't tell me to expect/support anything else than ePITD attributes, does it?) – but then saml2int already states that (though in the attribute section) and we shouldn't have to repeat this here.

    Is adding a bit about SAML 2. making this (more) SAML-specific when people now seem to want a generic spec that can be used with other protocols as well?

    1. Scott Cantor

      I think there's enough SAML in it now that it doesn't do much more harm to call it out. I took "support Name Identifier format" to be explicitly about the Subject case, that's language I've used elsewhere. I think we can't get much more precise without turning it into a paragraph and going overboard, but I thought it would help motivate the FAQ to say something if the spec itself mentioned it.