Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Provided comment through item 84

...

comment #Line/Reference #Proposed Change or QueryProposer / AffiliationAction / Decision (please leave blank)
1150-151

?
277-82The definition of CSP in this paragraph doesn't align well with that on page 4, and (I think) page 4 better represents what this document means by "CSP" (i.e., the organization's whole technical and organizational infrastructure for IAM). I suggest removing "...the central part of..." from that paragraph.David Walker / independent consultantThe Working Group (WG) agreed with this proposed change.
3232In the definition of "low," the issue is not really when an identity is self-asserted, but rather whether it was validated and verified. I suggest rewording the first sentence to ""The bearer of this claim is a Person with an identity that has not necessarily been validated and verified (i.e., a self-asserted identity).David Walker / independent consultantThe WG understand your perspective; however after discussion we agreed to keep the statements positive rather than mixing in negative ones, to keep the style consistent. We kept the original wording.
4generalThanks to the authors for your work to date. Overall, v2 is a big improvement and I think you've achieved the objectives outlined. This is both technical and abstract and I acknowledge that English is often not the author's native language. Great job! 👏 I'm going to add a lot of comments below but hopefully it will improve readability and clarity. Please don't take it as criticism.John Scullen / Australian Access FederationThank you so much for the diligent feedback! The Working Group has discussed all the submitted comments, and will be posting responses to each in the upcoming days (this statement posted 29 Sep 2023). We spent time discussing each comment, and attempted to be as mindful as possible whether to accept the proposed change, keep the original wording, or if the proposed change pointed out an underlying point of confusion, we may have adjusted the text an a different way.
5comment 1 and 2+1. I agree with david on both of these points.John Scullen / Australian Access FederationSee responses to 2 and 3 above.
64-10

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.

John Scullen / Australian Access FederationAfter discussing, the WG agreed that the word 'confidence' is better than 'certainty', and made commensurate changes.
711orthogonal → independentJohn Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
816delete "with the arbitrary names"John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
916cover → encapsulateJohn Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
1016-18

Revise final sentence to:

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

John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
1119-22

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.

John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
1274-76

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.

John Scullen / Australian Access FederationThe WG discussed this and felt the suggested revision too narrowly represents what is addressed in RAF 2.0 (it mentions only identity assurance). However, we agreed the existing wording might be confusing, and amended it to: “This document provides a framework by which a Credential Service Provider (CSP) asserts claims to an RP's service about its confidence in the values of selected user attributes”
1378-79Delete: "In a federated environment". I think we've adequately scoped this in the introduction. No need to keep repeating it.John Scullen / Australian Access FederationWG discussed... while considering these revisions, we also had to look at how one revision might affect the flow with other proposed revisions. Given that for comment 12 we deleted 'federation protocols', the WG felt it was best to keep the original text here.
1481This framework → The REFEDS Assurance FrameworkJohn Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
1583-84

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.

John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change. WG also deleted the verbiage 'a method to' in lines 83,85, and 90.
1685-89

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).

John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
1790-91

Revise to:

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

John Scullen / Australian Access FederationThe WG agreed in part with this. The WG revised the text to "Attribute Assurance - communicates to the RP the quality and freshness of attributes (other than the unique identifier) passed in the login assertion."
1892-101

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.

John Scullen / Australian Access FederationThe WG discussed and ultimately voted to keep the original text. However, the WG did change the original wording of 'certainty' to 'confidence'.
19105-107

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.

John Scullen / Australian Access FederationAfter WG discussion, the WG decided to keep the original wording.
20109transport → transitJohn Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
21109-110

Revise to:

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

John Scullen / Australian Access FederationThe WG discussed this for several sessions. We decided to keep the original text because it is an example in an informative piece of text. Making it more generic might have lost the purpose of providing an example, or lead to a desire to exhaust all possible examples (e.g., OIDC). The WG ultimately felt that wasn't necessary here.
22111

Revise to:

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

John Scullen / Australian Access FederationThe WG discussed, but decided to keep the original text. The purpose or RAF 2.0 framework itself is larger than the purpose that drove to a revision.
23112, 114Numbered paragraphs as 1. and 2. rather than using dot points.John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
24118 - meaning of Registrar

Revise to:

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

