Using Passbook for Attribute Management

By now we know all there is to know about managing digital identities so the next level of access control is to further investigate managing (defining, granting and revoking) authorizations. And the ideas about granting access to resources, based on certain (user owned) attributes are gaining ground. In the future I will get access to documents, files, databases and locations based on attributes, more than because of who I am (one of my many identities).

A while back I wrote some posts ("I need a Pall or Pass" and "Attribute management") about managing attributes and about the lack of information about this issue. And I found one interesting entity providing attributes: ISACA issues attributes in the form of OpenBadges, an open standard to manage whatever attributes in a digital wallet, like Mozilla Persona.

Only recently did I come across another digital wallet system, Passbook by Apple. According to Wikipedia "Passbook is an application in iOS that allows users to store coupons, boarding passes, event tickets, store cards, credit cards as well as debit cards via Apple Pay." That's interesting. I didn't know about Passbook, because I don't own or use any iThings, but someone crafted an app for the Sailfish OS on my Jolla smartphone. So, thank you :)

A little about the purpose of Passbook: it is there to manage coupons, tickets and all. And those items are valuable items, they have to be protected. So inherently passes are secured to a certain level and Passbook must facilitate that. These items give access to certain features that were defined by the coupon or ticket provider, these permissions were defined by the owner of the resource that the ticket holder wants to have access to.

This look a lot like the owner's responsibilities that we see in regular IAM environments. Someone, an owner of a resource, a file, a database, a room, defines access rules and decides what identities can have access. Yes, not unlike any theater ticket. And yes, I did write that I need a Personal Attribute Storage System, a Pass. It could well be a Passbook...

Can we use some app like Passbook for attribute management. Yes of course, by all means. But I am curious to know if Apple created an open standard to make it feasible to use the platform elsewhere too.

OpenBadge Based Access Control

A while ago I posted a few entries about using attributes instead of roles to grant access to resources. At the same time I wrote that the current way of providing attributes is limited. So far attributes are provided by identity providers, hence only parties that trust an identity provider know what attributes can be used and may decide to trust the attributes provided by the identity provider. But as I stated, there are many cases that you do not want to get an attribute from your identity provider. You may have passed an exam, received a compliment or endorsement, or you may be part of another community than the one you work for and the one who provides your (digital) identity. Your digital identity provider may not even know all these attributes. And rightly so, an identity provider needs to provide trustworthy (within the trust framework) identities.

So I came up with the idea to make it possible to receive and collect attributes, much in the same way that we are used to receive and collect badges for gaming, or scouting...?.

And I showed that such a mechanism is in use at this very moment, although not yet in the way that I want: Isaca provides digital badges to certified members. And you can collect these badges in a digital wallet, that you can also use to present youor badges.

It's a pity that there is no use other for these Isaca attributes yet. I would like to use my CISA and CISM badges to be elegible as a candidate for a security consultancy project with prospective customers. How easy it would be to just so show my Isaca badge, instead of writing a resume or pointing to my LinkedIn profile. If you need an IT Auditor, here's my Isaca CISA badge... Or if you need a CISM, just search LinkedIn for CISM badges...


Today I learned that there is a another organisation contemplating to provide badges. LibreOffice volunteers may get badges in the OpenBadge format, the same format that Isaca is using. This wil most certainly mean that we will see OpenBadge become a default adopted open standard.

We probably have to come up with use cases for access control based on OpenBadges. Currently these badges are just that, they just show that you are member of a community, but there are no permissions connected to badges. Yet...

Attribute management

In my previous post I said that I need a facility to manage attributes issued by third parties. I have plenty digital identities, but most of them can only be used for a specific purpose. A limited number can be used in a multi-purpose fashion.
There's DigiD, the Dutch digital identity that was provided to me by the Dutch government and that can be used in my relation with a number of national and local government transactions and for a few transactions beyond that, like for my health insurance business. But these services can use only one specific attribute of my DigiD identity, the 'BSN', a unique identifier, like the American SSN.
Another multi-purpose identity is my Twitter account. But it also only has some predefined attributes, but if a service provider needs extra attributes, he needs to capture those through other channels. But there are no attribute providers beside the identity providers we know and love...

