[OpenID] Too many providers... and here's one reason

[Andrew Arnott]

There is no trusted OP in my ideal scenario... unless it was the Org's OP in
question, but I'm trying to avoid creating that... or at least the need to
log in with that Org's OP.
With an XRI, is there no way to add a <Service> in the XRDS file that
somehow would point to the Org in some special way that could (with
programming on the RP's side) allow the RP to contact the Org
programmatically and check membership?  The XRDS seems like an ideal place
to put it.

On Mon, Sep 15, 2008 at 4:52 PM, Nate Klingenstein <ndk at internet2.edu>wrote:

> Andrew,
>
> As long as the identifier itself is both the expression of membership and
> inextricably linked to a DNS name, your scenario is pretty difficult to
> realize without placing requirements on the organization that many today
> would judge impractical.  The obvious answer is to send an attribute that
> represents "this is a member of organization XYZ", and allow the trusted OP
> to assert that information on behalf of organization XYZ.
>
> However, OpenID support for attributes has been mostly theoretical to this
> point in time.  I would like to see that change, but there's a lot of
> inertia now and a huge focus on imputing meaning to the identifier itself.
>
> Take care,
> Nate.
>
>
> On 15 Sep 2008, at 23:45, Andrew Arnott wrote:
>
>  How can an RP accept an OpenID Identifier from arbitrary OPs, but at each
>> login determine whether the Identifier represents a user who belongs to a
>> particular Organization?  Basically the Organization needs to send an
>> assertion about the Identifier's membership, but only be willing to do so if
>> that identifier is confirmed as having logged in successfully to that RP.
>>  This would be easy to do if that Org was an OP, but I'm trying to reduce
>> the # of reasons to be an OP.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080915/6d5979ab/attachment-0002.htm>