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...
Posts tonen met het label open standards. Alle posts tonen
Posts tonen met het label open standards. Alle posts tonen
woensdag 25 februari 2015
zaterdag 10 mei 2014
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.
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.
dinsdag 7 juni 2011
RSA mocking hype
And so finally RSA aknowledged that the march hack can in fact result in risks. It took some while and perhaps because of this the tweetosphere exploded by all experts mocking RSA: SecurID is unsafe now. And the fact that RSA said to replace unsecure SecureID's for only a few 'high risk' customers made things even worse.
And alas, for RSA things will not get better soon. Being vague about the theft of whatever was stolen does not help getting back the trust that was lost today.
But there is another problem. Media report that SecurID is corrupted, but, as long as we don't know what the real problem is, I have not yet seen an objective problem analysis. What is the real risk for a regular RSA customer? Is everybody just repeating (RT'ing) others without thinking for themselves?
Fact: trust in RSA is low. No fact: SecurID is corrupted.
Let's just think of an attack scenario like this:
An attacker can calculate the security code, based on knowledge of the algorithm, using a seed from the stolen dataset. But, what seed is the seed that belongs to a token that is used for authentication? What token is used? A web login form does not contain this information. Besides one would need a valid userid (for a Windows domain), a valid password and the pincode of the device, that is needed to proof the legitimed use of the token.
Unless an attacker has all this information, he cannot authenticate. An attacker might fool the RSA authentication server, that is not enough to enable access. More is required. That makes me think that the documented attacks must be inside jobs and that the insiders had to steal the RSA data as well to make further remote access possible.
I may be wrong, must be because of all the fuss by the security community, but I really don't see SecurID compromised. I don't trust it now, because the strange moves of RSA, but as far as I can see, SecurID can still be used as a means for strong authentication. But we need to know more of the data loss and we need to know more of the (obscure) security model.
And no, besides being a SecurID user I have no relationship whatsoever with RSA.
And alas, for RSA things will not get better soon. Being vague about the theft of whatever was stolen does not help getting back the trust that was lost today.
But there is another problem. Media report that SecurID is corrupted, but, as long as we don't know what the real problem is, I have not yet seen an objective problem analysis. What is the real risk for a regular RSA customer? Is everybody just repeating (RT'ing) others without thinking for themselves?
Fact: trust in RSA is low. No fact: SecurID is corrupted.
Let's just think of an attack scenario like this:
An attacker can calculate the security code, based on knowledge of the algorithm, using a seed from the stolen dataset. But, what seed is the seed that belongs to a token that is used for authentication? What token is used? A web login form does not contain this information. Besides one would need a valid userid (for a Windows domain), a valid password and the pincode of the device, that is needed to proof the legitimed use of the token.
Unless an attacker has all this information, he cannot authenticate. An attacker might fool the RSA authentication server, that is not enough to enable access. More is required. That makes me think that the documented attacks must be inside jobs and that the insiders had to steal the RSA data as well to make further remote access possible.
I may be wrong, must be because of all the fuss by the security community, but I really don't see SecurID compromised. I don't trust it now, because the strange moves of RSA, but as far as I can see, SecurID can still be used as a means for strong authentication. But we need to know more of the data loss and we need to know more of the (obscure) security model.
And no, besides being a SecurID user I have no relationship whatsoever with RSA.
dinsdag 27 oktober 2009
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.
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.
donderdag 10 september 2009
Open Trust Frameworks for Open Government
As I wrote earlier, the biggest problem in the identity 2.0 space is the absence of trustworthy public Identity Providers. I called for a trust framework that would enable differentiation in trust levels for identity providers. Of course that requires some major party to define the standards.
There is some great news about the development of a standard trust framework for identity providers. Initiated by the US Government the Open Trust Framework for Open Government was formed. In a White Paper the methods are described.
There are other initiatives, like the Dutch OpenIDPlus. Let's just hope that these initiatives will converge into an interoperable international standard.
There is some great news about the development of a standard trust framework for identity providers. Initiated by the US Government the Open Trust Framework for Open Government was formed. In a White Paper the methods are described.
There are other initiatives, like the Dutch OpenIDPlus. Let's just hope that these initiatives will converge into an interoperable international standard.
donderdag 18 juni 2009
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.
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.
donderdag 26 februari 2009
Let's review too
Mike jones reported the availability of the Identity Metasystem Interoperability Version 1.0. This looks good news to me, progress being made, so all hands on deck for reviewing.
maandag 15 december 2008
Community effort
I just like to point to the ibpedia.nl community project, that aims to be a research portal for information security professionals.
The project was started by a few Dutch enthusiasts, who (in vain) tried to use wikipedia for knowledge sharing. Due to the fact that a lot of knowledge was still in research phase, wikipedia could not host the items, so a new wiki was started.
ibpedia got its name form the ib abbreviation: Informatie Beveiliging, Information Security for those who are not familiar with the Dutch language. But, there's also a lot of content in English.
The content of ibpedia is published under a creative commons license, so free to share and add to. Don't hesitate to join the community.
The project was started by a few Dutch enthusiasts, who (in vain) tried to use wikipedia for knowledge sharing. Due to the fact that a lot of knowledge was still in research phase, wikipedia could not host the items, so a new wiki was started.
ibpedia got its name form the ib abbreviation: Informatie Beveiliging, Information Security for those who are not familiar with the Dutch language. But, there's also a lot of content in English.
The content of ibpedia is published under a creative commons license, so free to share and add to. Don't hesitate to join the community.
maandag 11 augustus 2008
donderdag 15 mei 2008
The Hague Declaration
Andy Updegrove just mentioned this initiative. So being a firm believer in Open Everything, I just signed this petition.
Have a look en feel free to add your name to the form too.
Have a look en feel free to add your name to the form too.
Abonneren op:
Posts (Atom)