John Scullen / Australian Access FederationWG agreed, and added a "Registrar" definition, and changed 'executing' with 'carrying out'.
25118 - meaning of Unsupervised Remote Proofing

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.

John Scullen / Australian Access FederationThe WG discussed, but ultimately decided to keep the original wording.
26124-125

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:

John Scullen / Australian Access FederationWG agreed with this change. WG incorporated the change but also changed word from REQUIRED to MUST: “A CSP MUST conform to the following REFEDS Baseline Expectations for Identity Provider Operators in order to conform to the REFEDS Assurance Framework:”
27125Include link/reference to [REFEDS Baseline Expectations for Identity Provider Operators](https://refeds.org/baseline-expectationsJohn Scullen / Australian Access FederationWG agreed. Good catch. Added to references.
28172Delete "The components are orthogonal; therefore,". Doesn't add any extra meaning.John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
29184 - UN3

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 

John Scullen / Australian Access FederationWG discussed and came to consensus that no change is needed. One point of discussion highlighted that the framework is not making claims about future behavior. [UN3] implies that ID/unique declares that identifier will never be assigned to another Person - that’s more stringent than ceasing to assert ID/unique upon its reassignment. [UN3] need not imply that the identifier has always been assigned to the present Person.
30188 and 195-209

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?

John Scullen / Australian Access FederationWG discussed, and consensus agreed this is out of scope. There are better options, but addressing ePPN or documenting alternatives is out of scope of this framework.
31213, 118I expected "Identity Assurance" to be a defined term in 118 because of the capitalisation but it doesn't appear in the table. John Scullen / Australian Access FederationWG discussed and agreed; decided to add them to the definitions with “see section 1”. Also capitalize in lines 12-14.
32215Delete "sets of"John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
33216Delete "set(s) of"John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
34244, GR3, last dot pointSpace missing: "Claimantand" → "Claimant and"John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change. Good catch.
35244, VA4, 2This seem a bit vague and open to interpretation. Maybe it needs examples or some criteria about the kinds of attributes to look for (e.g. matching name, address, or date of birth to other evidence presented)John Scullen / Australian Access FederationWG agrees with the observation. We tried to provide some degree of flexibility so that RAF 2.0 might fit circumstances in many different contexts (e.g., different national paradigms), and we don't want to be too prescriptive. We appreciated that the text was not ideal, so thanks for bringing this to our attention. We revised the wording to improve readability.
We rewrote VA4 to change verb ‘document’ to ‘confirm’ in the transactions case to: The registrar confirms the presence of the claimed identity in transaction records of a recognized organisation providing financial, educational, or utility services."
36244, VA4, 3Should "person" be "Person"?John Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change. Good catch.
37244, VA4, 3"in a trusted manner". This seems open to in and could lead to practices that make this method less robust depending on what the CSP considers to be trusted.John Scullen / Australian Access FederationThe WG agrees, but ultimately decided not to change the text, so as not to be overly prescriptive as standards change and evolve.
38244, VA4, 3I'm not sure how comfortable I am with vouching as validation check for IAP high. For access to identifiable human genomic data I'm not sure this is robust enough. Maybe there is a case for IAP very high in a future RAF version.John Scullen / Australian Access FederationThis is a good point. The WG decided to keep the wording, and wanted to share the rationale. The first point is to realize that RAF IAP high only approaches the 'medium' levels in eIDAS and NIST (as described in Appendix A.2 of this document). One should not equate RAF High with the highest levels of assurance in nationally prescribed standards. We do not feel, for example, that RAF High would be sufficient for highly sensitive medical information, such as a person's genomic data. In crafting RAF 2.0, one of the tangential goals was to close the gap with NIST's IAL-2 (the moderate level). It would not be sufficient for a a FISMA High system requiring IAL-3.
39244, AB3Is it worth making explicit that evidence of delivery to the Claimant should be recorded (e.g. signature)?John Scullen / Australian Access FederationWG discussed and consensus landed on not changing the wording. Note that this is eIDAS text, and other ways may not use a signature; but those are certainly ways to meet this requirement. GR3 addresses record-keeping.
40244, UR1"trusted source is defined in VA4". I don't think it's defined very well though (see also comment 37). Trusted sources seem very open to interpretation. Maybe adding some example use cases of sources that may be trusted in different contexts might help. This could probably go in an appendix with reference from the main part of the document.John Scullen / Australian Access FederationWG decided not to change the wording. 'Trusted source' is intentionally open to adapt to a multiplicity of cultural and national contexts.
41278-279

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.

John Scullen / Australian Access FederationThere was some discussion on this, but ultimately the WG agreed with the proposal. WG added ‘staff’ and ‘employee’, and also noted the difference in the versioning text.
42330-332Add: For further information see the REFEDS Must-Factor Authentication Profile and REFEDS Single Factor Authentication Profile. (and include links to the specs)John Scullen / Australian Access Federation

WG agrees with the underlying point… added “for example, look at…” (we chose not to link in the original spec in case the frameworks change, or titles change).

43373-374Revise to: RAF 1.0 is not deprecated. However, some RPs may require assurance using RAF 2.0 criteria over RAF 1.0 criteria.
 
John Scullen / Australian Access FederationWG agrees proposed change is clearer and made the change.
44377below → followingJohn Scullen / Australian Access FederationWG agrees to change and also capitalised ‘Implications’ in this section.
45380"find itself having" → needJohn Scullen / Australian Access FederationThe WG agreed and incorporated the proposed change.
46474-477Revise to: 

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.

John Scullen / Australian Access FederationWG discussed, but consensus was to keep the original text. This is informative text. The WG felt that the revision might be interpreted as both parts are required, and notes that this is an example list.
47474-484Should these definitions be moved to the Terms and Definitions table (118)? They are used throughout the document and might be better placed there since they are used more widely than in the context of Appendix B. For this reason I think section 2 is a better home for them.John Scullen / Australian Access FederationThe WG agreed,  and moved these definitions to the glossary, and changed this paragraph to just list the fundamental concepts.
48525-528Revise complete sentence to: 

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

John Scullen / Australian Access FederationThe WG agreed this needs revision. The WG felt original is a clear either/or construct, while the proposed revision suggests that the first 2 requirements are compounded. But, revision is warranted. Revised to "The identity evidence presented must be valid (i.e., unexpired) at the time of identity proofing. The evidence presented must be either: (a) issued by a nationally recognized source, (b) or a document nationally recognized as being valid for identification purposes, (c) or a documented attestation of knowledge of their identity from an authority recognized by the CSP." → and formatted this as a bulleted list for reading clarity.
49540delete "its"John Scullen / Australian Access FederationWG agreed with change.
50550-551

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:" 

John Scullen / Australian Access FederationWG agreed change is needed; revised to ""IAP high adds one requirement".
51560

Revise:
"achieve that assurance of Personhood."

To:
"confirm the Claimant is a Person."

John Scullen / Australian Access FederationWG agrees and adopted. This is simpler language.
52560-562

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.

John Scullen / Australian Access FederationWG agreed this needs revision. WG felt the proposed change didn't quite capture the essence of the original text's intent, but appreciated bringing attention to  clunky text in need of wordsmithing. WG revised the document to read: “When the process is in-person, this is a trivial requirement in that the Registrar’s interaction with the Claimant face to face confirms the Claimant is a Person. “
53562-563

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."

John Scullen / Australian Access FederationWG agrees with this change.
54567"check for Personhood" → "confirm the Claimant is a Person"John Scullen / Australian Access FederationWG agrees (ref comment 52).
55573-575Same comments apply as for comment 35.John Scullen / Australian Access FederationAs discussed in comment 35, the WG was intentionally broad in some language to allow for variations in how the international community and different nations' systems' implementations vary. WG appreciated bringing attention to this, and tried to revise for further clarity. WG 

rewrote VA4 to change verb ‘document’ to ‘confirm’ in the transactions case to: The Registrar confirms the presence of the claimed identity in transaction records of a recognized organisation providing financial, educational, or utility services. Also updated lines 573-575 to reflect this change in VA4.

56580"." → ":" at the end of the lineJohn Scullen / Australian Access FederationWG decided not to make the change.
57581 and 584Number these paragraphs as 1. and 2.John Scullen / Australian Access FederationWG decided to reject numbering the primary paragraphs in this informative section.
58585 and 588Change (1) to (a) and (2) to (b) if you add numbers as recommended in comment 57. It would be a less dense paragraph if these were formatted as sub-points too.John Scullen / Australian Access FederationWG agreed, and made the existing numbered list into a readable bullet indented style.
59588

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

John Scullen / Australian Access FederationWG agreed, and made the existing numbered list into a readable bullet indented style.
60596-597Revise from the comma to:
"but instead articulates functional requirements in that are relevant across international contexts and as technologies evolve."
John Scullen / Australian Access FederationWG discussed, but consensus was to keep the original wording.
61598-601Revise to:
"This section is intended to provide illustrative examples and discussion illustrating how to implement RAF. These examples and discussion points show how to interpret the normative criteria for implementation, but are not intended to be exhaustive."
John Scullen / Australian Access FederationWG discussed, and preferred neither the original wording nor the change as proposed. This prompted discussion which lead to a revision to enhance readability and clarity. 

Changed first sentence to: "This section is intended to provide illustrative examples and discussion of how to implement RAF." Second sentence only changed ‘exhaustive’ to  ‘comprehensive’.

62605"a known and" → "an"John Scullen / Australian Access FederationWG agrees with and adopted this change.
63606

"and" → "if"

John Scullen / Australian Access FederationWG discussed, and felt that in terms of logical expression, 'and' is the correct operator to require both expressions to be true. WG decided to remain with original text.
64607-608

Revise:
"done by the Claimant demonstrating authentication with"

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

John Scullen / Australian Access FederationWG agrees with and adopted this change.
65610-611

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

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

John Scullen / Australian Access FederationWG agrees with and adopted this change.
66633-634

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)."

