[OpenID] Delegation leading to new accounts on websites

[John Bradley]

Yes the delegated openid.identity is issued by the OP but in the case  
of delegation the openid.claimed_id is not.

If as an example we have a psydonomous id type that a RP can request  
via PAPE or some other extension and someone has delegated to that OP  
say Google, then Google has no control over the claimed_id and the  
resulting assertion may violate the non-correlation privacy policy.

If for example the OP is assessing some profile that mandates a  
particular password strength etc.   The OP has no knowledge of how the  
XRD doing the delegating is secured.

I am saying that with delegation some of the security is outside of  
the control of the OP and hence the OP can't be authoritative for it  
and may not be able to make the same PAPE or other assertions  
regarding it.

There might be a legitimate reason for an OP not to support delegation  
under some limited circumstances.
However most of the time it shouldn't be a problem as long as RPs are  
properly validating the returned assertions and not believing the  
openid.identity is something it is not.

John B.

On 7-Jul-09, at 7:03 PM, Johnny Bufu wrote:

> On Tue, Jul 07, 2009 at 05:56:36PM -0400, John Bradley wrote:
>> It is true that the OP is validating the openid.identity
>> but in openID 2.0 the RP can no longer trust using that as a  
>> identity.
>
> The RP is not required to trust the openid.identity; if it chooses  
> to do
> so it would be out of scope of the protocol.
>
>> With delegation the openid.identity is possibly a arbitrary URI  
>> that the
>> OP will treat as a local identifier and verify but has no authority  
>> over.
>
> Doesn't even have to be a URI even; what matters is that the OP issues
> it, so they (can) have full control/authority over it if that's a
> concern for them.
>
>> If the openid.claimed_id is different from the openid.identity the RP
>> performs discovery on the claimed_id to verify it.
>>
>> So while the OP may be verifying the openid.identity no RP should  
>> assume
>> that proves any control over that URI in openID 2.0.
>>
>> The openid.claimed_id is the only identity that the RP should use.   
>> The
>> ownership is proved via discovery independent of the OPs authority  
>> over
>> the URI.
>
> Right, with the same mention that proving control over the delegated
> identifier / local_id is not in the scope of the protocol. There's no
> authoritative party defined for it, discovery is never performed on  
> the
> delegated identifier.
>
> 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).
>
>> In some higher security applications where the RP is relying on the  
>> OP
>> being audited against some profile ie attribute verification.
>> I can see the problem a RP may have accepting a delegated openID as
>> conforming to some profile even if the OP conforms to the profile.
>>
>> I think an OP needs to be cautious about what it asserts for a
>> claimed_id it is not authoritative for.
>
> I don't see an issue here either, since the delegated  
> openid.identity is
> issued by the OP.
>
>
> Johnny