What's in a claim?

The use of infocards does not dictate a specific authorization pattern. There are at least 3 authentication patterns at play that I can see... Identification, Roles based and Claims based... We can, and do, use all three of these interchangeably and simultaneously. I will explain what I think these three patterns are:

Identification:- Provide a previously know ID that relying party can resolve to a user record that has all of the additional information needed to make permission decisions. In this case only one claim is ever needed... the ID as one assumes that ALL other information is in the user record. The major problem with this pattern is that sharing the same ID between different relying parties is often impractical and definitely bad from a privacy standpoint. Using pair-wise PPIDs does not really satisfy the Identification pattern as all you are enabling is the ability to say "this is the same person as logged in as before" but not get a lock on a user record (unless you do a mapping at each RP which is probably the BEST application of this pattern).

Roles Based:- (See: http://en.wikipedia.org/wiki/Role-based_access_control ). With Role Based Access Control (RBAC) you don't need to know who the 'Subject' is; you trust the IDP to enforce policy and assign the roles and the RP simply has to present the functionality and access based on the roles provided. The major, known, problem with classic RBAC is that it fails to address either resource or person specific access control. There is lots written about this failing so I will refrain from going into details :-).

Claims Based:- With this pattern all of the information that is needed for the RP to enforce policy is presented to the RP by the IDP. This includes not only the claim values but how the claim was established. Sometimes knowing that the IDP is willing to assert something to be true is enough to trust it, at other times you want to know that the 'Over 13 years old' claim was based on a more rigorous check than... "they checked a box that they are over 13". Claims based authorization becomes especially powerful, IMO, when you take claims from multiple claims providers so that you can do uniquely specific authorization and service delivery at each RP based on a Claims Network.

Classically websites have used 'Identification' to authorize users. A user logs in and the relevant record is found in the database. RBAC has been widely deployed in Enterprise type settings or in 'tight' federations; where the IDPs and the RPs can collude to agree on Role names and Role interpretation. Claims Based authorization is the solution that is growing to address the needs of a distributed authorization framework or 'lose' federations.

Roles are probably defined in the context of a 'vertical' (industry, community, academic practice, etc..). Claims are the raw data about the subject and 'tend to be' as objective as possible so that the consumer can apply its own policy.

I personally believe that Claims Based is a powerful way forward and should be embraced, however, we also need to be realistic and pragmatic. In cases where there is a known tight relationship between the IDPs and the RPs mixing these 3 patterns together seems expedient. There is no point going to great lengths to build zero-knowledge identifiers if you KNOW that each relying party is going to then require an email address (unless you are also confident that the users have mechanisms to deliver and manage zero-knowledge email addresses).

SO.... specifically....

* I think that the Library Community is homogeneous enough that we can define so mutually agreeable Roles, like the ones you suggested.
** Faculty (Academic libraries)
** Staff (all types of libraries)
** Student
** Adult
** Young Adult
** Juvenile

* Where needed, service providers can establish mappings between PPIDs delivered by the infocards and internal IDs for Identification.

* ILL and Electronic Resource Delivery (eBooks) will require Claims Based authorization to augment the Roles so that the systems know not just that the user is a patron, but that they should have access to 'this specific eBook' from 'this date to that date'.

So the delivery mechanism that we are using, ws-* / Information Cards, IS a Claims Based framework, BUT, we are using the framework to deliver claims to enable all 3 authorization patterns.

Do you agree?

The winner is:

As you know, I have been trying to decide how I think we should model the ‘roles’ claims for the ICF’s pilot Library Card project (see my last post: The Claim Game). I have talked, emailed and blogged with a bunch of people who have opinions on the subject and have come to the following conclusions.

Off the point for a moment: There seems to be some consensus that if the policy description and interpretation step that goes on between the relying party and the ‘selector’ was richer then we may have better options open to us. However, today the Information Card specification is what it is and I don’t recommend putting a hold on our project in the hope that it might change.

The options that we have are either to have a single ‘roles’ claim that contains a list of the roles that the user has been granted, or, to have separate claims for each role. The separated claims could be on different cards but I see that option as being basically the same as option 2.

Having thought about this a bunch I think that the better option is option 2, a separate claim for each role. This will force us to formalize and standardize the role names, which is not ideal, but, it provides the best privacy protection and ultimately the smoothest user experience. While the user experience may be a little more complicated on the face of it, I believe it is superior because it will be predictable.

With this option the presence of the claim indicates the assignment of the role. The value of the claim is basically ignored, as it is in the selectors’ card selection process. If a resource indicates a specific role or set of roles that must be present to gain access; only cards capable of satisfying the policy will be presented as selectable cards.

I look forward to hearing why I am wrong :-)

