SSO authentication: a new approach

[Paul Harrison]

Ray Plante wrote:
> On Tue, 15 Mar 2005, Paul Harrison wrote:
> 
>>I think that the distinction would have a bearing on any design - 
>>instead of having different classes of CA, all CAs would be equal, but 
>>the  less privileged user would only be registered in a low priviledge 
>>community for instance.
> 
> 
> I'm trying to address a very practical problem:  the hassle of getting a 
> certificate.  I want to allow users to be able to fill out a registration 
> form and begin access restricted services immediately.  This is not the 
> current practice with cert-based trust models.  Many sites provide 
> immediate restricted access without the use of certs, so why bother?  
> Because we don't need to support two forms of authentication, for one; 
> interoperability across sites, for two.  
> 
> So, do you want to see an easier way to get a certificate?  If not, then
> weak certs are not useful.  If so, can you really trust a process that
> cuts corners for expediancy as much as a process that takes greater care?  
> When you assign lower priviledges to a user (because we're not really sure
> they are who they say they are), how do you do that?  For one, how do you
> recognize that this person should get lower priviledges?  You can only do
> it if you control both the granting of the certificate AND the assigning
> of priviledge.  Priviledges, however, are assigned by the maintainer of
> service and not the CA.
> 
> 

I think that we are both looking at solving the same use case of making 
it easy to get a certificate that can be in use minutes after the user 
has registered.

Effectively what I am arguing for is that once an identity has been 
issued to a user (in the form of a certificate) they keep that identity. 
  In the document that you distributed, there is a requirement 2.4-R2 
'Users should be allowed to "upgrade" a weak certificate to a strong one 
without loss of access to their data' - if there are different classes 
of certificate, this necessarily means issuing a new certificate and 
effectively changing identity, which then means that the effective owner 
of all user's resources needs to be changed to maintain access 
permissions - not a nice process....

What makes it a pain normally to get a certificate (in the UK at least) 
is that once you have made the certificate request with the shared 
secret from your private key, you are expected to turn up in person at 
the CA before they will push the button to send the signed certificate 
back to you - we could relax that process so that the CA always will 
return the signed certificate without this human step. At which point 
the identity confirmed by the certificate is effectively a member of the 
anonymous community - for this identity to be admitted into other more 
priviledged communities perhaps they would have to undergo some more 
rigorous identity check. It means that when checking for authority to do 
an operation, the priviledges will have been assigned to communities and 
  then a community service will have to be consulted to check it the 
identity belongs to the community.

There is the other side of the coin, that the user has to trust the CA 
not to allow easy identity theft - if the standard procedures are 
relaxed too much then that becomes a real possibility, accidental or 
malicious.

-- 
Paul Harrison
ESO Garching
www.eso.org