Korean Identity Management(KIM)

title; 한국, 일본, 중국, 미국 SNS 사이트 비교.
link; http://2ndfinger.com/781

'전설의 에로팬더' 님 블로그에서 SNS(Social Networking Service) 사이트를 비교한 자료를 봤습니다. Cyworld는 다른 SNS 사이트와 비교하여 가입자 수가 적은데도 좋은 수익모델을 확립한 것이 인상적이더군요.

| View | Upload your own

제가 이 발표자료에 관해 포스팅 하는 이유는 후반부에 ID 관리와 연관된 내용이 나오기 때문입니다. 52-57 페이지를 보시면 됩니다.

SNS는 사용자의 정체성(Identity)를 제대로 보여줄 수 있도록 설계되어야 합니다. 현실과 일치할 수도 있고, 아니면 현실과는 달리 매력적인/왜곡된 정체성을 드러낼 수도 있죠. 그리고 '이웃'이나 '일촌' 같이 서로 믿을 수 있는 사람들 간의 관계를 맺을 수 있어야 합니다. 그래야지 사용자는 SNS 서비스에 제대로 몰입할 수 있죠.

SNS는 ID(Identity)에 대한 서비스이기 때문에, ID 관리 측면에서 고려해야 할 이슈가 많습니다.

1. 인증/인가

개인의 ID 정보가 고스란히 기록되어 있고 외부와 접촉하는 곳이기 때문에 인증/인가 작업이 철저하게 이루어져야 합니다. SNS 사이트의 해킹이 얼마나 큰 위협이 되는지 잘 아시죠? 유명 연예인들의 싸이월드 홈피 해킹 사고를 보세요. 타인이 내 계정에 저장된 비밀 정보를 빼내고 나를 사칭하여 이상한 글이라도 올린다면 어떻게 될까요? 사회적으로 매장당할 수도 있습니다. 해킹이니, 고소하느니 해도, 소 잃고 외양간 고치는 격입니다. 최근 싸이월드의 OTP 서비스 는 이런 문제를 대처하는 좋은 접근이죠. 저는 개인적으로 몇년 전부터 연예인들에게 진짜 OTP 장비를 무료로 나눠주는 마케팅을 싸이월드가 하면 좋을텐데..라고 생각했었습니다. 좋은 홍보가 될텐데 말이죠.

2. 제어/공유

자신이 올린 정보를 제대로 관리할 수 있어야 합니다. 간단하게 보면, 현재 블로그 서비스에서 제공하는 것처럼 각각의 포스트마다 공개 여부(모두 공개, 선택적 공개, 등급별 공개..)를 결정할 수 있고, 덧글 또한 선택적으로 허가할 수 있습니다. 포스트를 다른 곳으로 복사해가는 스크랩을 제공할 지 여부도 선택할 수 있고, 어느 곳에서 스크랩을 했는지도 따라갈 수 있습니다.

데이터 이동성과 관련된 최근의 이슈들은 SNS 사이트 간에 정보를 이동하고 싶다는 사용자들의 필요성이 증가했기 때문에 생겨났습니다. 이 때에도 ID 관리 기술이 중요하게 고려될 수 있음을 제 블로그에서 몇 번 언급드렸습니다. 


발표자료에서는 SNS의 Missing Block을 3가지로 구분했습니다.

- Payment Infrastructure
- Trust System
- New Value Chain

지금도 나름대로 구축되어 있는 것 같은데, 무슨 의도로 3가지를 언급했는지는 잘 모르겠습니다. 하지만 3가지 블록을 제대로 완성하기 위해서는 ID 관리 기술이 필요한 건 확실합니다. 새로운 가치를 창출하기 위해서, 사람들이 데이터 이동성에 많은 관심을 보이는지도 모릅니다. 

1. 소셜 네트워크의 문제: 서로 다른 플랫폼 구조

