This document is an attempt to rewrite the R&S specification for clarity and simplicity without breaking existing R&S deployments.
Note |
---|
The following draft text is for discussion only! For comparison, the official normative text is shown below the horizontal line. |
...
Code Block | ||
---|---|---|
| ||
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> <!-- entity attribute for SPs that conform to R&S --> <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"> <!-- the refeds.org R&S entity attribute value --> <saml:AttributeValue> http://refeds.org/category/research-and-scholarship </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> |
...
Code Block | ||
---|---|---|
| ||
<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> <!-- entity attribute for IdPs that support R&S --> <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"> <!-- the refeds.org R&S entity attribute value --> <saml:AttributeValue> http://refeds.org/category/research-and-scholarship </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> |
...
The R&S attribute bundle consists of the following attributes:
- non-private shared user identifier
- person name
- email address
where non-private user shared user identifier is a persistent, non-reassigned, non-targeted identifier defined to be any one of the following:
...
and where email address is defined to be the mail
attribute.
6. Attribute Request
...
Service Providers SHOULD request a subset of the R&S attributes attribute bundle that represent represents only those attributes that the Service Provider requires to operate its service. Such an R&S attribute requested in metadata MUST NOT be decorated with isRequired="false"
.
7. Attribute Release
An Identity Provider supports the Research & Scholarship (R&S) category if, for some subset of the Identity Provider’s user population, the Identity Provider is willing and able to release the R&S attribute bundle to all conforming R&S Service Providers without administrative involvement, either automatically or subject to user consent.
An Identity Provider MUST release the R&S attributes to attribute bundle to any conforming R&S Service Provider upon request, in one of two ways:
- By unconditionally releasing the complete R&S attribute bundle; OR
- By filtering attributes from the R&S attribute bundle based on the
<md:RequestedAttribute>
elements in Service Provider metadata, regardless of whether the optionalisRequired
XML attribute is (or is not) present.
An Identity Provider is NOT REQUIRED to release an R&S attribute to a given R&S Service Provider unless that attribute is requested in Service Provider metadata. Conversely, an Identity Provider that supports the R&S category MUST release the attributes shown below upon request from the Service Provider:
requested | released |
---|---|
refedsUserID | refedsNonPrivateUserID |
refedsNonPrivateUserID | refedsNonPrivateUserID |
eduPersonUniqueId | refedsNonPrivateUserID |
refedsPersonName | refedsPersonName |
displayName | refedsPersonName |
refedsEmailAddress | refedsEmailAddress |
mail | refedsEmailAddress |
All other attributes listed in Service Provider metadata are out of scope with respect to this specification.
8. Examples
Example 1. The R&S Service Provider requests refedsNonPrivateUserID
, refedsPersonName
, and refedsEmailAddress
in metadata.
An Identity Provider that supports R&S releases the full R&S bundle (refedsNonPrivateUserID
, refedsPersonName
, and refedsEmailAddress
).
Example 2. The R&S Service Provider requests eduPersonUniqueId
, displayName
, and mail
in metadata.
An Identity Provider that supports R&S releases the full R&S bundle (refedsNonPrivateUserID
, refedsPersonName
, and refedsEmailAddress
). Compare with the previous example.
Example 3. The R&S Service Provider requests refedsNonPrivateUserID
and refedsEmailAddress
in metadata.
An Identity Provider that supports R&S releases at least refedsNonPrivateUserID
and refedsEmailAddress
. Some Identity Providers will release refedsPersonName
as well. Presumably this latter group of Identity Providers do not filter on requested attributes in metadata.
Example 4. The R&S Service Provider requests refedsEmailAddress
in metadata.
An Identity Provider that supports R&S releases at least the refedsEmailAddress
attribute. Some Identity Providers, even those that filter on requested attributes in metadata, may release refedsNonPrivateUserID
as well.
Note | ||
---|---|---|
| ||
Registrars should discourage R&S Service Providers from relying on an email address as a user identifier. |
Example 5. The R&S Service Provider requests refedsUserID
in metadata.
An Identity Provider that supports R&S releases at least the refedsNonPrivateUserID
attribute. Other Identity Providers may release any persistent, non-reassigned user identifier, including refedsPrivateUserID
(i.e., eduPersonTargetedID
) but this is out of scope with respect to this specificationwithout regard for any R&S attributes requested in Service Provider metadata.
...
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
...