John Scullen / Australian Access FederationWG agrees with and adopted this change.
67642Delete: "each of"John Scullen / Australian Access FederationWG agrees with and adopted this change.
68652Add comma after "proofing process"John Scullen / Australian Access Federation

WG discussed.. adding a comma shifts where the prepositional phrase is. However, discussion drove a revision of this part of the text. Splitting into two sentences as described below.

Line 647-657 replacement:

"Validation and verification during an unsupervised remote identity proofing session may need to rely on special purpose systems designed to perform validation checks of identity evidence and to verify that the Person being proofed matches a photo on a piece of validated identity evidence. Such systems are becoming increasingly available in some jurisdictions.

For example, in the US, the Kantara Initiative assesses commercial providers of such services Kantara’s Trust Status List [Kantara TSL] identifies these services. These, together with 3rd parties identified in supporting material 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."

69653"each such service" → "these services"John Scullen / Australian Access FederationAgreed and incorporated into edits from comment 68.
70653-657

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."

John Scullen / Australian Access FederationAgreed and incorporated into edits from comment 68.
71659-660Revise first sentence to:
"This framework does not explicitly require a government-issued photo ID."
John Scullen / Australian Access FederationWG agreed with proposed change, and changed follow on sentence from "The reason is simply" to "This is."
72660"simply because" → "that"John Scullen / Australian Access FederationWG agreed; revision from comment 71 applies.
73664-665"do not implement things in the same way" → "use different approaches and standards"John Scullen / Australian Access FederationWG accepts the original language is awkward. Discussion led to the following revision: " Given that technology evolves and different nations may have different approaches and standards, the RAF framework attempts to state “what” is required at an assurance level without prescribing “how”. "
74666-668Revise second sentence to:
"The easiest way to meet IAP medium in-person requirements is to compare a photo on the identity evidence with the Person."
John Scullen / Australian Access FederationWG accepts the original language is awkward. Discussion led to the following revision: "