2007년에는 전세계적으로 소셜 네트워크 사이트가 주목을 받았습니다. 국내에서도 여러 블로그와 카페 서비스가 엄청한 호황이었고, 해외에서도 Facebook이나 MySpace가 초대형 기업으로 성장하였습니다. 소셜 네트워크가 성장하면서 여러 사이트들이 좀 더 편리하면서도 뛰어난 기능을 제공하려고 노력하고 있습니다. 그런데 문제가 하나 생겼습니다. 한 사이트를 오랫동안 사용하다가 다른 사이트로 옮기고 싶은 경우, 기존에 축적한 모든 정보를 버려야 하는 경우가 생깁니다. 편법을 이용한 데이터 백업 방법이 간혹 있지만, 많은 사용자들은 귀찮아서 계속 사용하던 사이트에 머물러 있게 되죠.

데이터가 호환되지 않는 이유는 소셜 네트워크 사이트마다 독자적인 플랫폼을 가지고 있기 때문입니다. 대표적인 소셜 네트워크 사이트들은 사용자의 프라이버시를 보호하기 위한 정책을 준수한다는 이유로 사용자의 데이터를 외부에 공개하지 않습니다. 물론 납득할 수 있는 이유지만, 어떤 사람들은 다르게 생각합니다. 사이트는 사용자의 가치있는 개인정보를 보관하고 이를 이용하여 타 사이트와 차별화된 서비스를 제공하게 됩니다. 사용자의 개인정보를 어느정도 보유하고 있는지가 그 사이트의 가치를 나타낸다고 생각할 수 있습니다. 제3의 사이트가 등장하여 더 나은 서비스를 제공하더라도, 사용자의 개인정보를 독점하고 있기 때문에 상대적인 강점을 가질 수 있습니다. 어느 정도 유명해지기 전까지, 즉 사용자가 제3의 사이트로 이동하겠다는 마음을 먹기전까지, 해당 서비스를 카피하는 전략을 사용할 수 있습니다. 국내에서도 자주 볼 수 있는 모습입니다.


출처: http://www.flickr.com/photos/500hats/2105757707/

얼마전 Microsoft 출신의 블로거인 Robert Scoble의 Facebook 계정 삭제 사건이 있었습니다. Facebook는 프라이버시를 이유로 친구 연락처 목록의 이메일 주소를 '이미지'로 표시하는데, Scoble이 친구 연락처 정보를 비롯한 여러 개인정보를 포팅하여 Plaxo라는 서비스에 활용할 수 있는 스크립트를 공개했었습니다. 하지만 이는 Facebook의 프라이버시 정책을 명백히 위반하는 행동이어서 Scoble의 계정은 삭제되었습니다. 데이터 공유에 대한 사용자의 욕구와, 사이트의 개인정보 독점 및 프라이버시 보호에 대한 욕구가 충돌한 케이스였습니다. 이에 대한 Scoble의 동영상을 참고해 보시죠.

Last week, the debate over data portability was ignited when popular blogger Robert Scoble (a DataPortability member) was banned from Facebook (represented in the DataPortability group by Benjamin Ling) for using the aforementioned script from Plaxo (represented by platform guru Joseph Smarr)

출처: http://www.news.com/8301-13577_3-9845304-36.html?tag=nefd.top

그럼에도 불구하고 지난 주에 Facebook이 DataPortability.org 에 참여한다고 정식으로 발표하였습니다. 또한 Google도 참여를 발표하였습니다. Google은 이미 독자적으로 OpenSocial 프로젝트를 운영하고 있던 터라서 의외였고, Facebook은 지금까지 사용자 데이터에 대한 독점적인 지위 행사로 많은 비판을 받고 있었기 때문에 - 심지어 Scoble의 계정 삭제 사건까지 - 이번 결정은 상당한 충격을 가져왔습니다.


2. DataPortability: 내 데이터를 내 마음대로 옮길 수 있게 된다.