But, a few weeks ago I received an invitation from ISACA to download digital Badges that can be used to indicate that I am a Certified  Information Systems Auditor (CISA) and a Certified Information Security Manager (CISM). These badges can then be imported in an 'Acclaim' account, that I can use to present my badges to others. And ISACA mentioned that presenting these badges in my LinkedIn profile is a preferred way to show my certifications.

How about that? ISACA issues a badge that proves my qualification. It is an attribute of my profile, it belongs to me. Not to one of my identities, but it is an attribute of me as a professional. And ISACA is qualified to issue these attributes, ISACA created these attributes, ISACA is the owner of the CISA and CISM titles.

ISACA issues badges in the form of an Open Badge, an open standard, created by Mozilla. And Mozilla created it's own backpack facility in the Mozilla Persona digital identity. The backpack can be seen as a wallet that contains the badges. Acclaim is another form of a digital badge wallet. Here is the acclaim page with my ISACA badges.

I really liked this idea, so I created my own badge issuing process. As you may recall I started the #ditchcyber campaign and this campaign is supported by the @CyberXpert account. I decided to offer CyberXpert badges to followers of this Twitter account. Any follower who uses the RCX or CCX title can get a digital badge and import that badge in a Persona Backpack. Here's my backpack, showing a CyberXpert badge.

Next thing we need to find out is if an Open Badge attribute can be collected by a digital identity and combined to a SAML message.

I need a PAL or a PASS

There are two IAM concepts that I really like:

• Identity 2.0, where I can login to a service provider using an identity that was provided to me by an identity provider, who proofs that it is really me.
• Attribute Based Access Control (link to the NIST ABAC standard): you get authorizations not based on your identity, but on your capabilities that some authority feels you have.

The first development makes it possible to separate responsibilities for objects on the internet. A service provider only needs to take care of services and data, an Identity Provider (IdP) only has to take care of digital identities and authenticating it's users. A service provider only needs to trust the digital identities provided by an Identity Provider, and that creates an enormous scalability of web services.

Attribute Based Access Control enables the authorizing of persons as requested by a process owner or data owner. This owner has to define the quality requirements for executing tasks within a process of towards a data element. The process owner or data owner doesn't need to have any knowledge about the identities or roles or groups that are defined within an organization. But this is a new concept and a very tough responsibility: these owners never before had to think about these requirements. Nevertheless, this is an exciting concept: someone doesn't get permissions because of his function or role within an organization, but because of his capabilities. And these capabilities are called 'attributes' of the identity.

The interesting thought is that an identity provider also provides some attributes. Such as address, phone number, gender, date of birth, expiration date and a lot of other variables. The IdP concept of ABAC is implemented in the SAML message format, where the term Claim component is used as the attribute component.

One of these attributes could well be the Role of an identity. An internal identity provider in an organization may well know the function type or role of an employee, who gets a business identity. In such a case an attribute can be used to allow Role Based Access Control capabilities to the access control mechanism.

But... what if a process owner requires an attribute outside of the scope of the identity provider? Where does the extra attribute come from? In the ABAC concepts attributes are bound to identities, that means that in order for an employee to prove that he has the extra required attribute, he in fact needs to provide another identity that does contain the required attribute. But... in all reality, that's just not feasible. What might be possible is that the identity provider forwards the attributes provided to an identity on behalf of another identity provider. For instance: an internal IdP could add attributes, like results from a course that the user attended. But that creates new trust issues (did the user follow the course successfully, is the attribute really provided by the school, in what context can the attribute be used and some more).

I am not aware of any implementation. And perhaps we should not want such an implementation and we should think of another way.

As a user I would not like this hassle of using different identities or of 'IdP-in-the-Middle' constructs. I want a convenient place to store my attributes, some kind of a wallet. Not a wallet with different identities (although I really loved the Information Cardmetaphor promoted by Kim Cameron), but a wallet with different attributes. And the attributes within this store could be used with any of my identities that I want to use for a specific purpose.

