Claims or Rules

Wow! I haven't done any blathering here for over a year.

The other week, Andy Dale wrote about a problem with claims. Pam Dingle added her thoughts.

As I read it, the perceived problem is that a relying party policy of just asking for a set of claims by name may not be enough. The relying party may still reject what it receives and force the user to try something else.

The attribute-based folk will say that the answer is that we need yet more attributes. I wonder who has a number in mind about how many attributes would be too many.

Pam's response seems to be some combination of this and role-based systems.

Over ten years ago, a paper was written by Winslett, Winsborough, and Seamons about credential acceptance policies. Granted, the context then was PKI client certificates, but it still addresses this problem. Just read "certificates" as "claims".

The answer proposed in this paper is essentially this. The relying party sends the client some code that it will use to determine if the claims will be accepted -- its acceptance policy. The client uses this code to determine which claims to send, sends them, and voila.

Now, here's the part where some folks will stop reading. The language used to communicate the relying party's policy is Prolog. The paper justifies this choice. One of the reasons of interest is this:

Prolog language features support using the same CAP implementation in these two ways. The bidirectionality of unification enables the same policy code to handle the case where the desired role is specified (server side) and the case where it is not (client side). The Prolog setof/3 meta-predicate enables the same policy code to be used on the client side to find all possible roles and supporting credentials and on the server side to determine whether the credentials submitted by the client authorize the role it has requested.

What I think is even more appropriate is that Prolog or logic programming is based on rules. Rules are, after all, how people think and write when describing policies.

So, what I have to say about this problem is this. The best approach is not attribute-based, it's not role-based, and it's not claims-based (sorry, Kim). The best approach is rule-based.

Impact of Writer's Strike

Weird thought for today.

Does professional wrestling have to show reruns
now because the scriptwriters are on strike?

Rx: Bad Example

It's going to be difficult to have a useful discussion if the discussion is centered abound a poor scenario.

In the discussion about Bob Blakley's identity oracle, Kim Cameron has offered the following example:

For example, consider a health-related Identity Oracle that could answer the question, ”Can Kim take drug X without fear of drug interactions?”.

Today, Jeff Bohren questions this example, and I think he's right to do so. Even though he ventures off into a distinction between data and metadata, he does hint at something that was not explicitly stated in the example.

Who is asking the question?

The prescribing physician? She already has access to Kim's medical records and presumably also has access to medical data about drug interactions. Ergo, she doesn't need to go off and ask an identity oracle.

The dispensing pharmacist? He has a valid prescription from the physician above and I think he can assume that the physician has done her job.

The drug dealer down on the dark street corner? I don't think he cares what the answer would be.

Hence, it doesn't seem to be a question that needs an answer from an identity oracle.

To be honest with you, at least in this and similar cases, I'm having a hard time seeing why the "identity oracle" wouldn't be the same as the health care provider. What value would be added by having it be a separate business? In case the health care provider is providing such answers (to whom? by the way), it wouldn't be an identity oracle at all. This is just like the case Bob mentioned in his comments where universities aren't in the business of providing identity information. I suspect that this is one of the things Phil Hunt was trying to get to. Although he also seems to be assuming that a pharmacist is asking the question.

So, if folks want to talk about business models, methinks they need to say a lot more than who pays money to whom. They need to include the architecture of the model and whose business it is to know what and so forth.

More Meta-

Arrrrr, ye hearties! The meta fad is really catching on. Lookie here: http://metaplace.com

Here's a quote from the hype:

We speak Web fluently. Every world is a web server, and every object has a URL. You can script an object so that it feeds RSS, XML, or HTML to a browser. This lets you do things like high score tables, objects that email you, player profile pages right on the player -- whatever you want. Every object can also browse the Web: a chat bot can chatter headlines from an RSS feed, a newspaper with real headlines can sit on your virtual desk, game data could come from real world data... you get the idea. No more walled garden.

Law 5 and OpenID Information Cards

There have been some challenges to the proposal for information cards that carry OpenID tokens on the OpenID list. There was minor spillage into the Concordia list (this is good; Concordia should be aware of this). Gerry Beuchelt, Robin Wilton. John Kemp, and Jeff Bohren have seen fit to comment in the blogosphere. Paul Madsen added a bit of biting sarcasm. I even wondered about the interaction with Law 7 and usability last week. Since I've been involved, I think I'll poke around in the hornet's nest some more.