DataPortability 워킹그룹은 2007년 11월 경부터 활동을 시작했습니다. 이 프로젝트의 목적은기존 기술(OpenID, RSS, hCard 등)을 이용하여 사용자의 개인정보에 대한 이동성(Portability)를 제공하는 것입니다. 주로 소셜 네트워크 사이트를 자유롭게 이동하기 위한 용도로 인식되고 있습니다. 기존에는 사이트가 사용자의 개인정보를 독점하여 서비스를 공급하는 입장이었지만, 이제는 사용자가 자신의 개인정보를 제어할 수 있으며 원하는 서비스를 제공해주는 사이트로 자유롭게 이동할 수 있게 됩니다. 신규 소셜 네트워크 사이트 또한 좋은 서비스를 개발하면 쉽게 사용자를 유치할 수 있습니다.

where users can take their data from the websites they use to reuse elsewhere and where vendors can leverage safe cross-site data exchange for a whole new level of innovation. Good bye customer lock-in, hello to new privacy challenges. If things go right, today could be a very important day in the history of the internet.
출처: http://www.readwriteweb.com/archives/goog-fb-data.php

Google에서는 Social Graph의 제안자인 Brad Fitzpatrick, Facebook의 Benjamin Ling, Plaxo의 Joseph Smarr 가 DataPortability의 발기인으로 참여하였습니다.

현재 DataPortability 워킹그룹은 꾸준한 진행을 보이고 있습니다. 공식 홈페이지 는 간단한 소개 정보와 기술&정책 설계가 있습니다. 그리고 커뮤니티 그룹  에는 187명이 가입하여 활동하고 있습니다. 작성중인 드래프트 문서 가 있기는 한데 아직은 많은 점이 부족합니다. 기술문서에서 기존 기술을 이용한 서비스 제공 방안을 설명합니다.

인증, 인가: OpenID, OAuth
데이터 추출: hCard, OPML, APML, XFN
데이터 동기화: GetPingd, SyncStream

3. 비관적인 평가

관련 업계에서는 DataPortability의 필요성을 강조하고 있었지만, 실제로 Facebook과 같은 대기업이 참여한다는 사실에 고무되어 있습니다. 하지만, 비관적인 예상 또한 존재합니다. 우선 데이터 이동성을 제공하기 위해서는 합의해야 할 항목들이 많은데 쉽게 해결할 수 있는 사안이 아닙니다.

This looks like a legitimate effort on behalf of some great minds who really do want to make the social Web run more smoothly, but anything like this is going to take quite some time to overcome the roadblocks.
출처: http://www.news.com/8301-13577_3-9845304-36.html?tag=nefd.top

또한 행동력을 가진 업체에서는 적극적인 의지를 보이지 않고 있으며, 현재 참여하고 있는 멤버들은 개인적인 차원의 관심사 차원에 국한된다고 DataPortability의 운영자가 말했습니다.

But Saad said many of the other members of DataPortability, who come from companies like Yahoo, Six Apart, and MySpace.com, are "more likely to be personally interested rather than company representatives
출처: http://www.news.com/8301-13577_3-9845304-36.html?tag=nefd.top

Facebook의 속셈 또한 오리무중입니다. 아무리 생각해도 Facebook은 득보다 실이 더 많습니다. 단순한 마케팅 전략이라는 분석이 있는데 저도 같은 생각입니다. Facebook에 대한 불만이 너무 많아지니까, 이를 무마하기 위한 목적으로 DataPortability에 가입한 듯 합니다.

The real question of the day is if Facebook will follow through on its support of the DataPortability.org mission, "To put all existing technologies and initiatives in context to create a reference design for end-to-end Data Portability. To promote that design to the developer, vendor and end-user community." Or if this is just a marketing tactic given the issues from last week?
출처: http://radar.oreilly.com/archives/2008/01/is_being_open_n.html

4. 정작 우리에게 필요한 것은 데이터 이동성이 아니라, 데이터 공유다.