I need a PAL, a Personal Attribute Locker, or a PASS, a Personal Attribute Storage System (I'm great with acronyms :) ). Identity Providers could post digital identities and/or attributes to my locker and I could mix and match whatever combinations of identities and attributes I would want to use. Provided that the context and scope of identity and attribute is a valid combination, but we'll have to think about this in another post. What would the implication be? Suppose I am an employee who needs access to the CRM system. But in order to execute some CRM task, I would have to provide an attribute that I am an experienced blog poster. This attribute cannot be provided by the company I work for, but it can be provided by Google because of this blog. Google could post this attribute to my PAL and I could use this 'external' attribute with my company Identity to execute the CRM task.

What do you think? Is this a feasible idea?

In a future post I will expand on this idea, because recently I found out about an interesting standard that could perhaps be used as the mechanism that I want...

Stork and other assurance frameworks

As I wrote earlier am involved in the Dutch OpenID.nl+ initiative to help grow the acceptance of OpenID (and to a lesser degree Information Card) in The Netherlands. Within the initiative Identity Providers and Relying Parties define an interoperability standard whereby Relying Parties can rely on digital identities from Identity Providers, based on the verification level of identity attributes by the participating Identity Providers. RP's can authorize users based on the verification information in the claims.

The Trust Framework is based on the assumption that trust derives from the reliability of the identity provider (including the reliability of the identity priovisioning process) and from the reliability of the use of a digital identity. Meaning that there are two parameters: trust in the identity as verified by the identity provider and trust in the use of an identity by the individual owning a digital identity (proof of posession). IdP's must adhere to a certification scheme to prove their reliability. The OpenID.nl+ initiative manages the white list with trusted IdP's.


International developments like STORK also define authentication assurance levels, but these levels are a combination of Identification (by the IdP) and the method of authentication (by the user, based on proof of identity). These assurance levels are the product of a mix of both parameters.


The strange issue is that for certain levels a low level of trust in the process can be compensated by using a strong form of authentication. So QAA2 can be the result of accepting an identity that's hardly verified by an identity provider, but requiring a one time password. Strangely, that would mean that the IdP may not fully know the individual who is issued a digital identity, but you know for sure that the user of the digital identity is the rightful owner of the identity. So someone logging in as Mickey Duck may not really be Mickey Duck, but he is the rightful owner of Mickey Duck's digital id.

In the OpenID.nl+ initiative the net effect may be the same, for most combinations, but the vision on trust is more distinct, the implementation offers a lot more granularity (because of the trust model), although implementing this granularity is not yet part of the roadmap.
In my opinion you shouldn't require a combined assurence level, but you should demand a certain level of trust in ownership of a digital identity and the use of a digital identity.

I will probably get this al wrong, since this model is widely accepted, but then again, maybe I'm not.

Jim Harper and identity claims

The best book about identities that I read is Identity Crisis by Jim Harper. After you read the book, please come back and check this concept:

A digital identity is issued by an identity provider. The relying party has to be able to interpret the data in order to act on them. Important information is the trustworthyness of the identity provider (trust level). But just as important is the trust level of the identity information. An identity provider can issue digital identities based on a visual verification of a person, but also based on nothing more than an email address. The IdP may be trusted, but the value of the identity based on visual verification can be different from the identity based on an email verification.

Identity Providers should add this value of the identity in the digital passport. A claim should be used to differentiate identity trust level. The same goes for authentication (I will come back to this later).

Jim Harper identifies 4 different kinds of identity:

• something you are
  
• something you are assigned
  
• something you know
• something you have

This classification is not at all developed for the purpose of digital identification (and it is not meant as a classification for authentication, read the book!) But could it be used for the IdentityTrustLevel claim?
The first type of identity can be verified by visual verification of a physical id by the Identity provider. The IdP could check a user's passport or driver license. It is a very strong identity, based on some form for biometrics: visual check of the photo on an official document.
The second type of identity is the assigned identity. That could be an email address. It can be verified by addressing the identity (a claimed email address can be verified by e-mail verification).
The something you know identity is the shared secret. The IdP can verify by using a payment from a bank account. That fact that someone can make a payment through a trusted source must have some value in itself.
The last type is just an id issued by an IdP, without any verification. It's just handed over to a person (probably after an identity check, but that's not important, because that would make it a type 1 identity)
If the IdP would add a claim based on the type of identity and if relying parties would know how to interpret this identity, the trust level could be objectively identified.

I suppose that better classifications and claims could be defined, but I just like Harpers ideas. I just tried to analyse some of Harpers concepts, sorry for any trouble :)

Claims and white lists

