HOJIN's Blog
썰렁한 엔지니어

Yahoo에서 발급하는 OpenID가 아직은 Beta 수준입니다. Yahoo는 OpenID2.0을 기준으로 만들고 있죠.

혹시 Yahoo의 오픈아이디를 시험해 보실분들은, Textcube 1.6.x가 설치되고 OpenID가 활성화된 곳에 로그인해보시기 바랍니다. Textcube는 OpenID 2.0 스펙으로 발급된 아이디가 소비될 수 있는 발빠른 공간입니다.

2.0을 지원하는 Yahoo OpenID는 openid 쓰는 곳에 yahoo.com 만 쓰면 됩니다. 아직은 Attribute eXchange는 지원하지 않습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Textcube.org는 PunBB로 돌아가는 TNF 포럼이 있습니다. 오픈아이디를 지원하도록 고민중에 있습니다만, 단순히 TNF에서만 사용한다면, 뚝딱뚝딱 만들겠지만, 많은 사람들에게 도움이 될 우아한 모습을 생각하려니 여러가지 생각이 떠오르는 군요.

1. PunBB의 기존 아이디에 한 개 이상의 오픈아이디를 연결한다.
2. PunBB의 기존 아이디에 강제로 한 개 이상의 오픈아이디를 연결한다.
3. PunBB의 기존 아이디 시스템은 운영진에게만 발급하고, 일반 회원은 오픈아이디로 사용하도록 한다.
4. 일반 회원을 오픈아이디로만 사용할 때는 PunBB용 아이디를 하나 선택하도록 한다.
5. 운영중인 PunBB에서는 최초 로그인할 때 강제로 오픈아이디와 연결하도록 유도한다.
   

아직 공식적으로는 PunBB 1.3beta상황에서도 OpenID는 지원하지 않습니다만, 잘 만들어서 공개하는 방향으로 해보렵니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

간만에 OpenID 관련 글하나 써보렵니다.
블로그 주소를 OpenID로 사용하기, 혹은 위임 기능의 동어 반복이지만, OpenID 관점에서 보는 것이 아니라, 일반 블로그관점에서 보는 글입니다.

XFN을 Textcube에 구현해 넣으면서 생각해본 것입니다. 내가 친구로 정한 사람이 내 홈에 방문했을 때, 다른 뭔가를 더 줄 수 있지 않을까? 내가 친구로 정한 사람은 어떻게 확인할 수 있을까? 당연한 결론은 링크를 OpenID로 사용하게 만들고, 그 OpenID로 로그인하게 만드는 것이죠.

기존의 접근은, 오픈아이디를 만들었는데, 이걸로 돌아 다닐 수 있는 사이트는 이러저러한 사이트들이 있고, 그런 사이트에 자신을 구별하는 동일한 방법으로서의 오픈아이디이며, 따라서 왠만하면 블로그 주소로 자신을 구별하는게 어때? 라는 식의 접근이었습니다.

그러나, 반대로 내가 알고 있는 친구는 이 블로그 (혹은 링크)를 소유하고 있는데, 그 친구라는 것을 증명해보라는 접근은 오픈아이디가 정말 필요한 예라고 볼 수 있습니다.

XFN이 분산화되어 있는 SNS를 지원하는데 도움이 되는 포맷 중의 하나입니다. 앞으로 생각이 발전하게 되어 쓸만한 기능으로 발전하게 되면, 오픈아이디에 대한 이런 접근을 UI에서 잘 드러내도록 해보겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오픈아이디는 URL(정확히는URI와 해당 Dispatcher조합)로 표현된다는 관점에서 우리는 재밌는 것을 실험해 볼 수가 있습니다. 이 실험에 대한 아이디어는 OpenID 세미나로 방문했던  David Recordon(블로그)으로부터 소개 받은 것입니다.

첫번째 실험은 앵커를 이용한 오픈아이디 사용입니다.

http://coolengineer.idtail.com/

이라는 아이디가 있을 때, 보통 한 페이지에 여러 섹션을 두고 그 섹션을 찾아가기 위해애 앵커라는 표현 방식으로 다음과 같이 사용할 수 있습니다.