The argument had been made that there can be different kinds of information cards. Information cards carrying SAML tokens and information cards carrying OpenID tokens. The argument goes on that this is a good thing since it gives relying parties a choice. Is it? Let's play it out.

Suppose a lot of RPs exercise their choice and deploy code that accepts information cards carrying OpenID tokens -- only. Now some user is sitting there with an information card that contains claims and level of assurance an so forth that an OpenID RP would accept. You see this coming, right? The user's card is one that carries a SAML token. She's out of luck.

Her "workaround" is to go get another card that carries a token with the "proper format". This doesn't seem like a very good way to construct an internet scale Identity metasystem to me.

So one of the real consequences of the different token formats is that all RPs, all identity selectors, all IdPs and OPs are going to have to deploy two different pieces of code. And they'll have to maintain those two pieces of code. And for what?

Do Kim's 7 Laws of Identity allow those with such a proposal to wave Law 5 in front of everyone and claim it's justified? I think not. I think Law 5 acknowledges that there might be different situations and they might call for different protocols. But I don't think it gives anyone license to add different formats just because they're different. This is a known phenomenon in the computer field; it's called "Not Invented Here".

I have yet to see any reasons why OpenID tokens provide any extra benefits beyond what you would already have with information cards carrying SAML tokens. Even if there were some, it would be better to work together and make improvements to the next evolution of information cards.

There's one question I forgot to include last week. It came from Mike Beach at Boeing during the Concordia workshop in June. See his last slide (really the penultimate one, I reckon). As they say, it's a good question. And as they should conclude, it deserves a good answer.

Law 7 and OpenID Information Cards

Mike Jones just posted an article announcing that Sxip has code to handle OpenIDs using the information card metaphor. That certainly seems like a major improvement for OpenID.

But I wonder how this all plays out when Law 7 enters the picture. Law 7 calls for a "consistent user experience" (whatever that means).

Well sure, selecting a card instead of typing in 20 characters or so is a large step toward such consistency with CardSpace, but that's not the question. The question is whether it's consistent enough. "Consistent experience" certainly doesn't mean that a user sees identical stuff displayed on her screen every time she uses the identity metasystem. However, I think it does mean that she can at least operate it correctly, make good decisions from the information provided, and avoid mistakes.

I don't know good answers to that question. I know how to ask more questions, though. So here goes.

The current strategy seems to be for a relying party to present the user with multiple login options. Is this really a good thing to do? If a user only has the capability to use one option, then why are they being offered a choice? If a user can use either, then what do they need to know to select the better choice? If it doesn't make any difference which they select, then why are they being offered a choice? If a user doesn't have, or doesn't know about, either option, then what do they need to do to have one? Which one? If the only significant difference between the choices is which protocols operate behind the scenes, then why have different protocols? This is just more work and more opportunities for mistakes for lots of folks. In the longer run, will such "convergence" strategies just lead to more confusion for users?

This is Stupid

I'm just going to rant a bit since I encountered this once again. I'm not going to name names since it appears that there's just too many to name.

Anyway, I'm reading this blog and down at the bottom it has this; I'm sure you've all seen it or something similar.



OK, I think to myself. I'm being invited to comment and I would really like to. So I type in my name and email address and so forth, type in my comment, spend some time proofreading it, and finally push the "Submit Comment" button.

And then what happens? I get a message informing me that I have to be logged in to post a comment!

What kind of crap is that? Is this someone's idea of a cruel joke? If you're going to invite me to make a comment, then let me do it, dammit!

Some blogs are even more egregious. They don't even provide you with a clear mechanism for creating an account. I reckon you have to be a member of some secret society to comment.

Well, at least some other blogs warn you that you need to be logged in before wasting your time.

I don't think this is naming names, but my gut tells me that this heinous behavior is more common with WordPress blogs than others. Perhaps there's something wrong with the default configuration there.

Anyway, the conclusion I come to is that if the author is this stupid, then their stupidity is also operating when they write their articles. Ergo, there's not much reason to read this blog again.