for Conor's 'List of Identities'.
I need more timely updates than every few months. How am I supposed to build a mashup without timely data?
He passed 350 without my even knowing it! So what am I now supposed to do with the balloons I had stocked for the celebration?
Wednesday, February 28, 2007
Tuesday, February 27, 2007
It's bad enough
that ZDNet makes me create an account in order to leave a comment on their identity blog. Worse still is making my ability to turn off their newsletter spam dependent on providing my company name and phone number.
Pam, I respectfully submit this for your consideration .
Pam, I respectfully submit this for your consideration .
Friday, February 23, 2007
Existence proof
AOL's John Panzer responds to my concern over AOL arbitrarily gifting me with another OpenID. John writes
John goes on
Of course, I don't want to use OpenID's delegation mechanism to point at this AOL OpenID - I don't even want the thing, why would I direct RPs to it?
If anything I'd want to instead edit the AOL HTML page to point at my chosen OpenID provider and URI. John suggests that this is now possible
Does John mean that AOL supports OpenID as the delegatee, but not the delagator? A business model peaks through the clouds.
My take is, if you don't actually use the OpenID URL, it doesn't really exist. The same way a Wiki page doesn't exist until you edit it.Well, until you create a link to a Wiki page and then edit it, it actually does not exist, i.e. it's not addressable. My AOL OpenID manifestly does exist and is addressable. What's more, anybody who knows (or can guess) my AIM screenname, can get to it.
John goes on
Another important point is that you can point at the AOL OpenID service from any web page you own in order to turn its URL into an OpenID. The minimal requirements are basically that you have some AOL or AIM account, and that you add a couple of links to your document's HEAD:
Of course, I don't want to use OpenID's delegation mechanism to point at this AOL OpenID - I don't even want the thing, why would I direct RPs to it?
If anything I'd want to instead edit the AOL HTML page to point at my chosen OpenID provider and URI. John suggests that this is now possible
We added this to our blogs product in a few minutes minutes (sic) and it's in beta now.I created a blog at AOL in order to try it out (NBARM - Nothing But a Redirect Mechanism) but I can see no ability to directly edit the HTML header to add the OpenID delegation tags.
Does John mean that AOL supports OpenID as the delegatee, but not the delagator? A business model peaks through the clouds.
Recommendation vs References
Johannes uses a nice employee hiring analogy to argue that both identity flow patterns of 'through the user-agent' and 'around the user-agent' are valid. As proponents of the Liberty Alliance's ID-WSF have been arguing the same for years, I heartily concur (and would argue that Liberty's People Service could be an excellent platform to build a reputation system on).
A slight quibble. The impression from Johannes analogy is that the 'Reference Check' model (comparable to 'around the user-agent') would allow the RP to get a more accurate view of the candidate's qualifications - even perhaps obtaining negative reviews from previous employers. Two points here:
A slight quibble. The impression from Johannes analogy is that the 'Reference Check' model (comparable to 'around the user-agent') would allow the RP to get a more accurate view of the candidate's qualifications - even perhaps obtaining negative reviews from previous employers. Two points here:
- in ID-WSF, the User still knows (but admittedly can't be completely sure) what goes in the 'reference letter'. It is the User that effectively both writes the letters through their interactions with their providers, and controls the advertisement of these letters, through their policy over controlling how such letters can be discovered. In Johannes's employment analogy, the candidate would never see such letters (and indeed would never know if they've been exchanged), and so the previous employer would presumably feel free to express their true opinion. As Johannes points out, in fact laws may still constrain the previous employer, and they definitely also constrain what an IDP will or can say about its Users.
- if a RP asks for the user's 'Frequent Flyer Status' from an IDP, and the User doesn't like the fact that the IDP asserts 'Silver' when the level of desired RP service is 'Gold', the Recommendation Letter model for identity flow would theoretically allow the User to see the assertion and, not liking the consequences, remove it (they can't change it). But of course, this doesn't help the User. Without the frequent flyer information of 'Silver', the RP will likely provide the default 'Bronze' level of service. The User is worse off than if they just let the 'Gold' status claim through. So it is for Recommendation letters - if the User filters out all information they don't wish to be disclosed to the prospective employer, they may be left with nothing at all to show.
Tags:
Thursday, February 22, 2007
Been there, done that
Scott Kveton equates Passport with the Liberty Alliance, minimizing both as 'been there ,done that' and 'totally impenetrable to the casual developer'. I totally agree. For too long, identity security has been stuffy and serious, let's just have fun with it.
Subscription-based Google Apps
From ZDNet, Google is expected to announce subscription-based web apps for enterprises.
This would be a perfect application of Google's existing SAML support for partner SSO.
This is encouraging
This isn't
This would be a perfect application of Google's existing SAML support for partner SSO.
This is encouraging
Built on open standards: We build our products using open standards when possible, simplifying the integration with or replacement of your existing IT infrastructure.
This isn't
Tags:
Identity Confusion - the Universal Graphical Language
MasterID is NTT Communication's SAML-based (specifically Liberty Alliance ID-FF) SSO solution with over 4M users.
Tags:
Wednesday, February 21, 2007
Parade of Nations
From Eve, It's a SAML World.
Makes me think the SSTC or the Liberty Alliance should hire the Muppets for a remake of the clip below. They could probably use the gig - last I heard the Swedish Chef was flipping burgers and Kermit and Miss Piggy have an 'Inter-species erotica' show in Amsterdam.
The "Parade of Nations" theme seems appropriate given Eve's litany of SAML support amongst government.
Makes me think the SSTC or the Liberty Alliance should hire the Muppets for a remake of the clip below. They could probably use the gig - last I heard the Swedish Chef was flipping burgers and Kermit and Miss Piggy have an 'Inter-species erotica' show in Amsterdam.
The "Parade of Nations" theme seems appropriate given Eve's litany of SAML support amongst government.
Friday, February 16, 2007
Public service phish awareness idea
- Guy goes up to obviously fake ATM machine.
- Unquestioningly provides his PIN (hums vaguely familiar Broadway tune while doing so).
- Walks away with slightly puzzled expression over not retrieving requested cash.
Voice over: Nobody would actually do this right?
Absence of evidence
is not Evidence of Absence. Carl said that. He wasn't talking about identity ceremonies as far as I know.
MyOpenID's 'Safe Sign-In' mechanism made me think of the phrase. Safe Sign-In is a feature of MyOpenID whereby users can stipulate that they want the normal OPenID sign-in sequence interrupted - this interruption designed to thwart the much discussed OpenID phish vulnerability.
Because the phish in question relies on a bad RP directing the user to a bad IDP for authentication, the Safe Sign-In option intentionally throws a wrench into the normal OpenID sequence with the GOOD IDP (in which, when arriving at that IDP, the user is asked to log-in if not already in a session). Instead of immediately asking the user to authenticate, the IDP instead displays a screen that basically says "To protect you, I'm not going to ask you to log-in yet. You need to come back on your own through a bookmark or entering my address manually". The MyOpenID screen in question is shown below
If the user enables Safe Sign-In for their IDP account, this is what they see whenever directed to the IDP from an SP. At this point, they would (presumably in a different tab/window) manually go the MyOpenID sign in page and authenticate, secure in the knowledge that they have run an end-around on any phisher. Afterwards, they'd return to the above page and click on 'continue this action' for redirection back to the RP. Note that, when actually being redirected to the valid IDP, this is all just unnecessary hassle for the user - they could have safely logged in as typical. (it's a hassle, but meant to be instructive hassle, no pain no gain etc).
Now, if a site were to want to phish MyOpenID, they would of course not display the above screen - they would instead display the log-in page as per the normal OpenID sequence. It's at this point that the Safe Sign-In mechanism is supposed to demonstrate its worth. The hope is that the user, conditioned by the previous multiple authentications to the valid IDP through the intentionally awkward Safe Sign-In mechanism - will identify (and avoid) the now easier log-in option as offered by the phisher. Alerted by the atypical log-in ceremony, the user would surf quickly away, feeling smug and safe.
The scheme relies on the user making the connection between the 'evidence of absence' (the fact that they see no Safe Sign-In screen) with 'absence of evidence' (a suspicious phish site that gets their spidy-senses tingling). This is the same model of Yahoo!'s Sign-in Seal, in which users are trained to expect to see a particular icon on their log-in page and warned to be suspicious should they not see it. I have doubts about the value of the model, it effectively places the burden of site authentication right on the user. Users make great validation engines of course.
But for OpenID IDPs, the value of such a model appears even more questionable. Remember that OpenID, to a certain extent, stipulates the form and format for the log-in ceremony in order to create a consistent user experience. Remember also that at any other OpenIDs the user will be authenticating to, unless those other IDPs also implement Safe Sign-In (or comparable), the user will be trained by their experiences to expect the normal OpenID log-in sequence of direct password prompt. So, what they are conditioned to expect as normal by these other IDPs is exactly what they would see by the MyOpenID phisher.
I just can't see the occasional 'training session' as delivered by MyOpenID's Safe Sign-In ceremony triumphing in setting user-expectations over the more frequent (and easier) conditioning they will receive everywhere else.
MyOpenID's 'Safe Sign-In' mechanism made me think of the phrase. Safe Sign-In is a feature of MyOpenID whereby users can stipulate that they want the normal OPenID sign-in sequence interrupted - this interruption designed to thwart the much discussed OpenID phish vulnerability.
Because the phish in question relies on a bad RP directing the user to a bad IDP for authentication, the Safe Sign-In option intentionally throws a wrench into the normal OpenID sequence with the GOOD IDP (in which, when arriving at that IDP, the user is asked to log-in if not already in a session). Instead of immediately asking the user to authenticate, the IDP instead displays a screen that basically says "To protect you, I'm not going to ask you to log-in yet. You need to come back on your own through a bookmark or entering my address manually". The MyOpenID screen in question is shown below
If the user enables Safe Sign-In for their IDP account, this is what they see whenever directed to the IDP from an SP. At this point, they would (presumably in a different tab/window) manually go the MyOpenID sign in page and authenticate, secure in the knowledge that they have run an end-around on any phisher. Afterwards, they'd return to the above page and click on 'continue this action' for redirection back to the RP. Note that, when actually being redirected to the valid IDP, this is all just unnecessary hassle for the user - they could have safely logged in as typical. (it's a hassle, but meant to be instructive hassle, no pain no gain etc).Now, if a site were to want to phish MyOpenID, they would of course not display the above screen - they would instead display the log-in page as per the normal OpenID sequence. It's at this point that the Safe Sign-In mechanism is supposed to demonstrate its worth. The hope is that the user, conditioned by the previous multiple authentications to the valid IDP through the intentionally awkward Safe Sign-In mechanism - will identify (and avoid) the now easier log-in option as offered by the phisher. Alerted by the atypical log-in ceremony, the user would surf quickly away, feeling smug and safe.
The scheme relies on the user making the connection between the 'evidence of absence' (the fact that they see no Safe Sign-In screen) with 'absence of evidence' (a suspicious phish site that gets their spidy-senses tingling). This is the same model of Yahoo!'s Sign-in Seal, in which users are trained to expect to see a particular icon on their log-in page and warned to be suspicious should they not see it. I have doubts about the value of the model, it effectively places the burden of site authentication right on the user. Users make great validation engines of course.
But for OpenID IDPs, the value of such a model appears even more questionable. Remember that OpenID, to a certain extent, stipulates the form and format for the log-in ceremony in order to create a consistent user experience. Remember also that at any other OpenIDs the user will be authenticating to, unless those other IDPs also implement Safe Sign-In (or comparable), the user will be trained by their experiences to expect the normal OpenID log-in sequence of direct password prompt. So, what they are conditioned to expect as normal by these other IDPs is exactly what they would see by the MyOpenID phisher.
I just can't see the occasional 'training session' as delivered by MyOpenID's Safe Sign-In ceremony triumphing in setting user-expectations over the more frequent (and easier) conditioning they will receive everywhere else.
Metasystem Permutations & Combinations
Ping's 'Internet Scale Identity' paper looks at the Big 4 (SAML, Cardspace, ID-WSF, and OpenID) of identity systems and analyzes each with respect to their support for (oversimplifying)
2 + (2*3) + (2*3*3) = 2 + 6 + 18 = 26
So, it seems there are 26 different ways to combine the 4 systems into identity transactions. Include X.509-auth direct to RPs and the list only grows.
Higgins has its work cut out for it.
- User authentication (Cardspace & ID-WSF)
- Subsequent front-channel SSO & attribute sharing from IDP to RP (Cardspace, SAML & OpenID)
- Subsequent back-channel Attribute Sharing from AP to SP (ID-WSF, some SAML & emerging OpenID )
- #1 on its own
- #1 followed by #2
- #1 followed by #2 followed by #3
2 + (2*3) + (2*3*3) = 2 + 6 + 18 = 26
So, it seems there are 26 different ways to combine the 4 systems into identity transactions. Include X.509-auth direct to RPs and the list only grows.
Higgins has its work cut out for it.
Please delete my AOL OpenID
George and Conor discuss AOL's new support for OpenID, specifically how best to inform users of their ability to use their AOL ID at other sites. Given that AOL is the first major public IDP to add support for OpenID, it will definitely be interesting to see how they 'brand' it to their, shall we say, less than internet-savvy core customer demographic.
My issue is more fundamental. I did not ask for, and nor do I want, an OpenID from AOL. I use AOL for the following purposes
Some will say 'So what, you don't want to use the AOL OpenID, don't use it, no harm done'. In a sense, they'd be right. If I can get over people seeing the empty ugliness of the above page (accessed simply by using my known AIM identifier) then I can let the AOL OpenID die a slow but natural death through lack of use.
But the real issue for me is not the page (even those pages I do maintain are only slightly less gaudy), it's the presumption on AOL's part that I want to have an OpenID with them, and their automatically enabling one for me without my consent. I already had (more than) enough OpenIDs with other IDPs (I am indeed waiting for a major public IDP to enable standards-based SSO to/from external properties but AOL is not that provider). I had only just recently consolidated on a preferred OpenID IDP (Go ProtectNetwork!) because of their multi-protocol support - I resent AOL coming along and complicating my IDP selection process once more.
Is AOL's enabling OpenID for me even consistent with the Terms of Service for AIM? The clause
Even if so, it's a no brainer that I should be able to turn off unwanted capabilities. Let me turn it off and get back to the business of growing my list of OpenID IDPs of my own choosing.
My issue is more fundamental. I did not ask for, and nor do I want, an OpenID from AOL. I use AOL for the following purposes
- AIM Instant Messaging
- Dulles meeting facilities
- Learning from George
Some will say 'So what, you don't want to use the AOL OpenID, don't use it, no harm done'. In a sense, they'd be right. If I can get over people seeing the empty ugliness of the above page (accessed simply by using my known AIM identifier) then I can let the AOL OpenID die a slow but natural death through lack of use.
But the real issue for me is not the page (even those pages I do maintain are only slightly less gaudy), it's the presumption on AOL's part that I want to have an OpenID with them, and their automatically enabling one for me without my consent. I already had (more than) enough OpenIDs with other IDPs (I am indeed waiting for a major public IDP to enable standards-based SSO to/from external properties but AOL is not that provider). I had only just recently consolidated on a preferred OpenID IDP (Go ProtectNetwork!) because of their multi-protocol support - I resent AOL coming along and complicating my IDP selection process once more.
Is AOL's enabling OpenID for me even consistent with the Terms of Service for AIM? The clause
AOL has the right at any time to change, modify, add to or discontinue or retire any aspect or feature of the AIM Products including, but not limited to, the software, community areas, Content, hours of availability, equipment needed for access or use, the maximum disk space that will be allotted on AOL servers on your behalf either cumulatively or for any particular service or the availability of AIM Products on any particular device or communications service. AOL has no obligation to provide you with notice of any such changes.might appear to give them all the legal leeway they need except how can they argue that OpenID functionality is part of the AIM Products?
Even if so, it's a no brainer that I should be able to turn off unwanted capabilities. Let me turn it off and get back to the business of growing my list of OpenID IDPs of my own choosing.
Tags:
Thursday, February 15, 2007
How very indulgent
I had never heard of the offsetting phenomenon until last week.I wouldn't be able to defend my business travel 'carbon footprint' were it not for Air Canada's reliance on solar power and wind turbines for their fleet.
Tags:
People! Pipes
What if the feeds/data sources that Yahoo! Pipes allows you to mash together were identity-based? What cool new social apps could you build? "Find me all single Zither players within 2 km of my current location"
The fact that a search for 'authentication' in the Message Boards returned nothing is telling.
The fact that a search for 'authentication' in the Message Boards returned nothing is telling.
Tags:
OpenID is not a unicycle
according to (currently) 18 Jyters(?).
So, given the obvious resistance, maybe the unicycle analogy isn't appropriate (and it definitely doesn't capture the momentum that OpenID is enjoying).
What vehicle would best capture the 'really great for building apps like Jyte' semantic? A Moke? open-sided, lightweight, cultish popularity, anti-establishment undertones?
So, given the obvious resistance, maybe the unicycle analogy isn't appropriate (and it definitely doesn't capture the momentum that OpenID is enjoying).
What vehicle would best capture the 'really great for building apps like Jyte' semantic? A Moke? open-sided, lightweight, cultish popularity, anti-establishment undertones?
Wednesday, February 14, 2007
Bootstrap
Discovery is a common challenge for identity systems. Fundamentally, requestors need to know where a bit of identity is located on the network so that a request can be sent there.
In SSO, when a User visits an SP, the SP needs to discover who and where the User's IDP is so that an authentication request can be delivered there. For the SP, the discovery question is 'Where should I redirect the user for them to authenticate?'.
OpenID solves the issue by allowing/requiring the User to provide either a specific identity URI at an IDP, or merely the URI of the IDP (directly or indirectly through delegation). SAML supports a variety of mechanisms (including the 'user-provides' model of OpenID) but standardizes a cookie-based option. Cardspace has the requestor present its identity needs to Cardspace, which then effectively 'discovers' appropriate IDPs.
When moving beyond SSO to attribute sharing, unless the desired attributes happen to be available from the same IDP as made the authentication assertion, discovery rears its head again. For an SP receiving an SSO assertion bu desiring additional attributes, the question becomes 'from which attribute provider can I obtain attribute X?'
The Liberty Alliance has always referred to this switch from the SSO to attribute sharing world as the 'bootstrap', and the bootstrap mechanism as the support that the SSO world can provide to the SP to facilitate this switch and subsequent discovery requirement. For the bootstrap from SAML & ID-FF based SSO to ID-WSF, we defined how the SAML SSO assertion carries the appropriate information (endpoint of a service at which the network location of the relevant user's various identity attributes and credentials to use there) for the SP to use should it wish to discover additional identity attributes.
But, other bootstraps are possible as well. Fundamentally, it's theoretically possible between any SSO protocol and a server-to-server attribute sharing protocol. For instance, you could define a boostrap mechanism from WS-Federation to ID-WSF if you were so inclined.
John Kemp explores mechanisms for boostrapping from OpenID to SAML (and then into ID-WSF). John provides two alternatives by which the OpenID RP could use SAML to retrieve an assertion to supplement the identity that flowed to it through the OpenID protocol. John doesn't mention emphasize subsequent bootstrapping into ID-WSF in his post, but the assertion that John's SAML mechanisms would retrieve could carry the necessary bootstrap information. Graphically
#1 is OpenID SSO, #2 is SAML Assertion retrieval, and #3 is ID-WSF Service discovery and query - now that's convergence! There must be a way to throw in Cardspace for good measure.
In SSO, when a User visits an SP, the SP needs to discover who and where the User's IDP is so that an authentication request can be delivered there. For the SP, the discovery question is 'Where should I redirect the user for them to authenticate?'.
OpenID solves the issue by allowing/requiring the User to provide either a specific identity URI at an IDP, or merely the URI of the IDP (directly or indirectly through delegation). SAML supports a variety of mechanisms (including the 'user-provides' model of OpenID) but standardizes a cookie-based option. Cardspace has the requestor present its identity needs to Cardspace, which then effectively 'discovers' appropriate IDPs.
When moving beyond SSO to attribute sharing, unless the desired attributes happen to be available from the same IDP as made the authentication assertion, discovery rears its head again. For an SP receiving an SSO assertion bu desiring additional attributes, the question becomes 'from which attribute provider can I obtain attribute X?'
The Liberty Alliance has always referred to this switch from the SSO to attribute sharing world as the 'bootstrap', and the bootstrap mechanism as the support that the SSO world can provide to the SP to facilitate this switch and subsequent discovery requirement. For the bootstrap from SAML & ID-FF based SSO to ID-WSF, we defined how the SAML SSO assertion carries the appropriate information (endpoint of a service at which the network location of the relevant user's various identity attributes and credentials to use there) for the SP to use should it wish to discover additional identity attributes.
But, other bootstraps are possible as well. Fundamentally, it's theoretically possible between any SSO protocol and a server-to-server attribute sharing protocol. For instance, you could define a boostrap mechanism from WS-Federation to ID-WSF if you were so inclined.
John Kemp explores mechanisms for boostrapping from OpenID to SAML (and then into ID-WSF). John provides two alternatives by which the OpenID RP could use SAML to retrieve an assertion to supplement the identity that flowed to it through the OpenID protocol. John doesn't mention emphasize subsequent bootstrapping into ID-WSF in his post, but the assertion that John's SAML mechanisms would retrieve could carry the necessary bootstrap information. Graphically
#1 is OpenID SSO, #2 is SAML Assertion retrieval, and #3 is ID-WSF Service discovery and query - now that's convergence! There must be a way to throw in Cardspace for good measure.
More wheels than Detroit
Ping ID's Chris Ceppi updates the (originally Stefan's) transportation taxonomy to reflect recent developments:
We shouldn't forget Stefan, he has a turbocharger that, once we work out how to strap it on, promises a serious boost in power.
- Cardspace is a pickup, reflecting its potential versatility for both work and play. Works for me, captures the uncertain fuel economy. Also begs the question - when shipped to the Midwest, will Cardspace come with gun racks and NRA bumper stickers?
- LID is deprecated in favour of OpenID, but a Unicycle is maintained as metaphor. It's fun to get around on but you can't carry groceries or beer with it.
- the recent Cardspace/OpenID integration is characterized as the OpenID unicycle thrown in the back of the pickup. The mental image I got from this is that the Cardspace truck gets you to the main destination, and then the OpenID unicycle serves as a handy runabout once there (like those tiny cars you see towed behind Winnebago's).
But, this isn't how the Cardspace/OpenID anti-phish integration works - Cardspace mostly stays put, it's OpenID that does the big mileage getting from the Cardspace authenticated IDP (thereby mitigating the phish) to the various SPs. So, it's more like the Cardspace driver dropping off the unicyclist at the freeway ramp, thereafter left to fend for themselves.
- SAML: SAML is a Honda Accord. Tried and tested, and you see them everywhere.
- ID-WSF: As far as I know, there are 4 maybe 5 space shuttles? I'd rather Liberty be considered the 777-300, state of the art and coming to an airline near you.
- WS-Federation: Too many ways to take this, I'm stumped.
We shouldn't forget Stefan, he has a turbocharger that, once we work out how to strap it on, promises a serious boost in power.
Tags:
Federated blogging
I may drive a Minivan
with child seats and a Dora the Explorer CD on continuous loop, but I have sufficient maleness left to recognize a completely cool convergence of identity and internal combustion when I see it.
I can just imagine.
Child 1: Dad, Quinn took my OTP token, and I can't login to the video server.
Child 2: I did not, and if I did, so what? It's 2-factor you doofus!
Tuesday, February 13, 2007
Subject Confirmation in Action
Last year I lost my package of Aeroplan upgrade certificates when returning from San Francisco. I had been using the envelope containing the upgrade certificates as a bookmark in the book I was reading. I was flying the red eye from SFO to YYZ and, when tiredness overcame me, placed the book in the pocket of the seat in front. And that's where it was when I left the plane.
A book can be easily replaced. But upgrade certificates - they're gold. It's the thought of using them (against all odds) that can make the anticipation of a 14 hour flight to Tokyo bearable. I was not happy when I realized I had lost them.
Coincidentally Aeroplan had just moved to personalized upgrade certs - each had my name printed on it. Aeroplan's motivation was to curtail the thriving black market for the certificates - a market made possible because the certificates were anonymous and so could be easily traded. The new personalized certificates can only be redeemed by the frequent flyer whose name is on the cert - no use selling them because the purchaser won't be able to use them. In order to use the certificates, the required subject confirmation method would have been to separately prove ownership of the subject identity.
If the certificates I had lost were anonymous, I wouldn't have even bothered asking for replacements. Aeroplan would have had no way to ensure that I wasn't double-dipping, e.g. falsely claiming their loss in order to receive replacements for sale. But, because the certificates I lost were personalized, Aeroplan could be at least confident that I wouldn't be able to sell them. And so, I asked for replacements. And, to my surprise, expecting bureaucratic inertia, they gave them to me.
They couldn't be sure I wasn't falsely claiming the loss of the certificates in order to get replacements for my own personal use - I expect they guard against this by watching how many certificates I might try to redeem over the next year.
A book can be easily replaced. But upgrade certificates - they're gold. It's the thought of using them (against all odds) that can make the anticipation of a 14 hour flight to Tokyo bearable. I was not happy when I realized I had lost them.
Coincidentally Aeroplan had just moved to personalized upgrade certs - each had my name printed on it. Aeroplan's motivation was to curtail the thriving black market for the certificates - a market made possible because the certificates were anonymous and so could be easily traded. The new personalized certificates can only be redeemed by the frequent flyer whose name is on the cert - no use selling them because the purchaser won't be able to use them. In order to use the certificates, the required subject confirmation method would have been to separately prove ownership of the subject identity.
If the certificates I had lost were anonymous, I wouldn't have even bothered asking for replacements. Aeroplan would have had no way to ensure that I wasn't double-dipping, e.g. falsely claiming their loss in order to receive replacements for sale. But, because the certificates I lost were personalized, Aeroplan could be at least confident that I wouldn't be able to sell them. And so, I asked for replacements. And, to my surprise, expecting bureaucratic inertia, they gave them to me.
They couldn't be sure I wasn't falsely claiming the loss of the certificates in order to get replacements for my own personal use - I expect they guard against this by watching how many certificates I might try to redeem over the next year.
SPML as Sanitation Custodian?
Ian asks "Is SPML irrelevant in the coming CardSpace/Higgins/OpenID identity world?", citing some work Liberty Alliance has been doing around its Advanced Client provisioning as cause for his question.
Ian points out that the Liberty Provisioning Service specification does not use the Service Provisioning Markup Language (SPML). True, but Ian himself acknowledges that the type of provisioning being addressed here is different than traditional 'account provisioning', for which the SPML defined CRUD operations were designed.
Nevertheless, SPML is very much on Liberty's 'radar', but for a different set of provisioning use cases, ones more in line with Ian's traditional 'enterprise user account provisioning' (albeit with a federated twist). Using Ian's analogy, SPML is poised to move up in the office hierarchy, leaving the mop behind for the exciting world of mail-room cubbyhole creation.
Whether the Cardspace product team or OpenID community thinks about provisioning (and possible relevance of SPML) is a different matter. Is a priori or batch account provisioning even compatible with the hard-line definition of 'user-centric' identity that would have the user checking every packet as it flows by?
Ian points out that the Liberty Provisioning Service specification does not use the Service Provisioning Markup Language (SPML). True, but Ian himself acknowledges that the type of provisioning being addressed here is different than traditional 'account provisioning', for which the SPML defined CRUD operations were designed.
As a user provisioning guy this model of provisioning looked a bit strange to me. Think telephone service provisioning, not enterprise user account provisioning.
Nevertheless, SPML is very much on Liberty's 'radar', but for a different set of provisioning use cases, ones more in line with Ian's traditional 'enterprise user account provisioning' (albeit with a federated twist). Using Ian's analogy, SPML is poised to move up in the office hierarchy, leaving the mop behind for the exciting world of mail-room cubbyhole creation.
Whether the Cardspace product team or OpenID community thinks about provisioning (and possible relevance of SPML) is a different matter. Is a priori or batch account provisioning even compatible with the hard-line definition of 'user-centric' identity that would have the user checking every packet as it flows by?
Tags:
Disconnected Identity
Conor is silent on his key contribution to the Liberty Alliance Advanced Client specifications, the first public draft of which is now available.
A key driver of Advanced Client functionality are so called 'disconnected' use cases. From the overview:
Similar to Cardspace, Advanced Client enables use cases in which a client can present identity claims to an SP without a 3rd-party IDP being directly involved but, importantly, also supports a model in which the client can act as an extension of an IDP, with rights for making claims delegated to it by that IDP.
A key driver of Advanced Client functionality are so called 'disconnected' use cases. From the overview:
The Advanced Client will operate in multiple modes of operation based upon the parties that it is interacting with. The modes are differentiated by the connectivity level of the various actors within a transaction. The two primary modes of operation that we are concerned with here include:
- Connected - the Advanced Client is fully connected to the network and generally all parties to a transaction could communicate with each other if necessary. In this mode, the Advanced Client can choose to act as a simple facilitator of the actual operation or for various reasons (such as privacy, load balancing, etc.) the Advanced Client can take a more active role, providing delegated authentication and/or web services.
- Disconnected - the Advanced Client does not have connectivity to one or more parties in a transaction (such as not having connectivity to the IdP during an authentication transaction). This mode limits the Advanced Client to delegated services and can restrict the availability of services exposed directly by the Advanced Client.
Similar to Cardspace, Advanced Client enables use cases in which a client can present identity claims to an SP without a 3rd-party IDP being directly involved but, importantly, also supports a model in which the client can act as an extension of an IDP, with rights for making claims delegated to it by that IDP.
Tags:
Monday, February 12, 2007
Phish Alert
Watch out for a particularly nefarious new phish that started hitting e-mail boxes in the last little while.
The email purports to be a communication from Conor Cahill.
It asks users to click a link that appears as "http://conorcahill.blogspot.com.".
Unfortunately for the unsuspecting recipient, the link does indeed take them to Conor's blog site - at which they are presented with various posts about gadgets, United Airlines Business Class, and life in rural Virginia.
A clear case of identity theft. Our attention is a valuable thing, and Conor is clearly stealing it away from more useful applications.
Tell anybody you care about not to click on such links.
The email purports to be a communication from Conor Cahill.
It asks users to click a link that appears as "http://conorcahill.blogspot.com.".
Unfortunately for the unsuspecting recipient, the link does indeed take them to Conor's blog site - at which they are presented with various posts about gadgets, United Airlines Business Class, and life in rural Virginia.
A clear case of identity theft. Our attention is a valuable thing, and Conor is clearly stealing it away from more useful applications.
Tell anybody you care about not to click on such links.
Something is smishing
Amidst the praise for the anti-phish potential of sequencing Cardspace authentication to OpenID SSO, perhaps we shouldn't forget this. Or this.
Separately, I've an idea for a new phish attack. Steps follow
Separately, I've an idea for a new phish attack. Steps follow
- Write an article about phishing & identity theft etc.
- Give lots of statistics.
- Provide standard warnings about link clicking.
- Quote Bruce Schneier.
- Have somebody named 'Mike from Tulsa' bemoaning the loss of his identity.
- Provide an example of a phish email. For that example, have two links, one to a screen shot of the phished site, another prefaced with 'compared to the actual PayPal site (click here)'.
- Pay for search engine placement.
- Sit back.
Sunday, February 11, 2007
Andre, Conor; Conor, Andre
Friday, February 09, 2007
Disappointing
An article from RegDeveloper claims that Oracle's submission of its Identity Governance Framework to the Liberty Alliance is 'disappointing'.
There is no justification for the claim, no evidence at all in fact as to why the submission wasn't appropriate or a smart move by Oracle.
The only hint as to why the writer Gavin Clarke was disappointed was a reference to the absence of Oracle's CEO from the show due to illness. Somebody have a little thing for Larry?
There is no justification for the claim, no evidence at all in fact as to why the submission wasn't appropriate or a smart move by Oracle.
The only hint as to why the writer Gavin Clarke was disappointed was a reference to the absence of Oracle's CEO from the show due to illness. Somebody have a little thing for Larry?
Tags:
SAML and Cold Fusion
A two part series on an implementation of SAML in Cold Fusion from Phil Duba
Part 1 and Part 2
From a comment in the second, Phil writes
This is quite the exaggeration - there are only 6 (SOAP, PAOS, HTTP Redirect, HTTP POST, HTTP Artifact, URI).
Part 1 and Part 2
From a comment in the second, Phil writes
The hardest part we've found in dealing with SAML is trying to figure out what of the 7 different methods/bindings is best to use.
This is quite the exaggeration - there are only 6 (SOAP, PAOS, HTTP Redirect, HTTP POST, HTTP Artifact, URI).
Tags:
MLS & SAML
Rapattoni offers services to the real-estate industry. I had never heard of them until I saw them listed in Liberty Alliance's adoption pages. Rapattoni apparently uses PingFederate for SAML 2.0-based SSO between its various services.
I applaud the attempt (if not the result) to explain how SSO works. It's not often you see actual information (albeit confusing) in a press release.
Just when I thought I understood SAML.
Maybe they could next explain how agents are worth the egregious commissions they charge.
I applaud the attempt (if not the result) to explain how SSO works. It's not often you see actual information (albeit confusing) in a press release.
This new SSO feature is based on the security industry standard Security Assertion Markup Language (SAML) technology. This technology allows the customer to establish "trust" relationships between Web sites. Rapattoni's SSO program will create and send an attached SAML "file" along with a link that can be received by any complying vendor's Web site. This process allows the user to avoid the repeated logon. Further, once the user has gained access to a compliant remote site, they can move freely between Web sites.
Also included in the SAML file is all of the information required by the receiving site to perform a certain function properly.
Just when I thought I understood SAML.
Maybe they could next explain how agents are worth the egregious commissions they charge.
Tags:
One Elgg, Sunny Side Up
Ben Werdmuller and Marc Canter are engaged in a pissing match heated discussion over their respective social network offerings - it's Elgg vs PeopleAggregator.
When criticized for Elgg's supposed lack of FOAF support, Ben responded
Ben might be forgetting something.
When criticized for Elgg's supposed lack of FOAF support, Ben responded
Actually, we've been doing FOAF pretty much since the year dot. Trouble is, nobody actually uses it. Show me the consumer applications. Or, in fact, any significant applications that even produce it. It's a bit like IMS in the educational world; you can shout all you want about it, and tout it as an important commercial feature, but in reality it doesn't really make much of a difference to anything. Ditto, SCORM. Or XFN.
What I do agree is that there needs to be some kind of standard that reliably covers the sort of data FOAF was meant to represent, in a flexible way.
Ben might be forgetting something.
Thursday, February 08, 2007
Tribute #1 - Gizmo of the Week
I picked up this can-opener from eBay for a steal. It was listed as $79.99 but I was able to use 200,000 miles to knock down the price 5 bucks.
It's a big improvement over the previous version, along with the can-opening piece it has 802.11g so I can control it from my office. I hate wasting time for the can to actually open so this way I can get it started before I get to the kitchen.
It came with management software but I didn't like how the menus were on the left-hand side so I wrote my own instead. If anybody is interested in doing some interop testing against my implementation just let me know.
I had earlier tried another manufacturer but found that its frequency interfered with that of the cereal bowl heater I had bought my wife for last years Xmassss. I had originally thought the problem was solar flares so had built a 300-foot tall geodesic dome to shield the house but this turned out to be a mistake (not mine, somebody elses). I had to take it down because it was clear plastic and the girls were always riding their horses into the thing.
My son (who is in a school for enriched students, not sure if I've mentioned that) was eventually able to diagnose the problem by building an interference detection system from Knex, a piece of aluminum foil, and three discarded Qtips.
Now if only Cheerios came in cans.
Tags:
Let's be fair about this
From the TimesOnline
"New proof that man has caused global warming"
Sure, but it's not as if women didn't also benefit.
"New proof that man has caused global warming"
Sure, but it's not as if women didn't also benefit.
Sampling OpenID RPs
OpenIDDirectory lists a whole bunch of OpenID Relying Parties at which you can use your OpenID.
As an experiment, I picked the New Sites category and attempted to use my ProtectNetwork.org OpenID. Here are the results:
Separately, there were almost as many 'ceremonies' as there were sites. Permutations included:
As an experiment, I picked the New Sites category and attempted to use my ProtectNetwork.org OpenID. Here are the results:
- http://www.fileformat.info/ - no option to log-in (using OpenID or otherwise)
- http://health20.org/ - Received 'The server encountered an internal error () that prevented it from fulfilling this request' after authenticating to my IDP. Interestingly, the site used the LID GUI model (i.e. icon in bottom right corner).
- http://www.phixr.com/photo/ - unable to login, the site indicates you can supply either a user name or OpenID, but still demands a password
- http://www.sylvainbriant.com - no option to log-in (using OpenID or otherwise)
- http://www.suppressionlist.com/ - Received 'Application error' after authenticating to IDP
- http://www.placeengine.com - No option to log-in (using OpenID or otherwise)
- http://www.insanejournal.com/ - Success!
- http://www.donengel.net/ - Partial Success. After successfully being redirected to my IDP, I consented to the release of my email back to the SP. Nonetheless, the SP still asked me for my email.
- http://www.challgren.com/ - Success
- http://www.finnix.org - Success
Separately, there were almost as many 'ceremonies' as there were sites. Permutations included:
- offering OpenID login as a peer to normal local account (e.g. Doxory)
- linking from main log-in page to an OpenID specific page (e.g. Finnix.org)
- variations on 'LogIn', 'Verify', as the etc (e.g. Challgren.com)
- Asking for an OpenID AND a password (e.g. Phixr)
- Describing the OpenID option as 'Blog URL' (e.g. Challgren.com)
Google uses SAML for partner SSO
My video production skills are growing by leaps and bounds.
Clearly the next step is for Google to adopt Liberty Alliance ID-WSF to allow such partners to access Google applications in a non-browser context.
Clearly the next step is for Google to adopt Liberty Alliance ID-WSF to allow such partners to access Google applications in a non-browser context.
Tags:
ProtectNetwork.org - Public SAML and OpenID IDP
ProtectNetwork.org is a public IDP that's worth noting because it supports both SAML and OpenID as SSO protocols. Follows is my halting and awkward screencap video of the two protocols in operation.
The stumbling when I was selecting my IDP from the SAML RP (the Internet2 Wiki) illustrates one issue with this model versus that of OpenID. But, what wasn't shown was that the Wiki set a cookie capturing my choice of IDP so that, on subsequent visits, I'd get immediately directed to ProtectNetwork.org without having to manually select/indicate my IDP. Trade-offs all around.
Note to self: cookies are the bane of creating demos of SSO operations, they often hide exactly that which you want to make explicit.
The stumbling when I was selecting my IDP from the SAML RP (the Internet2 Wiki) illustrates one issue with this model versus that of OpenID. But, what wasn't shown was that the Wiki set a cookie capturing my choice of IDP so that, on subsequent visits, I'd get immediately directed to ProtectNetwork.org without having to manually select/indicate my IDP. Trade-offs all around.
Note to self: cookies are the bane of creating demos of SSO operations, they often hide exactly that which you want to make explicit.
Tags:
A certain irony
There is a certain (some might go so far as to say 'rich') irony in a paper commissioned by the Liberty Alliance proposing a distinction between user-centric and federated identity that runs completely counter to prevailing Liberty opinion (or my interpretation of at least).
The "Digital Identity Management A Critical Link to Service Success: A Public Network Perspective" paper examines the challenges and opportunities for network operators
In a discussion of user-centric identity, the authors write:
These are strange criteria. The first would suggest that the (many) Liberty use cases where the user is not actively mediating (either because the identity does not flow through the user agent or because they are not otherwise involved) identity flow are not 'user-centric' - this is absolutely not the accepted Liberty view (in fact it's the definition of user-centric that Liberty argues strongly against).
The 'already given' in the last definition implies that a federated model deals only with the flow of data once it has already been shared at least once, perhaps through 'user-centric' active mediation?
For me, federation is a set of tools (e.g. SAML, Cardspace, OpenID, etc) user-centric is a philosophy for applying those tools.
At least the definitions are qualified by 'not agreed'.
The "Digital Identity Management A Critical Link to Service Success: A Public Network Perspective" paper examines the challenges and opportunities for network operators
The study analyzes identity management and its crucial role in enabling personalized services. Identity management is viewed as a crucial element in a basket of technology enablers that will be instrumental in preventing network operators from experiencing a dreaded “bit pipe” fate.
In a discussion of user-centric identity, the authors write:
Proposed, but not agreed, definitions for the different architectures are:
- User-Centric: user decides every time what identity attributes to reveal to the content provider
- Domain-Centric: user approves identity attributes appropriate to specific domains
- Federated: user approves transferring of identity attributes already given to other federation members
These are strange criteria. The first would suggest that the (many) Liberty use cases where the user is not actively mediating (either because the identity does not flow through the user agent or because they are not otherwise involved) identity flow are not 'user-centric' - this is absolutely not the accepted Liberty view (in fact it's the definition of user-centric that Liberty argues strongly against).
The 'already given' in the last definition implies that a federated model deals only with the flow of data once it has already been shared at least once, perhaps through 'user-centric' active mediation?
For me, federation is a set of tools (e.g. SAML, Cardspace, OpenID, etc) user-centric is a philosophy for applying those tools.
At least the definitions are qualified by 'not agreed'.
Wednesday, February 07, 2007
Speak now or forever hold ...
My marriage counselor says that a good marriage is one in which the partners complement each other - where one is weak, the other is strong and so forth (she also said something else about listening closely and being attentive but I can't recall the specifics).
The same is true of identity systems. If you integrate them together, the 'marriage' is much stronger if their respective strengths address weaknesses and limitations of the other.
Consider the following table. It attempts to lay out (very coarsely) the relative scope of 4 key identity systems, SAML, ID-WSF, Cardspace, and OpenID. Each system is characterized by whether or not they have something to say regarding 3 different interactions:
SAML and Liberty Alliance ID-WSF are in a marriage, and you can see why it's a strong one. The interactions that SAML covers (e.g. between IDP and SP) are those that ID-WSF doesn't and vice versa. The two are like those old couples who are able to successfully ignore each other and stay together forever (SAML's drinking is admittedly a problem but it is getting help).
Cardspace and OpenID got engaged yesterday and, based on the table above, it should be a beneficial arrangement for both. It was the first column that motivated getting hitched - namely that Cardspace authentication could serve to address OpenID's vulnerability to phishing. Maybe the third column might be relevant in the future as well, this would involve a Cardspace RP using OpenID Attribute Exchange to get attributes not availableo from the Cardspace IDP.
But, if I was an 'identity system therapist', it would be the second column that might give me concern and have me set aside some 2 hour sessions for serious counselling. Both Cardspace and OpenID define mechanisms by which the assertions an IDP makes with respect to a user can be communicated to the RP - essentially, they both 'do' SSO. So, when is it appropriate to use OpenID, and when to use Cardspace?
One way for the two newlyweds to reconcile this overlap would be 'Well honey, OpenID is the right choice for low value transactions, and Cardspace for more sensitive applications' (I think this is how Jessica and Nick lasted as long as they did).
Ignoring questions of who decides what is valuable etc, this model might work - until such time as OpenID sees a self-actualization episode on Oprah and decides that it needs to 'grow spiritually'.
In the mean time, SAML and ID-WSF have been known to 'swing' - if you catch my drift.
The same is true of identity systems. If you integrate them together, the 'marriage' is much stronger if their respective strengths address weaknesses and limitations of the other.
Consider the following table. It attempts to lay out (very coarsely) the relative scope of 4 key identity systems, SAML, ID-WSF, Cardspace, and OpenID. Each system is characterized by whether or not they have something to say regarding 3 different interactions:
- that between the user and the IDP (i.e. how the user authenticates to the IDP)
- that between the SP and the IDP (i.e. how identity attributes are communicated/requested from one to the other)
- that between the SP and some other AP (i.e. how the SP finds and invokes sources of identity information other than the IDP)
SAML and Liberty Alliance ID-WSF are in a marriage, and you can see why it's a strong one. The interactions that SAML covers (e.g. between IDP and SP) are those that ID-WSF doesn't and vice versa. The two are like those old couples who are able to successfully ignore each other and stay together forever (SAML's drinking is admittedly a problem but it is getting help).Cardspace and OpenID got engaged yesterday and, based on the table above, it should be a beneficial arrangement for both. It was the first column that motivated getting hitched - namely that Cardspace authentication could serve to address OpenID's vulnerability to phishing. Maybe the third column might be relevant in the future as well, this would involve a Cardspace RP using OpenID Attribute Exchange to get attributes not availableo from the Cardspace IDP.
But, if I was an 'identity system therapist', it would be the second column that might give me concern and have me set aside some 2 hour sessions for serious counselling. Both Cardspace and OpenID define mechanisms by which the assertions an IDP makes with respect to a user can be communicated to the RP - essentially, they both 'do' SSO. So, when is it appropriate to use OpenID, and when to use Cardspace?
One way for the two newlyweds to reconcile this overlap would be 'Well honey, OpenID is the right choice for low value transactions, and Cardspace for more sensitive applications' (I think this is how Jessica and Nick lasted as long as they did).
Ignoring questions of who decides what is valuable etc, this model might work - until such time as OpenID sees a self-actualization episode on Oprah and decides that it needs to 'grow spiritually'.
In the mean time, SAML and ID-WSF have been known to 'swing' - if you catch my drift.
Tags:
Informed & controlling RPs
Informed Control's Mark Wahl discusses the range of possibilities by which an RP might come to the conclusion that a particular IDP was 'worthwhile'.
I explored a similar set of options in a previous post, options that would support the full range of RP selectivity from promiscuous to prim.
Mark makes the point that the RP will probably make its decision to trust an IDP (or not) just once in order to establish the relationship, with that decision subsequently manifested in the IDP being placed in a white (or black) list or some other more easily assessed mechanism (when you hire a new employee, you examine their resume and references at the interview, not every time they show up for work).
In a closed community in which a relying party only trusts the validation of credentials to be performed by a single identity provider, typically run by that same organization, then this is a non-issue. Other environments, such as in a federal government medium security infrastructure, a relying party may have an enumerated set of identity providers that it recognizes. In other environments, it is not clear how a relying party should choose the identity providers that it trusts.
I explored a similar set of options in a previous post, options that would support the full range of RP selectivity from promiscuous to prim.
Mark makes the point that the RP will probably make its decision to trust an IDP (or not) just once in order to establish the relationship, with that decision subsequently manifested in the IDP being placed in a white (or black) list or some other more easily assessed mechanism (when you hire a new employee, you examine their resume and references at the interview, not every time they show up for work).
Ping Metasystem Paper
I wonder if the timing of this metaystem paper from Ping is coincidental to yesterday's Cardspace /OpenID announcement?
The second integration scenario described in the paper could have come direct from yesterday's PR (albeit with an interesting SAML twist)
The second integration scenario described in the paper could have come direct from yesterday's PR (albeit with an interesting SAML twist)
- signon.com has implemented phishing resistant authentication and supports Self-asserted Card Space authentication. Alice uses her CardSpace Identity Selector to authenticate to signon.com.
- After successfully authenticating Alice, signon.com use the OpenID protocol to redirect Alice back to isp.com
Really great news coming on Ping Identity.
Tags:
I have a few of these
I'm seeing a ranking system whereby account holders can rate the 'usefulness' (and it's not simply how often it gets used) of an account - giving those considering establishing one some input. Maybe I can even define policy so that I don't even see 'Register Now!' prompts unless a certain threshold is met.
Tuesday, February 06, 2007
I rink therefore I am
At least that's how many Canadian (not those from Vancouver, maybe some Northern States, probably Finnish) fathers feel.What better way to demonstrate your devotion to your kids and their nascent NHL career than by building a rink for those first halting steps (and subsequent falls)? Also, what better way to get out of the house to avoid that busy post-dinner homework period?
Come to think of it, what other sport allows a parent to actually build the 'playing field' for their kids athletic aspirations? You ever see a Dad in India leveling out a cricket pitch by the rhododendrons? Or one in the US putting down chalk lines for a baseball diamond amongst the tomatoes?
In years past I built a rink in our backyard. I spent many a peaceful hour pacing slowly across the ice in rubberized boots, pulling a hose behind me, watching the water spread across the ice and slowly congeal into a smooth 'flood'. There is a certain satisfaction derived from such slow, almost mindless, repetitive operations working towards a distant and uncertain goal (e.g. the standards development process).
Unfortunately, due to the suburban sprawl of recreational equipment in our yard, there is no longer sufficient room for a reasonably sized ice surface. To satisfy my urge for nocturnal outdoor watering, I've taken to peeing on the neighbour's garbage cans. When challenged, I just say "It's for the kids".
Cardspace inside (OpenID)
The identity world is a flutter due to the announcement of Cardspace-OpenID integration (Johannes described it as a marriage, I wonder if there was a pre-nup?)
If I'm reading correctly between the lines, the announcement puts some meat on the integration scenario that was described by Kim a few weeks back - namely how Cardspace authentication could mitigate the much discussed OpenID phish attack.
For this to work, OpenID providers need to support Cardspace self-asserted cards (thus the commitment from OpenID vendors to add Cardspace) so that the OPs can bridge between the two worlds. Ping already demonstrates this working (importantly, as Ashish points out, if Cardspace authentication is going to be of value to an OpenID RP, there will need be mechanisms in OpenID to differentiate such an authentication from a lesser form. AQE is one option).
Interestingly, this is pretty much the same scenario (Cardspace authentication embedded within a SSO sequence) as previously portrayed in Ping's demo showing Cardspace and SAML integration (as commented on by Kim). Strange, no keynote announcement for that integration, I guess it didn't sufficiently excite Bill?
If I'm reading correctly between the lines, the announcement puts some meat on the integration scenario that was described by Kim a few weeks back - namely how Cardspace authentication could mitigate the much discussed OpenID phish attack.
For this to work, OpenID providers need to support Cardspace self-asserted cards (thus the commitment from OpenID vendors to add Cardspace) so that the OPs can bridge between the two worlds. Ping already demonstrates this working (importantly, as Ashish points out, if Cardspace authentication is going to be of value to an OpenID RP, there will need be mechanisms in OpenID to differentiate such an authentication from a lesser form. AQE is one option).
Interestingly, this is pretty much the same scenario (Cardspace authentication embedded within a SSO sequence) as previously portrayed in Ping's demo showing Cardspace and SAML integration (as commented on by Kim). Strange, no keynote announcement for that integration, I guess it didn't sufficiently excite Bill?
Monday, February 05, 2007
Only in horseshoes and big bombs
does 'close' count.
I searched for a song on Pandora. The system found it, but queued up another similar song instead of the one I asked for. The reason - their license does not allow them to immediately serve the particular songs that are searched.
Interesting model. When applied to identity, it might resemble
Requestor: Can I have Joe's shipping address?
Provider: As requested - here is Joe's email address.
Requestor: Sorry, you must have misheard, I asked for his shipping address.
Provider: My hearing is just fine, thank you very much.
Requestor: Didn't mean to offend, but you gave me his email address when I asked for his shipping address.
Provider: Indeed I did.
Requestor: Glad that's cleared up, could I get the shipping address then?
Provider: It's a perfectly good email address.
Requestor: I'm sure it is, but I don't need his email, I need his shipping address.
Provider: Seems a shame to not use it somehow.
Requestor: (sighing) OK, I'll take the email address. But I do need his shipping address.
Provider: Say hi to Joe from me when you use the email.
Requestor: I will most definitely mention you, but the shipping address ....
Provider: Oh, you need his shipping address?
Requestor: (pause) Yes, yes I do.
Provider: Are you going to ship something to him?
Requestor: Yes, but I don't see what ...
Provider: Did he get the flat screen? He's been wanting one for the longest time.
Requestor: I'm sorry but that's really none of your business.
Provider: Oh excuuuse me, what he bought is none of my business but his email address is yours?
Requestor: I didn't even want his email address!
Provider: Then why did you ask for it?
Requestor: Just forget it, I'll send him an email telling him to pick the parcel up from the store.
Provider: Hah, so you needed the email after all!
silence
Provider: Hello? Hello?
silence
Provider: Did you know he was a Sagitarius?
I searched for a song on Pandora. The system found it, but queued up another similar song instead of the one I asked for. The reason - their license does not allow them to immediately serve the particular songs that are searched.
Interesting model. When applied to identity, it might resemble
Requestor: Can I have Joe's shipping address?
Provider: As requested - here is Joe's email address.
Requestor: Sorry, you must have misheard, I asked for his shipping address.
Provider: My hearing is just fine, thank you very much.
Requestor: Didn't mean to offend, but you gave me his email address when I asked for his shipping address.
Provider: Indeed I did.
Requestor: Glad that's cleared up, could I get the shipping address then?
Provider: It's a perfectly good email address.
Requestor: I'm sure it is, but I don't need his email, I need his shipping address.
Provider: Seems a shame to not use it somehow.
Requestor: (sighing) OK, I'll take the email address. But I do need his shipping address.
Provider: Say hi to Joe from me when you use the email.
Requestor: I will most definitely mention you, but the shipping address ....
Provider: Oh, you need his shipping address?
Requestor: (pause) Yes, yes I do.
Provider: Are you going to ship something to him?
Requestor: Yes, but I don't see what ...
Provider: Did he get the flat screen? He's been wanting one for the longest time.
Requestor: I'm sorry but that's really none of your business.
Provider: Oh excuuuse me, what he bought is none of my business but his email address is yours?
Requestor: I didn't even want his email address!
Provider: Then why did you ask for it?
Requestor: Just forget it, I'll send him an email telling him to pick the parcel up from the store.
Provider: Hah, so you needed the email after all!
silence
Provider: Hello? Hello?
silence
Provider: Did you know he was a Sagitarius?
Friday, February 02, 2007
SAML =/= SOAP
While acknowledging the 'sensitivity/value' advantages it has over 'lighter' alternatives, Eric Norlin incorrectly describes SAML as SOAP-based.
I understand the mistake. SOAP is 'complex', SAML is 'complex', it just makes sense that they must be inextricably intertwined.
its still important to realize that SOAP-based systems of identity (SAML and WS-Federation) are still much more adept at maneuvering through high-risk transactions that take place onlineSAML does define a SOAP Binding as one mechanism for moving messages and assertions around. It also defines a number of other bindings that have nothing to do with SOAP.
I understand the mistake. SOAP is 'complex', SAML is 'complex', it just makes sense that they must be inextricably intertwined.
SordID Thought
If I could teach people just one thing about identity, I bet they would all be coming up to me at the front of the class saying "Hey, I want the money back that I paid you for the 'Detailed Overview of Identity Management' course".
Thursday, February 01, 2007
Atomic VRM
I have a pretty good idea of the business trips I will take this year. Current best estimate (will certainly change) is
I would even consider switching loyalty programs if it was worth my while. It wouldn't be for a single trip, it could be for a year's worth of travel.
A rough estimate of the cost for the above trips is $9-10K. Is this a big enough number for other airlines to want to proactively court my business by quoting me a number for the complete set? Is it large enough for them to throw in some status perks?
VRM should account for such dependencies between individual items - either an airline bids on the package or not at all.
Pseudo-XML might look like
I'd love to see the equivalent microformat.
- March - London
- April - Brussels
- June - Dulles
- July - Oxford
- September - Wellington
- October - Tokyo
- December - Santa Clara
I would even consider switching loyalty programs if it was worth my while. It wouldn't be for a single trip, it could be for a year's worth of travel.
A rough estimate of the cost for the above trips is $9-10K. Is this a big enough number for other airlines to want to proactively court my business by quoting me a number for the complete set? Is it large enough for them to throw in some status perks?
VRM should account for such dependencies between individual items - either an airline bids on the package or not at all.
Pseudo-XML might look like
<vrm:rfp>
<pol:all>
<vrm:item>
<air:flight return="1" maxConnect="1">
<air:from id="yow">YOW</air:from>
<air:to id="lhr">LHR</air:to>
<air:itin>
<air:day start="#yow" end="#lhr">07-07-07</air:day>
<air:day start="#lhr" end="#yow">14-07-07</air:day>
</air:itin>
</air:flight>
</vrm:item>
<vrm:item>
<air:flight return="1" maxConnect="2">
<air:from id="yow2">YOW</air:from>
<air:to id="wel">WEL</air:to>
<air:itin>
<air:day start="#yow2" end="#wel">10-09-07</air:day>
<air:day start="#wel" end="#yow2">24-09-07</air:day>
</air:itin>
</air:flight>
</vrm:item>
</pol:all>
</vrm:rfp>
I'd love to see the equivalent microformat.
Tags:
Subscribe to:
Posts (Atom)