The Claim Game

I-Cards provide a mechanism to deliver claims to relying parties (RPs) . The first i-card claims that we all became familiar with were the ones built into the CardSpace v1 client. While one COULD build an RP that asked for claims that were not one of this standard set the chances of finding a user with a card that had any other claims was pretty slim.

We are now entering the next stage of i-card evolution and adoption where we want to start to extend the list of claims. I am finding that the simple patterns established by the first claim set makes this issue seem more trivial than it is.

The pattern that I personally, mistakenly, thought I was seeing in the WS-*, InfoCard, dance was:

RP says to Card Selector: “I want a nickname claim”
Card Selector says to User: “Pick one of these cards that has a nickname claim”
User selects a card and the nickname claim from that card is sent to the RP.

My misunderstanding was the assumption that the communication between the RP and the selector meant that I would only be able to select a card that would result in a successful transaction. Not only is this not true it is looking to me like I may get very little guidance from the selector as to which card I should select.

In my nickname example above just having a nickname claim may not be enough to... for example... post a blog comment. The value of the claim may be null... The RP may tell me that someone with a different PPID has already used that nickname. And Nickname was an example that I picked as 'the most trivial self asserted claim'. When you get into claims of higher value this problem becomes more apparent. Try registering to leave a comment on Kims blog: All it requires is an email address claim BUT that email address is then validated via an email round trip (as it should be), my point being that the fact that the selector says a card can satisfy the policy of the site only gets me so far.

SO... I foresee, or fear, this user experience:

• I navigate to a web site and see the i-card logo and click on it to 'login'.
• The Card Selector pops up with... lets say... 5 cards highlighted.
• I consider for a moment which one I want to send... and pick number 4.
• The site then tells me that the VALUE in one of the fields is unacceptable (wrong issuer, non-unique, not a member of the formal options,etc..)
• So... I try another of the cards that are highlighted and that one fails too.
• So... I try another one... or did I try that one already?

Not only is the experience nasty, I just submitted 4 sets of data to one RP in a VERY correlate-able way.

So how do we avoid this pitfall?

It is possible that all of this can be solved in the selector, maybe it already is and I don't know it, PLEASE let me know if it is! The in-selector solution would be that the RP can communicate more of its policy to the selector so that the selector can make smarter decisions based on claims values and claims metadata not just the presence or absence of a claim in the schema.

Meanwhile... I have a problem... and I'm not sure what the solution is. Here's the problem:

I want to issue a Library i-card. One of the logical claims that one makes about the holder of a library card is what roles they play at the library; note that I say roleS not role. It is very common for an individual to have multiple roles at the same Library; they may be staff and a part-time student, faculty and staff, faculty and alumnus, etc...

So how do we model this in an i-card?

There seem to be 2 solutions; have one claim that returns a multi-value response OR have a claim for each possible role.

The first option; a single claim called 'library-roles':

• In this case the RP always gets to know all of the roles of the current user even if all they needed to know is if they had a specific role.
• I could have 4 cards highlighted in my selector but find that none of them deliver a claim that can actually satisfy the RP (after i have given them a LOT of information about myself).

On the other hand:

• In the vast majority of cases the user only has one library card and it will either work or won't work.
• The RPs are likely to be libraries and therefore trustable anyway?

In summary of option 1... can seriously compromise privacy, but that's OK.... if you don't care about privacy.

Option 2 is have a claim for each role. With this option you can maintain privacy but at the cost of usability. As I navigate the RP site I will be repeatedly prompted for 'another' card (could be the same one) as I move to parts of the site that require different roles. In this case I progressively give up privacy, if I want to, in order to get access to functionality. This again assumes that the presence or absence of the claim is actually more important than the claim value, which in this case is always assumed to be 'true' in order for this scheme to make any sense.

If you have managed to get to this point in this diatribe.... I would love to hear which option you think I should use... Or is there another option I haven't thought of?