Chiming in here. 

An Address of Record should be an attribute that is referenceable in GLB compliant records (e.g. phone number, mailing address, email address, etc). In that sense, once the user confirms they have possession of the address, which is also in records and can happen in a variety of ways, then it is useful both as evidence and for communications. 

A Communications or Notifications Address is something the user could choose to bind to their profile post-authentication and identity proofing. In terms of lifecycle, this address would then be designated as a Communications/Notifications Address -- and also an Address of Record if a proofed user entered it (that's how most GLB data originates) -- whereas a user might not wish to get notifications at other Addresses of Record. 

There is almost certainly more nuance here but I believe very strongly address of record and the user's ability to confirm possession is a key component of evidence & proofing. 

On Sun, Jan 21, 2024 at 10:17 AM Martin Smith <martin@bfcmclean.com> wrote:
IAWG – I like the characterization of "address of record" as an attribute which can be attached to a verified identity, but which is itself not evidence of identity. The definition of this attribute sems to be "a one-way channel
IAWG – 

I like the characterization of "address of record" as an attribute which can be attached to a verified identity, but which is itself not evidence of identity.  The definition of this attribute sems to be "a one-way channel (in the form of an email or postal address, perhaps a telephone number) using which the CSP can send a message to a subscriber." This is a one-way channel: presumably the CSP would not rely on messages received via the channel, since the sender would not be authenticated. The subscriber would presumably be required to use an authenticated channel to communicate with the CSP. Who is the "authoritative source" of this attribute? It seems clearly to be the subscriber, though the CSP might want to confirm (verify? validate?) that the "address of record" channel is working by sending a message and requiring the subscriber to respond back via the CSP's authenticated channel. Recourse for failure of the subscriber to respond would be for the CSP to invalidate—permanently or temporarily-- the credentials issued to the subscriber.  The subscriber would use the CSP's authenticated channel to provide updates to the "address of record".  

I don't know how this might translate into language for a recommendation to NIST, if at all:  just trying to work out the limitations of what the address-of-record should be used for, and the extent to which any assessment of conformance might be needed (which appears to be minimal.)  

Martin

---
Martin Smith
703 389-3224
From: Yehoshua Silberstein via WG-IDAssurance <wg-idassurance@kantarainitiative.org>
Sent: Friday, January 19, 2024 11:13 AM
To: IAWG <wg-idassurance@kantarainitiative.org>
Subject: [WG-IDAssurance] Address of record position & EU-US mapping feedback
 
Good morning everyone!

For those who have not had a chance to review, please see the attached document with our address of record position and provide any feedback via email before our next call on February 8. 

I also want to remind everyone to share their thoughts and feedback on the EU-US Trade and Technology Council Digital Identity Mapping Exercise Report via email before the next call as the deadline to provide comments is February 29. Any and all feedback is welcome. 

Best,

Yehoshua

--
Yehoshua Silberstein | Associate Counsel, Core Product

(857) 577-8144



Notarize is now a Proof brand 🎉 We hope you love our new look and feel as much as we do!


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.
_______________________________________________
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://urldefense.com/v3/__https://mailman.kantarainitiative.org/hyperkitty/list/wg-idassurance@kantarainitiative.org/__;!!AVdDjg!qeWojU_gj776bbaqr5DI0Jy7x702qGsd6hos8q2ymcqQYJGjDS7CKvnklFh9ase-HyBFso49hTXx$
______
Group wiki -- https://urldefense.com/v3/__https://kantara.atlassian.net/wiki/spaces/WG-IDAssurance__;!!AVdDjg!qeWojU_gj776bbaqr5DI0Jy7x702qGsd6hos8q2ymcqQYJGjDS7CKvnklFh9ase-HyBFsp8q3ihs$



--
Blake Hall
Founder & CEO
Mobile: 615-293-4702

 

 
Veterans Get Secure Single-Sign On for Benefits: http://go.id.me/2iKDM6j
President's National Strategy for Trusted Identities in Cyberspace: http://go.id.me/2hZzUKr
Building the Trust Graph: http://go.id.me/trust-graph


This message (including any attachments) may contain confidential and privileged information belonging to the sender, for a specific individual and purpose, and is legally privileged. If you are not the intended recipient, you should delete this message and any disclosure, copying, forwarding or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.