[OpenID] Delegation leading to new accounts on websites

[Peter Williams]

John: "You are free to choose URI from google or anyplace else to use as your
OP Local identifier and hence the openid.identity."

Johnny: "The relationship between the delegated identifiers and the OP is unidirectional: OPs need to keep track and recognize the local_id's they have issued (just like any other user/account identifiers), but the local_id is not required to be discoverable and point back to the OP (and no reason for the RP, as far as the protocol is concerned, to expect this).

For John, user's control the local id.

For Johnny, OPs control the OP local identifier.

One is the correct  validation logic of the auth-res protocol of XRI REsolution; the other is the validation logic overlay of an XRDS applciation (openid auth v2). They are not consistent, and need not be - since openid auth v2 RP is not an XRI resolution user: its formally a XRDS application.

The fact that an XRDS application like an openid RP MAY use XRI resolution to discover and retrieve a (cached) XRD does not mean it MUST apply XRI Reslution validation logic in the context of the XRDS application protocol.

It does appear that some OPs are implementing _additional_ non-standard XRI validation logic element (but only elements thereof) when acting in support of the ehnaced XRDS application protocol (openid auth v2 used in offloading OP and RP sites to a service bus): when acting as an OP service bus for outsourced OP-domains, SOME folks are evidently using canonical-id verification from the XRI resolver spec to detect whether the outsourcer (service bus) has rights to speak for the customer-domain's namespace. This requires full XRI validation logic at the OP to be invoked, including canonical-id verification and canonical-equiv-id verification.

if a service bus similarly outsources to replying party domains (as in RPX), then the RP service bus will act similarly.

AS far as I can tell, the main thurst of the Google/TC proposal is to avoid OP-service bus and RP-service parties using the validation logic of XRI resolution as noted above - in favor of explicit signals provided in a signed XRD's Google-SEP (another type of XRDS application, formally). This is merely an embodiment of a semantically-equivalent process specified in later X.509 revision, in which two policy domains, each operating in a different directory management domain, may cross map their policy identifiers/URLs AND their namespaces in a signed cross-certificate. Rather than use an SEP, X.509 uses a v3 policy mapping standard extensions.

I don't find it surprising that folks cannot really follow this topic: its just abstrusely presented, and not aall of it is even in the spec. It's all in the vendors "art". - much like all the art of being a VeriSign CA is not in using the open bit format or the signing but in the "certification practice statement" that characterizes the unique assurance services.
________________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of John Bradley [john.bradley at wingaa.com]
Sent: Monday, July 13, 2009 7:55 AM
To: general at openid.net
Subject: Re: [OpenID] Delegation leading to new accounts on websites

You are free to choose URI from google or anyplace else to use as your
OP Local identifier and hence the openid.identity.

The only constraint is that they be http, https or XRI.

The confusing thing for new people is that it's the openid.identity
that gets validated by the OP,  but that is only within the context of
that OP and not globally.
The only globally validated identifier is the openid.claimed_id and
that is validated through discovery, but only if the local validation
of "OP Local Identifier"  is successful.

The bottom line is that in openid 2.0 the RP cannot use the
openid.identity as an identity for the user.

I see people get this wrong too often.

John B.
On 13-Jul-09, at 9:10 AM, general-request at openid.net wrote:

> Date: Sun, 12 Jul 2009 21:08:32 -0700
> From: SitG Admin <sysadmin at shadowsinthegarden.com>
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
> To: Johnny Bufu <johnny.bufu at gmail.com>
> Cc: general at openid.net
> Message-ID: <f06110400c68062c3cb4f@[192.168.0.2]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>> The encoding scheme can be a OP internal deployment detail, since no
>> other party actively processes the local_id's; the URLs do not need
>> to be dereferenceable either.
>
> So, to actively confuse any 3rd party that *tries* to process my
> local_id's, I can scramble the external_id:local_id mapping until
> each external_id is known to my OP as a string exactly identical to
> *another* external_id?
>
> -Shade

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general