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. )