[OpenID] Identity-less OpenID

Andrew Arnott andrewarnott at gmail.com
Thu May 7 21:41:34 UTC 2009


I don't think the two parties have to come to any agreement for it to
be useful. Take the Google OP for example. An RP could skip the email
verification step if a user enters a gmail address by sending an AX
request to Google. This hypothetical RP doesn't want google's claimed
identifier for this user--just the email. This RP trusts Google and if
Google sends the same email back in the AX response then the email is
verified.

If you want to verify organization membership then yes some kind of AX
attribute will have to have an agreed use between the two parties to
be very useful.

On Thursday, May 7, 2009, Breno de Medeiros <breno at google.com> wrote:
> Andrew,
>
> I happen to agree that the feature is potentially useful. However, it
> requires prior agreement between the two parties about what a "group"
> is. Do you mean simply that the user can authenticate herself to the
> OP?
>
> On Thu, May 7, 2009 at 9:33 AM, Peter Williams <pwilliams at rapattoni.com> wrote:
>> i have to admit, I know nothing about Sxip protocols or directions. Ive only ever followed standards. ONly through standards does one address scale and fair competition between vendors.
>>
>> But, the feature was always intriguing. It implied, along with delegation, that openid protocol entities operating in a more advanced application context could be stateful over even multiple transactions.
>>
>> In the WS-SX world, before a soap xml document gets send over a binding, multiple transactions are performed by the communication bearer - to prepare a secure channel for the message exchange pattern. I always imagined the openid identityless feature facilitating what WS-SX facilitates, performing multiple communication-transactions - borne in openid extensions - that negotiate the requirement (crypto, timeliness, addressing) & policies of the endpoints. This is all in preparation, of course, for the MEP transactions the user is actually confirming with an identity transaction.
>>
>> In formal assurance language, the openid identitiy transaction would be known the identity protocol, which must complete to establish the security association.. identity-less transactions would be used when creating/maintaining/re-building the security association. Once there is an association or re-association that satisfied policies, then there can then be the actual exchange of information objects.
>>
>> ________________________________
>> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Johannes Ernst [jernst+openid.net at netmesh.us]
>> Sent: Thursday, May 07, 2009 8:40 AM
>> To: Andrew Arnott
>> Cc: general
>> Subject: Re: [OpenID] Identity-less OpenID
>>
>>
>> On May 6, 2009, at 21:22, Andrew Arnott wrote:
>>
>> The OpenID 2.0 spec allows for checkid_* messages to omit openid.identity and openid.claimed_id in order to send a message whose useful is entirely in the extensions it carries.  For a long time I thought "what's the point of that??" but I finally found a use case.  So I'm adding built-in support for it into DotNetOpenAuth both at the RP and OP sides.  Now that I've done it, I'm checking various OPs to see if they support it.  Google: no, myopenid.com<http://myopenid.com>: no, Yahoo.com: no, myvidoop.com<http://myvidoop.com>: no.  I'm out of OPs that I'd have guessed had any chance of supporting it. (Actually, I guess myvidoop.com<http://myvidoop.com> didn't have a chance since they only do a strange mixture of OpenID 1.1 with some 2.0 features support).  My favorite part of this is that every OP says there's something wrong with the request, instead of "this feature isn't supported."
>>
>> Does anyone know of an OP that actually supports this feature?  (or an RP that uses it?)  I'm puzzled that such a feature was included in the spec without anyone driving for its support.
>>
>> I believe this was one of Sxip's contributions that was closer to the roots of the original Sxip protocols that weren't driven by a unique identifier / URL.
>>
>>
>>
>> In case you're interested in the scenario in which this is useful, here it is:  Remember past threads where I've advocated against an organization becoming an OP just so RPs can force users to log in with that OP to verify some membership in the organization?    The alternative that I had proposed was for that org to set up an OAuth SP. While that idea is still valid, it might be the only reason for that org and an RP to add OAuth support, which may not be trivial.  If, on the other hand, the RP sent an identity-less OpenID request to the org's OP, with an "organization member check" extension request, then the OP could issue a positive assertion that carries no identity, but can assert that yes, the user is in fact a member of the org.  Of course the OP would still have to authenticate the user somehow, but the RP and OP would not have to agree on an Identifier to use for referring to the person.
>>
>> In fact there are many times perhaps when the RP doesn't care h> http://openid.net/mailman/listinfo/general
>>
>>
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>

-- 
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - Voltaire



More information about the general mailing list