Hi David
Interesting concept to distribute email verification. A modification
on it would be *if* we get secure DNS, that the domain would be able
to have a public key available and it could digitally sign the email
to the persona URL. This lets the world not have to *trust* a
centralized email verification service.
Having said that, I think there is a good likelyhood that trusted
email verification services will be offered for free, which means
that A1 may become widely adopted if it is as simple as todays email
process, but that the user only has to do it once. Since only one (or
maybe a few) sites do the verification, each domain does not need to
do any config and the user can have any email address.
To pick up on the value of verified email, there is another use of an
verified email address (or for the privacy conscience, a verified
hash of an email address). ACLs. It is a total pain to give certain
people access to a resource. Many of the private space wikis use
email invites. Taking that a step further, you enter in the email
addresses of who you would like to have access (email is an easy ID
for people), and your invitees prove they own that email address --
essentially it is the attribute that grants them access.
-- Dick
On 7-Jun-06, at 9:29 PM, Sappenin Technologies LLC wrote:
This post offers a discussion about incorporating some sort of
email verification into the DIX protocol, either in the main DIX
spec itself, or along-side DIX in a sub or related spec. In
particular, I propose an email verification solution that allows
domain owners to assert ownership over an email address, and link
that ownership to a DIX persona-url. To be clear, I view the
method proposed in this post as one method (of many possibilities)
that DIX ServiceProviders _could_ use to high effectiveness.
I'm not sure to what degree "email verification in DIX" has been
discussed on this list, but I'd like to offer a few arguments in
favor of my proposed scheme (or something like it), as well as a
sample flow of how such a scheme might work in the context of DIX.
Any feedback and/or comments are welcome.
david
[EMAIL PROTECTED]
--
First, the primary reason that DIX should have the capability to
validate email addresses in particular (and not necessarily other
“verifiable” pieces of information) is that most websites today use
an email-address as a unique identifier (think username). When
these sites transition to DIX, they (the sites) will rely on a
persona-url being associated with, and possibly the actual owner
of, a given email address. This is a lot of verification work to
be done. Further, while the transition to DIX will move people to
a persona-url-based identifier, and away from an email-based
identifier, verified email addresses will still be required by each
Service Provider that relies on the validity of an email address
belonging to a given persona.
It has been offered that external solutions already exist to solve
the problem of email address verification, and as such, the
challenge of such verification should _not_ be included in the DIX
spec. Two common approaches that I have seen (that already exist
outside of DIX) are as follows:
Approach 1.) Use a 3rd party signed claim about the email address,
where the service provider trusts the third party making the
assertion.
This is probably the most secure solution, since this would use
some form of cryptographic signatures to assert validity. However,
IMHO _many_ people are not going to go through the hassle of
getting a "verified" email address. It will probably cost money
(I'm thinking of Verisign), and the average person won't really
understand the benefit of getting "verified", at least initially.
Plus, it’s one extra hassle for a person who already “owns” their
email address.
Approach 2.) The ServiceProvider does some sort of email
verification once it receives the email address for the first
time. e.g. - SP sends an email to <[EMAIL PROTECTED]>
saying "you signed up for geeknews.com, please click this link to
complete your signup". This is not a terrible solution (many
companies employ this today for email verification), although I
have heard arguments against using such mechanisms. In the end,
however, this solution requires end-user work at potentially every
new Service Provider, which is annoying to the user, and may hinder
anti-phishing initiatives (by continuing to confuse end-users
trying to decipher legitimate from forged emails).
It would be better if the end-user only needed to establish email
ownership once (with their IdP), in a way that all ServiceProviders
could then trust and verify (and that didn't necessarily involve a
certificate-based 3rd party signed assertions that may or may not
cost money/be difficult to use).
Thus, I propose a third approach that allows domain owners to
assert ownership over email addresses, and then link that ownership
to a DIX persona-url via the DIX protocol (or DIX-like mechanisms).
Approach 3.) Automatic Email Verification by a Service Provider
We know that a given email is always owned by the domain that the
email sits in. For example, microsoft.com is the authoritative
domain for the email address <[EMAIL PROTECTED]>. Likewise,
sxip.com is authoritative for sxip.com email addresses, and so on.
Therefore, the domain owner is the best entity to verify an email
address! In lieu of a signed 3rd party assertion, or an email with
a "verify-me" link, domain owners can facilitate email verification
in the following way:
3.1) Service Provider receives a Fetch-Response with an email
address <[EMAIL PROTECTED]> that the SP wishes to verify. Assume
the following:
a1) The proposal introduces a new service called the
"email_verification_service" that receives requests to validate a
given email address. This service can run on any machine in any
domain (more on this in later sections).
a2) The DIX IdP's "Fetch-Response" contains a field called
"email_verifier_hash" that is an SHA hash of 1.) Beth's persona's
email address, and 2.) A secret number (preferably long) that only
the email_verification_service knows. For example: SHA1
(email_address + email_verification_secret_id) ==> SHA1
("[EMAIL PROTECTED]" + "A939....3939") ==> [email_verifier_hash].
To clarify, only the email_authentication_service knows what the
email_verification_secret_id is. Conversely, the
"email_verifier_hash" is given to the IdP upon account creation
(once), and freely passed around between IdP, SP, and
email_verifier_service.
3.2a) To verify the email address <[EMAIL PROTECTED]>, the
ServiceProvider navigates to http://example.com (the domain
specified in Beth’s email address), and follows the DIX discovery
protocol to find a DIX.html file or the root document. *** This is
despite the fact that Beth specified a different IdP during her
regular DIX auth session.***
3.2b) If http://example.com has no DIX capability, then fallback to
email verification approaches 1 or 2 above, or possibly deny the
login, or take some other measure.
3.3a) If http://example.com has DIX capability, then the root
document (or DIX.html) might contain regular DIX Links, but will
also contain a new link that indicates an endpoint URL that has
email authority for the specified example.com domain. For example,
the Link could be something like: <LINK
REL="urn:ietf:params:DIX:email-verification_service_endpoint"
HREF="http://www.example.com/smtp/endpoint";>. Alternatively,
Beth's domain (example.com) might delegate this authority to an
endpoint in a different domain using something like <LINK
REL="urn:ietf:params:DIX:email-verification_service_endpoint"
HREF="http://www.verifier.com/smtp/endpoint";>. Whatever the case,
the example.com domain owner asserts this link since the domain
owner should have control of the DIX.html or root html document in
its domain.
3.3b) The designated 'email-endpoint' HREF is used as a service
endpoint URL to determine if a given email address/persona-url
combo is valid. This email_verification query would look something
like this:
ServiceProvider sends email-verification-endpoint (which is, e.g.,
http://www.verifier.com/smtp/endpoint) the following:
a.) SHA1(email_address + email_verification_id), which is
equivalent to the email_verifier_hash provided in the fetch
response from the IdP.
b.) persona-url=http://homesite.org/493838 ==> Also provided in the
fetch response from the IdP.
The email_verification_endpoint will perform a lookup based on the
supplied information (email_verifier_hash and persona-url), and
respond with something like "DIX:true" if the persona url actually
"owns" the indicated email address. Otherwise, the response should
be something like "DIX:false", or perhaps "DIX:unknown" if the
verification_server is not sure(?).
** Notice that an eavesdropper will not know which email is being
verified **
*** By proving (via domain ownership) that a given persona-url is
linked to a given email address, the email_verification_service can
vouch that a given persona-url controls or doesn't control a given
email address.***
Potential Problems (and resolutions)
--------
P1.) What if the secret email_verification_id is guessed or
compromised?
[Answer] First, the secret verification id is never passed out to
remote sites, and should be different for each email address. If
an attacker somehow figured out the secret email_verification_id,
the attacker would still need to know the associated persona-url
that matched the specified email address.
In the worst case, if an attacker knew all 3 pieces of info (email
address, persona-url, and secret key), he would only be able to
figure out if a single email is valid for a given persona-url. It
wouldn't tell the attacker anything more about the email address in
question, nor about the persona's other personal info, nor about
any other email addresses that may or may not exist. The secret
key is really used to mask the email address so that a casual
eavesdropper will not know which email is being verified, and to
prevent spam trolling on the email_verification_service.
P2.) Couldn't someone else's email_verification_service vouch for
my email address without my permission?
[Answer] No. The email_verification_protocol specifies that a
Service Provider perform a DIX discovery at the root domain of the
specified email address. So, example.com is the first place to go
in order to verify any "example.com" email address. Only the
specified domain of an email address can delegate to a different
domain for email_verification (via DIX discovery).
P3.) What if I don't control my domain's root page (i.e., a
yahoo.com email address)?
[Answer] Worst case, you would need to fallback on solution 1 or 2
above, or urge the entity that does control your domain to embrace
DIX.
P4.) How does the email_verification_service assert control over a
given email address in the first place?
[Answer] Basically, a user who actually controls an email address
needs to login to the email_verification_service to get the process
started. The mechanism employed for login is
email_verification_service implementation-defined. The
email_verification_service could have some non-DIX method of
allowing a given user to login with their email address (perhaps
using the same login/password that the email account uses, since
the domain owner already knows this anyway). In any event, after
somehow logging in, the user tells the email_verification_service
what persona-url is linked to their specific email address(es), and
the email_verification_service does the rest through the protocol.
P5.) If the IdP and the email_verification service aren't the same
thing (i.e., separate domains or servers), how do the IdP and the
Email_Verification_Service share the secret email_verification_id
for comparison purposes?
[Answer] They don't. The IdP is given an SHA Hash of the "email
address" + the secret email_verification_id. This hash value can
then be sent out to various Service Providers, since this hash
value is just another DIX parameter that gets filled in when a user
creates a new IdP account. It is feasible that an
email_verification_service could somehow use a DIX store method to
propagate this information, but this requires further thought.
SUMMARY
-------
The main purpose of the email_verification_service is that a domain
owner should be the one to vouch for who controls an email
address. In addition, DIX ServiceProviders that use the proposed
email_verification_service can automatically determine if a given
persona-url is linked to a given email, and can trust that
determination because it is made by the owners of the domain that
controls the email address. In the final analysis, no continuing
end-user interaction is required for each ServiceProvider that
wishes to validate an email address. Plus, email_verification as
laid out in this post is not a requirement. SP’s could use
alternative methods to verify an email if, for instance, a given
email domain doesn’t support the email verification service, or the
SP determines that a stronger method of email verification should
be used.
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
