<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
h3
{mso-style-priority:9;
mso-style-link:"Heading 3 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:13.5pt;
font-family:"Helvetica","sans-serif";
color:#333333;
font-weight:bold;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:24.0pt;
mso-margin-bottom-alt:auto;
margin-left:24.0pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.Heading3Char
{mso-style-name:"Heading 3 Char";
mso-style-priority:9;
mso-style-link:"Heading 3";
font-family:"Helvetica","sans-serif";
color:#333333;
font-weight:bold;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1916741653;
mso-list-type:hybrid;
mso-list-template-ids:-1793424506 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<h3><span lang=EN>Appendix A.2. OP-Local Identifiers<o:p></o:p></span></h3>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-right:48.0pt;
mso-margin-bottom-alt:auto;margin-left:48.0pt'><span lang=EN style='font-size:
12.0pt;font-family:"Verdana","sans-serif";color:black'>An end user wants to use
"http://www.example.com/" as their Claimed Identifier. The end user
has an account with Example Provider, which functions as an OpenID Provider.
The end user's OP-Local Identifier is
"https://exampleuser.exampleprovider.com/". <o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>The definition of OP Local
Identifier might be changed. Though it MAY be an identifier the user does NOT
control, it MAY yet be one that the user DOES control. Currently the definition
does not allow the last clause.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>If the change is made the
following hold:-<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>If the OP is willing to treat a
foreign OP’s provisioned URL as its own local identifier, it can opt to _<i>chain</i>_
(or _proxy_) an openid auth request to that 2<sup>nd</sup> OP, where the
frontside OP receives a request with identity=<localid>. <o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>In the case of proxied OPs, the localid
would need to be user controlled.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>This change allows an openid
provisioned by one OP to be regarded as a localid by another, where the
two participate in SAML2- style idp-proxying.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Simple change, with major
ramifications to the scope of the OpenID Auth security model. No changes to the
delegation model occur, despite allowing for IDP proxying of user controlled identities
via the delegation mechanism.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>Peter
Williams<br>
<b>Sent:</b> Monday, November 10, 2008 8:16 PM<br>
<b>Cc:</b> OpenID List<br>
<b>Subject:</b> [LIKELY_SPAM]Re: [OpenID] [LIKELY_SPAM]Re: Problems with
delegation and directed identity OPs<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>4.2.1. Relying Parties<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>...<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>openid.claimed_id" is not
defined by OpenID Authentication 1.1. Relying Parties MAY send the value when
making requests, but MUST NOT depend on the value being present in
authentication responses. When the OP-Local Identifier
("openid.identity") is different from the Claimed Identifier, the
Relying Party MUST keep track of what Claimed Identifier was used to discover
the OP-Local Identifier, for example by keeping it in session state. Although
the Claimed Identifier will not be present in the response, it MUST be used as
the identifier for the user. <o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>"openid.identity" MUST
be sent in a authentication request (Responding to Authentication Requests).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Note
in the last sentence, a should be “an” – since folk are
back in editing mode.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>More
importantly, I cannot see how OpenID2 delegation is really that different from
OpenID2 delegation - despite all that’s been said. In OpenID1, keep the
normalized URL, but ask for an assertion about the delegation value. In
OpenID2: RP shall keep the claimed id, but ask for an assertion about the
localid value.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>The
only interesting case seems to be when >1 rounds of discovery occur, in
response to processing one or more unsolicited assertions. If an unsolicited
assertion is indicated, given the RP is retaining the required state for a
request that cited a localid != original cliamedid, presumably the handling
rule above now refers to the claimed id in the unsolicited assertion …
not that in the stored away during initiation of the current round of
discovery/auth. Presumably if a followup round discovery produces (performed as
oneMUST) and another localid != claimed id is determined, the first localid
storage/state is discarded…and a 2<sup>nd</sup>/nth round of auth is
required? Ad infinitum?<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText>-----Original Message-----<br>
From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf Of
Peter Williams<br>
Sent: Sunday, November 09, 2008 10:55 AM<br>
To: Andrew Arnott; Martin Atkins<br>
Cc: OpenID List<br>
Subject: Re: [OpenID] [LIKELY_SPAM]Re: Problems with delegation and directed
identity OPs<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Id recommend an openid.net 1000 word tutorial be written on
the openid2 delgation model, adressing clearely how its security model is
different to openid1.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>I've read and reviewed the openid2 spec several times,
and had not realized that fundamental delegation processes had changed (from
what I saw in the janrain openid1.1 .net code).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Id realized that names and metadata fields had
changed...but not that the security model had changed.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>I had no idea that an op maintained identity page (with
rdf tags, such as that of myopenid) was anything other than a nicety (that
could be entirely eliminated).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>________________________________<o:p></o:p></p>
<p class=MsoPlainText>From: Andrew Arnott <andrewarnott@gmail.com><o:p></o:p></p>
<p class=MsoPlainText>Sent: Saturday, November 08, 2008 5:19 PM<o:p></o:p></p>
<p class=MsoPlainText>To: Martin Atkins <mart@degeneration.co.uk><o:p></o:p></p>
<p class=MsoPlainText>Cc: OpenID List <general@openid.net><o:p></o:p></p>
<p class=MsoPlainText>Subject: [LIKELY_SPAM]Re: [OpenID] Problems with
delegation and directed identity OPs<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Reverting back to OpenID 1.1 style of delegation would
break unsolicited assertions when the OP is asserting a delegated
Identifier. I thought of another scenario or two that would break as well
but I can't think of them at the moment...<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>On Sat, Nov 8, 2008 at 12:05 AM, Martin Atkins
<mart@degeneration.co.uk<mailto:mart@degeneration.co.uk>> wrote:<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>This seems similar to what happened with
clavid.com<http://clavid.com>. When I tested their OP, they would accept
OpenID 2.0 requests but always respond with 1.1 responses. (They may have since
fixed this.)<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>The upshot of this was that the OpenID 1.1 responses
didn't include openid.claimed_id because that argument didn't exist in OpenID
1.1, so things broke.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>There is scope for a careless OP to break delegation by
failing to pass through openid.claimed_id as given. This was a concern I had
when we added that argument in OpenID 2.0; in 1.1, it was the RP's responsibility
to figure out how to maintain that state, and so some RPs did it by adding
stuff to openid.return_to in the request and others maintained state at the RP
server, but either way it was opaque to the OP and passed through correctly
unless the OP did something really bizarre.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>I wonder if it would be a good idea to revert to the
previous approaches for maintaining the delegation state at the RP, since
clearly a faulty OP can break delegation with 2.0 as currently specified. I'm
concerned that as we currently stand some 2.0-compatible libraries will be
preserving this state in a 1.1-compatible way and thus will work correctly with
Google's OP, while others will be relying on openid.claimed_id and break. I
know that Net;:OpenID::Consumer for Perl relies on openid.claimed_id in 2.0
mode, but if that differs from everyone else's implementations I would consider
making it do it the 1.1 way in all cases in order to be resiliant to broken
OPs.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Andrew Arnott wrote:<o:p></o:p></p>
<p class=MsoPlainText>So I whipped up a delegated claimed identifier for
Google. And guess what?! Google's OP is buggy.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>This is my delegated OpenID page that delegates to
Google's OP:<o:p></o:p></p>
<p class=MsoPlainText>http://nerdbank.org/RP/rpgoogle.html<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>It's magic contents are:<o:p></o:p></p>
<p class=MsoPlainText><link rel="openid2.provider"
href="https://www.google.com/accounts/o8/ud"/><o:p></o:p></p>
<p class=MsoPlainText><link rel="openid2.local_id"
href="https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU"/><o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>This works just like any other delegated thing.
Since Google provides pair-wise unique identifiers, I had to first log in to nerdbank.org/RP<http://nerdbank.org/RP>
<http://nerdbank.org/RP> using google directly, find out what identifier
Google assigned for me at that RP, and then stick that into the above local_id
field. Then this delegated page will /only/ work against that RP.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Or at least that's what should happen. In actuality
Google changes the claimed_id though it shouldn't. This is what it
asserts:<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>ClaimedIdentifier:
https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU<o:p></o:p></p>
<p class=MsoPlainText>ProviderLocalIdentifier:
https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU<o:p></o:p></p>
<p class=MsoPlainText>ProviderEndpoint: https://www.google.com/accounts/o8/ud<o:p></o:p></p>
<p class=MsoPlainText>OpenID version: 2.0<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>And this is what was discovered at the delegated identity
page:<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>ClaimedIdentifier: http://nerdbank.org/RP/rpgoogle.html<o:p></o:p></p>
<p class=MsoPlainText>ProviderLocalIdentifier:
https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU<o:p></o:p></p>
<p class=MsoPlainText>ProviderEndpoint: https://www.google.com/accounts/o8/ud<o:p></o:p></p>
<p class=MsoPlainText>OpenID version: 2.0<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>The ClaimedIdentifier has been tampered with. This
Google's OP should note that the auth request was with its local_id but a 3rd
party claimed_id and preserve the claimed_id so that delegation works.
They don't, and delegation breaks.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>So you see, it's not that they use directed identity that
breaks delegation. It's that their OP doesn't preserve the
openid.claimed_id parameter. I'm not sure if this is a strict
contradiction to the spec, but it breaks scenarios, which stinks.<o:p></o:p></p>
<p class=MsoPlainText>I'll send this over to the Google folks and see what they
have to say.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>On Fri, Nov 7, 2008 at 7:17 PM, Andrew Arnott
<andrewarnott@gmail.com<mailto:andrewarnott@gmail.com>
<mailto:andrewarnott@gmail.com<mailto:andrewarnott@gmail.com>>>
wrote:<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> From the spec:<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> Value: (optional) The Claimed Identifier.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> "openid.claimed_id" and
"openid.identity" SHALL be either both<o:p></o:p></p>
<p class=MsoPlainText> present or both absent. If neither value is
present, the assertion<o:p></o:p></p>
<p class=MsoPlainText> is not about an identifier, and will contain
other information in<o:p></o:p></p>
<p class=MsoPlainText> its payload, using extensions (Extensions).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> So you can't include one without the
other. And having neither<o:p></o:p></p>
<p class=MsoPlainText> doesn't provide any authentication at
all. Delegation /should/<o:p></o:p></p>
<p class=MsoPlainText> work, if you had an openid identity page
with a openid2.local_id tag<o:p></o:p></p>
<p class=MsoPlainText> that was exactly the opaque RP-specific
identifier that Google would<o:p></o:p></p>
<p class=MsoPlainText> assign the RP that you are trying to log
into. That would mean<o:p></o:p></p>
<p class=MsoPlainText> you'd need a separate delegate page for
every single RP you log<o:p></o:p></p>
<p class=MsoPlainText> into... but it's theoretically
possible. It would just be a<o:p></o:p></p>
<p class=MsoPlainText> maintenance nightmare. It would be
interesting to test just to see<o:p></o:p></p>
<p class=MsoPlainText> if Google actually implemented the spec
correctly to handle<o:p></o:p></p>
<p class=MsoPlainText> /non/-directed identity scenarios.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> On Fri, Nov 7, 2008 at 5:40 PM, Breno de
Medeiros <breno@google.com<mailto:breno@google.com><o:p></o:p></p>
<p class=MsoPlainText> <mailto:breno@google.com<mailto:breno@google.com>>>
wrote:<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> On Fri, Nov 7, 2008
at 4:48 PM, Allen Tom <atom@yahoo-inc.com<mailto:atom@yahoo-inc.com><o:p></o:p></p>
<p class=MsoPlainText>
<mailto:atom@yahoo-inc.com<mailto:atom@yahoo-inc.com>>> wrote:<o:p></o:p></p>
<p class=MsoPlainText> > Deron
Meranda wrote:<o:p></o:p></p>
<p class=MsoPlainText> >> Of
course, from an OP usability perspective, it's not<o:p></o:p></p>
<p class=MsoPlainText> exactly straight<o:p></o:p></p>
<p class=MsoPlainText> >>
forward for somebody to determine their actual Yahoo<o:p></o:p></p>
<p class=MsoPlainText> identity(-ies),<o:p></o:p></p>
<p class=MsoPlainText> >>
although it is possible.<o:p></o:p></p>
<p class=MsoPlainText> >><o:p></o:p></p>
<p class=MsoPlainText> > We
definitely can improve the usability, but you can list<o:p></o:p></p>
<p class=MsoPlainText> your Yahoo<o:p></o:p></p>
<p class=MsoPlainText> > OpenID
identifiers by going to http://openid.yahoo.com and<o:p></o:p></p>
<p class=MsoPlainText> clicking on<o:p></o:p></p>
<p class=MsoPlainText> > the
"OpenID Home link" at the top of the page.<o:p></o:p></p>
<p class=MsoPlainText> ><o:p></o:p></p>
<p class=MsoPlainText> >> And,
just from curiosity, why are the randomly generated URIs<o:p></o:p></p>
<p class=MsoPlainText> >> (both
Google and Yahoo!) so long?<o:p></o:p></p>
<p class=MsoPlainText> > :)<o:p></o:p></p>
<p class=MsoPlainText> ><o:p></o:p></p>
<p class=MsoPlainText> >> So,
the current Google situation makes it almost impossible<o:p></o:p></p>
<p class=MsoPlainText> to use delegation!<o:p></o:p></p>
<p class=MsoPlainText> >><o:p></o:p></p>
<p class=MsoPlainText> >><o:p></o:p></p>
<p class=MsoPlainText> > Hmm, it
does appear that it's impossible for someone to<o:p></o:p></p>
<p class=MsoPlainText> delegate their<o:p></o:p></p>
<p class=MsoPlainText> > OpenID to
Google.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> The OpenID spec says
that the op_local is an optional field. I think<o:p></o:p></p>
<p class=MsoPlainText> in practice
libraries set identity=claimed_id in this case. I assume<o:p></o:p></p>
<p class=MsoPlainText> it is then unspecified
how the OP validates that the user is<o:p></o:p></p>
<p class=MsoPlainText> authorized over that
URL. That changes nothing from the RP<o:p></o:p></p>
<p class=MsoPlainText> perspective, because
it always has to depend on the OP to make that<o:p></o:p></p>
<p class=MsoPlainText> judgment.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> Bottom line: The
fact that the op_local technique is not<o:p></o:p></p>
<p class=MsoPlainText> available for<o:p></o:p></p>
<p class=MsoPlainText> usage with the
Google OP does not mean that it cannot support<o:p></o:p></p>
<p class=MsoPlainText> delegation.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> ><o:p></o:p></p>
<p class=MsoPlainText> > Allen<o:p></o:p></p>
<p class=MsoPlainText> ><o:p></o:p></p>
<p class=MsoPlainText> ><o:p></o:p></p>
<p class=MsoPlainText> >
_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText> > general
mailing list<o:p></o:p></p>
<p class=MsoPlainText> >
general@openid.net<mailto:general@openid.net>
<mailto:general@openid.net<mailto:general@openid.net>><o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> >
http://openid.net/mailman/listinfo/general<o:p></o:p></p>
<p class=MsoPlainText> ><o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> --<o:p></o:p></p>
<p class=MsoPlainText> --Breno<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> +1 (650) 214-1007
desk<o:p></o:p></p>
<p class=MsoPlainText> +1 (408) 212-0135
(Grand Central)<o:p></o:p></p>
<p class=MsoPlainText> MTV-41-3 : 383-A<o:p></o:p></p>
<p class=MsoPlainText> PST (GMT-8) /
PDT(GMT-7)<o:p></o:p></p>
<p class=MsoPlainText>
_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText> general mailing list<o:p></o:p></p>
<p class=MsoPlainText>
general@openid.net<mailto:general@openid.net>
<mailto:general@openid.net<mailto:general@openid.net>><o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>
http://openid.net/mailman/listinfo/general<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>------------------------------------------------------------------------<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>general mailing list<o:p></o:p></p>
<p class=MsoPlainText>general@openid.net<mailto:general@openid.net><o:p></o:p></p>
<p class=MsoPlainText>http://openid.net/mailman/listinfo/general<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>general mailing list<o:p></o:p></p>
<p class=MsoPlainText>general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>http://openid.net/mailman/listinfo/general<o:p></o:p></p>
</div>
</body>
</html>