Since there's no trust hierarchy for identity providers yet, some other mechanism should be developed to be able to trust third party identity providers. At least if we want to be able to use identity information within the digital identity, the digital passport, to act on. As long as a digital identity is used instead of userid and password, there is no problem. Any digital identity used on a site is as good as a self managed identity and password. But if a digital identity is used in a transactional way or if someone wants to access confdential information, some trust in the reliability of the digital identity of a user is needed to be able to control access.

As long as there's no structural solution for trust hierarchy in identity space, white listing is the answer. In a white list a service provider could state which identity provider's identities can be trusted. But that's just the first step.

The second step is that a service provider could allow the use of claims defined by the white listed identity provider. The service provider might accept specific claims issues by a specific identity provider.

In an earlier post I wrote that we would need only a few standard claims to be able to identify the value of a digital identity. What's needed is the level of verification of the identity by the identity provider and the authentication method. If these two claims would be standardised across identity providers and service providers, we would only have to whitelist an identity provider to be able to differentiate user authorizations based on the value of the digital identity.

Yesterday there was an interesting meeting of some potential Dutch OpenID relying parties and OpenID identity providers.
I will participate in a working group to explore the possibilities of standardising claims and trust level of identity providers. That second part is the tough one, it will require some form of accreditation. But if this works for OpenID, it will also work for Information Cards, of course.

European Identity Conference

Just a short update:
from 5th till the 7th of may I will attend the European Identity Conference in Munich. I will be presenting a few thoughts about Access Control in the Cloud, covering Claims Based Access Control and Identity Provisioning (in the fog...). My talk will follow Martin Kuppinger's in Stuart Boardman's forum. I'm looking forward to meeting lots of experts in the field.
Munich, twice within a year: last year I presented a similar story at The Open Group's architecture practitioners conference. I like this city :)

RBAC limitations in SOA

For a few years we have been working within a SOA environment and we implemented some form of the RBAC security paradigm. But since a few iterations of our SOA we feel that we arrive at the limits of RBAC. RBAC is fine within a single security domain, like an application, but as soon as you cross your security borders, like you will do in a SOA, you run against problems.

Some RBAC limitations in SOA

• In RBAC you still have to manage every user account and bind these accounts to roles. Unknown accounts can only be linked to a default role, like guest or customer. But users coming in through the Internet channel are not only guests or customers, but they can also be employees, partners, external service providers, you name it. There may be plenty accounts you don't want to manage, because they don’t belong to your security domain. Unless you manage different portals for different roles and have some form of identity management within the portal environment in place, RBAC is of no use.
  Federation could be a solution, but that only limits interaction possibilities to trusted partners you federate with. Besides, most federeation solutions use shadow accounts within the security domains, thereby creating a new identity management problem because all duiplication. Silly, but if you want RBAC, you pay for it…


• RBAC has a problem with the concept of context. If someone has a role, then he will get the permissions associated with that role. Automatically. There is no restriction in place based on the concept of context. A context could be the channel used (internet, lan), time of day, legal entity etc. An account using a wireless home PC might not deserve the same permissions as the same account in an office using a centrally managed workplace. But such a concept does not exist in RBAC terms (unless you define lots of extra roles). RBAC must always be complemented with a rule-based access control function.


• Another big objection (but that is not specifically SOA) is that there is no possibility for user profiling. Meaning authorisation based on the skills of an employees instead of the single fact that the user is connected to a role. RBAC doesn’t know the difference between junior or senior employees within the same role. Unless you define separate roles. And creating duplicate roles is not why you implement RBAC.


• Another problem (also not specifically SOA): role mining. Have you ever tried mining roles? How many roles have you identified? How many unique roles are absolutely necessary? Often mining is an useless excercise. But without mining roles it is hardly possible to define the necessary authorizations. Or is the role the object that you want to manage?

There are more issues, probably, but for us this was sufficient to declare RBAC ‘Old School’. We will continue to apply RBAC for some specific uses, but we will not implement RBAC as a dogma and certainly not within our SOA. We are studying new authorization paradigms, probably using the SAML Claims mechanism.
Identity management will be replaced by identity Provisioning and identity management will no longer be core business for most organizations. Access Control will stay core business, but no longer based on the user part and will also no longer be based on roles.