Claims, Tickets and HTTP – Security protocols for services

I'm writing an enterprise service. A request comes in. Do I honor the request or reject it? Answering this apparently trivial access control question has spawned whole universes of interlocking protocols. Kerberos, Shibboleth, SAML, WS-*, Liberty, OAuth, OpenID and so on. Before I can pick which protocol to use I need to define my requirements.

DISCLAIMER: Although I am an architect on .NET Services' Access Control Service nothing said in this document necessarily represents the opinions of my employer, my friends, my enemies or my teddy bears. No warranty express or implied. Your mileage may vary. Do not remove tag.

Claims – I like claims based programming for handling access control. In a claims based system a requester shows up with a request and attached to that request is a set of claims about the requester. The specific type of claim really isn't that important but typical examples include claims that the requester is person X, or is in role Y or is a member of group Z. The service then decides what to allow the requester to do based on those claims.

Validating that the claims submitted to a service are true isn't exactly trivial. Whole protocol suites exist to validate claims about identity, for example. And once identity is validated, figuring out what roles or groups the caller is in typically requires centralized logic. For example, my enterprise service probably doesn't want to figure out if someone is an employee of my company or not. I'd rather leave that determination to someone else and just get informed of the answer. So what I need is a way to let someone else validate a requester's claims and then just have my service informed of the result.

Tickets – So what I would really like is for the requester to present me with a ticket (in the Kerberos sense) that was signed by someone I trust attesting to what claims I should believe about the requester. It's up to the ticket issuer (called a Key Distribution Center in Kerberos, a STS in WS-*, an Identity Provider in SAML and so on) to figure out who the requester is and what claims I should believe about them. The ticket issuer summarizes what it knows about the requester in a signed (and/or encrypted) ticket that it gives the requester who then hands the ticket to my service. My service then validates the ticket (using shared trust with the ticket issuer, not the requester), pulls out the claims and makes its access control decision.

HTTP – The services I'm working with are native to HTTP. I say native to distinguish from "dig a tunnel through HTTP". Lots of protocols out there claim to be based on HTTP but in fact use HTTP as nothing more than a really inefficient implementation of TCP, completely ignoring the HTTP resource model, headers, etc. So I want a protocol that gives me claims and tickets that are native to HTTP. That means I want to see resources and authorization headers.

Less is more– The enemy of interoperability is optionality. The more options a protocol has the lower the probability that two parties using that protocol will successfully interoperate. As we used to say in the protocol world "the spec is done when there is nothing left to cut". So I want the protocol to be embarrassingly simple. If a protocol looks like a Chinese Menu then it isn't for me.

Reach – The services I need to work with are written in every language for every platform so I can't assume that my partners will just be able to grab some library to implement the security protocol. Sure, some components, such as a HTTP stack or hashing/encryption libraries are ubiquitous. But beyond that my partners, for the foreseeable future, will need to write things themselves. So I'm looking for a protocol so trivial that someone could whip together a basic implementation in a few hours.

When I think about the protocol I would like to have I focus on a few things. The claims format should be so trivial that it uses name/value pairs not structured formats like XML/JSON/YAML. I want tickets so small that in practice all the claims and the ticket overhead can trivially fit into a HTTP header. And I want the protocol/encryption process to be so simple that all the claims handling/encryption code can be written in 100 or 200 lines of readable code. I also want a pony.

So what do you think? Is there a protocol that meets my needs today? Is there a protocol that is close and I should just adapt it? Feel free to respond in comments or, if you are going to be at the Internet Identity Workshop 2009A in Mountain View May 18-20th we can talk there!