Hi Enrico, Sorry for replying this late, I was pretty busy...
On Thu, Aug 16, 2012 at 1:33 PM, Enrico Zini <enr...@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 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cal60pd_3snrgp9afvjprzj8e-clfrmni6xrx0h5vxhhbcb_...@mail.gmail.com