[OpenID] Delegation leading to new accounts on websites

Mon Jun 22 16:43:37 UTC 2009

Hi George,

Just some terminology refinements for you:

The identifier entered by the user is called the "User-supplied identifier",
which may be a URI or an XRI.
After discovery/resolving you get the "Claimed Identifier" which may be a
URI or an i-number and an OP Local Identifier.
The positive assertion still contains a Claimed Identifier and OP Local
Identifier, but they may not be the same ones as the ones sent in the
request, as you point out.
--
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

On Mon, Jun 22, 2009 at 8:44 AM, George Fletcher <gffletch at aol.com> wrote:

> 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
>
> Andrew Arnott wrote:
>
>> In my opinion and/or experience...
>>
>> Whether you use XRDS or HTML tags has nothing to do with getting Yahoo
>> working with delegation.  Only the RP cares about how you set up the
>> delegation.  So if Yahoo is not honoring the delegated identifier then
>> either Yahoo is broken, or the RP is not performing discovery correctly.  If
>> using XRDS fixes it, then the problem was at the RP rather than Yahoo!
>>
>> I just tested it, and Yahoo treats a delegated checkid_setup as a directed
>> identity request regardless of what the openid.claimed_id value is.
>> Google doesn't support delegation at all.  Some concern about asserting an
>> Identifier it has no control over..., and then there's the fact that you
>> have no local_id to use except an arbitrarily picked anonymous identifier
>> they assigned to you for a particular RP, which doesn't work when passed as
>> a local_id.
>>
>> So yes, delegation is a great OpenID feature to be able to switch
>> Providers without changing your identity.  But you'll have to pick OPs other
>> than Google and Yahoo.
>> --
>> 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
>>
>>
>> On Sun, Jun 21, 2009 at 4:54 PM, Peter Williams <pwilliams at rapattoni.com<mailto:
>> pwilliams at rapattoni.com>> wrote:
>>
>>    try using the X-XRDS-... trick, for use by YADIS. All the metadata
>>    is the in the XRD instead,as located by the X-XRDS-... header.
>>
>>    We had it working last week with Yahoo (but not with Google), when
>>    we used XRD file.
>>
>>    With Yahoo, it didn't seem to matter what you put in the Service's
>>    LocalID - which makes sense if you think about the semantics of
>>    LocalID. But, in the context of openid discovery, I THOUGHT (given
>>    the UCI security model) citation of localID in a vanity XRD was
>>    supposed to REQUIRE Yahoo (the OP) to use the directed id of the
>>    user's choice (assuming there are several)!
>>
>>    if someone can, please point to a public, working trial of
>>    delegating to Google Accounts OP. Its an important milestone for
>>    openid - when vanity XRDs are properly handled by all the major
>>    OPs, including FaceBook, Google etc. We know openid is balancing
>>    commercial and personal interests then. A technology that (a)
>>    works in practice, and (b) somehow balances such contrary
>>    interests is, of course a world beater (like SSL!)
>>
>>    ________________________________________
>>    From: general-bounces at openid.net
>>    <mailto:general-bounces at openid.net> [general-bounces at openid.net
>>    <mailto:general-bounces at openid.net>] On Behalf Of Tom Edwards
>>    [t_edwards at btinternet.com <mailto:t_edwards at btinternet.com>]
>>    Sent: Sunday, June 21, 2009 3:21 PM
>>    To: general at openid.net <mailto:general at openid.net>
>>    Subject: [OpenID] Delegation leading to new accounts on websites
>>
>>    My personal OpenID server broke a while back, and I've decided this
>>    evening to start delegating in order continue using my personal URL
>>    (<http://steamreview.org>). This is the code now in my page header:
>>    > <link rel="openid.delegate openid2.local_id"
>>    > href="http://www.flickr.com/photos/varsity/" />
>>    > <link rel="openid.server openid2.provider"
>>    > href="https://open.login.yahooapis.com/openid/op/auth" />
>>    But when I login to the sites I used my openid on before it broke
>>    (I've
>>    tried Get Satisfaction and Userstyles.org so far), they don't
>>    recognise
>>    me as an pre-existing user. They think I'm
>>    www.flickr.com/photos/varsity/
>>    <http://www.flickr.com/photos/varsity/>, whereas I actually still
>>    want to be
>>    steamreview.org <http://steamreview.org>.
>>
>>    Is this intended behaviour? I thought the point of delegation was to
>>    allow people to switch providers without changing consumer-facing
>>    identity.
>>
>>    _______________________________________________
>>    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 <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/20090622/e8868d31/attachment.htm>