2023-11-09 Minutes

Owned by Amanda
Last updated: Nov 30, 2023
5 min read

11.09.2023 Meeting Minutes

  1. Administration:

  2.  Discussion:  

    • Address of Record Inquiry (last topic on 2023 Meeting Materials page)

      • Jimmy: This has come up with various systems and has often been probed as clients come before ARB.  What are the requirements attempting to achieve, and when rev.4 gets going, what will we have to say about Address of Record?  

      • Initial points from email (pulled from Kantara criteria):

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

        2. 63A specifically calls out postal, mobile-phone (SMS), landline or email as potential addresses of record (with a preference for Postal)

        3. For Unsupervised proofing you must send an enrollment code to the confirmed address of record, which the Applicant must return. (for Supervised you may)

        4. If the enrollment code is also an authenticator it must be reset

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

        6. There are various limitations in the format, validity and attempts allowed for enrollment codes.

        7. The enrollment code and notification of proofing must be sent to different addresses of record.

      • Initial take-aways/questions:  We can confirm control of the address and the identity of the person (they can also confirm control/receive communications via enrollment codes), but it’s very difficult to prove control of emails, as mechanisms often don’t exist to validate emails. How to validate (from an authoritative source) to validate all the addresses?  Is it useful to validate an address of record if the applicant controls the address and we have identified the applicant?  Why are we doing this and what do we hope to achieve?  Should this be the case going forward?

      • Mark King: Reports that it is a uniqueness requirement to stop people from going in twice.

      • Andrew Hughes: The rules/requirements were written before people had mobile phones and multiple email addresses.  This was from the PKI days when you had a physical existence (not about communications).  

      • In the preceding systems, things were issued from the system of record (CSPs aren’t the system of record for things). A government agency would be, because it’s part of their formal process to require you to register an address of record.

      • NIST has conflated a communication channel that exists regardless of credentialing status and a secure channel for exchanging enrollment codes and resuming services.  

      • Some uniqueness exists, but it’s expanded into electronic communication, which has no uniqueness guarantee.

      • Mark King-could we add a legal notice when something goes wrong?  Jimmy concurs, and notes that channel for communication with this would be key, especially control over the channel versus having the issuer/other entity confirm the address.

      • Andrew Hughes: Demonstrating control over the address endpoint isn’t the goal, it’s the ability to receive communications at that endpoint.  

        1. If a subscriber has an agreement with a CSP, there should be a section for notices.  Is that an address or communication method we care about?  Jimmy falls back on the idea that the criteria leans is “unsupervised” (Example: Someone ordering prescriptions online, at some point, an address is requested, but who knows where the email address came from?)

        2. Richard-what is the pragmatic purpose to the address of record?  How NIST has used it-they think it gives a degree of confidence in identity proofing.  However, NIST has never actually published their thoughts regarding these criteria.  It’s almost impossible to gain any confidence with any consistency on any of these points of contact (email, phone, etc).  As an item in the proofing process, it’s simply a means of communicating with the applicant.  

      • Yehoshua’s email: In agreement with points mentioned above, but ties into comments given for rev. 4

        1. The introduction of attributes would include an address, which would mean it can be validated if it is present on the ID that was presented (by verifying the ID, the attributes contained on the ID are also validated).

          1. However, addresses are possessives, they are not identifiers.  If they are not on the ID, it’s unclear how to establish possession of an address for it to be useful.

          2. You can’t validate that it belongs to a real person, until you know someone has it. 

          3. Digital IDs like phone numbers and emails are not on IDs.  An enrollment code could be used to verify and validate these, but that leads to the same issue currently faced (an enrollment code can not be sent to an address of record, it needs to be an address of record before starting the process).

        2. Proofing notifications-These must be sent to an address of record, which is different from where the enrollment code is sent.  Future standards require a proofing notification, but not an enrollment code, but no other method for validating or verifying addresses is offered.  There’s no possibility of having another address if the only way you can have a validated and verified address is through an enrollment code.

        3. NIST is trying to push “addresses” into other concepts of validation and verification, whereas Kantara considers it more in line with receiving communications (not as an attribute of digital identity).

      • Richard-more likely to think address of record has little weight within a proofing process, as most services these day would use an electronic address of record, which means you are unlikely to get any reliable proof that includes an address of record.  This puts the address back into a means of communication.

      • Location services:

        1. Yehoshua-your identity can expand and contract as you change what is part of your digital identity

        2. Richard-nothing says you have to be anywhere to enroll with services.

      • Overall conclusion-there is value in exploring this, but likely not in proofing.  Criteria can’t be changed, as it’s tied to 800-63 rev. 3

      • Andrew Hughes suggests developing a position to inform NIST of changes for rev. 4.  Richard concurs, that we can’t change rev.3 as it would leave out multiple service providers.  Richard points out that only some part of rev. 4 will be open for comments.

      • ACTION: Request that Kay broach the topic of address of record in a high-level way (prepped by Andrew/IAWG) in larger NIST meeting.

      • ACTION:  As a group, IAWG will develop a position on address of record and produce a 1 page proposal (what is it, what it’s useful for, what it should do, KI view, etc.) to send to NIST for rev. 4 (outside of the available sections that will be open for comments).

      • Richard proposes something broader-He has heard Temoshok reference a risk assessment regarding the requirements for various strengths–but it’s never been seen.  If they could say–this is why it’s worthwhile doing, then they’d have to justify why address of record was a requirement and so difficult.  Produce basis of risk assessment–pursue risk assessment for a broader context. (action: Andrew reach out to NIST)

      • ACTION: Andrew will reach out to NIST regarding the status of risk assessment.  

    • Charter and restructuring

      • Charter needs a refresh for 2024, as the current version is from 2021.

      • Responsibilities, among other sections, are outdated.  

      • ACTION: Andrew - Produce a line-numbered charter document and invite comments from the group.

  3. Any Other Business