| | | Andrew H: My main issue is the inconsistency within the document itself (many contradictions likely a result of updating the various parts). Identity proofing: Figuring out a unique individual and what the relying party needs to know Evidence collection-can it relate to a real person? Issue arises with the lack of an omni-vew of everyone in a population and someone might be missed with a second CSP using different documentation.
In general, fraud prevention is one of the main goals and it’s woven throughout the document, but with imprecise language.
Jimmy: Will be sending comments to Carol soon. Attributes–identity evidence is getting harder to obtain while being equitable IAL2-most likely going to be a DL and a passport IAL3-likely the same, but some of the verifications and collections are different Facial compare-which could include confirmation codes and microtransactions - AAL2 authentications (hypothetical/aspirational). How would a student ID be validated other than by looking at picture?
Big carve out for data brokers to supplement the evidence Wendy Brown: Uniqueness-how is a CSP going to figure out uniqueness, especially with one that’s just starting out? Richard-likely some sort of biometric binding requirement and a record of the evidence presented (which may contain a unique reference) We are doing what we can with a degree of rigor appropriate to the assurance level provided. Right now, it’s levels 1-3–perhaps with level 5, things will be more confident?
Equity-how to account for people who don’t integrate in the same manner or simply don’t have some things available to them? Andrew: What can we recommend to help CSPs? Reminder that the first step is comments directly on the NIST documents, but the second step will be to determine Kantara’s criteria. Vlad: Could it be how you get access to an identity document? NY or SF city ID’s (but these are not as useful). Using a prepaid phone means a lack of depth of record. City IDs are a way to be fair, but the next piece of evidence wouldn’t be available. Jimmy: Evidence is validated, identity is verified. Attributes are verified. In one spot, they say you collect your core attributes, but everyone else it says you must collect all the core attributes and then validate them with one authoritative source. They list name, unique numbers, address, etc as attributes, and then require that they are validated with an authoritative source. Is this possible? It’s not the person or the evidence, it’s the attributes of the person on the evidence. Andrew H: A core attribute is defined as whatever the CSP defines as a core attribute in conjunction with whatever the RP requires. The example doesn’t always apply (this has been asked and confirmed) Richard: We should be mindful that anything exemplar is not normative. An “eg” should be ignored, an “ie” can be a clarification (with caution) Andrew: The text is loose and there is ongoing conversation with the authors that some sections say “to conform, you shall fulfill every shall-statement” and in discussion, the true intention emerges (we meant to say this) Schedule-this week and next-send everything to Carol. Next call-try to walk through the actual comments to see what can be worked up/sent in. The following week (Oct 3) is essentially the deadline and consensus will be needed. Carol: In agreement with the loose language being a problem-in order to submit comments, an articulation will need to be made, which could be inflammatory. Mike: Notes that NIST requested not to duplicate comments. So the majority of Mike’s comments will be provided via Easy Dynamics, with minimal notes to IAWG/Kantara. Any other things to discuss? Andrew Hughes: 63C ( wallets)-Thought was that if the guidance on wallets went into an annex to get industry perspective, then issued a supplement–it seems way too early to be providing guidance/standards, as the world hasn’t decided how wallets are going to be used Carol-concurs on too many variants with wallets at present
Jimmy: There seem to be many “shall” statements in the base document. What happens with those? Richard: oversight when we produced rev.3 criteria, didn’t look at the base doc. There are normative things that should apply across the span of A-C, but whether we have time to review them is another questions. Jimmy: Can we pass those off onto the RP? Sessions at the end of 63B–do we leave it ambiguous or push to RPs? Or even create a “session manager role”? Andrew: Friday’s live session-confused answer about risk management roles. CSPs have to do some risk evaluation because they are offering services Likely a second-stage conversation RE: Kantara’s criteria
Yehoshua: Concurs on wallets, but some of the details don’t seem relevant (just an application of 63B concepts). Provisioning seems to go into the wild. (Hughes-different groups are wrestling with issuance and provision). Wallets seem to be a package for a bunch of verifiable credentials. How and who packages/their role should not be relevant. If you are using a wallet, you need to maintain the same things from 63B. Hughes: one of the big issues no one knows how to deal with is whose wallet? User’s v. issuers? What assertions are in the wallet? Issuer’s claims about the person or the person’s claims about the person? How much control should the issuer have over what the person can do with the claims, credentials, wallets that they have? How much should the verifier/RP be able to find out about the wallets/issuers to make a trust decision? No one knows because a wallet is a nexus point for a variety of roles/responsibilities outside of the data center. It started with credentials signed by issuers and the decision was made to put them into wallets. Now what? Carol: We need to clarify the definitions between wallets, personal data stores and pulps. There is user agency with a personal data store, with more contention around wallets (issuers say they own it). Who owns the wallet? The issuer or the user? James: The ownership of data has always been key. You don’t necessarily own your data.
Yehoshua: Rev 4 and components. A more concrete definition of identity proofing components will be needed. Right now-almost every provider lacks proofing agents and trusted referees. Unlikely that suddenly everyone will have their own teams of proofing agents. What will happen is that different providers will focus on difference pieces of evidence and evaluation. This means our assessment, criteria, and certification will have to adapted/broken down (“componentized”) rather than a single laundry list of things to be met in order to be compliant. This links into risk management–how are the risks evaluated with being a piece of a larger identity solution (not the full solution)?
Richard: 63A has requirements that basically impose a minimum style or number of types of identity proofing. NIST should be writing technical standards, not driving how the market develops. Yehoshua-would this remove the 1-3 paradigm? Richard: not likely-if they can define types of proofing and the requirements for the types of proofing, let the providers determine which of those types they wish to offer. Yehoshua: Wouldn’t there be multiple levels (not just three)? Each piece of evidence would have its own way of validating/verifying. Andrew: There are infinite paths, but narrowing into a discrete numbers is needed.
|