When it comes to identity, a Service Provider (SP) or Relying Party (RP) has a couple of key issues. One is customer facing (user experience) and another is technical (supporting multiple identity protocols). Of these two, the user experience is more important as it affects the consumer.
Take the following use case. My mother-in-law goes to a cooking web site to search for a new coffee-cake recipe. The cooking site (SP) allows for personalization and saving of favorite recipes, so she is presented with UI to login so she can save the recipe as a favorite (we'll assume that the “create the account” process has already occurred). The cooking site wants to support the widest range of people possible to access their site so they decide to support Cardspace, OpenID, and SAML at the identity protocol layer. Questions? How does the SP represent the UI so that it's not confusing to my mother-in-law? She doesn't understand anything about Cardspace, OpenID or SAML. She does understand that she has an AOL account.
Does this mean SP/RP's should be putting up icons of well known identity providers? That solution is not equalitarian and it doesn't scale. It's great that we have all these cool technologies that tackle different parts of the identity space, but it doesn't really help consumers if it is too confusing to use. I suspect most users know who they have an account with but not many know what protocol is used by their account. For example, I suspect that most Live Journal and AOL users do not know that they have an OpenID.
As for the technology side, the problem at the SP/RP is not that the issues are unsolvable (or even not currently solved). The problem is that all this code has to be written (or incorporated) and glued together to enable these different identity protocols. That is a rather significant barrier to entry. Currently, this tends to drive SPs to pick one of the existing identity protocols. From a business perspective this limits the total number of people that can use the service.
I tend to agree with Johannes, all this talk and work won't mean much if we don't make things simpler for the consumer first and the SP developer second.
Thursday, June 07, 2007
Tuesday, May 22, 2007
AOL supports simple federation with SAMLv2
In addition to the work AOL is doing to support OpenID, we've also been working with SAMLv2 to provide a simple federation profile for our partners. This allows users to federate an account at a partner to an account at AOL so that SSO is enabled from the partner to AOL or vise-versa.
This implementation uses the “SAMLv2 Lightweight Web Browser SSO Profile” and “SAMLv2.0 HTTP POST SimpleSign Binding”. Since the current use cases are fairly restricted we simplified the process even more such that only source-first SSO, using an unsolicited <Response> message is supported.
The actual federation of identifiers is done during the registration process using existing AOL protocols. SAML is then used for the SSO Assertion between the partners. The flow goes something like this...
Using the Simple-Sign binding significantly simplified the development effort as XMLDSIG is one of the more complicated parts of SAML. As more tools for XMLDSIG become available this will be less and less of a barrier to adoption.
This implementation uses the “SAMLv2 Lightweight Web Browser SSO Profile” and “SAMLv2.0 HTTP POST SimpleSign Binding”. Since the current use cases are fairly restricted we simplified the process even more such that only source-first SSO, using an unsolicited <Response> message is supported.
The actual federation of identifiers is done during the registration process using existing AOL protocols. SAML is then used for the SSO Assertion between the partners. The flow goes something like this...
- User goes to browser and loads site A
- User authenticates at site A using the account credentials associated with site A
- User clicks on link to partner site B
- Site A generates the SSO Assertion for site B using site B's pre-determined federation identifier
- Site A uses the http POST method to post the SSO Assertion to site B
- Site B validates and verifies the SSO Assertion
- User is “signed-on” to site B with site B's federated identifier
Using the Simple-Sign binding significantly simplified the development effort as XMLDSIG is one of the more complicated parts of SAML. As more tools for XMLDSIG become available this will be less and less of a barrier to adoption.
Thursday, May 17, 2007
Wednesday @ IIW 2007
Thankfully Wed. was not quite so intense, at least for me. The main items of interest for me were a review of Pythia (a reputation system that Phil Windley has been working on), the results of the OSIS interop event, and a discussion about user experience and identity.
Pythia
Phil Windley lead a session on the reputation system (pythia) he's been working on with his graduate students over the last year and a half. The system is based on evaluating transactions between identities. Reputation scores are calculated on a “personal” basis meaning that I can define my own ruleset for calculating reputation that might be different than someone else's ruleset. This, I think, is important because it allows me to value the information I receive about another identity according to my own view of what's important. For example, just because an identity has a great reputation within the drug culture doesn't mean that I want to ascribe a high reputation to them. Reputations are very contextual and I ascribe different levels of value to the different contexts.
In a very concrete example, there was a fair amount of discussion by relying party implementors (both during and after the session) about how to get transaction data (i.e. initial reputation) when a new identifier shows up at their site. The basic question being, is there a way for a relying party to know whether they can “trust” the 3rd party OpenID to be a genuine user. If there was a way to convey transaction data such identifier creation date, date of last use, number of “publish” transactions (meaning blog posts, comments, etc) then RPs could make a much better decision on whether to just let the identifier use their site, or whether they need to do some additional “verification” of the user. In this specific case there is immediate value in identity providers providing some additional attributes about the identifier that relying parties can use to make business decisions. For OpenID this probably means adoption of the Attribute Exchange extension or some additions to SREG.
OSIS interop event
I didn't participate in the OSIS event but was interested in the issues that arose from the event. Being an “outsider” it seems that while a number of issues were found, over all the event was a success. I think a next step is to get more RP's and IdP's involved especially where RP's are bridging identity meta-systems. Things like namespace mismatches, claim mismatches, and certificates are small hurdles that can easily be fixed.
User Experience
This was a very interesting discussion as it did not focus on computer user experience and UI for interacting online. Instead it was much more about how people use identity in the offline world and how does that map into the online world. One of the interesting points to me is that in the offline world, there is a lot of context available as part of the interaction. These could be visual clues (body language, facial expressions, etc), auditory clues (tone of voice, distance from sound, etc), olfactory clues (smell, etc) and the list goes on. In online social interactions much of this additional context is lost and hence a “distance” in the communication is created. This “distance”, or incompleteness in the context, causes some to feel safe to say anything and others to hold back and mask themselves. As more transactions and social interactions move online, it will be increasingly important for consumers to understand these dynamics. A more complete summary will likely be appearing on Heather's blog.
Tags: iiw2007, Reputation, OSIS, Offline Identity
Pythia
Phil Windley lead a session on the reputation system (pythia) he's been working on with his graduate students over the last year and a half. The system is based on evaluating transactions between identities. Reputation scores are calculated on a “personal” basis meaning that I can define my own ruleset for calculating reputation that might be different than someone else's ruleset. This, I think, is important because it allows me to value the information I receive about another identity according to my own view of what's important. For example, just because an identity has a great reputation within the drug culture doesn't mean that I want to ascribe a high reputation to them. Reputations are very contextual and I ascribe different levels of value to the different contexts.
In a very concrete example, there was a fair amount of discussion by relying party implementors (both during and after the session) about how to get transaction data (i.e. initial reputation) when a new identifier shows up at their site. The basic question being, is there a way for a relying party to know whether they can “trust” the 3rd party OpenID to be a genuine user. If there was a way to convey transaction data such identifier creation date, date of last use, number of “publish” transactions (meaning blog posts, comments, etc) then RPs could make a much better decision on whether to just let the identifier use their site, or whether they need to do some additional “verification” of the user. In this specific case there is immediate value in identity providers providing some additional attributes about the identifier that relying parties can use to make business decisions. For OpenID this probably means adoption of the Attribute Exchange extension or some additions to SREG.
OSIS interop event
I didn't participate in the OSIS event but was interested in the issues that arose from the event. Being an “outsider” it seems that while a number of issues were found, over all the event was a success. I think a next step is to get more RP's and IdP's involved especially where RP's are bridging identity meta-systems. Things like namespace mismatches, claim mismatches, and certificates are small hurdles that can easily be fixed.
User Experience
This was a very interesting discussion as it did not focus on computer user experience and UI for interacting online. Instead it was much more about how people use identity in the offline world and how does that map into the online world. One of the interesting points to me is that in the offline world, there is a lot of context available as part of the interaction. These could be visual clues (body language, facial expressions, etc), auditory clues (tone of voice, distance from sound, etc), olfactory clues (smell, etc) and the list goes on. In online social interactions much of this additional context is lost and hence a “distance” in the communication is created. This “distance”, or incompleteness in the context, causes some to feel safe to say anything and others to hold back and mask themselves. As more transactions and social interactions move online, it will be increasingly important for consumers to understand these dynamics. A more complete summary will likely be appearing on Heather's blog.
Tags: iiw2007, Reputation, OSIS, Offline Identity
Wednesday, May 16, 2007
Tuesday @ IIW 2007
Tuesday was a very full day at IIW. The sessions I attended are listed below with a brief summary.
AOL OpenAuth -- Overview
Srinivas Lingutla from AOL gave an overview of the AOL OpenAuth API's and discussed the differences between the OpenAuth capabilities and existing OpenID authentication. The key additions of OpenAuth are the ability to retrieve a “security token” that represents the authentication and can be used in a back-channel way with other AOL services (e.g. instant messaging), and the consent model that is structured around the use of the “security token”.
HTTP binding for identity web services
This discussion was intended to gage interest in a standard framework for invoking identity based web services using HTTP as the core binding. The focus being support of browser based applications that make use of AJAX and XSS. The session was not well attended so the group present ended up covering many different issues relating to HTTP based invocation of services. John Panzer from AOL discussed some work he's done extending the HTTP support for authentication and authorization to support authentication use of ATOM/APP interfaces. There was some consensus that for REST based API's extending the existing HTTP mechanisms is the best solution. For AJAX based applications, this method does not work well so another method is required. I discussed the simple framework that AOL has defined for its Open Services APIs (e.g. Web Instant Messaging). We also discussed a couple of different invocation models that can be used (front-channel based vs back-channel based) with HTTP.
Rich Client Authentication
In this group we discussed the issues around allowing device specific applications (i.e. not a browser) to authenticate the user and then invoke identity based web services on the user's behalf. From the client developer perspective, the general consensus was that they didn't want to deal with implementing this and would rather the environment provide a consistent API that could authenticate the user and return the appropriate token. Of course this sort of just pushes the problem to a different layer. One idea was to look at OSIS and Cardspace as possible client side systems that could be used to do the authentication though this requires the user to adopt a new model of authentication. It is not clear to me how long that sort of user “training” is going to take.
Another aspect of client authentication is the desire to provision the authentication credentials in such a way that they are specific to the device. This way if they are compromised, they are not valid outside the context of the device. One solution here would be to use PKI provisioned through some “installation/setup” step. What that would be was not discussed, though one could use the Liberty Alliance Advanced Client specifications if willing to implement SOAP web services.
OpenID Token Exchange extension
Srinivas Lingutla also did a session on a proposed extension to OpenID that will allow relying parties (RP) to request an authentication token from the OpenID Provider (OP) at the time of authentication. The token can then be used to access identity based web services. AOL has implemented this proposed extension and demoed it during the “speed geeking” session on Monday by using an AOL OpenID to launch a buddylist using the AOL Web IM APIs. There were a number of questions around how to support different token types (simple support already present in the proposed extension), and whether some level of application id (or provider id) is required. The next steps include evaluating the other related proposed extensions and seeing if these can be combined into a single extension to support token request and validation. The proposed extension should be posted to the OpenID list/wiki in the next week or so.
What's broken with OpenID 2.0
Dick Hardt led a session on what is broken with the existing OpenID 2.0 spec. I'm sure the details will be appearing on his blog in the near future. The session of course grew beyond just what is broken to business issues and next generation feature requests. It was a very lively discussion. The “really broken” things were tackled during sessions on Wed. At the closing session on Wed. Dick promised that the 2.0 specification would be ready “real soon now”.
Tags: iiw2007, OpenAuth, OpenID
AOL OpenAuth -- Overview
Srinivas Lingutla from AOL gave an overview of the AOL OpenAuth API's and discussed the differences between the OpenAuth capabilities and existing OpenID authentication. The key additions of OpenAuth are the ability to retrieve a “security token” that represents the authentication and can be used in a back-channel way with other AOL services (e.g. instant messaging), and the consent model that is structured around the use of the “security token”.
HTTP binding for identity web services
This discussion was intended to gage interest in a standard framework for invoking identity based web services using HTTP as the core binding. The focus being support of browser based applications that make use of AJAX and XSS. The session was not well attended so the group present ended up covering many different issues relating to HTTP based invocation of services. John Panzer from AOL discussed some work he's done extending the HTTP support for authentication and authorization to support authentication use of ATOM/APP interfaces. There was some consensus that for REST based API's extending the existing HTTP mechanisms is the best solution. For AJAX based applications, this method does not work well so another method is required. I discussed the simple framework that AOL has defined for its Open Services APIs (e.g. Web Instant Messaging). We also discussed a couple of different invocation models that can be used (front-channel based vs back-channel based) with HTTP.
Rich Client Authentication
In this group we discussed the issues around allowing device specific applications (i.e. not a browser) to authenticate the user and then invoke identity based web services on the user's behalf. From the client developer perspective, the general consensus was that they didn't want to deal with implementing this and would rather the environment provide a consistent API that could authenticate the user and return the appropriate token. Of course this sort of just pushes the problem to a different layer. One idea was to look at OSIS and Cardspace as possible client side systems that could be used to do the authentication though this requires the user to adopt a new model of authentication. It is not clear to me how long that sort of user “training” is going to take.
Another aspect of client authentication is the desire to provision the authentication credentials in such a way that they are specific to the device. This way if they are compromised, they are not valid outside the context of the device. One solution here would be to use PKI provisioned through some “installation/setup” step. What that would be was not discussed, though one could use the Liberty Alliance Advanced Client specifications if willing to implement SOAP web services.
OpenID Token Exchange extension
Srinivas Lingutla also did a session on a proposed extension to OpenID that will allow relying parties (RP) to request an authentication token from the OpenID Provider (OP) at the time of authentication. The token can then be used to access identity based web services. AOL has implemented this proposed extension and demoed it during the “speed geeking” session on Monday by using an AOL OpenID to launch a buddylist using the AOL Web IM APIs. There were a number of questions around how to support different token types (simple support already present in the proposed extension), and whether some level of application id (or provider id) is required. The next steps include evaluating the other related proposed extensions and seeing if these can be combined into a single extension to support token request and validation. The proposed extension should be posted to the OpenID list/wiki in the next week or so.
What's broken with OpenID 2.0
Dick Hardt led a session on what is broken with the existing OpenID 2.0 spec. I'm sure the details will be appearing on his blog in the near future. The session of course grew beyond just what is broken to business issues and next generation feature requests. It was a very lively discussion. The “really broken” things were tackled during sessions on Wed. At the closing session on Wed. Dick promised that the 2.0 specification would be ready “real soon now”.
Tags: iiw2007, OpenAuth, OpenID
Tuesday, May 15, 2007
Identity issues at IIW 2007
Something “new” happened at IIW 2007 yesterday. Instead of the normal “state-of-identity” talks and “introduction to the issues”, Monday afternoon focused around “speed geeking” and collective identity issues. We divided into groups and each group came up with a set of issues that they felt were important. Kaliya collected all the different issues/questions into a mind map (picture of it came be found here). Other summaries can be found here and here.Of noticeable interest to me was the commonality of a lot of the questions/issues.
Tags: iiw2007
- privacy
- trust
- reputation
- delegation
- user experience
- interoperability between identity systems
- identity relationships (parental controls was brought up and not by me:) )
- and the list goes on
Tags: iiw2007
Wednesday, May 09, 2007
Technology convergence or seamless integration?
A while ago I wrote that users want convergence not interoperability. I still hold that this is true, however “convergence” in this case, is “convergence of the user experience” not necessarily the technology. Paul describes the issues very well in his recent post. For users, the experience has to be that using one identity meta-system is all that is necessary to interact with the entire set of services on the web. Forcing a user to know about which meta-system is needed for which online services will never succeed. This means that the industry has to solve the problem somehow “under the covers”.
I applaud Sun's entry into the OpenID space. However, I disagree with some that this will lead to technological convergence. The existing meta-systems are too entrenched in their existing deployments to change to something new. Some believe that convergence will come through domination of a single protocol, but I have a hard time excepting that. So that leaves determining how to interoperate between the different identity meta-systems.
I don't think this is unsolvable but it will likely NOT be simple. There are issues with token exchange, token transformation, provider discovery, etc. With a number of good choices for back-channel web services (WS-*, ID-WSF), front-channel communication (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...), and SSO (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...) it seems the time has come for the industry to slow down the spec development work and instead focus on seamless interoperability.
Here are some starting use cases...
Tags: Convergence, Interoperability, OpenID, SAML, ID-WSF
I applaud Sun's entry into the OpenID space. However, I disagree with some that this will lead to technological convergence. The existing meta-systems are too entrenched in their existing deployments to change to something new. Some believe that convergence will come through domination of a single protocol, but I have a hard time excepting that. So that leaves determining how to interoperate between the different identity meta-systems.
I don't think this is unsolvable but it will likely NOT be simple. There are issues with token exchange, token transformation, provider discovery, etc. With a number of good choices for back-channel web services (WS-*, ID-WSF), front-channel communication (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...), and SSO (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...) it seems the time has come for the industry to slow down the spec development work and instead focus on seamless interoperability.
Here are some starting use cases...
- User uses Cardspace to authenticate to a picture services that uses ID-WSF with it's billing partner(s)
- User authenticates with her college library using SAML and then wants to SSO into zooomr.com
- User users OpenID to sign in to their favorite hiking site which wants to display their buddy list as part of the site experience
Tags: Convergence, Interoperability, OpenID, SAML, ID-WSF
Monday, April 30, 2007
Identity Meta-System SSO
In his entry “OpenID bootstrap to ID-WSF”, Paul describes the results of a very interesting IOS session in Brussels. As he outlines, the bootstrapping possibilities are pretty straight forward. An interesting point of the second option is that the RP would need to know how to obtain the appropriate security token in order to invoke the Discovery Service (DS) as defined in the publicly available DS-EPR. In the OpenID case, the OpenID “assertion” would need to be exchanged for the appropriate token used to invoke the Liberty DS service (in most cases a SAMLv2 assertion).
It's this token exchange mechanism that I find intriguing. Does it work both ways? Can I exchange a SAMLv2 Assertion for an OpenID “assertion”? This seems doable if the user is using a single IdP that “speaks” all the identity protocols. With this kind of a deployment model, the IdP can use browser cookies and other mechanisms to maintain the authentication session of the user. An example flow could be...
Tags: Identity, OpenID, SAML, SSO, metasystem
It's this token exchange mechanism that I find intriguing. Does it work both ways? Can I exchange a SAMLv2 Assertion for an OpenID “assertion”? This seems doable if the user is using a single IdP that “speaks” all the identity protocols. With this kind of a deployment model, the IdP can use browser cookies and other mechanisms to maintain the authentication session of the user. An example flow could be...
- User visits RP-A which only supports SAMLv2
- User's browser has a stored cookie identifying the SAML IdP to use (existing SAML IdP discovery mechanism)
- RP-A re-directs the user's browser to the IdP to authenticate via the AuthnRequest
- User authentications and the IdP sets authentication state cookies in the user's browser
- The IdP re-directs the user's browser back to RP-A passing the AuthnResponse
- User is not authenticated at RP-A
- User now loads RP-B which only supports OpenID
- User's browser has a stored cookie identifying the last OpenID used with RP-B
- RP-B invokes a check_immediate with the OP resolved via OpenID discovery (in this case the same IdP)
- The check_immediate re-directs the user's browser such that the IdP can validate the user's authenticated session
- The IdP now verifies that there is a previously established federation between the OpenID and SAML identifier
- If the federation exists, then the IdP can return the OpenID authenticated response
Tags: Identity, OpenID, SAML, SSO, metasystem
Monday, April 23, 2007
A knife... a real knife... magnetized!
To anyone familiar with the Tray Table blog, it is certainly no surprise that a certain unnamed individual was once again traveling in 1st class. However, just a metal knife in business class? Boring... Mine were magnetized!
Not sure what caused the magnetism. Feel free to post theories in the comments.
Not sure what caused the magnetism. Feel free to post theories in the comments.
Monday, April 16, 2007
AOL releases OpenAuth
As has been blogged by Praveen Alavilli and John Panzer, today AOL released a set of http-rpc based API's for authenticating AOL identities and leveraging that authentication to access AOL services. These API's fill a niche in the existing http based web protocols by supporting the concept of authenticated service access and user consent. As many web based applications move to an AJAX model, being able to expose identity based services in a user-centric way becomes very important. Hence the importance on user consent for access to a user's data by a 3rd party application.
There are a lot of similarities in the identity processing model between the AOL OpenAuth API's and the Liberty Alliance ID-WSF SOAP based framework (authentication tokens and multi-party transactions to name a few). The similarities are intentional. The goal has been to leverage the work done by the Liberty Alliance and other internet standards organizations, and apply it to the http-rpc space for which till now there hasn't been a “good” solution. While these API's only support AOL services, the model is extensible to other protocols (as Praveen mentions in regards to an extension to OpenID).
The basics for web developers are...
Much more detailed documentation is available at http://dev.aol.com/openauth.
Full disclosure: I work for AOL but not directly as part of the Authentication team.
Tags: Identity, AOL, OpenAuth, OpenID, Liberty Alliance, ID-WSF
There are a lot of similarities in the identity processing model between the AOL OpenAuth API's and the Liberty Alliance ID-WSF SOAP based framework (authentication tokens and multi-party transactions to name a few). The similarities are intentional. The goal has been to leverage the work done by the Liberty Alliance and other internet standards organizations, and apply it to the http-rpc space for which till now there hasn't been a “good” solution. While these API's only support AOL services, the model is extensible to other protocols (as Praveen mentions in regards to an extension to OpenID).
The basics for web developers are...
- Provisioning
- At runtime
- requires both authentication and consent from the user before returning the authentication token
- requires user consent (can be remembered) before returning requested data
1. Get a provider id (called a developer key)
2. Request an authentication token
3. Invoke AOL identity based service
Much more detailed documentation is available at http://dev.aol.com/openauth.
Full disclosure: I work for AOL but not directly as part of the Authentication team.
Tags: Identity, AOL, OpenAuth, OpenID, Liberty Alliance, ID-WSF
Sunday, April 15, 2007
Wednesday, April 11, 2007
When it is a Phish
So after my experience with getting a valid notification from eBay (thanks again eBay), I received the following email supposedly from PayPal.
This one was immediately suspicious. For one, the href for the URL was a dotted quad (85.234.150.131). Two, the “whois” entry wasn't in anyway associated with PayPal.
And three, the email was not sent to the email address associated with my PayPal account.
The rest of the email looked pretty legit however, and after my experience of the previous week... I had to look closely to file this in the “scam” folder. I have to wonder if this email is in any way related to the credit card fraud of the previous week.
Tags: Phishing, eBay, PayPal
This one was immediately suspicious. For one, the href for the URL was a dotted quad (85.234.150.131). Two, the “whois” entry wasn't in anyway associated with PayPal.
OrgName: RIPE Network Coordination Centre
OrgID: RIPE
Address: P.O. Box 10096
City: Amsterdam
StateProv:
PostalCode: 1001EB
Country: NL
ReferralServer: whois://whois.ripe.net:43
...
% Information related to '85.234.128.0/19AS29550'
route: 85.234.128.0/19
descr: PH-Network Europe, operated by Euroconnex Networks LLP
origin: AS29550
remarks: *********************************************
remarks: For Peering and more info: www.euroconnex.net
remarks: *********************************************
mnt-by: POUNDHOST
source: RIPE # Filtered
And three, the email was not sent to the email address associated with my PayPal account.
The rest of the email looked pretty legit however, and after my experience of the previous week... I had to look closely to file this in the “scam” folder. I have to wonder if this email is in any way related to the credit card fraud of the previous week.
Tags: Phishing, eBay, PayPal
Sunday, April 08, 2007
Friday, April 06, 2007
When it's not a Phish
On March 29 I received the following email from eBay (I left out the “boiler plate” text regarding how to protect yourself from fraud).
My first thought was another clever phishing scheme as I don't have a credit card on file with eBay other than my PayPal account. So I looked through the email for links or other telltale signs that would indicate a phish. I couldn't find anything so I went to eBay and logged in (not via the email of course). There were the same two emails in my eBay “inbox”. I checked my account at eBay and everything looked fine. I then checked my associated PayPal account and there were no purchases via that account. Next step was to check my credit card balance.
Hmm... there on my activity statement was a charge from snapfish.com. The immediate red lights started whirring as I don't have a snapfish account. So off to the hassle of calling the credit card company, snapfish.com etc. The result of these calls was to watch my credit card account (the first fraudulent charge was $1.33). The following day there were two more fraudulent charges from snapfish.com ($2.90 and $41.65 respectively). Now back to the phone to remove these charges from my bill, cancel the credit card and get a new card issued with a new number. The biggest hassle being finding all the companies that have re-occuring charges against that card. Yet another thing to keep track of in the event this happens again.
A BIG thank you to eBay for sending this email and helping me catch the fraud right from the start. Needless to say this experience has not been pleasant, including monitoring of online credit card statements while on vacation this week. This is my first experience with this sort of fraud and I don't hope to repeat the process anytime soon:)
Tags: Fraud, Credit Card, Phishing
My first thought was another clever phishing scheme as I don't have a credit card on file with eBay other than my PayPal account. So I looked through the email for links or other telltale signs that would indicate a phish. I couldn't find anything so I went to eBay and logged in (not via the email of course). There were the same two emails in my eBay “inbox”. I checked my account at eBay and everything looked fine. I then checked my associated PayPal account and there were no purchases via that account. Next step was to check my credit card balance.
Hmm... there on my activity statement was a charge from snapfish.com. The immediate red lights started whirring as I don't have a snapfish account. So off to the hassle of calling the credit card company, snapfish.com etc. The result of these calls was to watch my credit card account (the first fraudulent charge was $1.33). The following day there were two more fraudulent charges from snapfish.com ($2.90 and $41.65 respectively). Now back to the phone to remove these charges from my bill, cancel the credit card and get a new card issued with a new number. The biggest hassle being finding all the companies that have re-occuring charges against that card. Yet another thing to keep track of in the event this happens again.
A BIG thank you to eBay for sending this email and helping me catch the fraud right from the start. Needless to say this experience has not been pleasant, including monitoring of online credit card statements while on vacation this week. This is my first experience with this sort of fraud and I don't hope to repeat the process anytime soon:)
Tags: Fraud, Credit Card, Phishing
Friday, March 23, 2007
Identity Relationships: User vs Service Provider
There has been a significant amount of discussion and work (People Service, XFN, and FOAF to name a few) around the concept of managing personal or social relationships. These relationships are managed from a user-centric perspective and are really a one-to-many relationship between the user and the identities being managed. This allows the identity of the user to be implied in regards to the other identities and groups (e.g. it is my buddy list). The group structure provides a form of role classification that can then be leveraged for permissions and access control among other things.
However, managing relationships between identities at the service level is a little different. For a service provider the relationship is not one-to-many but rather many-to-many. For example, a hospital will want to manage which patients are assigned to which doctors. A doctor can have many patients and a patient might have many doctors. The existing social relationship mechanisms don't really fit this model as these relationships are defined from a service provider centric perspective. The hospital manages the relationships not the user; though the user is free to leave one doctor and move to another.
Where social relationships tend to be defined in a uni-directional manner (from the user to the other identity), service based relationships are often bi-directional. I don't see this as a problem as it is rather easy to model and implement. However, it is important to distinguish between these two kinds of relationships.
Tags: Identity Relationship, People Service, Social Networks
However, managing relationships between identities at the service level is a little different. For a service provider the relationship is not one-to-many but rather many-to-many. For example, a hospital will want to manage which patients are assigned to which doctors. A doctor can have many patients and a patient might have many doctors. The existing social relationship mechanisms don't really fit this model as these relationships are defined from a service provider centric perspective. The hospital manages the relationships not the user; though the user is free to leave one doctor and move to another.
Where social relationships tend to be defined in a uni-directional manner (from the user to the other identity), service based relationships are often bi-directional. I don't see this as a problem as it is rather easy to model and implement. However, it is important to distinguish between these two kinds of relationships.Tags: Identity Relationship, People Service, Social Networks
Monday, March 19, 2007
How DST cost me $5
So in the US we started daylight savings time (DST) three weeks early. I'm sure most of you received the wonderful emails from the IT department that outlook entries would be tenuous for the weeks between March 11 and April 1. I figured I'd just have a few meetings that were messed up and nothing major.
However, after returning from a Liberty Alliance TEG meeting in Ipswich, UK, I got a rude awakening. I did the normal airport procedures and paid my parking fee in the terminal using the "pay-and-go" ticket I had received when entering the parking lot 7 days earlier. The parking receipt is below. Notice that the payment time is 16:25pm.
I then walked to Daily Garage 1 (about 5-8 minutes), put my stuff in my car and proceeded to the parking lot exit. Normally, you just put in your ticket and it raises the gate and off you go. Not so this time. I received a screen on the monitor stating that the "grace period" (the time between paying in the terminal and exiting the parking lot; around 45 minutes) had expired and I needed to pay and additional $5 or press the button to speak with someone over the intercom. Without thinking, I just put in my credit card and paid the $5. The receipt for that is below.
Then as I was driving home (in the surprise snow/sleet/ice/rain) I realized that there was no way my approximately 10 minutes between paying in the terminal and exiting the parking lot could have been more than the grace period allowed. The time in the machines must be off. This turns out to be the case. The time on the second receipt is 17:35pm which should be 16:35pm. I'm guessing the machines in the parking lot initially didn't adjust so they were adjusted manually. Then a "software update" came through and adjusted the times again.
Unfortunately, I have no excuse as to why I didn't think this through before paying :(
However, after returning from a Liberty Alliance TEG meeting in Ipswich, UK, I got a rude awakening. I did the normal airport procedures and paid my parking fee in the terminal using the "pay-and-go" ticket I had received when entering the parking lot 7 days earlier. The parking receipt is below. Notice that the payment time is 16:25pm.
I then walked to Daily Garage 1 (about 5-8 minutes), put my stuff in my car and proceeded to the parking lot exit. Normally, you just put in your ticket and it raises the gate and off you go. Not so this time. I received a screen on the monitor stating that the "grace period" (the time between paying in the terminal and exiting the parking lot; around 45 minutes) had expired and I needed to pay and additional $5 or press the button to speak with someone over the intercom. Without thinking, I just put in my credit card and paid the $5. The receipt for that is below.
Then as I was driving home (in the surprise snow/sleet/ice/rain) I realized that there was no way my approximately 10 minutes between paying in the terminal and exiting the parking lot could have been more than the grace period allowed. The time in the machines must be off. This turns out to be the case. The time on the second receipt is 17:35pm which should be 16:35pm. I'm guessing the machines in the parking lot initially didn't adjust so they were adjusted manually. Then a "software update" came through and adjusted the times again.
Unfortunately, I have no excuse as to why I didn't think this through before paying :(
Wednesday, March 14, 2007
Provisioning Mobile Applications with SAML
So earlier this month I described a method that would simplify provisioning a user's identity credentials to a mobile application. This method will work but requires the application provider (e.g. an Instant Messaging service) to be able to send a binary SMS message to the phone to configure the application with the necessary credentials.
A less invasive method would be for the mobile operator and the application provider to federate their identities such that when the user activated an application on the phone, the mobile operator could authenticate the user to the application provider via a SAML assertion. This is not complicated and already supported via the existing SAML protocols. A possible flow could be...
This model keeps the interactions between the mobile operator host services and external application providers. It also makes it much easier for users to configure their applications because they don't have to enter their credentials into the phone itself. A win-win.
Tags: Identity, Mobile, SAML
Update: In my rush to post this entry I was remiss in pointing out that this solution was discussed over lunch at a Liberty Alliance interim TEG meeting. The other principals in the discussion were Fulup Ar Foll and Alvaro Armenteros.
A less invasive method would be for the mobile operator and the application provider to federate their identities such that when the user activated an application on the phone, the mobile operator could authenticate the user to the application provider via a SAML assertion. This is not complicated and already supported via the existing SAML protocols. A possible flow could be...
- User goes to application provider (Instant Messaging service) web page
- Web page asks the user if they want to activate their IM account on their phone
- User selects the link to start the process
- The web page asks the user to authenticate their Instant Messaging account (if not already authenticated)
- After authentication, the web site asks the user for their mobile operator and phone number
- One the information is received the web site sends a SMS message to the phone
- The user enters the SMS confirmation code to the web site
- The web site sends a SAML federation message to the mobile operator providing a pseudonymous identifier and phone number for the user
- The mobile operator receives the SAML message and maps the phone number to the user's account and stores the pseudonymous identifier for the IM service
This model keeps the interactions between the mobile operator host services and external application providers. It also makes it much easier for users to configure their applications because they don't have to enter their credentials into the phone itself. A win-win.
Tags: Identity, Mobile, SAML
Update: In my rush to post this entry I was remiss in pointing out that this solution was discussed over lunch at a Liberty Alliance interim TEG meeting. The other principals in the discussion were Fulup Ar Foll and Alvaro Armenteros.
Friday, March 09, 2007
When phishers get lazy
So I received this email at one of my email accounts this week. It's not nearly so clever as the one pointed out by Conor here. What I found interesting is that I don't use that email account with eBay and I've never sold anything on eBay. So naturally I was suspicious. I suppose it's just easier for the phishers to swamp the "market" rather than do their homework.
Hmm... I wonder if all those PowerSeller ratings are real?
Tags: Phishing, eBay
Hmm... I wonder if all those PowerSeller ratings are real?
Tags: Phishing, eBay
Wednesday, March 07, 2007
Do we really want SSO?
With the recent flurry of announcements around OpenID the same SSO issues are once again being raised. Kevin Farham documents some of these in his piece on OpenID. Kevin's friend's issues are not around OpenID but rather the whole concept of Single-Sign-On (SSO).
This begs the question, "Do users really want SSO?" Unfortunately, the perception might be scarier than the reality.
With a good Identity Provider (IdP) and strong authentication, the user should be more secure even though a single authentication event allows access to many sites. In fact, for many users, they expect this within a "proprietary" or "closed" environment ( AOL, Google, Yahoo, MSN, etc). It's extending this SSO concept beyond the "proprietary" environment that "scares" them.
Of course part of the issue is that this kind of "cross-domain" SSO doesn't really exist in the general consumer space. The unknown always breads fear; it's human nature. To overcome this "fear", we need SSO to be common place (known not unknown), and show how SSO is "just-as-secure" as the "money under the mattress" solution.
Tags: SSO, Identity, OpenID
This begs the question, "Do users really want SSO?" Unfortunately, the perception might be scarier than the reality.
"You mean, if someone knows my password they can access all my web sites?"Well... yes and no (depending on the implementation). However, the reality is that many users have the same password at all/most their sites and so the "hacker" can already get access to all their sites without SSO.
With a good Identity Provider (IdP) and strong authentication, the user should be more secure even though a single authentication event allows access to many sites. In fact, for many users, they expect this within a "proprietary" or "closed" environment ( AOL, Google, Yahoo, MSN, etc). It's extending this SSO concept beyond the "proprietary" environment that "scares" them.
Of course part of the issue is that this kind of "cross-domain" SSO doesn't really exist in the general consumer space. The unknown always breads fear; it's human nature. To overcome this "fear", we need SSO to be common place (known not unknown), and show how SSO is "just-as-secure" as the "money under the mattress" solution.
Tags: SSO, Identity, OpenID
Monday, March 05, 2007
Simplifying Parental Controls
In his blog entry "Social Engineering" Paul Madsen describes the classic "parental control" problem where the children understand the technology better than the parents:) However, this doesn't have to be the case. I can think of a number of simple solutions.
In my household, all members have their own OS user account (yes, including my 3 1/2 yr old daughter who dutifully types in her password to sign on). This works out great for them and simplifies my life as I don't have to deal with changed desktops pictures, dock apps appearing/disappearing (yes it's a Mac), etc. I highly recommend setting up OS user accounts for individuals (there can be a family one as well if necessary). On the parental control front at the very least it allows you to turn off Administrator rights for certain accounts.
Getting back to a solution.... Once signed in to my OS user account, I could click a widget/gadget/desktop-thingy to generate an assertion to my PS2 or other device authorizing the suspension of parental controls. I suppose that the PS2 could support something like Cardspace, but that seems a little overkill. Remembering the OS account password is not too difficult and should provide the necessary level of assurance as to the subject of the assertion.
Then again, a simple USB fob with appropriate credentials would work as well. Now where did I put that "key" for the TiVo.
Tags: Identity, Parental Controls
In my household, all members have their own OS user account (yes, including my 3 1/2 yr old daughter who dutifully types in her password to sign on). This works out great for them and simplifies my life as I don't have to deal with changed desktops pictures, dock apps appearing/disappearing (yes it's a Mac), etc. I highly recommend setting up OS user accounts for individuals (there can be a family one as well if necessary). On the parental control front at the very least it allows you to turn off Administrator rights for certain accounts.
Getting back to a solution.... Once signed in to my OS user account, I could click a widget/gadget/desktop-thingy to generate an assertion to my PS2 or other device authorizing the suspension of parental controls. I suppose that the PS2 could support something like Cardspace, but that seems a little overkill. Remembering the OS account password is not too difficult and should provide the necessary level of assurance as to the subject of the assertion.
Then again, a simple USB fob with appropriate credentials would work as well. Now where did I put that "key" for the TiVo.
Tags: Identity, Parental Controls
Friday, March 02, 2007
Provisioning identity to mobile applications
Not to long ago I decided to try and set up the instant messaging client on my cell phone. I dutifully went through the painful process of entering my authentication credentials (loginid and password). However, when I got to my password, I couldn't find one of the characters in my password using the phone character entry system. This was rather frustrating and I gave up using the instant messaging client for a while. Later I tried a different account where I knew I could find the characters for the password and the mobile application worked.
This got me thinking that there has to be a better way to provision the identity to the phone for use with mobile applications. One possible process flow would be...
This should all be doable with today's technology. Of course, the next step would be secure provisioning of multiple identities for the device, where the identities are consumable by multiple applications. For this, the Advanced Client work underway in the Liberty Alliance should help.
Tags: Identity, Mobile, Instant Message, Liberty Alliance
This got me thinking that there has to be a better way to provision the identity to the phone for use with mobile applications. One possible process flow would be...
- User authenticates to web site of mobile application provider
- User enters their phone #, and carrier to the web site
- The web site sends a code to the phone
- User receives the code and enters it into the web site
- The web site generates a unique set of authentication credentials for the phone
- The web site sends a binary SMS message to the phone with the mobile application identity configuration
- User starts up mobile application and is automatically authenticated
This should all be doable with today's technology. Of course, the next step would be secure provisioning of multiple identities for the device, where the identities are consumable by multiple applications. For this, the Advanced Client work underway in the Liberty Alliance should help.
Tags: Identity, Mobile, Instant Message, Liberty Alliance
Subscribe to:
Posts (Atom)