Page History

I'm not entirely happy with this redraft but suggest the following as an introductory paragraph: 

"In identity federations, Relying Parties (RP) grant access to services after users successfully authenticate to to their home organisation Identity Provider (IdP) using their institutional credentials. Identity Providers in turn rely on the home organisation's Credential Service Providers (CSP) to issue and manage user credentials. Each RP has a different risk profile and different thresholds of confidence regarding assertions made by IdPs in order to address the RP's operational risks. This REFEDS Assurance Framework specifies methods for expressing elements of identity assurance from the CSP for evaluation by the RP within research and education federations."

I think it's better to talk about "levels of confidence" rather than "certainty". Assurance is about collecting enough evidence to clear some threshold related to the risks in that particular situation. It's about having sufficient confidence rather than certainty.

Revise final sentence to:

This framework also specifies how to represent the defined claims using SAML 2.0 and OpenID Connect federated identity protocols.

Revise to:

Claims made on the basis of the original REFEDS Assurance Framework (RAF 1.0) can continue under the REFEDS Assurance Framework version 2.0 (RAF 2.0) with some exceptions for IAP process-based claims. Appendix A explains these exceptions and section 4 defines how to express IAP claims under both RAF 1.0 and RAF 2.0.

Revise to:

This document provides a framework by which a Credential Service Provider (CSP) asserts claims about identity assurance attributes in the process of authenticating to an RP's service.

Revise to:

Identifier Uniqueness - communicates to the RP that the user’s identifier (such as a login name) is unique and is bound to a single identity in the CSP’s context.

Revise to:

Identity Assurance - communicates to the RP how confident the CSP was at the time of enrollment, of the real-world identity of the Person to whom the account was issued. This framework specifies three levels of process-based identity assurance and authenticator management (low, medium and high) and one risk-based identity assurance claim (local-enterprise).

Revise to:

Attribute Assurance - communicates to the RP the quality and freshness of attributes (other than the unique identifier).

Revise to:

Since an RP trusts one or more external CSPs to issue and manage credentials, the RP must rely on the CSPs to help mitigate associated risks. The RP operator's assessment of the sensitivity of the data collected and processed by its information systems and infrastructure will influence how much risk is acceptable and the controls necessary to mitigate the risks. RPs need higher confidence in the quality of attributes and identities asserted by a CSP as the risk factors increase. This framework describes methods for communicating these levels of confidence in a federated login attribute assertion.

Revise to:

authentication needs to be sufficiently strong to confirm that the claims pertain to the person logging in. For example, if an RP determines that a service requires high identity assurance, it should also require MFA from the CSP for strong authentication assurance.

Revise to:

For example, the assertion response should be signed using a certificate known and trusted by the RP.

Revise to:

The REFEDS Assurance Framework (RAF 2.0) has two purposes:

Revise to:

A person carrying out the identity proofing process for the CSP organisation.

Revise after "Unsupervised Remove Proofing processes may be:" to:

1. manual, in which the CSP uses a Registrar to evaluate the application and perform any checks required after the time of the Claimant’s application, or

2. automated, where the CSP uses technology to process the claim and automate any required checks.

An identity proofing process may use a combination of manual and not automated unsupervised remote proofing.

Revise to:

A CSP is REQUIRED to conform to the following REFEDS Baseline Expectations for Identity Provider Operators in order to conform to the REFEDS Assurance Framework:

I'm not sure this is important, but the wording implies to me that the identifier has not been reassigned up to this point in time. There is potential that the identifier could be reassigned at some point in the future. Should this be revised to: "The identifier MUST NOT ever be reassigned"?

Perhaps it doesn't matter because if the identifier is reassigned at some future time they would have to stop asserting /ID/unique 

Probably not in the scope of this work, but do we need to revise [eduPerson] to address reassignment practices for ePPN? It seems a bit weird to paper over a hole in the original specification by creating what feels like a workaround in this this spec.

From all the commentary it sounds like ePPN is generally not reliable as a unique identifier. Do we have any better options?

Why are the attribute values limited to faculty, student, and member?

Faculty is rarely asserted in Australia but we almost always see staff and often employee too. Universities here understand who their staff are but have a harder time distinguishing between faculty vs general / professional roles.

I would like to see RAF broadened to include staff and employee. I acknowledge definitions vary between countries (highlighted in section 2.2.1 of the eduPerson spec but descoping staff and to a lesser extent, employee, substantially diminishes the value of RAF in the Australian context.

Identity evidence is any artefact that a Claimant presents to prove their identity. This includes: documentation such as a government- issued physical or digital identification document or record, and the ability to be validated and verified through a national registrar, or similar means.

The identity evidence presented must be valid at the time of identity proofing (e.g., unexpired), and the evidence must be: issued by a nationally recognized source; nationally recognized as valid evidence for identification purposes; or is a documented attestation of knowledge of the Claimant's identity from an authority recognized by the CSP

replace:
"IAP high levies one additional requirement for authenticator binding and issuance beyond the requirements in IAP medium and IAP low:"

with: 
"IAP high imposes the following requirements for authenticator binding and issuance in addition to the IAP medium and IAP low requirements:" 

Revise:
"achieve that assurance of Personhood."

To:
"confirm the Claimant is a Person."

Revise:
"When the process is in-person, this is a trivial requirement in that the Personhood is checked by virtue of the Registrar interacting with the Claimant face to face."

To:
"Face to face interaction with the Registrar automatically fulfils the requirements for in-person processes.

Revise:
"When the process is remote and unsupervised, then the CSP will need to consider how that requirement is to be fulfilled."

To:
"CSPs will need to determine how to fulfil the requirements when the process is remote and unsupervised."

Revise to:
"proofing process, or; (2) use an automated..."

"and" → "if"

Revise:
"done by the Claimant demonstrating authentication with"

To:
"demonstrated through successful authentication by the Claimant using"

Revise:
"When this approach is taken, criteria in the IE, VA, VF, and UR groups may be ignored."

to:
"Criteria in the IE, VA, VF, and UR groups may be ignored when this approach is used."

Revise to:
"Registrars will need to consider typical service standards in their location (e.g. longer postal delivery times may be needed in some locations)."

Revise:
"These, together with 3rd parties identified in material on their Trust Status List entries on which some of them rely in turn, provide a starting point for US based organisations thinking about implementing unsupervised remote identity proofing at IAP high. Some of those providers also operate outside of the US."

To:
"Together with 3rd parties identified in material on their Trust Status List entries, these services provide a starting point for US based organisations implementing unsupervised remote identity proofing at IAP high. Some providers also operate outside of the US."

"IAP" Spell out on first use then abbreviate.

244/UR3 +

394-397

I'm not sure if eIDAS is really built around an ‘in-person’ principle. If a claimant is identified by an (eGov-approved) eID-Server using an eID Token which is notfied as eIDAS LoA 'high', why would a CSP ever require an additional in-person check? Such a requirement would run completely counter to the basic idea of eIDAS  (IMHO, of course). I doubt that any German university would ever be able to assert IAP high...