한번 더 생각해보면, 사용자가 궁극적으로 원하는 건 데이터 이동성이 아닙니다. 왜 번거롭게 데이터를 옮겨야 하나요? 그보다는 여러 사이트에 흩어져 있는 내 데이터를 다른 사이트에서 통합하여 자유롭게 사용할 수 있어야 합니다. 아직 DataPortability의 스펙이 완성되지 않아서 모르지만, 현재 언급하고 있는 기술들을 살펴보면 이동성에 초점을 맞추는 부분(apml, opml), 공유에 초첨을 맞추는 부분(rdf, rss, OpenID, OAuth, Microformat)이 공존합니다.

지금도 타 사이트의 데이터를 이용하여 서비스를 제공해주는 사이트가 다수 있습니다. Daum, Naver, Google 등이 제공하는 OpenAPI를 이용하면 사용자에게 주어진 세션키로 데이터를 활용할 수 있습니다. 하지만 Scoble의 Facebook 데이터 악용 사례처럼 사이트에서 공개한 데이터 채널이 아닌, 수작업으로 html 내용을 파싱하는 식의 작업을 수행하는 경우도 많습니다. 사용자의 id와 패스워드를 요청하는 경우도 있는데, 프라이버시 문제가 우려됩니다. 만일 그 사이트가 악의적이거나 해킹을 당한다면, 내 계정 정보가 한 순간에 노출되어 악용될 수 있습니다.

우리에게 필요한 것은 안전하면서도 간편한 데이터 공유 프레임워크입니다. OAuth와 같은 데이터 공유 제어 기술은 사용자가 쉽고 효과적으로 자신의 정보를 공유할 수 있게 합니다. 그리고 마지막으로 사이트들이 보유하고 있는 사용자의 정보를 공유하겠다는 동기를 부여하는 일이 가장 큰 일입니다. 데이터 관리에 따른 보상 체계를 마련하여 데이터 제공자에게 혜택을 주는 방안, 사용자들의 적극적인 의지를 보여주어 데이터 공유 기술을 도입하도록 하는 방안들이 가능하겠죠. 사이트들에게 의지를 불어 넣어주는 것이, 바로 우리들의 역할이 아닐까요?

플릭커(Flickr)가 OpenID를 지원하고, Yahoo가 OpenID 2.0을 지원하는 오픈아이디 프로바이더(OP)를 만들 예정이라고 합니다. ReadWriteWeb에 따르면 CES 2008에서 Yahoo의 OpenID 지원 여부에 대한 소문이 돌았습니다.

Rumors abound that Yahoo! will make a major announcement about OpenID today at CES. It looks like at the very least you'll be able to use your Flickr user page URL to log in anywhere that supports OpenID login. The code is live, view source of any user page and search for OpenID and you'll find it. [3]

Simon Willison이 Flickr의 사용자 페이지 소스를 살펴본 결과 OpenID 2.0에서 사용하는 rel 태그를 발견했습니다. 이제 Flickr의 URL을 OpenID로 사용할 수 있다는 것이죠. 이 방식은 이글루스의 OpenID 지원 과도 동일합니다. 하지만 약간 아쉽게도 Flickr의 OpenID를 사용하기 위해서는 Yahoo에 가입해야 합니다. Yahoo가 OP로 설정되어 있거든요.

<link rel="openid2.provider" href="https://open.login.yahooapis.com/openid/op/auth" /> [2]

기존에는 OpenID를 쓰고, 해당 OP로 이동한 뒤에 인증 절차를 수행하였죠. 하지만 그 방식은 사용자의 OpenID가 매번 노출되기 때문에 프라이버시가 우려된다는 주장이 있었습니다. 따라서 OpenID 2.0 스펙에서는 OpenID를 기입하는 폼에 OP 이름만 쓰고, 해당 OP로 이동한 이후에 OpenID를 기입하고 패스워드를 쓰는 식으로도 동작 가능합니다. 바로 그 기능을 위해서  https://me.yahoo.com 가 사용될 것 같습니다. 추가로 일회용(One-Time) OpenID를 만들 수도 있다고 합니다.

