yadis Digest, Vol 13, Issue 14

Sat May 27 18:54:37 UTC 2006

Chris,

Sorry for the long delay -- I've been buried the last two days.

This is a great analysis. See ### inline below. 

-----Original Message-----
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Chris Drake
Sent: Thursday, May 25, 2006 12:52 PM
To: yadis at lists.danga.com
Subject: Re[2]: yadis Digest, Vol 13, Issue 14

Hi Drummond,

I'm just thinking out loud here relating to anonymous IDs (sorry if
I'm just re-stating the obvious):-

The relying party needs to know how to "get to" (or verify assertions
from) the identity provider (IdP).  To protect a users privacy:-

A) the relying party directs the user elsewhere to authenticate (some
   kind of trusted authentication proxy) - from the users point of
   view - they would merely click on the "inames" logo on enabled web
   sites to begin their login process - no typing anything in there.

   + really easy for users - one click.
   - trusted proxy knows everywhere the user goes.

### My understanding of this option is that in order for the site to simply
offer an "i-names" logo that the user could click to begin their login
process, it would require a common "trusted authentication proxy" (what I
had called an "anonymizing authentication service"). Since you're right that
this option would require the same trusted authentication proxy for all
relying parties, IMHO this is a non-starter. ###

B) the user tells the relying party who their IdP is - so the user
   enters 2idi.com in the box (not their username) and clicks the
   inames logo to commence the login stuff.

   ~ not so easy for users to understand
   - relying party at least knows the IdP - a privacy problem for
     small IdP's
   - IdP knows everywhere the user goes.

### Agreed on all 3 counts. See my further comments on this option below.###

C) the relying party tells the user what *their* iSSO URL is, the user
   carries this off to their IdP, logs in, and gets directed back to
   the replying parties URL.  (implementationwise - the user need only
   do this once - if their IdP "saves" their relying-party URL, a nice
   post-signon interface could be presented, eg: "where do you want to
   go today", listing all the places the user might want to log into.

   ~ initially tricky for users to grasp
   + really easy - one click - future signins
   - IdP knows everywhere the user goes.
   - "shoulder surfers" and hackers "getting in" to users account at
     IdP knows everywhere the user goes.

### Again agreed. I'm especially concerned about the initial usability of
this one -- it's a paradigm shift from "single sign-on" to "safe linking".
However if this new paradigm caught on, it could be very powerful. ###

D) relying party issues a one-time token (nonce?), user carries *this*
   off to their IdP, uses it to obtain a signed credential, carries
   this back to the relying party, and logs in with it.

   - extra tricky for users
   + IdP has no idea where the user's going
   - relying party probably again knows the users IdP

### It strikes me that unless there was software to automate this whole
process, it's a non-starter from a usability standpoint. I believe this is
similar to the basic concepts behind Credentica's software
(http://www.credentica.com/), but it will be a real uphill battle to get it
widely deployed. ###

Users already must trust their IdP (a rouge IdP is perfectly placed to
impersonate it's users) - so - I don't think it's too much to ask that
users also trust an IdPs policy of NOT recording where the user uses
their credentials.

### On this, we completely agree. I have long believed that the role of IdP
(for which I prefer the term "i-broker" as a market-facing term, see
http://en.wikipedia.org/wiki/Ibroker) is going to be very much like a bank,
credit card company, or ISP. Just as we know these entities know most places
we get/spend our (non-cash) money or get/send our bits, we know our
i-brokers will know about our online relationships. And we trust them to
keep that information private. But just as we can use cash transactions for
financial untraceability, or public Internet terminals for online
untraceability, we will be able to use non-i-brokered identity transactions
(such as we do with every website today), or Credentica-style highly-cloaked
transactions, when we don't want the i-broker in the loop. ###

### IMHO just a practical approach to unlocking the power of this new layer
of identity services while keeping them as simple as usable as possible. ###

I hope this helps someone, somewhere - good luck!

### I certainly appreciate it, Chris. We're still early in the thinking
about how to do anonymous identity transactions using URL- or XRI-based
identities. Your analysis is a good one. My gut feel is that option B is the
one that makes the most sense early on, as I believe it will be a fairly
intuitive option for the early adopters and thus could spread to the general
public over time. For example, here's how I might envision an i-broker (in
this case, @2idi) might instruct an i-name registrant about this option. ###

### EXAMPLE INSTRUCTIONS ###

To use your new i-name single sign-on (ISSO) service, simply type your
i-name into the login box of any website where you see the "I-Names" logo.
The website will then redirect you to @2idi to login (if you are not logged
in already) using your ISSO password on your personalized password page. 

IMPORTANT: If you do not want the website to know your i-name, you may still
use ISSO by typing the i-name "@2idi" into the website's login box. The
website will redirect you to @2idi to login, and @2idi will automatically
generate for you a unique username for that site. Whenever you return to
that site, just type "@2idi" to login, and 2idi will automatically use that
same unique username to log you in.

### END EXAMPLE INSTRUCTIONS ###

### Does that seem reasonably intuitive? ###

=Drummond (http://xri.net/=drummond.reed)  

Friday, May 26, 2006, 3:33:00 AM, you wrote:

DR> Josh is right -- this use case is popping up everywhere now. A few weeks
ago
DR> at the Internet Identity Workshop session on the SAML version of ISSO
(the
DR> i-name single sign-on protocol being specified at XDI.org), "anonymous
DR> single sign-on" ended out being the main subject of discussion.

DR> The basic principle is the same whether the identifiers used are URLs or
DR> XRIs/i-names: if you want to login anonymously on a site, rather than
DR> logging in with your own URL or XRI/i-name, you login with the URL or
DR> XRI/i-name of an anonymizing authentication service offered by your
identity
DR> provider/i-broker.

DR> That anonymizing identity service then generates a site-specific URL or
XRI
DR> that will identify you to that site. The end-user does not have to
remember
DR> or keep track of this site-specific URL or XRI because all the end-user
DR> needs to remember is the URL or XRI/i-name of the anonymizing
authentication
DR> service.

DR> I'm cc'ing Peter Davis at NeuStar who is authoring the SAML version of
the
DR> ISSO protocol (he should have it posted at XDI.org shortly -- we'll post
a
DR> link when it is) as he's looking at adding this anonymous single sign-on
DR> option explicitly to the spec (although it may not be until v1.1).

DR> =Drummond (http://xri.net/=drummond.reed)  

DR> -----Original Message-----
DR> From: yadis-bounces at lists.danga.com
DR> [mailto:yadis-bounces at lists.danga.com]
DR> On Behalf Of Josh Hoyt
DR> Sent: Thursday, May 25, 2006 8:08 AM
DR> To: Chris Drake
DR> Cc: yadis at lists.danga.com
DR> Subject: Re: yadis Digest, Vol 13, Issue 14

DR> On 5/25/06, Chris Drake <christopher at pobox.com> wrote:
>> How is my privacy being protected if I have to give my ID to a relying
>> party?  For example - I don't want the folks at "shame-your-boss.com"
>> to know my ID in case they later see me at work in my sourceforge
>> account - or do I have to create a collection of new Yadis IDs, one
>> for each new web site I go to ?   Am I missing something here?

DR> Use different identifiers in places where you do not want to be
DR> identified as the same person. Identity providers can (and will) make
DR> this easy, without requiring you to have more than one account.

DR> It is possible for your IdP to issue one identifier per site that you
DR> visit to get the convenience of single-sign-on without giving up any
DR> privacy. A case that I expect to be even more common is to use
DR> different identifiers in different communities, such as work and
DR> family.

DR> I hope that helps.

DR> Josh