http://coolengineer.idtail.com/#2
http://coolengineer.idtail.com/#3
http://coolengineer.idtail.com/#private
http://coolengineer.idtail.com/#public

위 URL은 모두 다른 것을나타내지만, 결국 http://coolengineer.idtail.com/ 을 가져오도록되어있습니다. 일종의 위임(delegation)이 일어나는 것으로 생각할 수 있습니다. (물론 link tag에 의한 위임은 일어나지 않습니다.)

위와같이 로그인시도를 할 경우 RP(Relying Party, Consumer site)에서는 각각을 다른아이디로 인식하게 됩니다. 하지만, IdP 쪽에는같은 아이디로 로그인을 하게 됩니다. 물론 IdP에서도 RP에 어떤 식으로 로그인하고 있는지 #뒤의 정보를 포함한 전체 URL이 전달됩니다. 따라서, 서버쪽 라이브러리가 #뒤의 내용을 무시하고 잘 처리해주어야하는데요, 제가 간단히 테스트한 상황으로, php 라이브러리를 사용하는 idtail.com과 ruby 라이브러리를 사용하는 myid.net은 정상적으로 처리하는것을 보았습니다. java나 .net은 살펴보지 않았습니다. (누가 테스트해서 댓글을 좀.)

두번째 실험은 전체 URL 대신 일부만으로 가능하냐입니다.

즉,

coolengineer.idtail.com#2
coolengineer.idtail.com#me2dayonly

이렇게 앞의 'http://'을 떼고, .com 뒤의 # 앞에 '/'을 빼도 되느냐하는 것입니다. 이것은 클라이언트의 URL 정규화 함수의 기능에 들어 있어야하는것입니다. php 라이브러리에서는 예상대로 잘 되는 군요. (누가 다른 클라이언트 라이브러리에서도 테스트해서 댓글을 좀. 부탁합니다.)

세번째 실헝믄 위임주소에서도 가능한가 입니다.

저와 같이 블로그 주소를 오픈아이디로위임하여 사용하는 것에서 실험해볼 수 있습니다.

http://coolengineer.com/#2

잘 됩니다. 즉, RP에서는 다른 오픈아이디로 인식하는 것을 확인하였습니다. 하지만, 제 블로그의 경우에는, 위임을 http://coolengineer.idtail.com/ 에 하기 때문에, IdP 입장에서는 블로그 주소뒤에 #XXX가 어떤 내용인지 알 수가 없더군요. 만약, IdP에서 #을 기반으로하는 기능 확장을 고려한다면, 주소를 위임받아 로그인하는 사람들에게는 어찌할 수 없어보입니다.

정리하자면...

이 기능을 고려하여 사용할 수 있는 것은, IdP의 입장에서는 여러 Persona에 대해서 URL을 부여할 수가 있으며, 각 URL이 다른 오픈아이디로 인식되게 할 수 있다는 것입니다. 또한 사용자도 IdP가 이런 확장을 지원하지 않아도 #XXX를 통해 달라지는 URL을 통해 많은 OpenID를 만들어낼 수가 있다는 것입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

작년에 쓴 글에서 아파치 사용자 모임이 다시 준비하고 있다는 것을 쓴 적이 있었는데, 6개월만에 오늘(05-16) 오픈합니다.

한 달전 쯤, 운영자이신 정관진씨를 만나서 OpenID를 지원해보는 것은 어떠냐는 말에, 검토하더니 슥슥슥 넣게 되었습니다.
그동안 회원가입없이 운영해왔는데, 스팸 방지 등의 오남용 사례가 있어서 최소한의 가입을 추진하게 되었다고 합니다. 최소한으로 Email 기반으로만 운영하려다가 OpenID 암초(?)를 만난 덕에 몇 일간 고생끝에 지원하게 되었습니다.

하는 김에, 제가 속한 IDtail.com에서 공동가입을 추진해보았고, OpenID 소개 페이지에서 가입페이지로 바로 이동할 수 있게 하였습니다.

온라인 비영리 커뮤니티 중에서는 처음으로 시작하는 경우이고, 오늘 오픈을 통해서 사용자모임이 확대되어 아파치 웹서비스의 정보가 많이 공유되었으면 합니다. 또한 곳곳에 흩어져 있는 아파치관련 소식들이 한 곳에 모이고, 나아가 전문성 있는 사이트로 더 발전하는 계기가 되었으면합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

