[OpenID] general Digest, Vol 34, Issue 61
Ján Uličný
jnln19728 at gmail.com
Tue Jun 23 16:47:31 UTC 2009
SOS-ja neviem ako som sa k vám dostal neviem o čo sa jedná ,prosím o
odhlásenie-dakujem.
2009/6/23 <general-request at openid.net>
> Send general mailing list submissions to
> general at openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://openid.net/mailman/listinfo/general
> or, via email, send a message with subject or body 'help' to
> general-request at openid.net
>
> You can reach the person managing the list at
> general-owner at openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of general digest..."
>
> Today's Topics:
>
> 1. Re: Delegation leading to new accounts on websites
> (George Fletcher)
> 2. Re: Delegation leading to new accounts on websites
> (Andrew Arnott)
> 3. Re: Delegation leading to new accounts on websites (Allen Tom)
> 4. Re: Delegation leading to new accounts on websites
> (Peter Williams)
>
>
> ---------- Správa poslaná ďalej ----------
> From: George Fletcher <gffletch at aol.com>
> To: Allen Tom <atom at yahoo-inc.com>
> Date: Tue, 23 Jun 2009 10:27:26 -0400
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
> Thanks Allen, good to know.
>
> I'm assuming for this behavior to work, the user must first have enabled
> their flickr URL as an OpenID. When I try with a flickr URL that is not yet
> enabled as an OpenID then I get the "directed identity" behavior. This is
> the behavior I described in my flow earlier.
>
> The confusion comes in that the RP MUST do late binding and can NOT assume
> that the identifier entered by the user is valid for the session. As long as
> the RP ignores what the user entered if the AuthN request claimed_id does
> not equal the AuthN response claimed_id there will be no mis-identity
> issues.
>
> Thanks,
> George
>
> Allen Tom wrote:
>
>> Hi George,
>>
>> If you type in your Flickr Photos URL into the RP's OpenID text box, the
>> Yahoo OP will return your Flickr Photos URL as your OpenID, instead of the
>> the https://me.yahoo.com/<randomstring> identifier in the response.
>>
>> However, if you type in "flickr.com", we'll assume directed identity, and
>> we'll display a drop down for you to select which OpenID (the Flickr one, or
>> the machine generated one) in the response.
>>
>> Note: you must type in http://www.flickr.com/photos/gffphotos and not
>> htttp://flickr.com/photos/gffphotos.
>>
>> Hope that helps,
>> Allen
>>
>>
>> George Fletcher wrote:
>>
>>> If I understand this correctly...
>>>
>>> 1. I enter http://www.flickr.com/photos/gffphotos (shameless plug for my
>>> photo stream:)
>>> 2. The RP normalizes the "user entered identifier" (in this case it's
>>> the same URL)
>>> 3. The RP does discovery on the "user entered identifier" and the HTML
>>> defines the OP as yahoo (no local_id)
>>> 4. The RP sends the AuthN request with openid.identity=
>>> http://www.flickr.com/photos/gffphotos
>>> 5. Yahoo ignores the openid.identity field and does directed identity
>>> 6. Yahoo sends back an openid.claimed_id=https://me.yahoo.com/
>>> <randomstring>
>>> 7. Since the openid.identity value the RP sent does not equal the value
>>> the OP returned, the RP does discovery on the https://me.yahoo.com/
>>> <randomstring>
>>> 8. Discovery shows that the yahoo OP is indeed authoritative for the URL
>>> 9. The RP has to ignore the value entered by the user (e.g.
>>> http://www.flickr.com/photos/gffphotos) and just use the value the OP
>>> returned (e.g. https://me.yahoo.com/<randomestring>) because there is no
>>> way to know whether the returned identifier from yahoo actually maps to the
>>> value entered by the user
>>>
>>> The following is also true if I try and delegate my vanity URL to an
>>> flickr based OpenID.
>>>
>>> I believe that if the RP sends an identifier for the user that is NOT the
>>> directed identity select URL, then the OP should either (A) authenticate
>>> only the specified identity or (B) fail the request. Allowing the request to
>>> succeed but for an identity totally different than what the user identified
>>> to the RP is just confusing.
>>>
>>> Thanks,
>>> George
>>>
>>> P.S. More comments inline
>>>
>>> John Bradley wrote:
>>>
>>>> George,
>>>>
>>>> The combination of directed identity is still a real interop issue
>>>> because it is not well explained in openID 2.0.
>>>>
>>>> When the claimed_id (less fragment) or the identity are different in
>>>> the response from the request the RP must rediscover the openid.claimed_id.
>>>>
>>>> If delegation was done the openid.identity must match the LocalID in the
>>>> XRD.
>>>>
>>> I don't think this will work in the Yahoo case. The openid.identity value
>>> returned by Yahoo is the https://me.yahoo.com/<randomstring>. If I do a
>>> discovery on this identifier, it case say that the "LocalID" at Yahoo is the
>>> same value, but that doesn't mean it matches to the URL the user entered at
>>> the RP. If the XRDS response, somehow ties the directed identity value back
>>> to the flickr URL the all the pseudonymous benefits of directed identity are
>>> broken.
>>>
>>>>
>>>> If the RP doesn't do this step anyone with a Yahoo account can log into
>>>> any openID that is delegated to Yahoo.
>>>>
>>> It isn't the discovery of the returned openid.claimed_id value that
>>> protects against this case. It's the fact that the RP ignores the value the
>>> user entered and even it's associated local_id value and instead just uses
>>> the values returned by the OP. It is impossible to associate in anyway the
>>> value the user entered with the value the OP returns.
>>>
>>>>
>>>> Yahoo is following the spec as intended. There is an OSIS test for RPs
>>>> to check if they are vulnerable to this.
>>>>
>>>> If the second discovery verifies then 1 can still be used safely as the
>>>> users identifier.
>>>>
>>>> I had to sit Johnny Bufu down to explain it to me what they intended
>>>> when they wrote 2.0.
>>>>
>>>> I couldn't extract the logic from the spec itself for the delegating to
>>>> a directed identity flow.
>>>>
>>>> John B.
>>>>
>>>> On 22-Jun-09, at 11:45 AM, general-request at openid.net <mailto:
>>>> general-request at openid.net> wrote:
>>>>
>>>> Date: Mon, 22 Jun 2009 11:44:03 -0400
>>>>> From: George Fletcher <gffletch at aol.com <mailto:gffletch at aol.com>>
>>>>> Subject: Re: [OpenID] Delegation leading to new accounts on websites
>>>>> To: Andrew Arnott <andrewarnott at gmail.com <mailto:
>>>>> andrewarnott at gmail.com>>
>>>>> Cc: "general at openid.net <mailto:general at openid.net>" <
>>>>> general at openid.net <mailto:general at openid.net>>
>>>>> Message-ID: <4A3FA6C3.9060305 at aol.com <mailto:4A3FA6C3.9060305 at aol.com
>>>>> >>
>>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>>>
>>>>> Isn't one of the underlying issues the fact that there are really 3
>>>>> identifiers in this scenario?
>>>>> 1. the identifier entered by the user (claimed_id or i-name)
>>>>> 2. the discovered/resolved identifier ("local_id" or "i-number")
>>>>> 3. the identifier returned by the OP
>>>>>
>>>>> In the case of OpenID 2.0 protocol flow, the RP has to remember #1 and
>>>>> send #2 as the openid.identity parameter. If the OP does NOT return
>>>>> openid.identity == #2, then the OP has chosen to do directed identity
>>>>> regardless of the request and the RP must throw out #1 and take #3 as the
>>>>> user's identifier.
>>>>>
>>>>> This causes some weird user experience issues, but this is what we ran
>>>>> into when implementing OpenID 2.0 Relying Party support.
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>
>>>> =
>>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>
>>
>>
>
>
> ---------- Správa poslaná ďalej ----------
> From: Andrew Arnott <andrewarnott at gmail.com>
> To: Tom Edwards <t_edwards at btinternet.com>
> Date: Tue, 23 Jun 2009 08:59:34 -0700
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
> Just a guess that sourceforge probably worked because its OpenID support is
> old and buggy (no offense, anyone!) and if it only does OpenID 1.x, then RPs
> in that version did their own delegation management instead of giving the
> OPs a chance to change it.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> 2009/6/23 Tom Edwards <t_edwards at btinternet.com>
>
>> I've tried both delegation URLs on several sites, but the only one that
>> recognises me as steamreview.org in either scenario is SourceForge. The
>> others I tried are:
>>
>> - getsatisfaction.com
>> - pbworks.com
>> - wishlistr.com
>> - stackoverflow.com
>>
>> These all thought I was flickr.com/blah/ or yahoo.com/blah/ - I was only
>> steamreview.org when delegating to <http://steamreview.org/openid/><http://steamreview.org/openid/>
>> .
>>
>> Yahoo only supports OpenID 2 while my server (PhpMyID) only supports
>> OpenID 1. Could this be making a difference?
>>
>> This process would be a lot more reliable if the openidenabled.com test
>> suite was working. :-(
>>
>>
>> Allen Tom wrote:
>>
>> Hi John -
>>
>> Your description accurately describes how the Yahoo OP is implemented, and
>> it is the RP's responsibility to keep track of the user's URL that was
>> delegated to the OP.
>>
>> One possible possible issue is that Flickr itself delegates to Yahoo, so
>> users are probably better off delegating to their default machine generated
>> Yahoo OpenID (of the form https://me.yahoo.com/a/<random string>) than to
>> to their Flickr Photos url.
>>
>> Tom - can you try delegating your personal URL to your default Yahoo
>> OpenID? This will eliminate the extra round trip to Flickr, which is
>> probably causing your problem. The easiest way to find out what your Yahoo
>> OpenID is to go here:
>>
>> http://openid.yahoo.com/
>> Click Get Started
>> Type in your password
>> and take a look at the identifiers at the bottom of the screen.
>>
>> Unfortunately, this doesn't seem to work on GetSatisfaction. :/
>> Allen
>>
>>
>>
>> John Bradley wrote:
>>
>> George,
>> The combination of directed identity is still a real interop issue
>> because it is not well explained in openID 2.0.
>>
>> When the claimed_id (less fragment) or the identity are different in
>> the response from the request the RP must rediscover the openid.claimed_id.
>>
>> If delegation was done the openid.identity must match the LocalID in the
>> XRD.
>>
>> If the RP doesn't do this step anyone with a Yahoo account can log into
>> any openID that is delegated to Yahoo.
>>
>> Yahoo is following the spec as intended.
>>
>> There is an OSIS test for RPs to check if they are vulnerable to this.
>>
>> If the second discovery verifies then 1 can still be used safely as the
>> users identifier.
>>
>> I had to sit Johnny Bufu down to explain it to me what they intended
>> when they wrote 2.0.
>>
>> I couldn't extract the logic from the spec itself for the delegating to
>> a directed identity flow.
>>
>> John B.
>>
>> On 22-Jun-09, at 11:45 AM, general-request at openid.net wrote:
>>
>> Date: Mon, 22 Jun 2009 11:44:03 -0400
>> From: George Fletcher <gffletch at aol.com>
>> Subject: Re: [OpenID] Delegation leading to new accounts on websites
>> To: Andrew Arnott <andrewarnott at gmail.com>
>> Cc: "general at openid.net" <general at openid.net>
>> Message-ID: <4A3FA6C3.9060305 at aol.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Isn't one of the underlying issues the fact that there are really 3
>> identifiers in this scenario?
>> 1. the identifier entered by the user (claimed_id or i-name)
>> 2. the discovered/resolved identifier ("local_id" or "i-number")
>> 3. the identifier returned by the OP
>>
>> In the case of OpenID 2.0 protocol flow, the RP has to remember #1 and
>> send #2 as the openid.identity parameter. If the OP does NOT return
>> openid.identity == #2, then the OP has chosen to do directed identity
>> regardless of the request and the RP must throw out #1 and take #3 as
>> the user's identifier.
>>
>> This causes some weird user experience issues, but this is what we ran
>> into when implementing OpenID 2.0 Relying Party support.
>>
>> Thanks,
>> George
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> general mailing listgeneral at openid.nethttp://openid.net/mailman/listinfo/general
>>
>>
>>
>
>
> ---------- Správa poslaná ďalej ----------
> From: Allen Tom <atom at yahoo-inc.com>
> To: Tom Edwards <t_edwards at btinternet.com>
> Date: Tue, 23 Jun 2009 09:16:46 -0700
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
> Tom Edwards wrote:
>
>
> Yahoo only supports OpenID 2 while my server (PhpMyID) only supports OpenID
> 1. Could this be making a difference?
>
> Hi Tom,
>
> I suspect that the fact that you're delegating to an OP that only supports
> OpenID 2.0 is probably causing some compatibility problems.
>
> The Yahoo OP does support delegation, and to the best of our knowledge, we
> are correctly implementing the OpenID 2.0 spec with regards to delegation.
> That being said, the OpenID 2.0 spec is a bit ambiguous regarding how
> delegation is supposed to work. Hopefully this can be cleared up in OpenID
> 2.1.
>
> If you do need backwards compatibility with OpenID 1.1, as well as support
> for OpenID 2.0, then delegating to MyOpenID.com seems to work pretty well.
>
> Allen
>
>
>
>
>
> ---------- Správa poslaná ďalej ----------
> From: Peter Williams <pwilliams at rapattoni.com>
> To: "general at openid.net" <general at openid.net>
> Date: Tue, 23 Jun 2009 09:21:48 -0700
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
>
> We know from the old Bufu rule that the RP is responsible for testing that
>
> "(identity claim == subscriber.OP.XRD[localID]) is element of
> user.XRD[localIDset]" ,
>
> through an act of RP-discovery.
>
> The RP is ALSO responsible for testing that yahoo.com has authority to
> make cross-realm claims (release a authoritative identity claim for the
> realm of homepw.org, which is outside the asserting parties OP-identifier
> realm of yahoo.com).
>
> But how do I as RP test that Yahoo is so authorized?
>
> Put in activeDirectory terms that a million Windows MCSEs can understand,
> how do I test that any one of 10 different UPNs in 10 different domains (
> peter at rapattoni.com<mailto:peter at rapattoni.com>, peter at homepw.com<mailto:
> peter at homepw.com>, ...) is "rapnt.com/pwilliams"?
>
> Some synonym service has to be attesting to the cross-realm
> OP-identifier-bridging - and it cannot be the OP itself. under my RP
> obligations, I have to be able to authenticate the synonym service, and
> determine its authoritive for some synonym mesh.
>
> In the delegation case, checking for LocalID intersections in the
> delegated-XRD and OP-XRD is not sufficient. One must discover the XRD for
> the OP identifier underlying the rapattoni.com or homepw.org domains that
> yahoo MAY provide as identity claims. I must ensure OP identifier underlying
> the claim's domain links back to OP identifier for the assertion domain -
> myopenid.com L authorizing the act of outsourcing (and the cross-domain
> assertion power).
>
> All we have done of course is obligate the RP to discover/create now a
> "chain" of XRDs, much like one has chains of authority certs in SSL! But
> then, what is an XRDS, but a chain of XRD elements? And, in the XRI
> resolution case, chain formation is done for you, where the particular
> chaining "route" is discovered in the delegation flow according to the
> user-controlled priorities and redirects/referalls - user-centric trust
> fabrics. If the user's vanity-XRD is being servered by an actual XRI server
> (in walled garden mode), that user gets a synonym-management service, of
> course. It _overlays_ the user-centric trust fabric of "who is authoritive",
> even when cooperating with OP identifiers that are perhaps formally
> registered in the public XRI space.
>
> ________________________________
> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of
> Allen Tom [atom at yahoo-inc.com]
> Sent: Monday, June 22, 2009 10:48 PM
> To: John Bradley; general at openid.net; t_edwards at btinternet.com; Andrew
> Arnott
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
>
> Hi John -
>
> Your description accurately describes how the Yahoo OP is implemented, and
> it is the RP's responsibility to keep track of the user's URL that was
> delegated to the OP.
>
> One possible possible issue is that Flickr itself delegates to Yahoo, so
> users are probably better off delegating to their default machine generated
> Yahoo OpenID (of the form https://me.yahoo.com/a/<random string>) than to
> to their Flickr Photos url.
>
> Tom - can you try delegating your personal URL to your default Yahoo
> OpenID? This will eliminate the extra round trip to Flickr, which is
> probably causing your problem. The easiest way to find out what your Yahoo
> OpenID is to go here:
>
> http://openid.yahoo.com/
> Click Get Started
> Type in your password
> and take a look at the identifiers at the bottom of the screen.
>
> Unfortunately, this doesn't seem to work on GetSatisfaction. :/
> Allen
>
>
>
> John Bradley wrote:
> George,
>
> The combination of directed identity is still a real interop issue because
> it is not well explained in openID 2.0.
>
> When the claimed_id (less fragment) or the identity are different in the
> response from the request the RP must rediscover the openid.claimed_id.
>
> If delegation was done the openid.identity must match the LocalID in the
> XRD.
>
> If the RP doesn't do this step anyone with a Yahoo account can log into any
> openID that is delegated to Yahoo.
>
> Yahoo is following the spec as intended.
>
> There is an OSIS test for RPs to check if they are vulnerable to this.
>
> If the second discovery verifies then 1 can still be used safely as the
> users identifier.
>
> I had to sit Johnny Bufu down to explain it to me what they intended when
> they wrote 2.0.
>
> I couldn't extract the logic from the spec itself for the delegating to a
> directed identity flow.
>
> John B.
>
> On 22-Jun-09, at 11:45 AM, general-request at openid.net<mailto:
> general-request at openid.net> wrote:
>
> Date: Mon, 22 Jun 2009 11:44:03 -0400
> From: George Fletcher <gffletch at aol.com<mailto:gffletch at aol.com>>
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
> To: Andrew Arnott <andrewarnott at gmail.com<mailto:andrewarnott at gmail.com>>
> Cc: "general at openid.net<mailto:general at openid.net>" <general at openid.net
> <mailto:general at openid.net>>
> Message-ID: <4A3FA6C3.9060305 at aol.com<mailto:4A3FA6C3.9060305 at aol.com>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Isn't one of the underlying issues the fact that there are really 3
> identifiers in this scenario?
> 1. the identifier entered by the user (claimed_id or i-name)
> 2. the discovered/resolved identifier ("local_id" or "i-number")
> 3. the identifier returned by the OP
>
> In the case of OpenID 2.0 protocol flow, the RP has to remember #1 and
> send #2 as the openid.identity parameter. If the OP does NOT return
> openid.identity == #2, then the OP has chosen to do directed identity
> regardless of the request and the RP must throw out #1 and take #3 as
> the user's identifier.
>
> This causes some weird user experience issues, but this is what we ran
> into when implementing OpenID 2.0 Relying Party support.
>
> Thanks,
> George
>
>
> ________________________________
>
> _______________________________________________
> general mailing list
> general at openid.net<mailto:general at openid.net>
> http://openid.net/mailman/listinfo/general
>
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090623/f1e61adb/attachment.htm>
More information about the general
mailing list