For example, in most in-person cases, the simplest way to meet IAP medium requirements is to compare a government-issued Photo ID with the Person."

75669-671Revise to:
"For nations that do not have robust national-level identity infrastructure, a government-issued photo ID may be the only evidence that enables the Registrar to meet all the validation and verification requirements."
John Scullen / Australian Access FederationWG accepts the original language is awkward. Discussion led to the following revision: "For nations that do not have robust national-level identity infrastructure, a government-issued photo ID may be the only evidence that enables the Registrar to easily meet all the validation and verification requirements."
76672-673Revise to:
' "Presented evidence" implies the Claimant must present the evidence themselves.'
John Scullen / Australian Access FederationWG discussed and consensus was the proposed change breaks the logical flow of the paragraph; decided to keep original wording.
77674"have implemented" → "adopt"John Scullen / Australian Access FederationWG discussed and consensus was to delete the word 'implemented', given that if they have a solution, it implies they have already implemented or adopted it.
78676Revise heading to:
" Appendix C: Example assurance values"
John Scullen / Australian Access FederationWG agreed and incorporated the change; also made the heading into Title Case.
79690In the "Reason" column it might be a good idea to cross referencing 5.2 to also include references to the GR, IE, VA, VF, AB and UR criteria where appropriate.John Scullen / Australian Access FederationWG discussed at length, but ultimately decided to reject the proposed change. Summary of discussion is: "adding the granular requirements makes this table too awkward, where the issue proposed is for just the identity proofing portion. Reference to 5.2.1 should direct reader to the ‘car chart’ for details (on identity proofing). Reference to 5.2 is a non-sequitur for all but three of the claims, and implementing High (as in this example) essentially sources nearly every requirement in the ‘car chart’."
8019

