I agree. This is in line with my blog post: <a href="http://www.sakimura.org/en/modules/wordpress/index.php?p=82">http://www.sakimura.org/en/modules/wordpress/index.php?p=82</a> I think. <br><br>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. <br>
<br>=nat<br><br><div class="gmail_quote">On Mon, Jul 6, 2009 at 1:46 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
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.<br>
<br>
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 : <a href="http://google.com" target="_blank">google.com</a>.<br>
<br>
(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...)<br>
<br>
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 <a href="http://openxri.org" target="_blank">http://openxri.org</a> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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<br>
<br>
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.<br>
<br>
________________________________________<br>
From: Johnny Bufu [<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>]<br>
Sent: Sunday, July 05, 2009 2:12 AM<br>
To: Andrew Arnott<br>
Cc: Peter Williams; <a href="mailto:general@openid.net">general@openid.net</a><br>
Subject: Re: [OpenID] Delegation leading to new accounts on websites<br>
<div><div></div><div class="h5"><br>
On 21/06/09 05:29 PM, Andrew Arnott wrote:<br>
> Google doesn't support delegation at all. Some concern about asserting<br>
> an Identifier it has no control over...<br>
<br>
Perhaps they are just being too cautious.<br>
<br>
The OP's assertion is about openid.identity, which is always under their<br>
control.<br>
<br>
The end-users presenting a valid assertion issued by their OP are<br>
claiming they control the openid.claimed_id. The OP's assertion is the<br>
tool that makes the claim verifiable.<br>
<br>
An OP's (valid) assertion alone cannot be used to prove ownership of<br>
another claimed identifier without actually having control over that<br>
claimed identifier (to configure delegation to the OP).<br>
<br>
<br>
Johnny<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>