Whois service (was: Review of personal information sources in Debian)
Hi Enrico,
Sorry for replying this late, I was pretty busy...
On Thu, Aug 16, 2012 at 1:33 PM, Enrico Zini <enrico@enricozini.org> wrote:
>> And it just made me discover sso.debian.org, that's great news too!
>
> :) I'm sorry I'm far too busy working on the site and on other FD/DAM
> things to be able to publicise it properly. Consider this an open call
> for help O:-)
Well, I could help, but I haven't found any information about it, not
even what is the help wanted :)
Is converting wiki/forum and other sites to use it part of the plan?
Will it use anything more than LDAP for authentication?
> Indeed. Currently once you log in nm.d.o you can see more information,
> advocate people or do AM work if you are an AM. Login is restricted to
> DDs because that's how DACS works at the moment, but I'm trying to
> figure out how to change that.
>
> I'd like to add a 'preferences' page where one could do some identity
> management. I want to avoid having nm.d.o be the primary data source for
> anything except the status of people in Debian, and I'd rather hook into
> other existing databases whenever possible.
I think that authentication could be managed independently of other
facets of persona management. There could be another service dedicated
exclusively to that.
The SSO service looks like the natural choice for authentication, but
as long as it does not support people outside of LDAP, it does not
seem suitable.
> In terms of managing one's visible full name, for example, this means
> that I was planning to just allow people to choose which of the various
> full names they have in Debian (for example, the primary UID on their
> GPG key) should be the default on the site.
This could be part of the persona service.
> The multiple email situation can be addressed by interfacing with the
> MIA database, which already tracks this kind of information, of course
> after a little discussion on what bits of it can be publicly exposed and
> what shouldn't.
I am not so sure about this, I think people should be able to manage
that information. Although it could be very useful for seeding a new
system.
> Sure, with the limitation that we currently do require legal names on
> LDAP, and that people may prefer to use something else for their online,
> google-searchable persona. Could there be a 'public name' field in LDAP?
> I haven't tried figuring that out yet.
As with many of the other items, one option would be to expand the
LDAP schema, but again there is the problem of people outside of it.
> I think we need some free-registration identity provider, and we can use
> Alioth, or even identi.ca via oauth. We've started discussing details
> with DSA and Alioth admins, but haven't found a workable solution yet.
Alioth seems like a good compromise to me. It is easy enough to create
an account, but we would need to interface it with other systems
before it is useful.
I think adding identi.ca or other third-party services could make the
system too complex. There's already the problem of matching duplicate
identities in LDAP and alioth..
>> Great. Do you have any thoughts to share on that?
> I think we need what you propose, and it fits perfectly with what I had
> in mind in my (and Francesca's) blog post you quoted[1].
Glad to hear that.
> In terms of implementation, I see an overlap with nm.debian.org,
> portfolio.debian.net and db.debian.org.
Sure. The more I think of this, the more I'm convinced I don't want to
get into the authentication/identity matching problem.
I am not so sure there is much overlap with portfolio.d.n, more like a
opportunity for complementing the two services.
> I hope I'm not frustrating your coding plans by saying this, but my
> suggestion would be, before you go beyond prototypes and mockups and get
> into serious site development, to have a quick round of discussion to
> see if they could be implemented as new parts of existing
> infrastructure instead.
Sure. My post was intended to start a discussion on this.
I haven't done any coding yet (too busy with other stuff). But I've
been thinking about this. I have identified these topics:
- Identity matching and aggregation, which I would like to delegate to
another service, and whois could live without for the time being.
- allowing management of the data shown, which I think could be done
with placing files in the user's home directory in Alioth, but
requires matching the identity with an alioth account. There could be
a web service, but I rather not get into that, and also it would
require authentication.
- collection of personal information, badges and stats would be done
from a central location, polling a hand-maintained list of sources.
- personas would be discovered passively by enumerating the results of
the data collection. In this step, the aggregation of identities would
allow to unify information, but I think we can live with split
identities for now.
- the results of this would go into some database, that will be use to
display a person's information. I thought about a simple web output,
as in the mock up, but exporting as json, or any other
machine-parseable format should be perfectly doable.
> For example, NM applicants already have to write a public bio. I was
> already thinking of adding a special field for that in nm.d.o, which
> means it'd automatically get posted to debian-newmaint when an applicant
> is approved, and it would save AMs some more work. The same bio could be
> shown on the person's personal page, and they could keep it up to date
> over time. That could become the bio that's shown in your mockup.
Indeed. NM could be one of the sources polled I mentioned before. We'd
just need to agree on the protocols to publish the data, and ways to
protect the data from being pulled directly by third parties.
> I was also already thinking of adding alternate emails from MIA to
> nm.d.o, which would improve the portfolio and DDPO links and the default
> minechangelogs search.
See my previous comment on MIA.
> The only information we would then miss would be badges and stats. I
> guess that, for those, what we most need is a way of collecting them: a
> standard REST API that various pieces of Debian infrastructure can
> implement, perhaps?
Yes. My initial thought was using simple text files that would list
identities getting a certain badge (or extra data for a certain stat),
plus a central configuration file that will list the URLs for these
lists, along with the list metadata (badge image, description, badge
maintainer, etc). Probably something sexier could be devised :)
> Once the data is collected, where it is displayed becomes a detail: it
> could be a stand-alone site linked by nm.d.o and portfolio.d.o, it could
> be nm.d.o itself, or both. I guess that boils down to what technologies
> whomever is doing the work is comfortable working with.
Indeed. I would like to provide the data and the mechanism, for other
people to do cool stuff with it!
> I was looking at it mainly as a standard protocol to handle badge
> information. Even if we don't care about integrating with them, what
> would you think of just reusing their technology?
I took a brief look at it, and it seems very complicated, we don't
need so much interoperability, nor validation of issuers and the such.
I think I'd rather not go that way, and maybe do it in the future.
Tincho.
--
Martín Ferrari
Reply to: