Changes between Initial Version and Version 1 of GeniControlIdentity

Timestamp:

02/07/08 12:39:36 (16 years ago)

Author:

Aaron Falk

Comment:

--

GeniControlIdentity

@@ +1 @@
+= __Identity__ =
+
+== Why keep the identity and authorization systems separate? ==
+
+''Ted Faber, 28 Jan 2008''
+
+It's less flexible and makes anonymity difficult.
+
+An identity, to my mind, has 2 simple properties:
+
+        If a principal asserts an identity, anyone in the system can
+        confirm that directly with the principal.  That is, I can prove
+        that I am who I say I am.
+
+        Each identity maps to one principal, so two elements in the
+        system with information tied to the same identity are sure it's
+        information about the same principal.  That is, identities are
+        impossible to forge. (Or impossible to forge with very high
+        probability).
+
+That's pretty easy to implement: if a PGP key is an identity we're
+already done; set the bit count high enough that collisions are unlikely
+to as many nines as you'd like.
+
+Authorization is built up from statements about those identities that
+trusted principals are willing to certify.  For example, ISI is willing
+to assert that I'm an employee.  NSF GENI components may be willing to
+grant some resources to any ISI employee.  One might be tempted to make
+that property (being an employee at ISI) part of my identity, either
+explicitly by putting a field into my ID (that is properly signed) or
+implicitly by having ISI certify or issue my identity.  That binding
+creates a typed ID.
+
+Don't do that.  Separate the assertion from the ID.  The cost is small -
+two pieces of data presented at authorization time rather than one - and
+the benefits are enhanced flexibility, not to mention cleanness of
+design.
+
+Separating them can be done by the trusted principal (ISI) signing a
+statement asserting a property (this ID represents an employee of ISI)
+about my ID.  When I come to NSF GENI to get resources I assert my ID
+(which I can prove) and present a ISI's declaration, which can be
+checked.  The validation of these two authorization representations
+(typed or untyped ID) is essentially the same - the same players are
+contacted and the same trust connections are represented.
+
+In the simple case the separation and benefits are hard to see; in the
+complex cases the separation makes life easier.  I'm also (lets say) an
+IETF working group chair, which allows me to allocate resources on IETF
+GENI (savor that scary combination).  If authentication information is
+tied to my ID directly, I've either got to get a new ID for my
+incarnation as an IETF principal or I've got to decide which of my ID's
+is primary and encode the second as a signed assertion.
+
+These are both bad choices.
+
+While there's nothing in my formulation of identity that prevents
+multiple IDs for the same principal, an authentication/authorization
+system that requires it seems ugly.  More objectively, it also means
+that I need a new ID whenever another principal wants to assert
+something about me.  More confusingly, component managers may need to
+make statements about multiple IDs to state their authorization
+requirements even when one principal is involved.  (e.g., IETF chairs
+who are ISI employees can allocate DETER resources).  And when
+assertions about an ID change, the ID must be reissued or revoked.
+
+If I allow signed assertions about identity I have to do all the work of
+the untyped IDs  and all the problems of needing a new typed ID if my
+primary circumstances change.  Since all the hard work is done, just
+remove the disadvantage.
+
+If identity and authorization data are kept separate, authorization
+information about my ID can change independently of any changes to my ID
+and my ID can be long lived and lightweight.
+
+Should one want to "revoke my ID" (a sign that they're thinking of ID as
+a credential (ID card) rather than an intrinsic property (the fellow
+with this retina scan)), one simply revokes the relevant authorization
+statements.  These are roughly the same amount of work (see FN if you
+care).
+
+
+I'm arguing that the untyped ID design is more flexible, not more
+efficient in terms of checking a given authorization.  But the
+efficiency loss is pretty minimal.  The same trust chains are traversed
+and the same proof of ID accomplished.  The encoding is just marginally
+less optimized.
+
+Finally, and importantly, keeping ID and authorizarion separate leaves
+the door open to real anonymity.  As I pointed out, if there's no
+assertion of authorization rights tied to the ID, there's no need to
+involve another entity in the ID's creation - PGP keys work and can be
+generated at will.  It's easy to imagine a world in which an ID without
+any authorization statements is worthless, but it leaves a door open
+that costs little (a door that in fact that improves overall
+flexibility) and allows another area of research into GENI.
+
+(FN: It's exactly the same if you've gone the multiple typed ID route
+and either a little easier or a little harder depending on if you're the
+primary certifier in the one typed ID case.  Each certifier in the
+multiple ID route must revoke the ID; the primary certifier can break
+the single ID chain, but another certifier can only revoke their
+statements until they convince the primary to revoke it all. )