two user databases - alioth & debian accounts with no overlap.
alioth uses -guest for others.
1 person 1 or more debian account names and 1 or more alioth account names.
	nominated onces can be disabled.

currently use DACS, stateless. cookies store user details and do not expire
logout is important but also hard. Federated cookies - need to visit every
site to actuate the logout.

configuration is weird and problematic.

No official mapping between alioth account name and GnuPG name.
Login with Alioth credentials, nm.debian.org cannot tell who you are.

Only implemented on debian.org sites as those are under DSA control.
Any DD can create a debian.net site - could also sponsor for anyone to
host debian.net entry. Hard to control federation with debian.net.

Need for something else.

sso.debian.org has the login screen. cleartext passwords.
all others get a transfer of credentials from sso.debian.org.
sso is the only machine with access to the LDAP of debian.org and
the postgresql database of alioth.
also acts as OAuth2 for summit but the OAuth2 protocol is unusable.
Very little provider side code for OAuth2 - having a Debian OAuth2 provider
does not provide access to useful sites - those use facebook or google
providers for OAuth2. Current OAuth2 is unmaintained for Debian usage.

Must not widen attack surface of cleartext passwords.

Problem with other server-side alternatives is maintenance.
	e.g. shibboleth (see https://wiki.debian.org/Teams/DebianShibboleth ?)
DACS is maintained by those who need it, not those who want to develop it.

Problem of providing identity and allowing users into a service.
	the service decides what is to be trusted

identity within Debian is currently OAuth2 and DACS.

Objective is a single place to enter passwords
	Authentication, not authorisation

https://lissabon-prototype-brlink-1.debian.net (IPv6 only)

One simpler alternative:
	Client SSL/TLS Certificates
	Issued by sso.debian.org using LDAP behind the scenes
		- simple button interface
	Needs support in the browser
	Import / exchange between browsers - need separate logins on sso.
	certificate will contain the username and token

	Depends on the target audience
	Fails on internet explorer
	chrome has deprecated implementation (for <keygen> HTML tag ?) but will replace with script.
	also use openssl and do the work yourself.
	some maintenance work required
	Certificate expiry needs to be resolved.
		sso shows which other certificates are in use
			- click on which to revoke
		one certificate per profile
	Users who have passwords in browser have the same security
	as the certificate itself.
	control the server side completely instead of problems of DACS
	single page to detect DD vs Alioth user.

	most of the clients should be stateless.

	certificate will not have an email address
	no use for email, attributes not set.
	minimal abilities embedded in the certificate.

Also WedID:
	See https://wiki.debian.org/WebIDForDebianWebServices
	http://www.w3.org/2005/Incubator/webid/wiki/Main_Page
	https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html

Also Mozilla Persona (deprecated by mozilla ?)
	Only used by Mozilla
	interesting : the ID of people is looking like an email (easy to remember)
	http://www.zdnet.com/article/mozilla-changes-focus-and-hands-persona-over-to-community/