...
comment # | Line/Reference # | Proposed Change or Query | Proposer / Affiliation | Action / Decision (please leave blank) | |||
---|---|---|---|---|---|---|---|
1 | 150-151 | ? | |||||
2 | 77-82 | The 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 consultant | The Working Group (WG) agreed with this proposed change. | |||
3 | 232 | In 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 consultant | The 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. | |||
4 | general | Thanks 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 Federation | Thank 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. | |||
5 | comment 1 and 2 | +1. I agree with david on both of these points. | John Scullen / Australian Access Federation | See responses to 2 and 3 above. | |||
6 | 4-10 | I'm not entirely happy with this redraft but suggest the following as an introductory paragraph: 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 Federation | After discussing, the WG agreed that the word 'confidence' is better than 'certainty', and made commensurate changes. | |||
7 | 11 | orthogonal → independent | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
8 | 16 | delete "with the arbitrary names" | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
9 | 16 | cover → encapsulate | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
10 | 16-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 Federation | The WG agreed and incorporated the proposed change. | |||
11 | 19-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 Federation | The WG agreed and incorporated the proposed change. | |||
12 | 74-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 Federation | The 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” | |||
13 | 78-79 | Delete: "In a federated environment". I think we've adequately scoped this in the introduction. No need to keep repeating it. | John Scullen / Australian Access Federation | WG 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. | |||
14 | 81 | This framework → The REFEDS Assurance Framework | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
15 | 83-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 Federation | The WG agreed and incorporated the proposed change. WG also deleted the verbiage 'a method to' in lines 83,85, and 90. | |||
16 | 85-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 Federation | The WG agreed and incorporated the proposed change. | |||
17 | 90-91 | Revise to: Attribute Assurance - communicates to the RP the quality and freshness of attributes (other than the unique identifier). | John Scullen / Australian Access Federation | The 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." | |||
18 | 92-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 Federation | The WG discussed and ultimately voted to keep the original text. However, the WG did change the original wording of 'certainty' to 'confidence'. | |||
19 | 105-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 Federation | After WG discussion, the WG decided to keep the original wording. | |||
20 | 109 | transport → transit | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
21 | 109-110 | Revise to: For example, the assertion response should be signed using a certificate known and trusted by the RP. | John Scullen / Australian Access Federation | The 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. | |||
22 | 111 | Revise to: The REFEDS Assurance Framework (RAF 2.0) has two purposes: | John Scullen / Australian Access Federation | The 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. | |||
23 | 112, 114 | Numbered paragraphs as 1. and 2. rather than using dot points. | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
24 | 118 - meaning of Registrar | Revise to: A person carrying out the identity proofing process for the CSP organisation. | John Scullen / Australian Access Federation | WG agreed, and added a "Registrar" definition, and changed 'executing' with 'carrying out'. | |||
25 | 118 - meaning of Unsupervised Remote Proofing | Revise after "Unsupervised Remove Proofing processes may be:" to:
An identity proofing process may use a combination of manual and not automated unsupervised remote proofing. | John Scullen / Australian Access Federation | The WG discussed, but ultimately decided to keep the original wording. | |||
26 | 124-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 Federation | WG 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:” | |||
27 | 125 | Include link/reference to [REFEDS Baseline Expectations for Identity Provider Operators](https://refeds.org/baseline-expectations) | John Scullen / Australian Access Federation | WG agreed. Good catch. Added to references. | |||
28 | 172 | Delete "The components are orthogonal; therefore,". Doesn't add any extra meaning. | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
29 | 184 - 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 | John Scullen / Australian Access Federation | WG 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. | |||
30 | 188 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 Federation | WG 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. | |||
31 | 213, 118 | I 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 Federation | WG discussed and agreed; decided to add them to the definitions with “see section 1”. Also capitalize in lines 12-14. | |||
32 | 215 | Delete "sets of" | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
33 | 216 | Delete "set(s) of" | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
34 | 244, GR3, last dot point | Space missing: "Claimantand" → "Claimant and" | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. Good catch. | |||
35 | 244, VA4, 2 | This 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 Federation | WG 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." | |||
36 | 244, VA4, 3 | Should "person" be "Person"? | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. Good catch. | |||
37 | 244, 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 Federation | The WG agrees, but ultimately decided not to change the text, so as not to be overly prescriptive as standards change and evolve. | |||
38 | 244, VA4, 3 | I'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 Federation | This 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. | |||
39 | 244, AB3 | Is it worth making explicit that evidence of delivery to the Claimant should be recorded (e.g. signature)? | John Scullen / Australian Access Federation | WG 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. | |||
40 | 244, 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 Federation | WG decided not to change the wording. 'Trusted source' is intentionally open to adapt to a multiplicity of cultural and national contexts. | |||
41 | 278-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 Federation | There 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. | |||
42 | 330-332 | Add: 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). | |||
43 | 373-374 | Revise 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 Federation | WG agrees proposed change is clearer and made the change. | |||
44 | 377 | below → following | John Scullen / Australian Access Federation | WG agrees to change and also capitalised ‘Implications’ in this section. | |||
45 | 380 | "find itself having" → need | John Scullen / Australian Access Federation | The WG agreed and incorporated the proposed change. | |||
46 | 474-477 | Revise 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 Federation | WG 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. | |||
47 | 474-484 | Should 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 Federation | The WG agreed, and moved these definitions to the glossary, and changed this paragraph to just list the fundamental concepts. | |||
48 | 525-528 | Revise 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 Federation | The 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. | |||
49 | 540 | delete "its" | John Scullen / Australian Access Federation | WG agreed with change. | |||
50 | 550-551 | replace: with: | John Scullen / Australian Access Federation | WG agreed change is needed; revised to ""IAP high adds one requirement". | |||
51 | 560 | Revise: To: | John Scullen / Australian Access Federation | WG agrees and adopted. This is simpler language. | |||
52 | 560-562 | Revise: To: | John Scullen / Australian Access Federation | WG 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. “ | |||
53 | 562-563 | Revise: To: | John Scullen / Australian Access Federation | WG agrees with this change. | |||
54 | 567 | "check for Personhood" → "confirm the Claimant is a Person" | John Scullen / Australian Access Federation | WG agrees (ref comment 52). | |||
55 | 573-575 | Same comments apply as for comment 35. | John Scullen / Australian Access Federation | As 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. | |||
56 | 580 | "." → ":" at the end of the line | John Scullen / Australian Access Federation | WG decided not to make the change. | |||
57 | 581 and 584 | Number these paragraphs as 1. and 2. | John Scullen / Australian Access Federation | WG decided to reject numbering the primary paragraphs in this informative section. | |||
58 | 585 and 588 | Change (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 Federation | WG agreed, and made the existing numbered list into a readable bullet indented style. | |||
59 | 588 | Revise to: | John Scullen / Australian Access Federation | WG agreed, and made the existing numbered list into a readable bullet indented style. | |||
60 | 596-597 | Revise from the comma to: "but instead articulates functional requirements in that are relevant across international contexts and as technologies evolve." | John Scullen / Australian Access Federation | WG discussed, but consensus was to keep the original wording. | |||
61 | 598-601 | Revise 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 Federation | WG 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’. | |||
62 | 605 | "a known and" → "an" | John Scullen / Australian Access Federation | WG agrees with and adopted this change. | |||
63 | 606 | "and" → "if" | John Scullen / Australian Access Federation | WG 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. | |||
64 | 607-608 | Revise: To: | John Scullen / Australian Access Federation | WG agrees with and adopted this change. | |||
65 | 610-611 | Revise: to: | John Scullen / Australian Access Federation | WG agrees with and adopted this change. | |||
66 | 633-634 | Revise to: | John Scullen / Australian Access Federation | WG agrees with and adopted this change. | |||
67 | 642 | Delete: "each of" | John Scullen / Australian Access Federation | WG agrees with and adopted this change. | |||
68 | 652 | Add 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." | |||
69 | 653 | "each such service" → "these services" | John Scullen / Australian Access Federation | Agreed and incorporated into edits from comment 68. | |||
70 | 653-657 | Revise: To: | John Scullen / Australian Access Federation | Agreed and incorporated into edits from comment 68. | |||
71 | 659-660 | Revise first sentence to: "This framework does not explicitly require a government-issued photo ID." | John Scullen / Australian Access Federation | WG agreed with proposed change, and changed follow on sentence from "The reason is simply" to "This is." | |||
72 | 660 | "simply because" → "that" | John Scullen / Australian Access Federation | WG agreed; revision from comment 71 applies. | |||
73 | 664-665 | "do not implement things in the same way" → "use different approaches and standards" | John Scullen / Australian Access Federation | WG 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”. " | |||
74 | 666-668 | Revise 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 Federation | WG 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." | |||
75 | 669-671 | Revise 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 Federation | WG 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." | |||
76 | 672-673 | Revise to: ' "Presented evidence" implies the Claimant must present the evidence themselves.' | John Scullen / Australian Access Federation | WG discussed and consensus was the proposed change breaks the logical flow of the paragraph; decided to keep original wording. | |||
77 | 674 | "have implemented" → "adopt" | John Scullen / Australian Access Federation | WG 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. | |||
78 | 676 | Revise heading to: " Appendix C: Example assurance values" | John Scullen / Australian Access Federation | WG agreed and incorporated the change; also made the heading into Title Case. | |||
79 | 690 | In 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 Federation | WG 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’." | |||
80 | 19 | "IAP" Spell out on first use then abbreviate. | Nick Rossow / Australian Access Federation | WG agrees with change. | |||
81 | 244/GR1 | GR1 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/REANNZ | WG 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. | |||
82 | 244/UR1 | It 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/REANNZ | Thanks 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-AAI | 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-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' |
84 | 244/GR3 | Are there any means by which the records can be requested in case of an incident? | Anders Sjöström NeIC/Puhuri | WG 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. |