"IAP" Spell out on first use then abbreviate.


Nick Rossow / Australian Access FederationWG agrees with change.
81244/GR1GR1 requires that "The CSP takes measures to ensure that the Claimant accomplishing each step of the identity proofing and authenticator issuing process is the same Person throughout the process"

It is not clear how that can be fully achieved - there could be steps where another person could act on behalf of the Claimant - if they shared credentials, this would be impossible to detect.
Vlad Mencl / Tuakiri/REANNZWG discussed and decided to keep the original text. WG agreed this is a potential concern (especially if users are sharing credentials), but this is out of scope of this framework. This is also why we emphasise that if an RP requires IAP High, they should also be requiring complementary assurances such as MFA (non shareable credentials), as indicated in lines 102-107.
82244/UR1It is not clear what it means for contact information to "belong to the Claimant".  Would it be stronger then being "in control" of the contact channel.  Such as for a phone number, not only to be able to receive messages, but also be listed in a public phone directory as the owner?  Or for email, having it listed in institutional directory as belonging to the user?

Perhaps this should be made clearer.
Vlad Mencl / Tuakiri/REANNZThanks for bringing this to attention. The WG discussed in depth, and ultimately decided not to make a change. In developing RAF 2.0, the WG decided to avoid completely define ‘trusted source; it is intentionally left to adapt to a multiplicity of cultural and national contexts (see comment #40). It is left to the CSP to include what is the trusted source in its process documentation. The trusted source as described in VA4 checks against ownership, not control (given that a phone, for example, could be stolen and not owned). “Belonging to” (verified ownership) is stronger than being ‘in control of’. WG agrees that a public phone directory or institutional directory for email can be a trusted source to verify ‘ownership’ of the contact information.
83

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...

Wolfgang Pempe / DFN-AAI83

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...

Wolfgang Pempe / DFN-AAIThank you for pointing this out. WG discussed this at length. eIDAS is silent on additional requirements for Unsupervised Remote proofing, so we inferred an in-person requirement. Furthermore, in RAF 1.0, the WG had considered the possibility that an institution might use eIDAS standards to do their own ID proofing rather than leverage the eIDAS national infrastructure itself. We agreed this needs revision because the original text communicates an incorrect assumption. WG revised to a version of the following idea (subject to final edits prior to release): "eIDAS is silent on additional requirements for Unsupervise Remote processes, specifically [UR3]. Therefore, if the CSP has used the specific eIDAS paragraphs referenced by RAF 1.0 to make RAF 1.0 IAP claims, and is using Unsupervised Remote process, the CSP needs to check that the implementation satisfies the [UR3] requirement. Please also note Appendix A.2: if the CSP is leveraging users’ eIDs, then these checks need not be done." WG removed the text claiming that 'eIDAS was built around an in person principle'
84244/GR3Are there any means by which the records can be requested in case of an incident?Anders Sjöström NeIC/PuhuriWG discussed and confirmed that this security incident response is out of scope of this framework. There is another framework addressing security incident response and cooperation in federations; REFEDS Sirtfi (https://refeds.org/sirtfi). How records are requested and with whom they are shared will likely be governed by internal policies in addition to national requirement for privacy protect. Those things are important, but not in scope scope of RAF.