Such references got me thinking about the key role SAML plays in the emerging identity infrastructure and key deployments.
Dare I suggest
I guess this would be more speculative
Tags:
Sunday, December 17, 2006
SAML Inside
Last weeks's Liberty Alliance meeting at Intel in Portland was an opportunity for many a snide muttering of 'Intel Inside' anytime there was a glitch in the technical infrastructure (the screen in particular).
Such references got me thinking about the key role SAML plays in the emerging identity infrastructure and key deployments.
Dare I suggest
I guess this would be more speculative
Such references got me thinking about the key role SAML plays in the emerging identity infrastructure and key deployments.
Dare I suggest
I guess this would be more speculative
Saturday, December 16, 2006
Request/response trickery
From Don Park, a description of how Skype fools firewalls into allowing inbound messages by convincing the firewall that the request is actually a response to a previously sent request.
Feels sort of like SAML's PAOS (SOAP backwards) binding, in which
Feels sort of like SAML's PAOS (SOAP backwards) binding, in which
- The client requests a service using an HTTP request.
- The service provider responds with a SAML authentication request. This is sent using a SOAP request, carried in the HTTP response.
- The client returns a SOAP response carrying a SAML authentication response. This is sent using a new HTTP request
Tags:
A blank slate
I was helping my 7-year old son set up an account at a game site.
He chose an account name that he will remember, and then I asked him to choose a password. His reply?
" 'Madsen' - that's what I always use"
Some might think grounding him and having him write out 'I will not reuse passwords' a 100 times an over-reaction.
He chose an account name that he will remember, and then I asked him to choose a password. His reply?
" 'Madsen' - that's what I always use"
Some might think grounding him and having him write out 'I will not reuse passwords' a 100 times an over-reaction.
Thursday, December 14, 2006
Nice try eh
I began the checkout process for an Xmas gift for my son at an online toy store but did not complete - disgusted at the inflated price charged me solely on the basis of a Canadian address.
My hesitation did not go unnoticed.
The fact that retailers will offer discounts to hesitant closers has not gone unnoticed by myself.
Nevertheless, picked the gift up at Target with Conor and Taki.
My hesitation did not go unnoticed.
The fact that retailers will offer discounts to hesitant closers has not gone unnoticed by myself.
Nevertheless, picked the gift up at Target with Conor and Taki.
Stepper-up authentication
Ashish posts on the new Firefox extension through which Cardspace can be invoked.
Not sure what to make of the graphic Ashish uses. The dual escalators leading to a fitness club might be interpreted as suggesting Cardspace is the lazy man's option, as opposed to the morally and physically superior low-tech 'password as stairs'.
Overused Meme 2.0
Within the span of 3 days from a single RSS feed, I saw 3 profiles of the '2.0 Descriptor' standard.
4 if you consider 'Top 20' a typo.
4 if you consider 'Top 20' a typo.
Wednesday, December 13, 2006
Push me Pull me
Shekhar takes me to task for what he perceives as a bias towards pull-based authorization (and against push-based models).
I am disappointed that Paul missed another approach mentioned in the document ( or may be I am missing something). Pat rightly identified the 2 typical models that can be implemented and Paul extended it by coming up with all the permutation and combinations using various components. But all the model discussed look to be various permutation of just one model i.e. Authorization Pull Model where the resource is resposible to connect to the Decision Point to get the result. I think a hybrid of the "Authorization Push Model" and Local policy evaluation is more appropriate for the federation model where along with the identity the authorization of subject itself will flow to the other domain.
Actually, in listing out the permutations, we explicitly called out that we were not making any assumptions about the actual mechanism by which authorization data was transferred
It’s important to note that the above diagrams are intended to show configurations of components, not information flows. For instance, for any configuration that involves the sharing of subject attributes, these may be included in the actual request to access a resource, or they may be requested by the AEF (or other component) from the subject after receipt of the access request,
Sunday, December 10, 2006
Be prepared
After NBC airs their new show, all identity bloggers should be prepared for a barrage of (inevitably disappointed) visitors.
I can see it now
I can see it now
Hey Darlene, is one of them contestants named 'SAML', no wait, they must mean Samuel. Is there a 'Samuel' on the show?
No? well how 'bout a 'Uri'? Jeez, why are they putting one of those damn Russkis on the TV?
Saturday, December 09, 2006
Friday, December 08, 2006
And you need this info why?
I signed up for Sirius radio.
In the middle of the registration I was asked to indicate the primary place of installation. And then I was presented with this
How nice, save me the effort of remembering my model by allowing me to provide the VIN and have them do the work. It's only been 5 hours and I'm already impressed by their customer service.
If I bothered to read it I bet their privacy policy would have a clause on the order of
I also quite liked the 'Please be sure to click Next to proceed to the next screen'. Did usability studies show that people lost track at this point? 'Now what was I here for .....?'
In the middle of the registration I was asked to indicate the primary place of installation. And then I was presented with this
How nice, save me the effort of remembering my model by allowing me to provide the VIN and have them do the work. It's only been 5 hours and I'm already impressed by their customer service.If I bothered to read it I bet their privacy policy would have a clause on the order of
We may use your vehicle VIN at some point in the future, for reasons as yet undetermined but nevertheless still governed by your acceptance of this policy.
I also quite liked the 'Please be sure to click Next to proceed to the next screen'. Did usability studies show that people lost track at this point? 'Now what was I here for .....?'
Was this a script?
James McGovern posted the exact same comment to a post of mine, one of Conor's, and one of Pat's.
Not sure about the mechanism, but my thoughts regardless.
If you look at the P*P (PDP, PIP, PEP, PAP) model that SAML popularized, in theory you can distribute them any which way across the boundary between two policy domains. Typical federation models allow for the PIP (or at least one of them) separate/distant from the PEP and PDPs guarding some resource - the PIP supplies information (typically in the form of user attributes) to the PDP that feeds into the authorization decision. Shibboleth is a good example of this model.
In principle, you could have the PDP also distant from the PEP (which necessarily has to be 'close' to the resources its protecting) but its a special kind of PEP that will listen to such a PDP. This is what I expect James is referring to when he says 'federated authorization'.
In a previous life, my Entrust colleague at the time Carlisle Adams and I looked at the different permutations - the work can be found in an appendix to a GGF paper called "Conceptual Grid Authorization Framework and Classification".
The permutations we identified are shown below (with terminology aligned to the Grid world - the paper explains).
Does Federated Identity sometimes require Federated Authorization? If so, how come this isn't ever discussed. Maybe you could address in future blog entry...As ever, Eve is special, she rated a slightly modified version.
Not sure about the mechanism, but my thoughts regardless.
If you look at the P*P (PDP, PIP, PEP, PAP) model that SAML popularized, in theory you can distribute them any which way across the boundary between two policy domains. Typical federation models allow for the PIP (or at least one of them) separate/distant from the PEP and PDPs guarding some resource - the PIP supplies information (typically in the form of user attributes) to the PDP that feeds into the authorization decision. Shibboleth is a good example of this model.
In principle, you could have the PDP also distant from the PEP (which necessarily has to be 'close' to the resources its protecting) but its a special kind of PEP that will listen to such a PDP. This is what I expect James is referring to when he says 'federated authorization'.
In a previous life, my Entrust colleague at the time Carlisle Adams and I looked at the different permutations - the work can be found in an appendix to a GGF paper called "Conceptual Grid Authorization Framework and Classification".
The permutations we identified are shown below (with terminology aligned to the Grid world - the paper explains).
health.google.com
From Johannes, hints of Google's plans for health identity.
The kicker:
The kicker:
Patients also need to be able to better coordinate and manage their own health information. We believe that patients should control and own their own health information, and should be able to do so easily. Today it is much too difficult to get access to one's health records, for example, because of the substantial administrative obstacles people have to go through and the many places they have to go to collect it all. Compare this to financial information, which is much more available from the various institutions that help manage your financial "health."Currently, Google has no credibility here. They could buy some though.
Thursday, December 07, 2006
What the SP knows (and when it learns it)
It occurred to me that there are 2 distinct points at which the SP 'learns' something about the user in basic SSO - the first is whatever bit of information is provided to the SP to enable IDP discovery, and the second is whatever the IDP, once discovered, asserts to.
Our various identity systems differ in both steps, as shown below.
Time is the horizontal axis, the vertical is a representation of how 'much' the SP knows at any one time
Normal caveats about over simplification, not drawn to scale, etc.
I was hoping this would lead to some sort of "Madsen's Privacy Law of Minimal Area" - expressing the premise that, all else being equal, the area under the curve should be minimized for optimal privacy but can't quite reconcile that with Credentica's tech having greater area than others. Maybe I should just ignore it - I wouldn't be the first researcher to do so for data that didn't fit my theories.
Our various identity systems differ in both steps, as shown below.
Time is the horizontal axis, the vertical is a representation of how 'much' the SP knows at any one time
Normal caveats about over simplification, not drawn to scale, etc.I was hoping this would lead to some sort of "Madsen's Privacy Law of Minimal Area" - expressing the premise that, all else being equal, the area under the curve should be minimized for optimal privacy but can't quite reconcile that with Credentica's tech having greater area than others. Maybe I should just ignore it - I wouldn't be the first researcher to do so for data that didn't fit my theories.
Mapping Cardspace to OpenID (and then back)
Chuck Mortimore posts a movie of a login sequence in which an OpenID identity is represented by an Infocard in his Firefox Cardspace. When the user selects that card (after the Cardspace RP requests login) his extension uses the OpenID protocol to retrieve the necessary claims from the OpenID IDP, and then dynamically maps them into the Cardspace format for delivery down to the Cardspace RP.
Very nice PoC. It seems anything is possible when clients can translate between protocols.
Despite the data within originally coming from a 3rd party IDP, I guess the card that gets created will necessarily be self-issued - this because the step of translating from OpenID to Cardspace format would destroy any means by which the Cardspace RP would (reliably) determine origin.
The UI initially gave me the impression that the user actually presented their OpenID IDP credentials to the Identity Selector (and that caused great confusion for a bit) but its just how the OpenID HTML login page is embedded within.
Very nice PoC. It seems anything is possible when clients can translate between protocols.
Despite the data within originally coming from a 3rd party IDP, I guess the card that gets created will necessarily be self-issued - this because the step of translating from OpenID to Cardspace format would destroy any means by which the Cardspace RP would (reliably) determine origin.
The UI initially gave me the impression that the user actually presented their OpenID IDP credentials to the Identity Selector (and that caused great confusion for a bit) but its just how the OpenID HTML login page is embedded within.
Wednesday, December 06, 2006
Where's the Porschaaaa?
If not for a certain video, this comment would be meaningless - context really is everything.
My boss is aIs it true Dick drives a Pinto? and he's actually *A Prestige?
Canadian
from BC
specifically
Vancouver
where they'll hold the Olympics
in Gastown
who's male
42-years old
which means he's over 25
and under 65
who went to UBC
and is a CEO
and founder
and bartender
and belongs to the Vancouver Entrepreneur Forum
and is a blogger at blame.ca
who banks at HSBC
and flys Air Canada
and is a Star Alliance Gold member
who likes Macs
Real world Authentication Context
Responding to a challenge by Dave Kearns, Symlabs responds on the topic of real-world application of SAML's Authentication Context.
Symlabs writes
Separately, Sampo should blog, it would be ... 'interesting'.
Symlabs writes
At Symlabs, we see our customers using AuthnContext for information about how a user was provisioned in the first place, and also how the user was authenticated for the current session.and
Symlabs was instrumental in getting the mobile authentication contexts defined, because our wireless operator customers requested our participation in this area.Indeed, I remember well the after-hours session (Paris?) with Sampo thrashing out the mobile classes for ID-FF.
Separately, Sampo should blog, it would be ... 'interesting'.
Ponderings
Lots of very smart identity people subtlely diminish their blogging as 'My X on identity', where X is some noun denoting esoterica or inconsequentiality etc
A short list:
Roger Sullivan - musing and meanderings
Ben Laurie - blatherings
Robin Wilton - esoterica
Andre Durand - ramblings
Conor Cahill - musings
Ludovic Poitou - sketches
Julian Bond - a pointer to nothing
Me, I'm searching for a noun for 'semi-authoritative pontification'.
'Pompousity' comes close but doesn't quite capture the essential sense of deep insecurity.
A short list:
Roger Sullivan - musing and meanderings
Ben Laurie - blatherings
Robin Wilton - esoterica
Andre Durand - ramblings
Conor Cahill - musings
Ludovic Poitou - sketches
Julian Bond - a pointer to nothing
Me, I'm searching for a noun for 'semi-authoritative pontification'.
'Pompousity' comes close but doesn't quite capture the essential sense of deep insecurity.
Identity-based Greeting Cards
- This might be the only non-spam you get today.
- Sorry to hear about your ID theft.
- Congrats on your new persona!
- Don't think of it as getting phished, but rather a chance to start your life over with a clean slate.
- You can scan this card in order to install me into Cardspace.
- If it ain't user-centric, it's crap!
- How's my driving? (you probably wish my URI was here for complaints right?)
- If you can read this, you can read my blog.
Cardspace Localization for Japan?
PATYADISXRISAMLSSOPHP
Pat has a very nice screenshot movie of the YADIS/XRI support he added to his SAML SSO PHP library.
Pat uses the OpenID favicon in the URL/XRI prompt.
I think this is perfectly appropriate as the ceremony he provides is exactly the same were the protocol OpenID and not SAML. Put another way, it's in the XRDS doc that the fact that the IDP speaks SAML and not OpenID is advertised, and not in the UI.
I do wonder though if an anarchist might resent having the "Big Business Driven" SAML (even ignoring the fundamental contribution of higher education) serve as the underlying protocol supporting their identity transactions?
Pat uses the OpenID favicon in the URL/XRI prompt.
I think this is perfectly appropriate as the ceremony he provides is exactly the same were the protocol OpenID and not SAML. Put another way, it's in the XRDS doc that the fact that the IDP speaks SAML and not OpenID is advertised, and not in the UI.I do wonder though if an anarchist might resent having the "Big Business Driven" SAML (even ignoring the fundamental contribution of higher education) serve as the underlying protocol supporting their identity transactions?
Thunderbolts and Lightning
Very very frightening me.
I'm not one to armchair compose, but I think Eve chickened out on the whole 'user-centric/tantric' rhyme possibility.
Before she sold out to "The Man", she would have gone there. It used to be about the music girl!
I'm not one to armchair compose, but I think Eve chickened out on the whole 'user-centric/tantric' rhyme possibility.
Before she sold out to "The Man", she would have gone there. It used to be about the music girl!
Tuesday, December 05, 2006
Here boy
I don't yet know everything that it is doing, but Sxipper is definitely cool and slick.
From what I see, I'd describe it as a client-side OpenID persona manager, simplifying for users the choice and use of different personnas at different sites. Sxipper also stores profile data, and form fills as appropriate. There are hints that it does some cool 'semantic maps' for forms, somehow my actions on a form (but not data?) are recorded and aggregated for good of commmunity?
Kind of similar to the Cardspace model. A request from an SP for an OpenID wakes up Sxipper, which then prompts user to choose an appropriate persona. Blurs the supposed distinction between card-based and URI-based identity.
I'm confused by the OpenID demo though.
How did Sxip determine that my wife calls me "joesixpack"? Is appending 'et' designed to inhibit correlation?
From what I see, I'd describe it as a client-side OpenID persona manager, simplifying for users the choice and use of different personnas at different sites. Sxipper also stores profile data, and form fills as appropriate. There are hints that it does some cool 'semantic maps' for forms, somehow my actions on a form (but not data?) are recorded and aggregated for good of commmunity?
Kind of similar to the Cardspace model. A request from an SP for an OpenID wakes up Sxipper, which then prompts user to choose an appropriate persona. Blurs the supposed distinction between card-based and URI-based identity.
I'm confused by the OpenID demo though.
How did Sxip determine that my wife calls me "joesixpack"? Is appending 'et' designed to inhibit correlation?Unfortunately
my sons will not be "Skating with an NHL star".
The registration form is ridiculous. I particularly like the fact that the only non-mandatory piece of info is the kid's favourite menu item.
They'll have to get into professional hockey the same way I did - through countless hours of practice, complete commitment, and learning how to sew those nice skirts. 
The registration form is ridiculous. I particularly like the fact that the only non-mandatory piece of info is the kid's favourite menu item.
They'll have to get into professional hockey the same way I did - through countless hours of practice, complete commitment, and learning how to sew those nice skirts. An inconvenient truth
Conor takes exception to Johannes's 'Identity Triangle' diagram. Conor's meta-objection seems to be that the diagram slots the three identity systems into a nice clean and seemingly intuitive model, but does so based on only on those criteria that ensure the fit - the reality of the blurry lines that distinguish the different systems are an inconvenient truth to be shuffled aside.
The 'user-centric' dotted line that excludes SAML is of course an old standby. I could just as easily draw a dotted line around SAML & Cardspace labelled 'privacy respecting' - a gross over-simplification but one with a kernel of truth when OpenID is used with global URIs.
Shouldn't it be What 2.0?
If anonymity is the appropriate default identity model, Who 2.0 implies an inappropriate level of precision.
Many service providers don't need (or eventually will want) to know 'who' you are, but rather 'what' you are.
Many service providers don't need (or eventually will want) to know 'who' you are, but rather 'what' you are.
Wet fish
Must spam be only a nuisance? Can it not also provide opportunity for childish amusement?
William Donaldson's "The Henry Root Letters" are a wonderful example of the comic potential of hoax communications.
In that vein, I recently received the following:
William Donaldson's "The Henry Root Letters" are a wonderful example of the comic potential of hoax communications.
In that vein, I recently received the following:
Lotto - Zo werkt Lotto Government Accredited Licensed lottery promoters. International Promotions/Prize Award Department.I replied with the following (from a suitably disposable address and after obfuscating above indices):
This Lottery is approved by the Netherlands Gaming Board and also Licensed by the The International Association of Gaming Regulators (IAG international emails. held on the 29th November, 2006.all winnings must be claim not later than Decembre 7th, 2006, after this date,unclaimed funds will be returned to the Lotto.
Your email won the lottery.For a total pay out of €1,000,000. no tickets were sold but all email addresses were assigned to different ticket numbers for representation and privacy.
Please remember to quote your reference number and batch numbers:
1, Batch 9484-9116-0076
2, Ref: 637405467-Nll
3, lucky numbers 1-0958-31-444
To file for your claim, please contact
**************************
Advocate Faber Dutchs
Tel: +31 -619 255 080
Fax: +31-84-728-9656
email- bejesbejes200@aim.com
From the desk of Renry HootLet's see if they are even set up to deal with responses.
Dear Sirs, thank you very much for the good news, I am ecstatic to hear about my good fortune. I have never won anybody before (Mrs. Hoot as the exception of course), much less 1 million Europeans!
Before we proceed I do have some questions on which I would appreciate clarification:
1) for those Europeans I have won, am I responsible for their travel costs from their respective homelands to mine? I do acknowledge that, even with this expense, I stand to benefit greatly from their subsequent labours, but I do need to budget accordingly.
2) To what standard of living are my prizes used? I do plan of course on providing them the base necessities but don't see the sense of spoiling them with luxuries beyond that to which they are accustomed. For instance, might a typical European find soap and similar toiletries an unexpected and unwelcome oddity? I'm sure you'll understand why I'd prefer to save this expense if possible.
3) Canada can be a cold country. Perhaps you could begin the conditioning process by occasional walk-in freezer sessions? If you could simultaneously broadcast French language programs to them that would be extremely helpful - it is that unique combination of shivering and strange vocalizations that typifies my country.
4) Related to above, any French language skills would be a welcome bonus (unless of course you are shipping me Frenchmen. If this is absolutely necessary please keep them to a minimum - Canada is already quite socialist enough Ha-Ha).
Thanks again. I'm very excited and happy to be the new owner of so many Europeans (although the task of choosing new names for them is daunting!)
Gratefully yours,
Renry Hoot
p.s. I wonder if your lottery might be affiliated with a similar one in Asia? Is there any precedent for trading some or all of my Europeans for Asians? I would be of course be willing to consider a considerable exchange rate, perhaps 5 to 1? Please advise if this is a possibility (and whether a donation to a 'charity' of your choice might expedite the process).
Monday, December 04, 2006
Pillar of Salt
Doc's wife must already be well versed in SAML and the Liberty Alliance because he mentions neither a single time in his "Let's go bust some Silos", an expanded description of a conversation Doc had with his wife discussing current identity developments and the importance of 'default anonymity'.
Or is because neither contribute to identity silos and therefore don't deserve the title? That must be it because both have support for anonymity built into their fibers.
Or is because neither contribute to identity silos and therefore don't deserve the title? That must be it because both have support for anonymity built into their fibers.
Saturday, December 02, 2006
Self-asserted (but should it be?)
Conor's geeking out over his latest gadget.
Three comments:
Three comments:
- 4 GB? My daughter has more space on her Tickle Me Elmo! I can hum that many songs.
- Bryan Adams? I know that questionable music can sneak into a collection. My niece recently used my iTunes to purchase a Jessica Simpson song - it was immediately purged (but I did keep the Jo Jo song, she's, like, way cute). But Conor's willingness to advertise this Canadian's place in his library indicates that it's no accident.
- The thought of Conor stretched out in Business Class tapping his toes to Sheryl Crow's 'Soak up the Sun' is disturbing.
Diffie-Hellman Example
Johannes recent comment hinted at alternatives to Diffie-Hellman in OpenID for situations where the shared-secret nature of DH would be a limitation - specifically mentioning the potential relevance of non-repudiation.
Brian Ellin has previously discussed Diffie-Hellman in the context of OpenID but, for me, real numbers make things real. So, a work through of how an OpenID RP and IDP would use Diffie-Hellman alorythm to generate a secret that could be used for securing OpenID protocol messages.
RP chooses x = 5 (smaller than p - 1)
IDP chooses y = 4 (smaller than p - 1)
RP and IDP exchange X and Y in the open (no need for secrecy)
Both RP and IDP have calculated the same secret, namely the integer 2, based on information publicly shared between them. They can then use this secret to sign and/or encrypt subsequent communications. OpenID refers to the establishment of this secret as 'association'.
Any eavesdropper, armed only with the public info shared between RP and IDP, would be unable to calculate the secret (if the integers were chosen appropriately large) - this because only both RP and IDP have the necessary additional info (the choices they made but not shared). It's Diffie-Hellman's support for establishing secure communication without any existing trust relationship (excepting SSL) that makes it relevant to OpenID's promiscuous providers.
But, because RP and IDP use the same secret, it doesn't allow the provenance of any particular message to be established. Even if 'signed' with the secret, it could have come from either of the two.
It's worth mentioning that nothing precludes a SAML SP and IDP using the same technique, i.e. establishing a shared secret through Diffie-Hellman and then using it to protect SAML protocol messages.
Brian Ellin has previously discussed Diffie-Hellman in the context of OpenID but, for me, real numbers make things real. So, a work through of how an OpenID RP and IDP would use Diffie-Hellman alorythm to generate a secret that could be used for securing OpenID protocol messages.
p = 7 (a small prime number)
p- 1 = 6
g = 2 (OpenID default)
RP chooses x = 5 (smaller than p - 1)
X = g ^ x mod p
X = 2 ^ 5 mod 7
X = 32 mod 7
X = 4 (the remainder when you divide 7 into 35)
IDP chooses y = 4 (smaller than p - 1)
Y = g ^ y mod p
Y = 2 ^ 4 mod 7
Y = 16 mod 7
Y = 2 (the remainder when you divide 7 into 16)
RP and IDP exchange X and Y in the open (no need for secrecy)
RP calculates IDP calculates
s = Y ^ X mod p s' = X ^ Y mod p
s = 2 ^ 4 mod 7 s' = 4 ^ 2 mod 7
s = 16 mod 7 s' = 16 mod 7
s = 2 s' = 2
Both RP and IDP have calculated the same secret, namely the integer 2, based on information publicly shared between them. They can then use this secret to sign and/or encrypt subsequent communications. OpenID refers to the establishment of this secret as 'association'.
Any eavesdropper, armed only with the public info shared between RP and IDP, would be unable to calculate the secret (if the integers were chosen appropriately large) - this because only both RP and IDP have the necessary additional info (the choices they made but not shared). It's Diffie-Hellman's support for establishing secure communication without any existing trust relationship (excepting SSL) that makes it relevant to OpenID's promiscuous providers.
But, because RP and IDP use the same secret, it doesn't allow the provenance of any particular message to be established. Even if 'signed' with the secret, it could have come from either of the two.
It's worth mentioning that nothing precludes a SAML SP and IDP using the same technique, i.e. establishing a shared secret through Diffie-Hellman and then using it to protect SAML protocol messages.
Friday, December 01, 2006
In triplicate
Standard or proprietary?
An interesting read from Texas Tech
Do Markets Prefer Open or Proprietary Standards for XML Standardization? - An Event Study investigates the market value of standardization initiatives, based on a variety of XML schema standards.
Do Markets Prefer Open or Proprietary Standards for XML Standardization? - An Event Study investigates the market value of standardization initiatives, based on a variety of XML schema standards.
The conclusion?
Proprietary standardization seeks to increase a firm’s market share (pie sharing).
Open standardization seeks to increase the size of the market (pie expansion).
The results show that financial markets respond positively to announcements of proprietary XML schema standardization, but not to those of open XML schema standardization.How encouraging.
A poor description of OpenID
Ma.gnolia.com has added OpenID support.
Their single-line description of what OpenID provides is going to scare (or a least confuse) some.
Most user already sign-in to different sites with the same password. Is 'safely' sufficient distinction?
The 'Get an OpenID' link goes to MyOpenID, the URL parametrized by an affiliate ID. Playing around with different values for this gives an interesting sense of who is using OpenID. Such an open and accessible listing of SSO partners creates for me a uneasy feeling though.
Their single-line description of what OpenID provides is going to scare (or a least confuse) some.
Most user already sign-in to different sites with the same password. Is 'safely' sufficient distinction?The 'Get an OpenID' link goes to MyOpenID, the URL parametrized by an affiliate ID. Playing around with different values for this gives an interesting sense of who is using OpenID. Such an open and accessible listing of SSO partners creates for me a uneasy feeling though.
Thursday, November 30, 2006
I demand a(nother) recount
The speaker assessments of the Liberty Alliance Tokyo Event held earlier this month are in.
with this legend
I expect the shirt Pat wore accounts for his inflated ratings.
It's also clear that are 3 individuals in Tokyo who just aren't into 'people'.
I wish I could claim language advantages for Shitamachi-san's dominant showing. Fact is, his talk was just incredible.
with this legend
I expect the shirt Pat wore accounts for his inflated ratings. It's also clear that are 3 individuals in Tokyo who just aren't into 'people'.
I wish I could claim language advantages for Shitamachi-san's dominant showing. Fact is, his talk was just incredible.
Viral (with no redeeming qualities)
A local electronics retailer sent me an incredible one-time offer and, best of all, gave me the option to tell my friends about it.
Who does this? Who is so insulated from dealing with their own spam that they are oblivious to the risk that giving away email addresses would mean for their friends or family?
Personally, I would never infringe on the privacy of anybody I had even a modicum of affection or respect for in this manner (Conor, I hope I gave your correct address).
Beyond the privacy issue, what's the motivation? What's in it for me beyond the gratification of increasing the spam burden of someone I care for? There is no hint of any social application (e.g. favourites list, wish list, reviews, tips, etc) that might be enabled by getting my friends/colleagues to sign-up.
In the Liberty Alliance People Service model, the sequence could work something like:
Who does this? Who is so insulated from dealing with their own spam that they are oblivious to the risk that giving away email addresses would mean for their friends or family?Personally, I would never infringe on the privacy of anybody I had even a modicum of affection or respect for in this manner (Conor, I hope I gave your correct address).
Beyond the privacy issue, what's the motivation? What's in it for me beyond the gratification of increasing the spam burden of someone I care for? There is no hint of any social application (e.g. favourites list, wish list, reviews, tips, etc) that might be enabled by getting my friends/colleagues to sign-up.
In the Liberty Alliance People Service model, the sequence could work something like:
- Store sends me above email (unlike my friends, I've opted in to receive them)
- Message contains a number of custom URLs that I can choose to send onto whomever I wish
- When my friend receives the message, clicking on link takes them to etailer where they are given options of a) federating an IDP account of theirs with the etailer, and b) joining my People Service (so that future interactions between ourselves can be facilitated)
- I don't give away the email addresses of my friends indiscriminately
- Interesting social applications between them and I (like above) can be enabled without requiring them create an account at the etailer.
- I rely on more traditional mechanisms to inconvenience Conor.
Wednesday, November 29, 2006
A marriage of convergence
Conor provides some feedback on the OpenID Authentication Quality Extension. I was involved along with David and Avery so will take the opportunity to respond (not to the specific issues he lists but the meta-issue)
Conor's fundamental objection is that the proposed extension does not take advantage of SAML's Authentication Context
There are tantalizing opportunities for convergence between OpenID and SAML floating around - AQE and AC is just one such.
I would not have liked to have seen Conor courting his wife. "Look, we both know where this is going so let's just cut to the chase".
Conor's fundamental objection is that the proposed extension does not take advantage of SAML's Authentication Context
Overall, as far as I can tell, there is nothing in this specification that is not easily handled using the SAML Authentication Context structure and so I don't understand why they didn't just adopt that model as-is (and the SAML model clearly handles much more than the limited cases supported currently by this proposal). At the minimum, this document should be a limited profile of what portions of the SAML model they want to use.The proposal's acknowledgement of the similarity between AQE and SAML AC isn't enough.
This is all you hear from or about SAML in the entire specification. There are no other references to the SAML authentication context, nor any use of the structures or capabilities of the Authentication Context. I'm not sure why this is even mentioned here if they aren't going to make use of any of the SAML work in this area.Personally (and I'm not speaking for David or Avery) I see OpenID leveraging SAML Authentication Context as a desirable end-state (as do I seeas desirable SAML possibly leveraging those pieces of OpenID for which there is no comparable existing functionality in SAML 2.0) and hope that AQE gets us closer to that end-state. Afterall, you can't converge if you don't have two parts to align.
There are tantalizing opportunities for convergence between OpenID and SAML floating around - AQE and AC is just one such.
I would not have liked to have seen Conor courting his wife. "Look, we both know where this is going so let's just cut to the chase".
Pat, it's called 'plenary', not 'pleeenary'
Just listened to Aldo interview Pat about Project Lightbulb
Pat will be discussing the same in just over an hour.
The only point I disagree with is Pat's minimization of the degree of the debauchery in Rome.
Pat will be discussing the same in just over an hour.
The only point I disagree with is Pat's minimization of the degree of the debauchery in Rome.
Unfortunate coincidence
Marc Canter has a post entitled 'Original Thinking' that returns a "Error 404 - Not Found". Probably not the effect Marc was going for.
Many of my posts should return 203.
Many of my posts should return 203.
AQE - SAML/OpenID Convergence Opportunity #1
David announces the OpenID Authentication Quality Extension (AQE) proposal that he, Avery Glasser, and I drafted.
The Security Assertion Markup Language (SAML) Authentication Context ([SAMLAC] (Kemp, J., “SAML 2.0 Authentication Context,” 2005.) defines mechanisms by which SAML Service Providers and OpenID Providers can discuss the context of an authentication assertion.
The authors acknowledge the similar motivation between SAML's Authentication Context and this extension. Where possible, we have attempted to stay aligned with the SAML Authentication Context model. Indeed, we see this topic as a likely area of convergence between OpenID and SAML. More work is needed here.
Tuesday, November 28, 2006
Complete transparency isn't always appropriate
A perfect example.
In web service security, the token can be opaque to certain actors (e.g. to a client presenting a bearer token, or to a Liberty Alliance People Service forwarding on an identity token) but other actors will need to be able to look into the same tokens (e.g. the WSP receiving the above token).
Like lettuce in the very back corner of the vegetable crisper, tokens don't last forever.
In web service security, the token can be opaque to certain actors (e.g. to a client presenting a bearer token, or to a Liberty Alliance People Service forwarding on an identity token) but other actors will need to be able to look into the same tokens (e.g. the WSP receiving the above token).
Like lettuce in the very back corner of the vegetable crisper, tokens don't last forever.
Monday, November 27, 2006
2 out of 3 ain't bad
If you're counting hot memes, I think we have 2 of the big 3.
I'm confident that the 3rd will rear its head at some point during Pat's webinar.
I'm confident that the 3rd will rear its head at some point during Pat's webinar.
Now that's a protocol
I gave blood this morning. The protocol the nurses use is incredibly precise.
There are no SHOULDs or MAYs here, everything they do is specified to the finest detail. Beyond the expected rigour over medical (and travel, Hong Kong gave them pause for thought) history, each operation is scripted out. The amount of time the nurse spends swabbing iodine before inserting the needle is even prescribed - and timed. I'm surprised the donut I had afterwards wasn't weighed to ensure I received the desired amount of sugar.
There are no SHOULDs or MAYs here, everything they do is specified to the finest detail. Beyond the expected rigour over medical (and travel, Hong Kong gave them pause for thought) history, each operation is scripted out. The amount of time the nurse spends swabbing iodine before inserting the needle is even prescribed - and timed. I'm surprised the donut I had afterwards wasn't weighed to ensure I received the desired amount of sugar.
Service Providers and Relying Parties
Friday, November 24, 2006
We'll always have Paris
Semi-Modal dialogs
A key piece of Cardspace is the UI experience/ceremony. At key times, Cardspace greys out the screen except for the Identity Selector, visually hiliting for the user that 'something important is happening' (this reinforced by the fact that the identity selector is a modal dialog and thereby prevents the user from doing anything else until they've dealt with the the dialog).
For the first time, I've seen this visual paradigm used elsewhere. When you try to login to Ping ID to access their information library (which I resent by the way) the rest of the browser screen is greyed out except for the account/password prompt window. Additionally, I can't do anything else in that window but deal with the dialog (see below)
Not sure what to make of this. One of the purported justifications for the Cardspace 'greying-out' is to produce a visual effect that would be difficult for a phish site to recreate. But, any phish site could recreate the effect within the browser and it's modal only within the browser (actually only within the tab).
Do semi-modal dialogs diminish the power of those that are fully-modal?
For the first time, I've seen this visual paradigm used elsewhere. When you try to login to Ping ID to access their information library (which I resent by the way) the rest of the browser screen is greyed out except for the account/password prompt window. Additionally, I can't do anything else in that window but deal with the dialog (see below)
Not sure what to make of this. One of the purported justifications for the Cardspace 'greying-out' is to produce a visual effect that would be difficult for a phish site to recreate. But, any phish site could recreate the effect within the browser and it's modal only within the browser (actually only within the tab).Do semi-modal dialogs diminish the power of those that are fully-modal?
What could be more user-centric?
POSTInterceptor is a GreaseMonkey script that intercepts POSTs and makes their contents visible.
Here is a screenshot taken of the first POST of the OpenID authentication protocol from the "I want my OpenID" RP (the mechanism isn't of course only relevant to OpenID, SAML allows for Assertions be be POSTed around).
For some reason (beyond my limited ability to troubleshoot) the act of intercepting the POST arrests the protocol flow and I don't actually make it over to MyOpenID.com. Strange because I verified that the extension did not interfere in POST operations at other (non OpenID-driven) sites. Perhaps it's interference between the Javascript controlled auto-submit and the extension?
If not for signatures, the user could use the similar control point on the POSTed response from the IDP to change/delete/add the identity attributes being asserted to.
Even without the ability to make changes, it would provide a 'Lets just see what they're saying about me' mechanism for the paranoid.
Here is a screenshot taken of the first POST of the OpenID authentication protocol from the "I want my OpenID" RP (the mechanism isn't of course only relevant to OpenID, SAML allows for Assertions be be POSTed around).
For some reason (beyond my limited ability to troubleshoot) the act of intercepting the POST arrests the protocol flow and I don't actually make it over to MyOpenID.com. Strange because I verified that the extension did not interfere in POST operations at other (non OpenID-driven) sites. Perhaps it's interference between the Javascript controlled auto-submit and the extension?
If not for signatures, the user could use the similar control point on the POSTed response from the IDP to change/delete/add the identity attributes being asserted to.
Even without the ability to make changes, it would provide a 'Lets just see what they're saying about me' mechanism for the paranoid.
Thursday, November 23, 2006
Mea culpa
Lately I've found myself occasionally thinking that (and I hesitate to even confess this) 'user-centric' identity might not be so ground-breakingly new and perhaps, just perhaps, might simply be the most recent manifestation of the long established concept of empowering users with appropriate controls over their identity. Technologies have advanced yes, but the fundamental principle is the same. I've even found myself questioning whether or not user-centric identity is appropriate for all use-cases.
Yes, I know, I'm disappointed in myself too. My only defense is to say that I did not want to have thoughts such as this and I can only assure you that this is not what I truly believe.
Consequently, these thoughts will not go unchallenged. To banish such doubts back to from whence they sprang, I've created a GreaseMonkey script to give me constant reminders of the truth.
Here is the script in action (click on the graphics for a larger view)
On the Google results page for 'user-centric'
and on OpenID
and at Project Liberty
Should you find yourself having similar doubts, I'd be happy to share the script.
Yes, I know, I'm disappointed in myself too. My only defense is to say that I did not want to have thoughts such as this and I can only assure you that this is not what I truly believe.
Consequently, these thoughts will not go unchallenged. To banish such doubts back to from whence they sprang, I've created a GreaseMonkey script to give me constant reminders of the truth.
Here is the script in action (click on the graphics for a larger view)
On the Google results page for 'user-centric'
and on OpenID
and at Project Liberty
Should you find yourself having similar doubts, I'd be happy to share the script.
Wednesday, November 22, 2006
Fair dinkum
Ping ID has a beaut animated sequence showing the different combinations of the various bindings that SAML 2.0 allows for, e.g. redirect for the AuthnRequest and Form POST for the Response, or Artifact for both AuthnRequest and Response, etc.
Unfortunately there is no audio. You'll have to use your imagination. I personally couldn't help but hearing a nasal Australian accent doing the voice-over, e.g. 'the SAIMEL aissershun' is paessed from IDP to SP'. Not quite sure why.
I also couldn't stop thinking that the cookies being passed around were Anzac biscuits.
Unfortunately there is no audio. You'll have to use your imagination. I personally couldn't help but hearing a nasal Australian accent doing the voice-over, e.g. 'the SAIMEL aissershun' is paessed from IDP to SP'. Not quite sure why.
I also couldn't stop thinking that the cookies being passed around were Anzac biscuits.
Many are called but few are chosen
These are the Pauls I know
Paul Squires
Paul Toal
Paul Trevithick
Patience gentlemen, it's all coming together. Pretty soon we'll be able to justify our own song.
Paul Squires
Paul Toal
Paul Trevithick
Patience gentlemen, it's all coming together. Pretty soon we'll be able to justify our own song.
My life flashed before me
When I saw this rendering of Google Calendar
I thought it might have been a 'To Do List' GreaseMonkey script I was trying out so I uninstalled that. No change. Cleared cache and cookies. No deal. Using an 'https' URL resolved the issue.
A phish site could intentionally display a seemingly garbled rendering of a page, the only clearly visible information a phone number for 'Having troubles with this page, call this toll-free number 111-222-3333'.
'Uh yes, sir, I'll just need your account details to fix this problem'.
I expect that intentionally garbling the page could actually assuage any ID theft concern the user might have - it being so out of the ordinary that their normal expectations of UI and experience would be ignored. At the very least it would effectively disable any personalization mechanisms the real site might have implemented.
I thought it might have been a 'To Do List' GreaseMonkey script I was trying out so I uninstalled that. No change. Cleared cache and cookies. No deal. Using an 'https' URL resolved the issue.A phish site could intentionally display a seemingly garbled rendering of a page, the only clearly visible information a phone number for 'Having troubles with this page, call this toll-free number 111-222-3333'.
'Uh yes, sir, I'll just need your account details to fix this problem'.
I expect that intentionally garbling the page could actually assuage any ID theft concern the user might have - it being so out of the ordinary that their normal expectations of UI and experience would be ignored. At the very least it would effectively disable any personalization mechanisms the real site might have implemented.
Tuesday, November 21, 2006
Knit one, perl two
What if you are ordering dinner online?
From Lifehacker, AllergyCards:
Better from a privacy point of view would have the restaurant pose the question to an 'Allergy Service'
Here is a list of ingredients for the food Joe just ordered, any concerns I should know about?
Shades of ACLU Pizza of course.
provides a fast and convenient way for people with food allergies to print off "allergy cards" for use eating out, while travelling, etc.
Better from a privacy point of view would have the restaurant pose the question to an 'Allergy Service'
Here is a list of ingredients for the food Joe just ordered, any concerns I should know about?
Shades of ACLU Pizza of course.
A video is worth a million statistics
This video and associated site changed the way I think about the world. Makes me want to be a demographer.
I can't help but imagine similar animations showing SAML, Cardspace, and OpenID evolution. Place security along the vertical axis, SP promiscuity along the horizontal, use appropriately sized radii to indicate numbers of enabled identities, and see how the picture changes over time.
I expect we'd see the three circles move through the spaceon different trajectories, sometimes overlapping, sometimes separating, and at any one instant in time, showing differently rates of growth (likely driven by external phenomena like legislative activity or OS upgrading).
Masters thesis anyone?
Alternatively, an animation showing numbers and type (verinymous, pseudonymous, anonymous) of identities for an Internet user over time. If the circles don't start to get smaller we should all start looking for real jobs.
I can't help but imagine similar animations showing SAML, Cardspace, and OpenID evolution. Place security along the vertical axis, SP promiscuity along the horizontal, use appropriately sized radii to indicate numbers of enabled identities, and see how the picture changes over time.
I expect we'd see the three circles move through the spaceon different trajectories, sometimes overlapping, sometimes separating, and at any one instant in time, showing differently rates of growth (likely driven by external phenomena like legislative activity or OS upgrading).
Masters thesis anyone?
Alternatively, an animation showing numbers and type (verinymous, pseudonymous, anonymous) of identities for an Internet user over time. If the circles don't start to get smaller we should all start looking for real jobs.
OpenID and i-names
Pamela commented on my post about the OpenID ceremony, at least as currently implemented by Paul Toal's.
Consequently, having the user provide both the IDP through a drop-down list as well as an i-name would seem to provide only opportunity for confusion.
And then there are the inames. I can't figure out when exactly I get to start using my iname to authenticate, and if I do, do I still need to specify a provider? I remember from IOS Santa Clara that inames & open IDs are merging for OpenID 2.0, I just can't figure out if that means now, or soon... luckily I get to ask all these types of questions at IIW in a few weeks :)As I understand it, in OpenID 2.0, if you provide the RP your i-name, the RP would use XRI resolution to retrieve an XRDS document, and from that extract the appropriate IDP endpoint for redirection.
Consequently, having the user provide both the IDP through a drop-down list as well as an i-name would seem to provide only opportunity for confusion.
Comment-nary
As I cannot leave comments on Paul Toal's blog, and he cannot leave any on mine (and I don't have an email address for him), we are forced to have a conversation through sequential posts.
Paul responded to a post of mine, in which I questioned the UI elements for his OpenID authentication option. Paul wrote
Paul also indicated that he wasn't able to comment directly on my blog because the Blogger captcha mechanism didn't work for him. No clue here. I use Firefox and the captcha works for me.
As for my OpenID-enabling my blog, lately I've found I have less and less ability to drive Google policy on identity. They listened so much more when they were only worth 20 billion.
Paul responded to a post of mine, in which I questioned the UI elements for his OpenID authentication option. Paul wrote
Actually, it does appear to do more than this. When I leave 'LiveJournal User' selected, and provide my Verisign PIP OpenID URI, I get an error message of 'Couldn't find OpenID Server'. When I switch to select 'Other OpenID' and provide the same URI, I am successfully directed to Verisign's PIP.
From looking at the code for the plug-in, the only real purpose of the drop down box is to change the icon within the field next to it to match the type of server you will be using. Other than changing the icon, it serves no real purpose.
Paul also indicated that he wasn't able to comment directly on my blog because the Blogger captcha mechanism didn't work for him. No clue here. I use Firefox and the captcha works for me.
As for my OpenID-enabling my blog, lately I've found I have less and less ability to drive Google policy on identity. They listened so much more when they were only worth 20 billion.
Monday, November 20, 2006
OpenID ceremony
Paul Toal's blog allows readers to use an OpenID for their authentication mechanism.
The ceremony is different than typical. If they wish to use an OpenID URI (as opposed to authenticating with a local account), the user is asked/allowed to specify the identity provider at which they maintain that URI in addition to the URI itself, see graphic
It's not clear to me why a user would need to both supply the URI as well as indicate the IDP through the select list?
It would make sense to me if the user was allowed to either pick their IDP from the list OR enter their own URI - the former being valid if the user wants the 'delayed binding' model of persona selection (this would be valid but seemingly antithetical to the supposed OpenID freewheeling trust model where an RP isn't expected to show any selectivity in its 'favours').
I tried not providing a URI to see if I'd get sent to LiveJournal regardless but the OpenID authentication on Paul's site isn't working.
The ceremony is different than typical. If they wish to use an OpenID URI (as opposed to authenticating with a local account), the user is asked/allowed to specify the identity provider at which they maintain that URI in addition to the URI itself, see graphic
It's not clear to me why a user would need to both supply the URI as well as indicate the IDP through the select list?It would make sense to me if the user was allowed to either pick their IDP from the list OR enter their own URI - the former being valid if the user wants the 'delayed binding' model of persona selection (this would be valid but seemingly antithetical to the supposed OpenID freewheeling trust model where an RP isn't expected to show any selectivity in its 'favours').
I tried not providing a URI to see if I'd get sent to LiveJournal regardless but the OpenID authentication on Paul's site isn't working.
Evolving Risk
Fidelity Investments has a mutual fund product - the distinguishing feature of which is that
Why not the same for identity policy, i.e. privacy rules that automatically become more conservative and risk-averse as the user ages?
I expect that I currently allow usages of my identity now that I won't in 20 years, and I'm absolutely sure that the 43 year old me wouldn't allow operations now that a 20 year old me wouldn't think twice about.
I propose a simple formula
For every 2 years of age past 20, allow one less identity operation in a weekly period.
Based on experience with my Dad :
as each Freedom Fund nears its target date, the investment mix gradually gets more conservative.As you near the time where you will be removing funds, the asset allocation changes to minimize risk.
Why not the same for identity policy, i.e. privacy rules that automatically become more conservative and risk-averse as the user ages?
I expect that I currently allow usages of my identity now that I won't in 20 years, and I'm absolutely sure that the 43 year old me wouldn't allow operations now that a 20 year old me wouldn't think twice about.
I propose a simple formula
For every 2 years of age past 20, allow one less identity operation in a weekly period.
Based on experience with my Dad :
- the particular operation being denied should be chosen randomly
- whatever decision made in one instance should not impact subsequent decisions
- the Fault code cited should place blame on the 'government', and
- should be followed by a prolonged rant on how, when the user was a kid, they had to create their own SAML assertions using a Number 2 pencil, use a slide rule to calculate the signature, and deliver them through plain POST operations, unassisted by JavaScript. And it was uphill for both the request and the response.
Friday, November 17, 2006
SAML paired with Skype
Jeff has made available a SAML document he created. It's more than just an overview, but rather 'How to Study and Learn SAML".
As a starting point, Jeff recommends
Presents some intriguing possibilities for smart clients.
As a starting point, Jeff recommends
Begin by studying various SAML Profiles, e.g. those given in [[SAMLProf]] and [SIP-SAML]. One will likely find the SAML Technical Overview whitepaper [[SAMLTechOvw]] helpful in this endeavor. It provides a detailed, illustrated expose of several of the SAML Web SSO profiles.Interestingly, when I view the document, a plugin Skype (yes Jeff, I know it's proprietary) installed when I recently upgraded renders a phone number in one of the XML examples as a 'click to call'.
Presents some intriguing possibilities for smart clients. Thursday, November 16, 2006
Big In Japan
My life is downhill from here on.
It's a bit of a stretch for my Nihongo skills but I believe the translation of the text besides my pic is roughly: "His looks are wasted on identity, he should be in the movies".
It's either that or "Who ironed that shirt" (I'm finding verb tense a bit of a challenge).
It's a bit of a stretch for my Nihongo skills but I believe the translation of the text besides my pic is roughly: "His looks are wasted on identity, he should be in the movies".
It's either that or "Who ironed that shirt" (I'm finding verb tense a bit of a challenge).
Ceremonial Trappings
Aldo has an interview with Drummond Reed, Johannes Ernst, and Chris Messina talking about the importance of usability design and user experience to OpenID. Like Kim, they refer to the importance of ceremony for users around identity transactions. Pam touches on the same.
Chris refers to the possible advantage of, at least initially perhaps, allowing for experimentation. Let different communities try different ceremonies and user interface paradigms and learn from the collective experiences. Fundamentally, recognize that we have much to learn here and we probably shouldn't think we can get it right the first time. This belief (admittedly as well as a recognition that user interface design was a potential differentiator for vendor's offerings) is the primary reason that the Liberty Alliance has never attempted to tackle this aspect of identity.
Separately, from the chat, you might get the impression that mobile clients present no special challenges or opportunities for user ceremony. It's hard enough for me to enter my email address on a phone but I'll take the 5 minutes to type in URL? How many users know how to find the '/'?
Update: I wrote the above before I got to the point of the interview where Johannes does briefly mention devices.
Aside from that, all other ceremonies I attend always end up with me wearing a suit. That's going to significantly slow down my log-in.
I'm not one to judge
But the stats for ths blog do show an increasing number of people arriving here after searching for 'federation promiscuous eve'.
Whatever clubs Eve chooses to belong to are of course a personal matter for her to decide. But perhaps the organization could pay for some search engine optimization to drive their placement up (and mine down).
Whatever clubs Eve chooses to belong to are of course a personal matter for her to decide. But perhaps the organization could pay for some search engine optimization to drive their placement up (and mine down).
Nature abhors an (identity) vacuum
The "nature abhors a vacuum" idiom is used to express the idea that empty space is unnatural (or improbable) as it goes against the laws of physics. It was first coined by Aristotle to explain how water pumps work. He theorized that, if you pump air out with the lever, something must flow into the place of where the air was, which is the water.
The pump works because Nature hates the idea of empty space and so fills it with whatever it has at hand. Give Nature enough time, and it will find a way to break the seal of a Thermos bottle and fill the vacuum that keeps soup hot and beer cold.
This idea of an absence of something enjoying only tenuous existence because the environment will always endeavour to provide that missing substance is, I believe, a nice analogy for anonymity.
What is anonymity but an 'identity vacuum' (its etymology means "without a name")? Anonymity refers to a state in which there is insufficient identity information to allow a user to be identifiable within some set. So, like a vacuum, it's a state defined by the absence of something, namely identifying information. Also like a vacuum, anonymity need not be absolute, you can have partial anonymity as you can have partial vacuums.
Importantly, anonymity is a tenuous state. Like air rushing in to a crack in a thermos bottle seal at the first opportunity, identifying information will always (eventually) leak into anonymity from the environment. However well a system is designed to enable anonymity, outside forces are always trying to find a crack through which identity can be pushed. The leakage may come from recognizable facial or voice characteristics in off line interactions, or from an IP address or buying patterns in those engaged in online. But, wait long enough, and it will happen. Anonymity, like a vacuum, is a fragile state of being (and should be recognized as such).
From this exploration, I posit the following (dare I say it) 'Law of Identity':
The pump works because Nature hates the idea of empty space and so fills it with whatever it has at hand. Give Nature enough time, and it will find a way to break the seal of a Thermos bottle and fill the vacuum that keeps soup hot and beer cold.
This idea of an absence of something enjoying only tenuous existence because the environment will always endeavour to provide that missing substance is, I believe, a nice analogy for anonymity.
What is anonymity but an 'identity vacuum' (its etymology means "without a name")? Anonymity refers to a state in which there is insufficient identity information to allow a user to be identifiable within some set. So, like a vacuum, it's a state defined by the absence of something, namely identifying information. Also like a vacuum, anonymity need not be absolute, you can have partial anonymity as you can have partial vacuums.
Importantly, anonymity is a tenuous state. Like air rushing in to a crack in a thermos bottle seal at the first opportunity, identifying information will always (eventually) leak into anonymity from the environment. However well a system is designed to enable anonymity, outside forces are always trying to find a crack through which identity can be pushed. The leakage may come from recognizable facial or voice characteristics in off line interactions, or from an IP address or buying patterns in those engaged in online. But, wait long enough, and it will happen. Anonymity, like a vacuum, is a fragile state of being (and should be recognized as such).
From this exploration, I posit the following (dare I say it) 'Law of Identity':
If there exists a region of anonymity relatively devoid of identity, identifying information from the environment surrounding that region will attempt to redistribute itself so as to fill said void.As an exercise I leave it to the reader to develop the "'Surfing Adult Sites at Work' Corollary".
Wednesday, November 15, 2006
I'm confused (and that's the problem)
Johannes asks people to consider whether or not a mashup of SAML and OpenID makes sense.
I don't see why the issue is any different than that which motivated a previous convergence between LID, Sxip, DIX, and OpenID - this manifested as OpenID 2.0?
There was duplication between these systems, now there is none (or less?). Less duplication means less confusion (I personally love no longer having to know what Passel does or doesn't do).
Between SAML and OpenID there is more and more duplication - this because:
Do we need more justification than the goal of creating a simpler marketplace - one unfragmented by confusion over multiple and incompatible identity systems?
I don't see why the issue is any different than that which motivated a previous convergence between LID, Sxip, DIX, and OpenID - this manifested as OpenID 2.0?
There was duplication between these systems, now there is none (or less?). Less duplication means less confusion (I personally love no longer having to know what Passel does or doesn't do).
Between SAML and OpenID there is more and more duplication - this because:
- the OpenID community is adding new functionality to OpenID 2.0 for which there are existing equivalent mechanisms in SAML, and
- the SAML community is exploring how to enable SAML for use cases historically the purview of OpenID (and its erstwhile counterparts).
Do we need more justification than the goal of creating a simpler marketplace - one unfragmented by confusion over multiple and incompatible identity systems?
Distributed Transaction Authentication
An interesting discussion of transaction authentication:
If the user's behaviour at the SP didn't fit previous transactional patterns (such as those listed above), should the SP alert the IDP as to that fact? There are, AFAIK, no protocols that would support such a call.
Or would the SP simply send the user back to the IDP with a request for an new authentication - this time with a mechanism that would better serve to erase the doubt in the SP's mind.
The semantics seem different, a simple request for authentication doesn't allow the SP to express it's reasons for concern and flag these to the IDP - this potentially important if the IDP has to decide to alert other SPs to which it has recently asserted the user's identity.
Transaction authentication is software residing on the enterprise security servers that monitors, in addition to the successful use of user id and password the:What if the scope of the 'transaction' were broadened, i.e. to include behaviours performed at an SP after the user SSO'd in from an IDP?
- IP address the user is coming in from
- Users geolocation
- Computer hardware the user is using
- Time of day
- Previous user pattern of behaviour
If the user's behaviour at the SP didn't fit previous transactional patterns (such as those listed above), should the SP alert the IDP as to that fact? There are, AFAIK, no protocols that would support such a call.
Or would the SP simply send the user back to the IDP with a request for an new authentication - this time with a mechanism that would better serve to erase the doubt in the SP's mind.
The semantics seem different, a simple request for authentication doesn't allow the SP to express it's reasons for concern and flag these to the IDP - this potentially important if the IDP has to decide to alert other SPs to which it has recently asserted the user's identity.
Chillin' (I think)
Julian's post alerted me to his Last.fm profile. Last.fm did not have high hopes for our musical compatibility. I'm happy to report them (mostly) wrong.
I can imagine a similar 'Interop-0-Meter' assessing the potential of different identity systems working together.
"You share a few logical functions in common, including: IDP discovery, request for authentication, artifact ...
Complaints from Finland
The Helsinki Complaints Choir is particularly timely for me personally as I deal with errata for the Liberty Alliance People Service.
I've contacted the choirmaster to suggest that the following lyrics be added:
I've contacted the choirmaster to suggest that the following lyrics be added:
- "Why on earth is the TargetID Optional?"
- "I hope this was a typo because otherwise the processing rule makes no sense"
- "I know I've said it before but I strongly disagree with this approach"
- "We also regularly lose to Canada in hockey"
HTML to blame for porn
At least, that's the reasoning Johannes seems to use when he expresses doubt about the relevance of SAML to Web 2.0.
Notwithstanding his doubt, Johannes signed up for the Liberty Alliance Open Source Identity Webinar and appears willing to have his SAML notions challenged.
Johannes also points out the irony in Liberty requiring Webinar attendees to create an account. A legitimate objection, and one for which steps are being taken (or at least being discussed). I expect Johannes will appreciate the extra irony in this being pointed out by someone who throws up a not insignificant barrier to anybody wishing to leave a comment on his blog.
I got to say that I'm a sceptic on this. I don't think that there has been an existence proof for the successful combination of SAML and Web 2.0: putting control in the hands of the end user — the essence of Web 2.0 — is not typically compatible with the way SAML projects tend to end up.The argument appears to be 'because SAML can be deployed in ways that don't directly/explicitly/visibly empower users, it can't be deployed otherwise'. Similiarly, because HTML can display porn, or violence, or politicians, it can't be used for more noble purposes.
Notwithstanding his doubt, Johannes signed up for the Liberty Alliance Open Source Identity Webinar and appears willing to have his SAML notions challenged.
Johannes also points out the irony in Liberty requiring Webinar attendees to create an account. A legitimate objection, and one for which steps are being taken (or at least being discussed). I expect Johannes will appreciate the extra irony in this being pointed out by someone who throws up a not insignificant barrier to anybody wishing to leave a comment on his blog.
Tuesday, November 14, 2006
Get on board
Johannes points out the Open Healthcare Manifesto. I expect the Liberty Alliance's eHealth Special Interest Group would have an opinion on the relevance of Liberty's architecture to certain of the stated principles, e.g. empowerment, trust, privacy, anonymity. I've even seen occurrences of "civility and respect" at Liberty meetings.
I'm not so sure about using a train as an analogy for identity though. According to the criteria of some, for it to be truly "user-centric", the user would be able to force the railroad lines to lay tracks to any and all desired destinations, irrespective of cost, timeliness, and environmental damage. Such a 'narrow gauge' provides a shaky foundation for high-speed travel.
Sunday, November 12, 2006
Remembering (Canadian style)
My son's hockey team had a game yesterday that spanned the 11th hour of the 11th day of the 11th month.
Friday, November 10, 2006
We need an IIW in Panama
Hypothesis - the level of promiscuity of an SP/RP (measured by its willingness to engage in identity transactions with IDPs) will demonstrate a strong negative correlation with the level of security that SP/RP expects for such transactions.
Highly promiscuous SPs/RPs will expect/require less security, selective SPs/RPS will require more (so, amongst other things, they can be sure they are dealing with the IDPs they think they are). What insight!
A consequence of the above is it's possible to combine 1) high security and promiscuous behaviour and 2) low security and discerning partner selection. Possible but not very logical. For the first combination, you are paying for security you don't need; for the second, you probably have insufficient security for your risk model.
I think OpenID and SAML have successfully found the right (but different) mixes of promiscuity and security. OpenID has focussed on promiscuous providers with an appropriate level of security, SAML on the opposite pairing. This is shown graphically below. Along the horizontal is SP selectivity (the opposite of promiscuity), along the vertical a measure of security.
So, both SAML and OpenID seem to have discovered distinct and valid islands. Nice. But, seems to me that both of late are exploring moving beyond these domains. OpenID is allowing for additional security options to OpenID 2.0, SAML to allowing for less security through the proposed SimpleSign binding.
Problem is, while OpenID is adding security, there is less evidence of that community defining mechanisms in support of less promiscuous partner selection (at least in the core spec and not deferred to extensions). Likewise, while SAML is allowing for security to be more a deployment decision, no mechanisms in support of more promiscuous SP/RP behaviour are being defined in the SSTC (like URI-based IDP discovery or something akin to OpenID's association mechanism). Consequently, OpenID appears to be expanding directly upwards into a zone of 'Pointless Overkill', and SAML straight down into a zone of 'Insufficient Security'.
We need an isthmus stretching from lower-left to upper-right - it's there that the "sweet spot" of convergence lays (and which keeps us well clear of the dangerous shoals threatening to tear a hole in the hulls of each ... blah blah blah).
Highly promiscuous SPs/RPs will expect/require less security, selective SPs/RPS will require more (so, amongst other things, they can be sure they are dealing with the IDPs they think they are). What insight!
A consequence of the above is it's possible to combine 1) high security and promiscuous behaviour and 2) low security and discerning partner selection. Possible but not very logical. For the first combination, you are paying for security you don't need; for the second, you probably have insufficient security for your risk model.
I think OpenID and SAML have successfully found the right (but different) mixes of promiscuity and security. OpenID has focussed on promiscuous providers with an appropriate level of security, SAML on the opposite pairing. This is shown graphically below. Along the horizontal is SP selectivity (the opposite of promiscuity), along the vertical a measure of security.
So, both SAML and OpenID seem to have discovered distinct and valid islands. Nice. But, seems to me that both of late are exploring moving beyond these domains. OpenID is allowing for additional security options to OpenID 2.0, SAML to allowing for less security through the proposed SimpleSign binding. Problem is, while OpenID is adding security, there is less evidence of that community defining mechanisms in support of less promiscuous partner selection (at least in the core spec and not deferred to extensions). Likewise, while SAML is allowing for security to be more a deployment decision, no mechanisms in support of more promiscuous SP/RP behaviour are being defined in the SSTC (like URI-based IDP discovery or something akin to OpenID's association mechanism). Consequently, OpenID appears to be expanding directly upwards into a zone of 'Pointless Overkill', and SAML straight down into a zone of 'Insufficient Security'.
We need an isthmus stretching from lower-left to upper-right - it's there that the "sweet spot" of convergence lays (and which keeps us well clear of the dangerous shoals threatening to tear a hole in the hulls of each ... blah blah blah).
OpenID Extensibility for Strong Auth
In response to my puzzlement, David points out plans for an extension to OpenID that would allow an IDP to distinguish between the nature of the authentication mechanism - and thereby allow the value of stronger methods to extend down to the RP.
This is good to hear. I'd really hope that the OpenID community, in specing out this extension, look at what SAML has done in the area. Additionally, I think its important that, in addition to the IDP being able to say 'This happened', the RP should be able to say 'I want this to happen'.
Avery also commented on the post. Interestingly, in describing the planned extension, he wrote:
In his own comment, Pete suggests:
Pete then writes
This is good to hear. I'd really hope that the OpenID community, in specing out this extension, look at what SAML has done in the area. Additionally, I think its important that, in addition to the IDP being able to say 'This happened', the RP should be able to say 'I want this to happen'.
Avery also commented on the post. Interestingly, in describing the planned extension, he wrote:
Differentiating between (and accounting for both) how the user was registered and how they were authenticated is something SAML's Authentication Context makes possible, most notable examples of which are the 4 mobile targetted AC class URIs that differentiate based on whether the user has a contracted account or is pay-as-you-go.
about the method of identification at the point of enrollment and the method used when authenticating
In his own comment, Pete suggests:
The RP doesn't have to bother but if it chose to it could keep track of those providers that provide strong auth and act appropriately when those IdP's are the ones doing the authentication.This could work if an IDP only supported a single authentication mechanism. If not, the RP wouldn't know which was used for any given assertion.
Pete then writes
What higher level value is a claim of strong auth from an IdP when there is no trust between the IdP and the RP anyway?Indeed, but if the RP doesn't trust the IDP, its unlikely to care about how the IDP authenticated the user. And if the RP doesn't care, why would the IDP go to the extra cost and effort?
Subscribe to:
Posts (Atom)