Jimmy, I would like to add that we submitted the following in our comments to NIST on rev. 4 which highlights similar points - The requirements for validating and verifying an address are unclear,

especially as they relate to digital addresses. Addresses that are documented in the presented identity evidence are validated and verified through validation and verification of the evidence. Digital addresses (phone number or email) however, would generally not be present in a credential and would require a separate step for validation and verification and the standards are unclear as to how to perform the validation and verification.

First, attribute validation is defined in line 2205 of 800-63-4 as “*the process or act of confirming the a set of attributes are accurate and associated with a real-life identity*.“ Arguably, confirming the existence of a possessive attribute such as an address does not validate it as belonging to a real-life identity. But an applicant who demonstrates possession of a digital address has both validated that the address is associated with an identity and verified it as associated with their identity. This argument can be applied to enrollment codes to allow them to function as both validation and verification of a digital address. However, the enrollment code standards in Sec. 5.1.6(1) seem to require an enrollment code be sent to an already validated address.

Additionally, the requirements for proofing notifications in Sec. 5.1.7(1) say that a proofing notification must be sent to an address of record that is preferably not the one that received the enrollment code. In line 1607 of 800-63-4, an address of record is defined as “*The validated and verified location (physical or digital) where a subscriber can receive communications using approved mechanisms*.” Taken together, this implies the possiblity of having a digital address that was validated and verified without relying on an enrollment code. This possibility is also supported by the fact that the new standards only require proofing notifications for IAL2 identity proofing but do not require enrollment codes. However, the standards do not provide another method for validating and verifying these addresses other than via an enrollment code.

Best, Yehoshua On Thu, Nov 9, 2023 at 10:41 AM Richard G. WILSHER (@Zygma Inc.) < RGW@zygma.biz> wrote:

Having already had some discussion with Jimmy on this topic here’s an observation on the NIST defn of AoR: that it has to be ‘validated *and* verified’ (my stress) suggests that these are two different processes/actions which have to be accomploished, yet I have no clue as to how they might differ.

I can see that validating might be proving that the applicant has access to the AoR (I wouldn’t even say ‘control over’, and certainly not ‘exclusive control over’), but then that becomes somewhat circular. Its frankly a poor definition and I think perhaps the term should be withdrawn. That there be an address to which the applicant can be proven to have access for the purposes of communicating with the CSP ought be the pragmatic requirement, though I see that this does little to bolster any confidence in a claim of identity if there can be no sense of real association between the address and the applicant (I think the trendy term is ‘velocity’).

This is compounded by the fact that in NIST’s requirements for proofing practices, one *validates* the authenticity *of evidence* offered (T5-2) but one *verifies* *the applicant* against validated evidence (T5-3).

Roll on v4!! :-o

*Richard G. WILSHERCEO & Founder, Zygma Inc.www.Zygma.biz http://www.Zygma.biz+1 714 797 9942*

*From:* Jimmy Jung [mailto:jimmy.jung@slandala.com] *Sent:* Thursday, November 9, 2023 15:15 *To:* IAWG *Subject:* [WG-IDAssurance] Address of Record

Folks,

Under the heading of other-topics/open-discussion/items-we-may-not-get-to, I wanted to send the following regarding the address of record criteria in 63A. Below please find an inclusive extract of criteria regarding “address of record.” On several occasions, systems I have worked with have run into complications with “address of record,” and I had hoped to explore what is trying to accomplish by this criteria, as well as gain some context for reviewing the criteria as it evolves in 63 rev 4.

SP 800-63 formally defines “Address of Record” as “the validated and verified location (physical or digital) where an individual can receive communications using approved mechanisms.”

I would summarize 63 and the criteria for address of record as follows:

- You must validate the address of record with an issuing or authoritative source using information taken from the valid id evidence.