you’ll be able to enter “me.yahoo.com” in to an OpenID field on a site and have Yahoo! pick an obfuscated, unique OpenID for your interactions with that site. This protects your privacy by preventing anyone from outside of Yahoo! from correlating your behaviour across multiple OpenID-enabled services, similar to how Yahoo!’s current BBAuth API provides applications with an opaque hash rather than a user’s Yahoo! screen name [2]

방금 확인해보니 아직 OP가 동작하지 않았습니다. 며칠 이내에 동작하리라 예상합니다.

OP의 역할은 사용자의 신원을 증명해 주는 것입니다. 얼마나 신뢰있게 제공해 주는지에 따라서, 그에 적합한 보안 수준을 요구하는 RP(Relying Party)가 서비스를 제공해 줄 수 있습니다. 지금까지의 OP는 사용자의 신원을 제대로 확인하지 않기 때문에 블로고스피어에서 사용되는 수준에 그칠 수 밖에 없었습니다.

여러 OP들이 단순한 인증을 넘어서 신원을 증명할 수 있는 서비스를 제공해 주려고 합니다. 일례로, IDTail 의 경우, OP로 시작하여 지금은 인맥을 관리하는 소셜 네트워크로 변화하고 있습니다. IDTail의 OpenID를 사용하는 사람은 자신의 정보와 평판을 쉽게 타인에게 보여줄 수 있습니다. 반면에 Flickr는 사진을 공유하는 소셜 네트워크로 시작하여 지금은 OpenID로 변화합니다. Flickr의 OpenID를 사용하는 사람은 자신의 신원을 '사진'과 '친구'들로 증명할 수 있습니다.

하지만 개인적으로는 우려가 됩니다. 만일 제가 IDTail에 등록하여 타인의 신원 정보와 사진을 올려두고, 그 사람인 것처럼 행사한다면 어떤 문제가 발생할까요? Flickr도 마찬가지입니다. 타인의 사진을 퍼와서 올리고 그 사람인양 행세한다면 어떤 문제가 발생할까요? 이런 우려에 대해서는 아무런 언급도 없습니다. 싸이월드에서 연예인을 사칭하는 경우는 자주 발생했지만, 해당 홈페이지에서만 문제가 생길 뿐입니다. 하지만 OpenID를 사용할 경우, 전세계적으로 개인의 명성을 악용할 수 있습니다.

추가1. 만일 사용자의 ID 정보가 조작되어 타인이 악용한다면, 사용자의 정보를 노출시키는 실수를 저지른 IDP가 처벌을 받아야 한다는 주장이 있네요.

If a user's identity information was compromised, and was used in a malicious manner, the identity provider could most certainly be punishable by the fullest extent of the data by contributing to the possible defamation of the victim's virtual identity. [5]

레퍼런스
[1] http://blog.k1v1n.com/2008/01/yahoo-to-embrace-openid.html
[2] http://simonwillison.net/2008/Jan/7/projection/
[3] http://www.readwriteweb.com/archives/flickr_to_authenticate_openid.php
[4] http://blog.wired.com/monkeybites/2008/01/is-yahoo-gearin.html
[5] http://akale.livejournal.com/154003.html

title; Mainstream acceptance of Twitter for disaster communication...
link; http://radar.oreilly.com/archives/2008/01/mainstream_acce.html

Twitter라는 소셜 네트워킹 서비스가 있죠. 한줄 분량의 포스팅을 하는 단순한 기능을 제공하고, 휴대폰에서도 사용가능합니다. 미국이나 일본에서는 엄청난 인기이고, 국내에서는 미투데이가 유사(거의 동일)한 서비스라고 생각됩니다.

