Turin tested “Profile Exchange”

By markcross

Sending server is the OpenId profile which a user uses to send their first email from to get on the targets white list
Target server is the OpenID server that hold the email address that the person wants but only releases it after a Turin test.

These are the functional steps required, as I see them:

#Sending server sends
xmlrpcmsg(‘OpenId.RequestEmailCaptcha’, $OpenIDUrl, ’string’, $EmailToWhitelist, ’string’);

#Target server sends
(‘CapthchaAsJPGencode’,'encoced binary IAB sized jpg’, $OpenIDUrl,’string’, ‘TransActionId’,'INT’)
If the person declines to issue an email the ‘CapthchaAsJPGencode’ could be NULL

#Sending server sends
xmlrpcmsg(‘OpenId.VerifyEmailCaptcha’, $OpenIDUrl,’string’, $CaptchaValueOffered, ’string’, ‘TransActionId’,'INT’);

#Target server sends
($OpenIDUrl,’string’, ‘TransActionId’,'INT’, ‘EmailAddress’, ‘email0′, ‘EmailAddressMetaDescription’, ‘email0MetaDescription’, ['EmailAddress','email1','EmailAddressMetaDescription','email1MetaDescription'], ['EmailAddress','email2','EmailAddressMetaDescription','email2MetaDescription']….)
If there is no email address or the person declines to issue one even after a captcha challenge. This email0 will be NULL EmailAddressMetaDescription is something like Work/Home/whatever

Questions:

1. Is there schema basic correct – to keep it AS simple as possible?
2. What offer functions or parameters could be included but NOT impact on a delieverable at developer level

3. The most important one – could this be implemented across “applicable to any URL-based identity system”?

Leave a Reply