(address of record can't be self-asserted)

- 63A specifically calls out postal, mobile-phone (SMS), landline or email as potential addresses of record (with a preference for Postal) - For Unsupervised proofing you must send an enrollment code to the confirmed address of record, which the Applicant must return. (for Supervised you may) - If the enrollment code is also an authenticator it must be reset - "An enrollment code allows the CSP to confirm that the applicant controls an address of record, as well as offering the applicant the ability to reestablish binding to their enrollment record." - There are various limitations in the format, validity and attempts allowed for enrollment codes. - The enrollment code and notification of proofing must be sent to different addresses of record.

My confusion stems from the difficulty, if not inability to validate the email or quite frankly postal as an address of record with an issuing or authoritative source. Citing my favorite examples, google will not validate a gmail address and no one “issues” a postal address.

- We identify an applicant by comparing them to the evidence and validating and verifying the evidence. - As described by 63, we can use an enrollment code to confirm that the same applicant controls the address of record and confirm that the applicant can “receive communications” at that address. - But given that email (not postal) is the likely preferred address for most systems and applicants, especially unsupervised systems; validating an email address with an issuing or authoritative source is very difficult. - and I am unsure of the utility – if the applicant controls the address and we have identified the applicant, how useful is it to validate an address of record?

- Also, if supervised doesn’t use an enrollment code to confirm control, then we would be sending notifications to an unvalidated address.

- And, if validating an address of record is so difficult; isn’t it that much more difficult to have two; so that you may send the “enrollment code and notification of proofing to different addresses of record”.

(often the different addresses are the web-site/application performing the identification and an email address)

- And just for fun, can you send an enrollment code to an address of record, if an address of record isn’t an address of record until the applicant returns the enrollment code?

Thanks

Jimmy

Jimmy Jung

*www.Slandala.com http://www.slandala.com/*

703 851 6813

*§*

*(..)*

*Clause title*

*Requirement*

*63A tag*

*index*

*KI_criterion(text in red in this column are revisions this version)*

*2*

*3*

4.4.1.6 (IAL2)

1

Address Confirmation

Valid records to confirm address SHALL be issuing source(s) or authoritative source(s).

*n/a*

4.4.1.6 (IAL2)

2

Address Confirmation

The CSP SHALL confirm address of record. The CSP SHOULD confirm address of record through validation of the address contained on any supplied, valid piece of identity evidence. The CSP MAY confirm address of record by validating information supplied by the applicant that is not contained on any supplied piece of identity evidence.

*63A#0270*

*The CSP SHALL validate and confirm the Applicant's address of record by relying only upon issuing source(s) or authoritative source(s).*

ü

ü

4.4.1.6 (IAL2)

3

Address Confirmation

Self-asserted address data that has not been confirmed in records SHALL NOT be used for confirmation.

*63A#0280*

*The CSP SHALL NOT accept un-validated self-asserted addresses.*

ü

ü

4.4.1.6 (IAL2)

4

Address Confirmation

If CSP performs in-person proofing (physical or supervised remote):

*63A#0290*

*If the CSP performs Supervised (In-person or Remote) proofing it SHALL document the maximum validities it allows for enrollment codes and only issue codes that meet that limitation, which SHALL NOT exceed 7 days.*

ü

ü

4.4.1.6 (IAL2)

4

Address Confirmation

The CSP SHOULD send a notification of proofing to a confirmed address of record.

*n/a*

4.4.1.6 (IAL2)

4

Address Confirmation

The CSP MAY provide an enrollment code directly to the subscriber if binding to an authenticator will occur at a later time.

*n/a*

4.4.1.6 (IAL2)

4

Address Confirmation

The enrollment code SHALL be valid for a maximum of 7 days.

*n/a*

*See 63A#0290*

4.4.1.6 (IAL2)

5

Address Confirmation

If the CSP performs remote proofing (unsupervised):

*63A#0300*

*If the CSP performs Unsupervised proofing it SHALL:*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

The CSP SHALL send an enrollment code to a confirmed address of record for the applicant.

*63A#0300*

*a)*

*send an enrollment code to a confirmed address of record for the Applicant;*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

The applicant SHALL present a valid enrollment code to complete the identity proofing process.

*63A#0300*

*b)*

*require the Applicant to present a valid enrollment code to complete the identity proofing process;*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

The CSP SHOULD send the enrollment code to the postal address that has been validated in records. The CSP MAY send the enrollment code to a mobile telephone (SMS or voice), landline telephone, or email if it has been validated in records.

*n/a*

4.4.1.6 (IAL2)

5

Address Confirmation

If the enrollment code is also intended to be an authentication factor, it SHALL be reset upon first use.

*63A#0300*

*c)*

