On Wed, 12 Jul 2006, Norman Gray wrote:
> On 2006 Jul 11 , at 20.57, Roy Williams wrote:
>
> > The Nesssi system is predicated on graduated security: the
> > certificate and the request are considered *together* to decide
> > whether to devote resources to the request. This is a contrast to
> > traditional systems, where you must prove who you are first in a
> > rigorous way before getting anything at all.
>
> Thanks for this -- I've added a suitable case to the list, making the
> general observation that access isn't necessarily a simple function
> of identity, but will depend on other factors, or other features of
> the certificate, which will vary in time.
Being picky, I would say that, in this case, a different certificate implies a different identity, so access rights _are_ just a function of identity.
There's an allied case where the service provider maps multiple external identities to one internal identity. E.g.
/C=UK/O=eScience/CN=Norman Gray
(strong certificataion) and
/C=UK/O=AstroGrid/OU=dodgy test CA/CN=Norman
(weaker certification) are correctly identified as the same person. In this case, the federation downgrades rights of the strongly-certified identity to those appropriate for the most-weakly-certified identity. It's only occasionally useful, and doesn't seem to apply to NESSSI.
None of this changes the usefulness of what NESSSI does. However, if we have useful services responding to weak certificates, we need to work out what other services should do for those identities. If we need a different weak certificate for each service then we've not got single-sign-on any more. Perhaps we need consistent levels of strength of certification for interoperation? The three levels that seem managable are:
Are there any other _necessary_ levels? We can always sub-divide, but it would be nice to keep it simple.
Cheers,
Guy
Guy Rixon gtr-at-ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523Received on 2006-07-12Z12:40:38