태터툴즈에 OpenID를 설치하다가 안되는 증상중 하나가 다음 웹인사이드용 플러그인이었습니다. ^^;

OpenID 플러그인이 어떻게 할 수 있는 부분이 아니어서 다음웹인사이드용 플러그인을 수정하여 배포합니다. 요기에서 받으세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

OpenID와 관련해서 지난번 글 말미에 환상을 품을 만한 실험에 대해 얘기했습니다. 사실, 낚시성 멘트였구요. 환상 정도는 아니지만, 재밌는 실험입니다.

1.
스패머들이 자신의 주소를 숨기기 위해 야후를 사용했던 방식을 이용한 방식으로 신뢰하는 도메인을 야후로 만들어 보겠습니다.

2.
지난 글에서 단일 사용자 로그인을 수행하는 OpenID의 질문중에 세번째로 인증 정보를 전달할 도메인을 확인하는 과정이 있다고 하였습니다. 인증정보를 확인하기 위한 질문까지 가기위해서 로그인사이트(이하 RP; Relying Party;Consumer site)에서는 OpenID를 접수 받고서, OpenID의 발급자(이하 IdP; ID Provider)에게 페이지를 리다이렉트합니다. 대개 사용하시는 분들은, 아이디는 로그인사이트에 넣지만, 비밀번호는 항상 발급자 홈페이지에 넣기 때문에 안심(?)스러운 광경을 연출되는 것을 보게 됩니다.

물론, 연출만이 아니라 모든 인증이 끝난 뒤에도, 실제로 비밀번호는 RP 사이트에 전달되지 않기 때문에 안심이죠.

3.
이렇게 비밀번호를 확인하고 마지막 단계로, RP 사이트에 대한 "신뢰하는 root url"을 보여주게 되고, 이 사이트가 정말 당신이 로그인하고 있는 사이트가 맞는지 확인하는 작업을 수행합니다. 사이트를 1회만 승인하던, 계속 승인하던간에 IdP에서는 RP로 다시 리다이렉트를 하게 됩니다. 이것은 처음 IdP로 건너 올 때, 되돌아갈 위치를 return_to라는 변수에 실어왔기 때문에 가능한 것입니다.

만약, 많은 사람들이 현재 사용하는 me2day나 스프링노트를 항상 승인하도록 설정해둔다면, 사이트에서 오픈아이디를 도입하고자 하는 개발자가 신뢰하는 root url을 me2day 로 해 놓고, 승인 시도를 하게된다면, 마지막 단계없이 로그인 할 수 있지 않겠습니까? 그러나, 이 경우에는 return_to의 url과 신뢰하는 root가 다른 hostname을 갖게 됩니다. 이에 대한 간단한 내용이 사양서의 노트에 기록되어 있지요.

The openid.return_to URL MUST descend from the openid.trust_root, or the Identity Provider SHOULD return an error. Namely, the URL scheme and port MUST match.

즉, 최종적으로 신뢰한 사이트를 돌려 받을 주소(return_to)는 반드시 trust_root로 부터 만들어져야하는 것입니다. 예를 들어,

trust_root=http://www.me2day.net&return_to=http://myservice.org/openid/finish

와 같은 방법으로 앞뒤를 다르게 서비스를 개설할 수 없다는 것입니다.

4.
서문이 너무 길었군요. 다시 처음에 언급한 야후를 이용하여 송신지를 숨기는 스패머들 얘기를 꺼내 보겠습니다. 야후에서 검색을 하고 난 결과 목록에서 원하는 링크를 누르면, 항상 다시 야후로 간다음 목적지로 리다이렉트 됩니다. 편의상 이것을 YR-Hack(Yahoo redirection hack) 이라고 합시다. 아마도, 이 YR핵은 통계를 내거나 클릭 기반의 데이터를 쌓아서 다음 결과에 반영하려고 그런것인지는 잘 모르겠습니다만, 다음과 같은 테스트를 해볼 수 있습니다.

http://rds.yahoo.com/*-http://coolengineer.com/