*If the enrollment code is also intended to be an authentication factor, reset the code upon first use;*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

Enrollment codes SHALL have the following maximum validities:

*63A#0300*

*d)*

*document the maximum validities it allows for enrollment codes and only issue codes that meet the following limitations:*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

10 days when sent to a postal address of record within the contiguous United States;

*63A#0300*

*d)*

*i)*

*10 days, when sent to a postal address of record within the contiguous United States;*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

30 days when sent to a postal address of record outside the contiguous United States;

*63A#0300*

*d)*

*ii)*

*30 days, when sent to a postal address of record outside the contiguous United States;*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

10 minutes when sent to a telephone of record (SMS or voice);

*63A#0300*

*d)*

*iii)*

*10 minutes, when sent to a telephone number of record (SMS or voice);*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

24 hours when sent to an email address of record.

*63A#0300*

*d)*

*iv)*

*24 hours, when sent to an email address of record.*

ü

4.4.1.6 (IAL2)

5

Address Confirmation

The CSP SHALL ensure the enrollment code and notification of proofing are sent to different addresses of record. For example, if the CSP sends an enrollment code to a phone number validated in records, a proofing notification will be sent to the postal address validated in records or obtained from validated and verified evidence, such as a driver's license.

*63A#0300*

*e)*

*ensure that the enrollment code and notification of proofing are sent to different addresses of record.*

ü

4.4.1.6 (IAL2)

Note

Address Confirmation

Postal address is the preferred method of sending any communications, including enrollment code and notifications, with the applicant. However, these guidelines support any confirmed address of record, whether physical or digital.

*n/a*

4.5.6 (IAL3)

1

Address Confirmation

The CSP SHALL confirm address of record. The CSP SHOULD confirm address of record through validation of the address contained on any supplied, valid piece of identity evidence. The CSP MAY confirm address of record by validating information supplied by the applicant, not contained on any supplied, valid piece of identity evidence.

*63A#0390*

*The CSP SHALL confirm the Applicant's address of record using either:*

ü

4.5.6 (IAL3)

Address Confirmation

*63A#0390*

*a)*

*only information taken from any piece of valid identity evidence; or*

ü

4.5.6 (IAL3)

Address Confirmation

*63A#0390*

*b)*

*for information values which might reasonably be amended from time-to-time, information substituted by the Applicant which SHALL be validated with the issuing source of the information.*

ü

4.5.6 (IAL3)

3

Address Confirmation

A notification of proofing SHALL be sent to the confirmed address of record.

*63A#0400*

*The CSP SHALL send a notification of proofing outcome to the confirmed address of record.*

ü

4.6

Enrollment Code

An enrollment code allows the CSP to confirm that the applicant controls an address of record, as well as offering the applicant the ability to reestablish binding to their enrollment record.

*n/a*

4.6

Enrollment Code

Binding NEED NOT be completed in the same session as the original identity proofing transaction.

*n/a*

4.6

Enrollment Code

An enrollment code SHALL be comprised of one of the following:

*63A#0450*

*The CSP SHALL only issue enrollment codes that are, minimally, a random six character alphanumeric sequence or other value of equivalent entropy, represented either as:*

ü

ü

4.6

1

Enrollment Code

Minimally, a random six character alphanumeric or equivalent entropy. For example, a code generated using an approved random number generator or a serial number for a physical hardware authenticator.

*63A#0450*

*a)*

*a human-readable text string; OR*

ü

ü

4.6

2

Enrollment Code

A machine-readable optical label, such as a QR Code, that contains data of similar or higher entropy as a random six character alphanumeric.

*63A#0450*

*b)*

*A machine-readable optical label.*

ü

ü

_______________________________________________ A Community Group mailing list of KantaraInitiative.org WG-IDAssurance mailing list -- wg-idassurance@kantarainitiative.org To unsubscribe send an email to staff@kantarainitiative.org List archives -- https://mailman.kantarainitiative.org/hyperkitty/list/wg-idassurance@kantara... ______ Group wiki -- https://kantara.atlassian.net/wiki/spaces/WG-IDAssurance

-- *NOTICE: This email may contain proprietary, business-confidential, and/or privileged material. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited. This email does not constitute a signed writing for purposes of a binding contract.*