OpenID-style Group Proposal
dick at sxip.com
Tue Aug 1 05:00:26 UTC 2006
Another use case is that I want to prove that I am part of group X,
without disclosing my specific identity.
I could provide the group URL to the RP which then send me to the IdP
for that URL (Group IdP) where I then enter my OpenID URL which then
acts as an RP to check if I am in the group. If I am in the group,
then the Group IdP responds to the original RP.
An RP may not even know that it was a group URL that was used.
On 31-Jul-06, at 12:09 AM, Martin Atkins wrote:
> Lukas Rosenstock wrote:
>> Hm, good idea!
>>> The GroupID concept would be that a site supporting OpenID could
>>> it by publishing a URL as a GroupID url. So, they could publish
>>> a URL
>>> (e.g. http;//en.wikipedia.org/groupid/sysops ) which they say "we
>>> verify your assertion that your OpenID is a member of the group
>>> identified at that URL".
>> I'd suggest using that the GroupID in fact is an RDF file with
>> FOAF elements because there a data format for describing a group
>> of people already exists.
> I think Rob's intention was to avoid enumerating all of the group
> members. Whether that was what Rob meant or not, there are three
> main situations where this is useful:
> * Where the set as a whole is a secret, but you are happy to give a
> YES or a NO to specific identities.
> * Where the set is too large to enumerate, such as with the set of
> all LiveJournal users.
> * Where set membership is computed on request rather than there
> actually being a physical list stored behind the scenes.
> The latter two are related and are, I think, the most important:
> * Currently several sites identify LiveJournal users by doing
> pattern-matching on the URL. While in most cases this would be the
> only efficient approach, it'd be nice to have a URL where you can
> say "does this URL represent a LiveJournal user?", and perhaps in
> future have it take into account the "custom domain" feature that
> LJ offers, or other situations where the URL doesn't match http://
> * Imagine the set of all OpenID identities. Every single one of
> them. This wouldn't actually be *stored* anywhere, but instead the
> software that answers for it could just go and fetch the URL and
> see if it has an openid.server link or a Yadis link with an OpenID
> entry and make up the answer based on what it finds.
> If you take it down to the bare guts of the idea, it's really just
> a question about whether a particular entity is part of some set.
> The protocol could be as simple as this:
> * GET http://www.whatever.com/mygroup?identity_is_member=http://[...]/
> * Server says "YES" or "NO" in the body of the response.
> I think it's important to keep this one simple, since if it's going
> to be used for trust applications a caller may want to check a few
> dozen different trust services in one go. From a pie-in-the-sky
> point of view it'd be nice to use Yadis discovery for this, but my
> view is that the overhead would be too large for something so simple.
> Someone can define some custom elements for FOAF so that foaf:Group
> entities can say "My set-discovery URL is ...", or whatever.
> The only thing I really see wanting here is the ability to return
> some kind of score for "how much" you are in the set, but that's a
> can of worms that I'm happy to leave closed for someone else to
> open with a different proposal. :)
More information about the yadis