위와 같이 야후를 이용하여 제 홈에 오는 방법이 가능합니다. 아차!

5.
그럼 신뢰하는 root url을 rds.yahoo.com 혹은 *.yahoo.com 으로 한다면, 야후로 승인받고, 제 홈에 올 수 있다는 얘기 아닙니까. 예를 들면,

trust_root=http://*.yahoo.com/&return_to=http://rds.yahoo.com/*-http://myservice.org/openid/finish

와 같은 형식으로 하면, trust domain을 yahoo로 하고 return_to 에 씌여지는 url이 정상적으로 동작하는 것이라면, 그 앞에 http://rds.yahoo.com/*- 을 붙여주면, myservice.org 서비스에 로그인이 가능하게 됩니다.

자,자, 무슨 얘기인지 차근차근 따져봅시다. YR 핵의 핵심은 rds.yahoo.com 서버가 하는 일은 단지 "*-" 뒤에 있는 페이지로 redirection한다는 것이고, 이 서비스를 이용하면, trust 경로를 yahoo로 할 수 있다는 것인데. 일반적으로 사이트에서 오픈아이디를 지원하려면, 굳이 야후로 할 이유가 없습니다. 그러나, 악의적으로 사이트를 개설하고, 오픈아이디를 로그인 하도록 만들어 놓았는데, 신뢰하는 사이트가 야후로 보인다면? 자신의 신상 정보를 쉽사리 줄 수가 있겠지요. 보안에 취약해지는 부분입니다. 물론, 이런 YR 핵을 이용하여 만든 것들이 얼마나 퍼질지는 모르겠습니다.

6.
자, 환상은 무엇이고 재미는 무엇이란 말입니까?

환상은 분산환경에서 단일 사용자 로그인(SSO)을 구현해 봄직한 구멍이 보인다는 것입니다.지난 글과 서두에 언급한 세번째 질문을 처음가는 사이트라 할 지라도 비슷한 사이트에서 승인처리를 해놓았다면 야후라는 이름으로 승인될 수 있다는 것입니다.

재미는 무엇입니까? 야후 기록만 살펴봐도 어디에 누가 깔려 얼마나 많은 사용자가 로그인하고 있는지 알 수 있다는 것입니다. 분산환경에서 집중화된 로그인 기록!

자, 우리 대화를 YR 핵 대신 서비스를 만드는 사람이 중앙에서 리다이렉션해주는, 이런 비슷한 처리하는 서버를 두는 것으로 바꾸고 생각해봅시다.

환상과 재미가 취약한 보안(?)과 함께 느껴지시나요?

기회가 되면 적용할만한 꺼리와 보안을 고려하여 좀 익은다음 뒷 얘기를 더 해보겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

단일 사용자 로그인(Single Sign On; SSO)은 다음과 같은 상황에서 일어납니다.

1. 사용자 인증
2. 인증을 공유할 같은 도메인 혹은 그 서브 도메인의 서버들
3. 각 서버들은 그 기원이 서로 다른 서비스로 운영됨.
4. 각 서비스들이 요구하는 사용자 정보는 최소한으로 ID 이며, 그 외에 이메일, 이름 등이 있음.

이를 위해서는

