Lessons Learned Past Efforts
Convener: Jim Fenton & Craig Spiezle
Tags: How can we apply lessons learned in standardization/adoption of email authentication and Extended Value Certificates to current efforts in the identity space?
Discussion notes:
Emal Authentication Chicken and egg... no one wants to invest before the technology is active in the industry multiple technologies... which one to implement?
Even within a given technology, specs were still evolving, some had protected intellectual property or proprietary specs... some concerns about motivations of key players involved in spec development disconnect between technical specs and business stakeholders... what's the business case?
Role of policy layered on top of authentication specs.. technology, use case, etc conflict of interest: anti-spam vendors, certification services sometimes over focus on fringe cases... can derail standardization efforts lack of analysis tools slowed adoption... lack of confidence that implementations have gotten it right some rough tools have been pretty widely available (test reflectors for DKIM, similar tools for sender ID / SPF... but hasn't really been enough maybe less incentive for e.g. esps to get their customers on board... left it up to individual companies (this has for the most part changed now... most esps support email authentication at least as an option for their customers also issues with incenting hosters to support necessary DNS configuration (this is still somewhat an issue today, especially for smaller businesses who use 3rd party DNS/web hosting services... some key hosters are starting to make it easier for their customers to configure email authentication, although probably still too complicated for really small businesses openID may have an advantage because it's a community effort and not driven by one (or a small number) of companies with potentially private agendas open id may still have some of the long tail for small businesses, because the setup requires network configuration knowledge...currently that tail is mostly not using authentication on their web sites, but that may change
Key issue: how to motivate adoption: what is the business case for key stakeholders
another example: Extended Validation certs (EV Certs)- needed to address the fact that certificates were losing value because it was relatively easy to procure a deceptive certificate and confuse consumers.
Went after key stakeholders to encourage early adoption, and provide concrete examples for follow-on adopters; early adopters could also use their adoption to self-promote added business value for their customers also got browser support for recognizing ev certs and making validation visible to users (green/yellow/red bars in URL text box) value proposition was higher level of consumer trust for participating sites (not enitrely clear how to measure this) driven by smaller, focused group with clear goals
succeeded in much shorter time frame than email authentication
like with many of these efforts, need to do this within the constraints of existing technical infrastructure
needed to create/standardize new requirements for the additional validation for cert requister (organization applying for certificate)
DNS issues:
is there support for publishing txt records (required to store auth info)
is there support for '_' in domain names (required for dkim key publishing)
Question: how can we get identity efforts from today's state to something closer to the EV cert experience early focus on compelling business case and value proposition (ideally for both business and for end user) identifying key set of visible initial stakeholders to adopt and promote technology/standard make sure to have sufficient focus on user experience (both for deploying organizations and for end users)
Email auth experience focused more on technology side and on fringe cases, and less on business case, value proposition, end user experience
Domain reputation:
domains may have more than one reputation (e.g. email reputation vs. is the site fraudulent)... but many discussions seem to confuse the two what is identity? e.g. there are email auth domeains that aggregate under a brand (e.g. newsletter.brand.com), and others that aggregate under a 3rd party (e.g. brand.3rdparty.com)
How can we support multiple identites (specific limited representation for particular sites/applications) but also have an easy way for me to locate and manage all of these? One answer is that the “collector” is the IDP, but it's unlikely that at least in the near term that a person will have a single unique IDP (but at least there will be fewer IDPs than personae).
