[OpenID] Delegation leading to new accounts on websites

Tue Jul 7 00:12:20 UTC 2009

I agree. This is in line with my blog post:
http://www.sakimura.org/en/modules/wordpress/index.php?p=82 I think.

In XRD 1.0 parlance, I suppose it will be link/rel forward pointing to
second XRD, and again link/rel pointing back to the original.

=nat

On Mon, Jul 6, 2009 at 1:46 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

> Yes - and in "denying" openid-delegation flows, Google are somewhat
> undermining and denying UCI - a founding mission of the movement. They are
> apparently taking a slice of openid auth protocol and superimposing SAML2
> semantics -- an IDP-centric control model.
>
> But I also think that openid architecure has in the XRD exactly what's
> needed to find the middle ground - addressing the concerns of the
> "overly-cautious OP" with a mega-brand  to worry about. I think we would be
> further maturing as a community if we could accommodate in openid auth 2.1
> the "control" issues facing such mega-brands.
>
> 1. As OP, Google could be resolving to a 100% Google-controlled XRD any
> discovery request for the HTTP URL they currently place in the
> openid.identity response (a persistent, per RP, law#4 URL). That XRD is
> Google property, is licensed and copyrighted by Google, and is "theirs". No,
> the user may not add an SEP that points to Yahoo's openid endpoint, despite
> the nature of underlying XRD architecture. That XRD is Google property, is
> under the firm's control, brings Google Governance to the world (do not harm
> etc), and hopefully still addresses Google goals for funding their
> (world-beating) OP on the most famous home page in the world : google.com.
>
> (This is a  "just-stunning" openid movement accomplishment; and
> complementary recognition MUST be given to Google for taking such a risk. It
> takes my breath away each time I consider what has really happened in the
> security world, here...)
>
> 2. Independently, the user can go purchase an XRI. Or, weirdos like me
> learn to operate a "delegated XRI child authority" server in their data
> center - a glorified DNS server administering a child domain. (I received
> lots of open-source help on that from the http://openxri.org crew last
> week, proving to my satisfaction that I *can* opt retain my independence
> from the XDI.org governance apparatus). As a result, each user optionally
> has their own XRD - that can now be used in the opend delegation flow of
> openid auth, promote UCI, and thus provide portability.
>
> Now, let's put the 2 together. Let's now make Google-OP happy - exercise
> "protective control". And, lets make users happy - they retain portability.
> Lets make the XRI folks happy - their linked-identifier vision get applied .
> Lets even keep the ever-testy W3C TAG happy - only use XRD's whose ids align
> with semweb's own globally distributed identifier architecture. Not that it
> matters much, let's even make Peter happy: UCI is retained.
>
> To "arm" the openid-delegation feature at a Google OP, a
> google-governed-user must establish equivalency of his/her own XRD with the
> Google-governed XRD. Logged on to Google  Accounts locally - an act by which
> any Google-user admits and confirms the governance relationship of Google
> over the Google XRD - the now Google-governed-user induces Google-OP to add
> an EquivID to the Google XRD for that google-user - pointing back at the
> user's own XRD. Being a google-governed session, the Google use terms are in
> control, and the private-party user must license Google to
> store/apply/cite/verify/validate/... that user-owned/copyrighted backpointer
> value ... to his/her own XRD.
>
> As with all openid-delegation, the user must alter his/her own XRD to
> complement what just happened at Google-OP. The user of  course adds an SEP
> that points to Google's OP endpoints. But now, the user (or rather a
> tool-wizard in practice...) adds the canonicalid of the Google XRD as a
> "canonicalEquivID" field in the SEP entry.
>
> The result would seem to be that user may now apply his/her own identifier
> at RPs, without the RPs storing any Google-governed property. Google-OP only
> participates in openid-delegation for those Google-users who have registered
> (and previously authenticated to Google-OP during registration) their own
> XRD.
>
> Now, Im sure I have my XRI v2 resolver theory slightly wrong, in the above.
> Perhaps the SEP in the user's XRD would better have a XRD "ref" to the
> google XRD, vs a canonicalEquivID. XRI is far to hard for my class of brain,
> to understand such technical subtleties
>
> But, regardless of final techniques chosen, hopefully one sees the pattern
> Im advocating - reaching for a middle ground by exploiting linkages between
> XRDs. Im aiming to find a half way house between the impuse of an OP to want
> to project legal-control over a users life at an RP, and the users desire to
> be retain independence from any one OP while on that RP site. Such a form of
> formal independence would allow the OP/user relationship to subsequently
> terminate, but terminate in a manner than has zero impact on the
> still-ongoing RP/user relationship.
>
> ________________________________________
> From: Johnny Bufu [johnny.bufu at gmail.com]
> Sent: Sunday, July 05, 2009 2:12 AM
> To: Andrew Arnott
> Cc: Peter Williams; general at openid.net
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
>
> On 21/06/09 05:29 PM, Andrew Arnott wrote:
> > Google doesn't support delegation at all.  Some concern about asserting
> > an Identifier it has no control over...
>
> Perhaps they are just being too cautious.
>
> The OP's assertion is about openid.identity, which is always under their
> control.
>
> The end-users presenting a valid assertion issued by their OP are
> claiming they control the openid.claimed_id. The OP's assertion is the
> tool that makes the claim verifiable.
>
> An OP's (valid) assertion alone cannot be used to prove ownership of
> another claimed identifier without actually having control over that
> claimed identifier (to configure delegation to the OP).
>
>
> Johnny
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090707/59cacbf5/attachment.htm>