Proposal: IdP-supported delegation

[Chris Drake]

Hi All,

I've been absent 2 months, and missed the announcement of this list.

On a brief skim of the archive re delegation, I can't see a clearcut
agreement yet?  There was also talk of omitting delegation from the
first draft - did this omission go ahead? 

I would like to propose the following.

1. RP (Relying Party) *requests* a users identifier (eg: global iname)
   in RPs login <FORM> on their web site, however, the post target for
   this form is *not* the RP, but instead the RP's IdP (iBroker).

2. Users may...
   A) Key in their unique global identifier
   B) Key in their actual IdP URL
   C) Enter nothing at all and click either the "login" button, or the
      inames logo
   D) Not click anything at all (as would be the case if their browser
      held an RP-issued cookie stating "stay logged on")

3. The RPs iBroker agrees to suitably issue HTTP redirects to the
   correct iBroker should they discover they're not the correct IdP
   for the user.
   

Solves:

   i) eradicates the difficult-for-end-users-to-understand problem of
      trying to explain to them why they formerly needed to enter
      other stuff besides their iname to log in - from a users
      perspective, they only need log in one time, using their genuine
      favorite identifier.
      
  ii) Privacy problems solved: control over which identifier to
      subsequently present to RP is returned to the user.  At NO time
      does the users keyed identifier need or get communicated to the
      RP

Facilitates:
      
 iii) Genuine single-signon (SSO) - Just because a user only has to
      type their *password* once, doesn't make that a "single sign on"
      in my opinion.  If I have SIGNED ON - I do not expect to have to
      re-type my wretched identifier every time I visit a new RP.  I
      just want to click *once*, or, not even click at all.

  iv) A single sign off (SSOFF?) - the "log out" problem: many RPs
      support "stay logged on" features, so to expect an RP to use
      OpenID, we should also support this, or risk them all having to
      implement this themselves, which robs our users of the ability
      to "log out" from every place they are currently logged in to.

   v) Anonymous single signon, but still using just our users favorite
      identifier

  vi) Automatic IdP-provided unique identifier provision - RP site
      always gets the same identifier for the user, which is never the
      same as the identifier the user keyed in, and such identifier is
      never shared amongst RPs

 vii) Double-blind anonymous single sign on (neither does the RP know
      the users identifier nor iBroker, nor does the iBroker know what
      RP the user is signing in to.) [requires a nonce, which we
      already have for other reasons anyway]

viii) Lets a user log in to any site they've joined, simply by
      clicking on it in the list on their own personal iBroker sites
      page at their IdP.
      
Requires:

  ix) iBrokers to co-operate, and possibly someone to administer a
      root key to sign certificates to allow RPs to automatically
      ascertain the accreditation and policy status of the iBroker

In general, my coding and standards philosophy is to cater for as much
as possible, even if it's not all initially implemented.  Also in
general, my UI philosophy is to make everything as utterly simple for
users as we possibly can.  I think my the above proposal caters for
both.

As an IdP myself (1id.com) I offer to implement the above. I also
offer my response to Josh Hoyts worry:-

>On Sep 4, 2006, at 13:00, Josh Hoyt wrote:
>> I think that disclosing the identifier to the *IdP* is a non-issue.
>> The only potential issue is that some IdP may choose not to support
>> delegation in order to lock in users.

My IdP will properly honor delegation issues, and will not store or
use the flow of other IdP's identifiers for anything.  (indeed, if
delegation is global, then all RPs for whom I am their iBroker will
therefore gain the advantage that even if other IdPs don't commit to
the same practice as me - all their users still get the advantages of
a working and functional solution, by virtue of my place in the
middle - e.g. my step numbered "3." above)

Kind Regards,
Chris Drake