미투데이는 자주 사용해 보려고 했는데, 저는 사적인 생각 or 정보는 가급적이면 온라인에 노출하지 않으려고 하기 때문에 분위기 적응이 어렵더군요. 온라인 환경에서 프라이버시가 얼마나 중요한지 알기 때문인지도 모르죠. 싸이월드 같이 사생활을 오픈하는데 꺼리낌이 없는 신세대들에게는 충분히 어필하고 있습니다. 하지만 잡담 수준에 그친다고 생각하였습니다.

어제 O'Reilly에서 포스팅한 글을 보면 제 생각이 조금 성급했다는 느낌이 듭니다. 재난 시 응급 수단으로 Twitter를 사용하는 방안이 가능하듯이, 짧지만 중요한 내용을 올려야 할 때에는 Twitter나 미투데이 같은 마이크로블로그가 유용할 수 있습니다. 가령 범죄 현장이나 아이들의 일상 확인 등등.. 좀 더 특화시킨 서비스를 제공한다면 사회적으로도 큰 도움이 되지 않을까요?

OAuth의 기본 개념은 맘에 듭니다. 사이트에 정보를 제공할 때에 내가 원하는 부분만 제한하여 제공해주자는 것이죠. 기존 서비스의 경우에는 api-key나 id/pass를 넘겨주어, 사용자가 할 수 있는 모든 일을 처리할 수 있었습니다. 언제든지 무슨 일이든 할 수 있기 때문에 보안상으로는 매우 취약하죠. 실례로, "Mint"라는 해외의 재무사이트는 모든 은행의 id/pass를 입력받아 계좌 내역을 통합관리할 수 있지만, 해킹이나 악의적인 목적으로 id/pass가 노출된다면 심각한 문제가 될 것입니다. 국내외에 이런 서비스가 상당히 많습니다.

He adds that it's now becoming common for financial-management sites such as Mint to ask for passwords in order to aggregate information for users. In addition to posing a security risk, Hammer-Lahav says, it's actually not the best way for sites to share information. The aggregator sites often have to scrape financial information off banking pages by training their software to seek certain clues in the page source that signal key pieces of data. The problem, he says, is that if the bank redesigns the look of a page, those clues might change, rendering the aggregator unable to read the information. A system such as OAuth, Hammer-Lahav says, allows the sites to share information directly.

open social network와 관련하여 나오는 친구 찾기 서비스 같은 것들 또한 email 주소와 패스워드를 넣는 방식을 사용하더군요. 어쩔 수 없죠. 정보를 가지고 있는 사이트에는 정작 해당 정보를 공유할 수 있는 기능이 없으니깐요.


출처: http://flickr.com/search/?q=antipattern&w=25419820%40N00


출처: http://factoryjoe.com/blog/2007/12/19/public-nuisance-1-importing-your-contacts/

OAuth가 효과를 발휘하려면 사용자의 정보를 관리하고 있는 측에서 적극적으로 수용해야 합니다. 하지만 현실적으로는 어렵죠. 자신들의 강점이 녹아있는 정보를 공유해야 하기 때문입니다. 물론 정보를 관리하는 측과 사용하는 측이 윈-윈할 수 있는 방법이 있다고 생각할 수 있겠죠. 하지만 제 성격이 이상해서 그런지, 사용하는 측에서 한 번 중요 정보를 끌어와서 더 나은 서비스를 계속 제공하지 않을까라는 생각이 드는군요. 사용하는 측의 이점이 더 많기 때문에 id/pass 방안, 기껏해야 api-key 방안이 도입되었다고 결론을 내렸습니다. api-key를 이용한 방안도 살펴보면 api-key를 제공함으로써 정보를 관리하는 측이 이점을 가지는 경우이고, 해당 서비스 또한 정보를 관리하는 측에서 만든 경우가 많습니다.

이렇게 써놓고 OAuth에 대해 쓴 이전 포스팅 을 찾아보니, 그 때와 똑같은 논조네요.