The dastardly folks at FaceBook have repeated the same trick they have tried before, to take control of YOUR information! They have exposed the names of your friends to the world... They should be STOPPED!
If you are a teenager, then the folks at FaceBook have taken one of the most effective pieces of information that "nasty" folks could use to befriend you and made it available to them with out any warning.
They have made your Friends Lists available to those same "nasty" folks, despite how you had previously set the lists privacy! In effect THEY decided that everybody should share the names of their friends so they changed the roolz!
Happily a hue and cry from the great FaceBook Public persuaded them to enable your ability to make your Friends Lists sort of "Private".
HOWEVER you will not find the means of changing the Privacy of your friends list in the Settings page!!! You will need to click the pencil on the Home Page by the Friends List section. Then un-select the show friend list to everybody box that our FaceBook friends so kindly to set to YES!
Happily there is a website that explains it more clearly than I just did...
Thanks Avinash!
But if I were you I would look around for a Social Media site with a little more ethics!.
PARENTS
Think carefully about letting your offspring use FaceBook or for that matter MySpace
If you choose to let them, help them make sensible choices about their privacy settings. The reason is simple : Keep them Safe!
This problem is not new as this news report shows!
July 2006 CNET Page
CHILDREN
You will know some very security unaware Parents! Please help your Parents use Social Media sites carefully. For one very simple reason it will save you future embarrassment! Seriously!!! Do you really want that photo of your (Fill in the Blank) shared with the world.
An intermittent record, if that is what it could be called, of my journey of learning, as I come to grips with the implications of e-Trust.
Friday, December 25, 2009
Thursday, November 19, 2009
Identity and the Black Hole
There are many reasons for us to drive the e-Trust frame onwards and upwards, not least the implications of the loss of electronic trust. The impact of a catastrophic failure in e-Trust would be profound. Leaving the recent financial melt-down looking like a mere blip. I predict that one of the reasons for such a failure also provides the means of protecting against that same failure. That reason is the failure of electronic identity to appropriately protect the users of the internet from their fears. Identity Theft and other identity failures are occurring at an astonishingly more rapid rate. I posit that the public's ability to accept such failures has a very finite level and once the level is passed e-Trust will rapidly start to collapse. I propose that the response is very similar to the ability of Ethernet to accept "collisions", it works fine up to a point but once that point is exceeded the knee of the curve creates a sudden and precipitous drop in the networks responsiveness. A large number of users will accept a surprisingly large number of identity incidents but at a certain point the willingness to "e-Trust" will collapse in the populous.
This positited phenomena, simply positions the importance of expanding our ability to protect e-trust by enhancing identity across 5 domains: Applications, Enterprises, Devices, Users and Information as crucial to our economic well being..
In dialogue with Steve Greenham, I have developed a model for ascertaining "Identity" using the Digital Shadow of Users. Coupled with a shift to claims or attribute based access management we have the potential of creating a robust means of protecting e-trust.
In the same way that the location of a Black Hole can be identified, so to can the identity of a human be identified. In the case of the black hole it is by observing the phenomena that the existence of the black hole in a specific location creates. In the case of a human being, one can observe the "Digital Shadows" of the user and predict to the required level of confidence the identity of the user.
There are a number of intriguing challenges that will be documented later in this blog.
The present challenge is how to rapidly enable this approach. It will require the partnership of a large number organisations to put in place the capabilities that will allow us to avoid the precipitous collapse of e-Trust. For who knows where we are on the e-trust curve? Humanity has not been here before!
This positited phenomena, simply positions the importance of expanding our ability to protect e-trust by enhancing identity across 5 domains: Applications, Enterprises, Devices, Users and Information as crucial to our economic well being..
In dialogue with Steve Greenham, I have developed a model for ascertaining "Identity" using the Digital Shadow of Users. Coupled with a shift to claims or attribute based access management we have the potential of creating a robust means of protecting e-trust.
In the same way that the location of a Black Hole can be identified, so to can the identity of a human be identified. In the case of the black hole it is by observing the phenomena that the existence of the black hole in a specific location creates. In the case of a human being, one can observe the "Digital Shadows" of the user and predict to the required level of confidence the identity of the user.
There are a number of intriguing challenges that will be documented later in this blog.
The present challenge is how to rapidly enable this approach. It will require the partnership of a large number organisations to put in place the capabilities that will allow us to avoid the precipitous collapse of e-Trust. For who knows where we are on the e-trust curve? Humanity has not been here before!
Tuesday, April 21, 2009
From Identity Service Provider to Identity Provider Service!
I had the pleasure of meeting one of my identity heros at ESAF on Monday; Kim Cameron. It went well and truly made up for my trip to PARSIFAL, where I had been told he was going to present, I did however meet the EU Information Commissioner at PARSIFAL though, and discussed with him the importance of Cloud Based Identity. This initiated the seed growing.
At ESAF I also bumped into a number of other potential Cloud Based Identity Players. The result of the interaction with Kim created a massive brain explosion. The result two words swapped places. Seems such a minor result when stated like that! :-(
But Identity Service Provider became Identity Provider Service! (IPS)
Definition: An Identity Provider Service, is a Cloud Based Identity Service Model that allows any individual, leader of a group or organisation to create identities for themselves or their members. Allowing the management of the Identities in such a manner that they can be simply used by and within the group or organisation, or can be raised to a level of trust whereby they can be consumed by third parties, and as a result the Identity Provider and Identity Provider Service can recieve a revenue.
The following Graphic attempts to capture the concepts that were borne in my mind, undoubtedly the result of reading what many others have written on the topic and watching the Dick Hardts Identity 2.0 Video (he's my other Identity Hero, how can I properly cite all the folks who helped create conditions for the two words to swap! My friends at the Jericho Forum undoubtedly played a key part, especially Steve, Paul and Andrew. I am confident that the LEF Cloud Study Tour also had an impact. So I lay these out for the world to consume in an OPEN Manner. In the hope that a new Identity Provider Service Model will result.
Imagine the three Customer, Professional and Organisation components as Blimps floating atop the Identity, Claims, & Access Management landscape. They will be populated with Personas with Claims that need to be verified. These claims could either be self asserted or verified in the "New Cloud based Identity Provider Service" approach ie the Scout Leader or the BMA said they were they accurate claims!
I see the Identity Provider Service being delivered at varying levels of trust, Self Asserted (Free), Group Leader Asserted (Free with Certificates), or Organisational Assertion (One Off Fee with Certificates), and Authenticated Organisational Assertion (higher One Off fee with additional means of authentication) Payment is made by the consumer of the identity in the latter two cases on a transaction basis (think credit card transactions) and this payment is split between the Identity Provider Service and the Identity Provider.
Expanding the example the Boy Scouts of America may choose to allow each Troop Leader to publish their own Troops Identity or negotiate a higher Trust Level with IPS and issue Certificated Authenticated Identities for which they will receive revenue when the Identities are used/trusted by third parties. The Identity Provider Service would operate like Mastercard/Visa charging a verification fee that rises dependant upon the the level of Claims being Made and the Risks involved in the transaction.
The British Medical Association could choose to issue an electronic identity to its Doctors using this Identity Provider Service approach and recieve a revenue from the organisations that consumed the Doctors Identities that naturally came with a verified Claim that they were a Practising Doctor (Meta Data of the Claim to be determined)
NB In this new IPS Model all parties would need to determine HOW the Identity Risk is shared. The BSA would be the Identity Provider. IBM, PayPal, Microsoft, RSA could provide the Identity Provider Service following a standard approach. Lots of legal and compliance stuff to be sorted!
But in the meantime it could start small, I would use the service to publish Information Cards (for that feels like the best form in which to create the Identities) for my friends and family so that we could all safely interact on the Web.
I wouldn't buy a "Geneva Server" to do that but I would certainly sign up to the first IPS that would allow me to publish such Information Cards.
After the concept takes off, I predict an early explosion of Identity Provider Services followed by a shake out that would reduce to 3 maybe 4 providers within 3-5 Years. The number of Identity Providers would remain large. In comparison to the Credit Card Model, I can get a Credit Card from the Royal Society for the Protection of Birds! Why? because they earn revenue from it... I'd quite like an RSPB Identity for my Twitcher Persona!!!!
Alternatively we could continue populating the Blimps from the Enterprise Centric Model, more costly and less effective. Please NO!
I propose the population of the Group, Organisation and Professional Blimps ahead of the population of the Customer Blimp, ultimately these three Blimps will merge. Initially Enterprises will think they want Enterprise issued Identities to fill the Customer Blimp using this new Cloud Identity Service Model but eventually we will get that the other Identities are cheaper and more reliable!
Needs far more thought, for 'tis early in the morning...
But I just had to share!!!
At ESAF I also bumped into a number of other potential Cloud Based Identity Players. The result of the interaction with Kim created a massive brain explosion. The result two words swapped places. Seems such a minor result when stated like that! :-(
But Identity Service Provider became Identity Provider Service! (IPS)
Definition: An Identity Provider Service, is a Cloud Based Identity Service Model that allows any individual, leader of a group or organisation to create identities for themselves or their members. Allowing the management of the Identities in such a manner that they can be simply used by and within the group or organisation, or can be raised to a level of trust whereby they can be consumed by third parties, and as a result the Identity Provider and Identity Provider Service can recieve a revenue.
The following Graphic attempts to capture the concepts that were borne in my mind, undoubtedly the result of reading what many others have written on the topic and watching the Dick Hardts Identity 2.0 Video (he's my other Identity Hero, how can I properly cite all the folks who helped create conditions for the two words to swap! My friends at the Jericho Forum undoubtedly played a key part, especially Steve, Paul and Andrew. I am confident that the LEF Cloud Study Tour also had an impact. So I lay these out for the world to consume in an OPEN Manner. In the hope that a new Identity Provider Service Model will result.
Imagine the three Customer, Professional and Organisation components as Blimps floating atop the Identity, Claims, & Access Management landscape. They will be populated with Personas with Claims that need to be verified. These claims could either be self asserted or verified in the "New Cloud based Identity Provider Service" approach ie the Scout Leader or the BMA said they were they accurate claims!
I see the Identity Provider Service being delivered at varying levels of trust, Self Asserted (Free), Group Leader Asserted (Free with Certificates), or Organisational Assertion (One Off Fee with Certificates), and Authenticated Organisational Assertion (higher One Off fee with additional means of authentication) Payment is made by the consumer of the identity in the latter two cases on a transaction basis (think credit card transactions) and this payment is split between the Identity Provider Service and the Identity Provider.
Expanding the example the Boy Scouts of America may choose to allow each Troop Leader to publish their own Troops Identity or negotiate a higher Trust Level with IPS and issue Certificated Authenticated Identities for which they will receive revenue when the Identities are used/trusted by third parties. The Identity Provider Service would operate like Mastercard/Visa charging a verification fee that rises dependant upon the the level of Claims being Made and the Risks involved in the transaction.
The British Medical Association could choose to issue an electronic identity to its Doctors using this Identity Provider Service approach and recieve a revenue from the organisations that consumed the Doctors Identities that naturally came with a verified Claim that they were a Practising Doctor (Meta Data of the Claim to be determined)
NB In this new IPS Model all parties would need to determine HOW the Identity Risk is shared. The BSA would be the Identity Provider. IBM, PayPal, Microsoft, RSA could provide the Identity Provider Service following a standard approach. Lots of legal and compliance stuff to be sorted!
But in the meantime it could start small, I would use the service to publish Information Cards (for that feels like the best form in which to create the Identities) for my friends and family so that we could all safely interact on the Web.
I wouldn't buy a "Geneva Server" to do that but I would certainly sign up to the first IPS that would allow me to publish such Information Cards.
After the concept takes off, I predict an early explosion of Identity Provider Services followed by a shake out that would reduce to 3 maybe 4 providers within 3-5 Years. The number of Identity Providers would remain large. In comparison to the Credit Card Model, I can get a Credit Card from the Royal Society for the Protection of Birds! Why? because they earn revenue from it... I'd quite like an RSPB Identity for my Twitcher Persona!!!!
Alternatively we could continue populating the Blimps from the Enterprise Centric Model, more costly and less effective. Please NO!
I propose the population of the Group, Organisation and Professional Blimps ahead of the population of the Customer Blimp, ultimately these three Blimps will merge. Initially Enterprises will think they want Enterprise issued Identities to fill the Customer Blimp using this new Cloud Identity Service Model but eventually we will get that the other Identities are cheaper and more reliable!
Needs far more thought, for 'tis early in the morning...
But I just had to share!!!
Friday, March 13, 2009
Sexily Oriented Architecture
It's been bugging me for a while: How many orientations can one architecture have? There seem to be so many to choose from, though some of these are not yet recognised as mainstream they actually hold the real promise. Unfortunately they both begin with "C"!.
Lets start with the obvious ones:
Technology Oriented Architecture: The orientation that most organisations were starting to use in the late 70's and most still use to this day as their primary oreination despite wishing to deny the fact.
Data Oriented Architecture: The orientation that some organisations started to use in the late 80's and some use today, many organisations aspire to being data or information oriented but few have achieved a high level of Information Orientation. Simple test: Has your organisation identified and classified all of its sensitive Information Asset Types?
Process Oriented Architecture: An orientation made famous by Michael Hammer of "Re-engineering" Fame, some trepidatious Enterprises were trying to use in the early 90's and few use today despite some of the huge value that Re-engineering Processes appeared to promise.
Now moving from the mainstream, and I am sure there will be some that will tell me that EOA and SOA are both mainstream, but I have to put the bar somewhere, and I have chosen solid signs of implementation as being my bar.
Enterprise Oriented Architecture: The orientation that most Architects are now talking about, though very few have delivered in practise. Perhaps I should be kind and refer to it as Mainstream! Nah!!!
Service Oriented Architecture: The morph of Technology orientation that is changing our focus from the technology to services. Some of you will remember the great renaming exercise that shifted IT departments to become IS departments, During the "noughties" Service Oriented Architecute started to gain sway, though few organisations have created one at the Enterprise Level. A few are achieving some degree of SOA at much lower levels.
Now onto the truly non Mainstream Architecture Orientation it is the
Collaboration Oriented Architecture, developed by the Jericho Forum as the answer the Life the Universe and everything....oops I clearly meant the answer to the De-Perimiterisation issue/opportunity. This Architecture Orientation is still not accepted by Architects, at least not those developing TOGAF. I think, that they think that we must all be on something!!
The fast approaching Semantically Oriented Architecture will certainly make a dent when it arrives, though I have a hunch it will first do a belly flop, for as far as I can tell the Semantic purists have not built into the core of their models and standards the rights and wishes of the individuals who are the principal or own the resources. Seems to me that the Web 3.1 will be better when it includes Security at its core. My attempts to find someone in Boston to explain this crucial notion to was a flop. So in fact you can blame me.
It all revolves around this thing called Entitlement, but that's another Blog Post.
So we finally get to the last orientation or to avoid future confusion I will call it a "Centricity"..... drum roll .... thus we have the Customer Centric Architecture!
So what is a Customer Centric Architecture, simply it is one that places the Customer at the heart of all Architecture Decisions and NOT the Product or Service that a company is selling. This is or at least should be the core or heart of all Architecture models, it's just that few of of us have truly understood this, and still fewer have implemented a Customer Centric Architecture.
As a quite aside Apple understood this in the way they designed their technology, they produce User Centric Technology, rather different to the Disk based Operating System of their rivals which is more technology out, than user in... but I digress
Then at 4am this morning it hit me.... We need all the orientations to make a Customer Centric Architecture Work!!! Then it was much easier for me to see them not as Orientations, but rather Layers.
Thus we now have:
Customer Centric Architecture CCA
Collaboration Architecture Layer CAL
Enterprise Architecture Layer EAL
SEmantic Architecture Layer SEAL
Process Architecture Layer PAL
Service Architecture Layer SAL
Technology Architecture Layer TAL
Data Architecture Layer
Architecture
Lets start with the obvious ones:
Technology Oriented Architecture: The orientation that most organisations were starting to use in the late 70's and most still use to this day as their primary oreination despite wishing to deny the fact.
Data Oriented Architecture: The orientation that some organisations started to use in the late 80's and some use today, many organisations aspire to being data or information oriented but few have achieved a high level of Information Orientation. Simple test: Has your organisation identified and classified all of its sensitive Information Asset Types?
Process Oriented Architecture: An orientation made famous by Michael Hammer of "Re-engineering" Fame, some trepidatious Enterprises were trying to use in the early 90's and few use today despite some of the huge value that Re-engineering Processes appeared to promise.
Now moving from the mainstream, and I am sure there will be some that will tell me that EOA and SOA are both mainstream, but I have to put the bar somewhere, and I have chosen solid signs of implementation as being my bar.
Enterprise Oriented Architecture: The orientation that most Architects are now talking about, though very few have delivered in practise. Perhaps I should be kind and refer to it as Mainstream! Nah!!!
Service Oriented Architecture: The morph of Technology orientation that is changing our focus from the technology to services. Some of you will remember the great renaming exercise that shifted IT departments to become IS departments, During the "noughties" Service Oriented Architecute started to gain sway, though few organisations have created one at the Enterprise Level. A few are achieving some degree of SOA at much lower levels.
Now onto the truly non Mainstream Architecture Orientation it is the
Collaboration Oriented Architecture, developed by the Jericho Forum as the answer the Life the Universe and everything....oops I clearly meant the answer to the De-Perimiterisation issue/opportunity. This Architecture Orientation is still not accepted by Architects, at least not those developing TOGAF. I think, that they think that we must all be on something!!
The fast approaching Semantically Oriented Architecture will certainly make a dent when it arrives, though I have a hunch it will first do a belly flop, for as far as I can tell the Semantic purists have not built into the core of their models and standards the rights and wishes of the individuals who are the principal or own the resources. Seems to me that the Web 3.1 will be better when it includes Security at its core. My attempts to find someone in Boston to explain this crucial notion to was a flop. So in fact you can blame me.
It all revolves around this thing called Entitlement, but that's another Blog Post.
So we finally get to the last orientation or to avoid future confusion I will call it a "Centricity"..... drum roll .... thus we have the Customer Centric Architecture!
So what is a Customer Centric Architecture, simply it is one that places the Customer at the heart of all Architecture Decisions and NOT the Product or Service that a company is selling. This is or at least should be the core or heart of all Architecture models, it's just that few of of us have truly understood this, and still fewer have implemented a Customer Centric Architecture.
As a quite aside Apple understood this in the way they designed their technology, they produce User Centric Technology, rather different to the Disk based Operating System of their rivals which is more technology out, than user in... but I digress
Then at 4am this morning it hit me.... We need all the orientations to make a Customer Centric Architecture Work!!! Then it was much easier for me to see them not as Orientations, but rather Layers.
Thus we now have:
Customer Centric Architecture CCA
Collaboration Architecture Layer CAL
Enterprise Architecture Layer EAL
SEmantic Architecture Layer SEAL
Process Architecture Layer PAL
Service Architecture Layer SAL
Technology Architecture Layer TAL
Data Architecture Layer
Architecture
Saturday, February 28, 2009
Abstraction and Clouds
After my SaaS/Abstraction Tweet, I have been considering my posit ie That SaaS can be implemented in a Cloud like Manner or NOT. Which appeared cause some tension...
FROM @golfcaddy
@adrius42 But isn't SAAS an abstraction of sorts?
From @ccairney
@adrius42 @golfcaddy if cloud computing is defined by layers abstraction then SaaS sits in one of the layers
From @RobynMiller
@adrius42 I don't know why, but the word abstraction doesn't 'click for me...
I have come to the conclusion that the tension comes down to the fact that the act of abstraction is NOT a binary switch, ie abstracted or not. I have perhaps been lazy in my thinking.
So to build my posit, here are some elements of the Abstraction Concept
SubRoutines: These are often just Abstraction within the Application
Service: Clearly a type of Abstraction that can be found in Clouds, but does that mean existance of Service Level abstraction = Cloud. I would argue not. Thoughts???
I personally believe you can use the service level abstraction in a manner that is not Cloud like.
I would also argue that the degree of abstraction, when designed in a cloud like manner is directly proportional to the Cloudiness of the Cloud involved.
For example I would argue that the use of Amazons S3 for data storage is clearly Cloud to some degree, but not "Full On Cloud". That would look like storage of data fully virtualised below the Abstraction Layer stored across, virtualised internal data storage, Amazon S3, and Nirvanix. So that if any of the storage services below the abstraction layer fail then the abstraction layer ensures that the consuming party above the abstraction layer is not aware of the event. Now that is Full On Cloud Computing, between the Platform and Storage Layer.
FROM @golfcaddy
@adrius42 But isn't SAAS an abstraction of sorts?
From @ccairney
@adrius42 @golfcaddy if cloud computing is defined by layers abstraction then SaaS sits in one of the layers
From @RobynMiller
@adrius42 I don't know why, but the word abstraction doesn't 'click for me...
I have come to the conclusion that the tension comes down to the fact that the act of abstraction is NOT a binary switch, ie abstracted or not. I have perhaps been lazy in my thinking.
So to build my posit, here are some elements of the Abstraction Concept
SubRoutines: These are often just Abstraction within the Application
Service: Clearly a type of Abstraction that can be found in Clouds, but does that mean existance of Service Level abstraction = Cloud. I would argue not. Thoughts???
I personally believe you can use the service level abstraction in a manner that is not Cloud like.
I would also argue that the degree of abstraction, when designed in a cloud like manner is directly proportional to the Cloudiness of the Cloud involved.
For example I would argue that the use of Amazons S3 for data storage is clearly Cloud to some degree, but not "Full On Cloud". That would look like storage of data fully virtualised below the Abstraction Layer stored across, virtualised internal data storage, Amazon S3, and Nirvanix. So that if any of the storage services below the abstraction layer fail then the abstraction layer ensures that the consuming party above the abstraction layer is not aware of the event. Now that is Full On Cloud Computing, between the Platform and Storage Layer.
Subscribe to:
Posts (Atom)