1. 가장 공통의 인증을 위한 미들웨어 강제로 사용하는 방법이 있을 수 있고,
2. 웹이라면 쿠키의 서브 도메인에 설정하는 기능을 이용하여, 전달 받은 쿠키를 공유하는 DB 질의를 통해서 접근하는 방법이 있으며
3. 토큰하나를 캐시나 URL에 인코딩하여 전달한 뒤, 토큰의 진의 여부를 결정해주는 내부 서버를 두어 필요시마다 서버들간 대화를 하게 만들 수도 있고,
4. 무식하게는 ID와 패스워드가 몰래몰래 네트웍을 날아다니게 만들 수 도 있습니다.`

OpenID는 하나의 사이트에 로그인할 때, 세 번의 질문을 하게 됩니다. 하나는 OpenID를 묻는 것이고, 두번째는 OpenID 자체의 소유여부를 확인하기 위한 비밀번호 등이고, 세번째는 인증정보를 전달할 도메인을 확인하고자함입니다. 대개 두번째 질문은 한 동안은 묻지 않고 유지 됩니다. 세번째도 만약 신뢰하는 사이트라면 묻지 않게 됩니다.

OpenID가 SSO를 구현하는데 사용된다고 합니다만, 이를 위해서는 로그인사이트(Consumer Site; Relying Party)들이 정교한 처리를 해주어야합니다. 몇몇의 서비스를 이용해 보셨지만, 한 사이트를 사용하다가 다른 사이트에 이동하게 되면, 적어도 셋 중 최초 자신의 OpenID는 넣어야 인증이 됩니다.

정교한 처리란, 이 OpenID 마저 다시 넣지 않는 개발이 필요한 것인데, 만약 그 사이트에 두 번째 들어간다면 처음 로그인할 때 쿠키를 설정해놓고 들어 오자마자 쿠키에 씌여 있는 OpenID로 로그인 시도를 할 수 있겠지요. (Jyte.com이 그런 행위를 하는 것 같습니다만, 때에 따라 그렇지 않은 것을 보아서 정확한 구조는 파악 못하였습니다.)

OpenID가 SSO에 사용된다는 것은, 최초 OpenID를 제출하고, 이것의 OpenID의 소유자임을 확인한 브라우져 세션에 대해 "계속 승인"으로 설정한 경우, OpenID를 제출하는 것만으로 로그인이 가능하다는 것을 의미합니다. 따라서, 최초에 제기한 조건들을 충분히 만족하지 않고, 이러한 가장 큰 이유는 로그인하는 서비스들이 모두 분산되어 있는 상황이기 때문입니다. 애초부터, 같은 조직이 아닌 서비스들을 단일 사용자 로그인을 지원한다는 것 자체는 보안상 상당히 취약한 생각입니다.

다음 글에는 환상을 품을 만한 실험 한 결과를 공유해 보겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

한동안 글이 없었습니다. 심신이 피곤하여 긴 글을 쓸 염두가 안나더군요. (미투데이조차.. ^^)

www.idtail.com을 여는 것 때문에 많이 긴장했던것 같습니다. 사이트에는 베타라는 말은 없지만, 사실 팀에선 Open Beta 상태입니다. 요즘엔 베타라는 이름으로 오픈하는 것이 더 부끄(?)러운 모양인지라, 뭔가 부족한 듯한 것이 있다는 거 뻔히 아는데, 베타라는 말까지 달고 있으면, 정말 부끄러울 것 같더군요.

그간 약 150명 가량 등록되어 있는데, 시험삼아라도 가입해주신 여러분들께 감사드리구요. 불편한점 고쳐가며, 여러가지로 회사이미지에 맞는 보안성도 만족하고, 또한 보안이라는 이미지를 확장하는 서비스로 정착할 수 있는 서비스를 만들어가겠습니다.

지난, 미투데이 오픈마루의 번개에서 몇몇 분들께는 4월초에 연다고 말씀을 드렸었는데, 아직까지 이 다음단계는 아이디어 단계에 있습니다. 무한한 가능성이 있는 이 OpenID를 정말 제대로 된 물건이 되게하기 위해서 올해는 여러 실험들이 있으리라 보여지는군요.

많은 서비스들이 오픈아이디로 이어지는 세계를 꿈꾸며.. 이만.

------

제가 이 글을 쓰고, 저희 로고에 Beta가 붙어 있는 것을 보고는 화들짝 내렸습니다만, 이미 RSS로 널리널리 퍼져가고 말았습니다. 12시간 만에 다시 이 댓글을 추가하여 올립니다. 긴장의 끝이 엄청난(?) 사실 왜곡으로 가는 군요. 쩝...

저를 비난하세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

OpenID로 2007년은 시작하고 있습니다. 아마 곳곳에서 기존의 서비스에 이것을 어떻게 붙여볼까 많은 고민들을 하고 계시리라 생각합니다. 이런 고민들을 하겠지요.

1. 히야, 이거 막 뜨고 있는데, 샘플 보니 구현도 쉬울 것 같애.
2. 기존 ID를 위한 필드를 작게 잡아 두었는데, URL을 키로 사용한다니 너무 길잖아?
3. 게다가 기호까지 ID에 들어 있군, 쉽지 않겠어.
   
4. 기존 ID에 OpenID를 인증하여 한 번 연결시켜놓으면, 다음에 OpenID로 들어오면 그 ID의 권한을 주면 되잖아?
5. 그럼 기존 User 테이블에 필드를 하나 추가할까? 아니면 테이블을 하나 더 두어 Join할까?
6. 사용자 신규 가입시에는 OpenID로 받게하면, 기존 ID 필드에는 랜덤값을 넣는 방향으로 하고, 메뉴 전면에서 그 값은 안보여주면 되지 않을까?
7. 랜덤값이면 추적하기 힘들어 OpenID의 첫번째 단어로하고 만약 존재하면 1,2,3.. 붙여나가면 될 것 같애.
8. 만약 신규로 OpenID만으로 가입하여 랜덤 ID로 처리되는 중에 OpenID를 분실했다고 하면 어떻게 하지?
9. 아니, IdProvider는 그쪽 회원 탈퇴여부를 우리에게 알려주지도 않는데, 우리는 어떻게 이 계정이 휴면되었는지 알 수 있지?
   
10. 기존 ID에는 꼭하나의 OpenID만 인증해 둬야하나? 만일 맘에 안드는 OpenID라서 다른 것으로 가입하고 싶다고 불만접수되면 어떻게 하지?
11. 아예, 기존 ID에 두 개이상의 OpenID를 넣게 해서 자유롭게 사용할 수 있도록 하면, 어떨까? 어차피 AAA 개념상 어떻게든 적절한 Authentication이 일어나면 그 사람임을 기존 ID로 인정하여 접근 권한을 Authorization하는 것 아니겠어?
12. OpenID로 접근하는 것은 아예 댓글 정도의 부분적인 기능만 제공하는 것은 어떨까? 그 정도면, 사이트도 지원한다고 광고할 수 있을 것이고, 기존 체계를 많이 엎지도 않아도 되는 것 아니겠어?
13. OpenID로 로그인하겠다고 한 계정은 기존 계정으로는 로그인 못하게 막아야하는 것 아닐까? 굳이 경로를 두 개를 두어 보안 홀이 생기는 것 아냐?
14. OpenID로 가입유도를 해야하는 것일까? 아니면, 로그인하자마자 바로 사용하게 만들어야할까?
15. OpenID로 먼저 로그인하게 만들고 미가입 회원인 경우 기존 ID도 만들게 하는 것은 어떨까?
16. OpenID는 사용자가 제출한 것을 사용해야하는것일까? 아니면 1.0, 2.0 스펙이 말하는대로 사용자가 제출한 URL이 Redirection하는 마지막 URL을 사용해야하는 것일까?
17. 외부에 노출되지 않게 설계한다면, 어떤 것을 사용해도 좋은것 아닐까? 외부에는 별명정도만 선택하게 만들어거 노출시키면 되지 않나?
18. 자신의 홈페이지 주소를 OpenID로 사용하였는데, IdP의 OpenID로 로그인 시도하면 이것을 같은 계정으로 받아 줘야하는 걸까, 아니면 다른 계정으로 봐야할까?
19. 어차피 위임받은 계정인지 알 수 있으니까 둘 다 저장해두고, 이 계정으로 쓴 글들을 다른 사용자들이 조회할 때 두 계정을 모두 볼 수 있도록 하지 뭐.
20. 검색 페이지에는 openid 를 검색할 수 있게 해야하나 말아야하나.

밑도 끝도 없이 늘어나는 고민입니다. 1 번의 쉬운 유혹이 사람을 잡죠.

글 다쓰고 트랙백 날릴려고 했는데, 이런 링크가 있었군요. 이건 고민이 아니라 "잘했다 칭찬하리라" 를 위한 가이드군요. OpenID 사이트가 늘기전에 "칭찬 받을 짓"에 대한 목록을 미리 만들어 각자의 모습으로 개발하는 것을 막는 것은 중요한 것 같습니다. 어찌, OpenID는 다른 것과 달리 뒤에서 정리하는 것이 아니고, 미리 정리되는 듯한 느낌입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.