About released attributes
Released attributes
The following OpenAthens attributes are released to all service providers by default:
| Attribute | Released as | Associated with | Notes |
|---|---|---|---|
| Persistent user identifier | persistentUID | Accounts | A legacy pseudonymous user identifier generated by the system. This attribute is deprecated and has been replaced by Unique ID. It is only released by default by domains created before May 2021. |
| Unique ID | urn:oid:1.3.6.1.4.1.5923.1.1.1.13 | Accounts | A persistent user identifier. Includes the organisation's 'scope' - e.g. yn6uxrtfy5emfk6jq2v5rw6t3u@yourdomain.com |
| Organisation ID | organisationNum | The domain organisation (usually) | A legacy numeric identifier for the user's organisation. |
| Role | urn:oid:1.3.6.1.4.1.5923.1.1.1.1 | Permission sets | E.g. member, staff, alum, etc. Defaults to member. Can be set as blank, but usually shouldn't be. |
| Role (scoped) | urn:oid:1.3.6.1.4.1.5923.1.1.1.9 | Permission sets | The role attribute but the organisation's 'scope' is included - e.g. member@yourdomain.com |
| Entitlement | urn:oid:1.3.6.1.4.1.5923.1.1.1.7 | Permission sets | A general purpose attribute that could be used for several purposes - e.g. identifying departments, or special types of user. It has a per-service component so can have different values for each resource. This attribute is not used by many services so does not often need to be set at all. |
| Targeted ID | urn:oid:1.3.6.1.4.1.5923.1.1.1.10 | Accounts | A pseudonymous user identifier generated by the system. Each service sees a different value for the same account, but the value is consistent for the same service. |
These are used for authorisation activities - i.e. so that the service provider can link a user to your subscription with them and provide the content. You should not remove them from your global release policy as this is likely to break access for your users.
Additional attributes can be released via release policy if you need to.
What are they for?
The default released attributes are all there to handle authorisation by services and should cover most situations. You should not remove them from your global release policy.
The other releasable attributes might be useful to a service for things such as personalisation, or avoiding the requirement for users to fill in those details on first access to a site. A common example of this has long been a VLE, but it is becoming common for remote service providers to request these details from users too and providing them as attributes could smooth your users' journey (subject to data protection and privacy considerations).
There is also the facility to create custom attributes for release and these can be released as any name that you and the service provider agree.
Anything to watch out for?
You should of course check your local laws, policies and user-agreements before releasing additional attributes. If the service provider in question only supports the older SAML 1.x standard then information cannot be transmitted as securely and this may affect your choices.
If you remove the default attributes from your global policy you are unlikely to be able to gain access to any content.