Korean Identity Management(KIM)

제가 생각하는 OpenID의 방향은, 대형 포털이 자사의 SSO 시스템에 OpenID를 지원하는 식입니다. 약간의 변형이 있을 수도 있겠지만 대부분의 OpenID 스펙을 준용하기 때문에 간단한 확장 기능만으로 타 OpenID도 수용할 수 있죠. 예전에 Daum에서 제공했던 Daum Sign과 유사한 서비스입니다. 즉, API 라이브러리를 제공하며 내부에는 OpenID를 쓰지만 사용자는 굳이 OpenID인지 몰라도 사용하는 것이죠.

지난 주 Google이 공개한 OpenID 제공자가 바로 제가 생각하는 방향이었습니다. 가맹된 사이트에는 Google 계정으로 OpenID 사용 가능하며 매뉴얼 또한 제공됩니다.[4] 하지만 타 RP에서도 OpenID를 사용할 수 있습니다.

Google will allow web services to join a limited test of an API based on the OpenID 2.0protocol that will give Google Account users the option to sign in towebsites with their Google credentials and without having to sign upfor a new account at those sites.[1]

Google은 Plaxo나 Zoho 사이트처럼 협력 관계를 맺고 있는 RP에 대해서는 "Sign in with Google" 버튼을 추가했습니다. 이를 누르면 'https://www.google.com/accounts/o8/id'로 이동하여 XRDS를 가져와서 로그인을 하거나, 또는 OpenID URL 입력 창에 Gmail 주소를 입력하여 Google의 계정으로 매핑하는 작업을 수행합니다.

Now, however, Google has announced that it will start publishing XRDSfiles 'as quickly as possible.' For the time being, you can use'https://www.google.com/accounts/o8/id' to sign up for OpenID enabledsites.[2]

다음은 Plaxo의 로그인 화면입니다. 로그인버튼 아래에 있는 링크를 클릭하면 Google 계정으로 로그인할 수 있습니다.


Google과 제휴되지 않는 RP에도 로그인 해보았습니다. Springnote에서 OpenID URL로 'https://www.google.com/accounts/o8/id' 를 입력해 보았습니다. 제가 이미 Google에 로그인 된 상태라서 아래와 같이 Springnote에 로그인 정보를 제공할 지 물어보는 화면이 나왔습니다. '계속 진행' 버튼을 누르면 곧바로 로그인되는 화면을 확인할 수 있습니다.


Google의 OpenID 구동 절차는 다음과 같습니다.


Google의 OpenID 지원은 2가지 특징이 있습니다. 첫번째는 OAuth를 지원하는 것입니다. 추가로 정보를 요청할 때, 즉 Google의 Data API나 Portable Contact와 OpenSocial API 등의 데이터를 요구할 때 OAuth를 통해 사용자의 허락을 받아야 됩니다.

Google also announced that it is looking to combine the OAuthand OpenID protocol so that a service can not only request a user'sidentity through OpenID, but also "request access to information available via OAuth-enabled APIs such as Google Data APIs as well asstandard data formats such as Portable Contacts and OpenSocial REST APIs."[1]

두번째는 기존의 OpenID 대신 Gmail 주소를 OpenID URL에 사용하는 방안입니다. 아래 그림에서 3 단계는 기존 url 방식의 OpenID가 아니라, 제시된 gmail을 이용하여 xrds를 가져오는 절차입니다.

Google was not following the OpenID guidelines closely and that it was basically forking OpenID to suit its own agenda.[2]

OpenID 커뮤니티에서도 예전에 email 주소를 OpenID URL로 고려한 적이 있었지만, 프라이버시나 스팸 문제를 우려하여 채택되지 않았죠. 하지만 Google은 사용자 입장에서 url 방식은 안좋다고 평가하였습니다. gmail을 사용하는 방식은 OpenID 표준에 없기 때문에 현재의 RP들은 사용할 수 없습니다. OpenID url이 아닌 gmail을 해석해야 하는 모듈을 하나 추가해야 됩니다.

It’s not just a “departure” from OpenID, it’s a whole new standard.. As you can see, steps 3 & 4 are not part of OpenID and leave Google’s implementation of OpenID, such as it is, incompatible with everyone else.[3]

Google’s implementation of OpenID seems to be incompatible witheveryone else. Of course Google is big and might very well persuadelots of web services to drop OpenID support and simply go for TheGoogle Solution.[6]

Google은 이제 OP(OpenID Provider)가 되었지만 RP(Relying Party)가 될 계획은 전혀 없습니다. Google의 리치 클라이언트에 하드코딩된 로그인 절차 때문이라고 합니다. 기술적인 문제인데, 이를 수정하기 위해서는 Google 전체의 동의를 얻어야 할텐데 상식적으로 어려울 것 같습니다.

Google itself did not accept OpenID for letting users sign in to itsown properties. According to today's blog post, the reason for this is purely technical, as "all Google rich-client apps would break if we supported federated login for our consumer users."[2]

One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem isthat rich-client apps (desktop apps and mobile apps) are hard-coded toask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for ourconsumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today.[5]

OpenID는 활성화를 선택할까요? 아니면 스펙과 정형성을 선택할까죠? Google의 행동에 대해서 어떤 사람은 'Don't be Evil'을 어겼다며 비난하는 사람이 있고, 어떤 사람은 발빠르게 email 식별자를 해석하는 방식을 확장 스펙에 추가하려는 논의를 하고 있습니다. 제가 WebAppsCon에서 말한 내용은 '전자'였는데요, 어떤 식으로 계속 진행될지 흥미있게 바라보겠습니다.

Google and its partners are taking a similar route and are basically bypassing any mention of OpenID itself in favor of a simple messagesaying "Sign in with a Google Account."[1]

Google 본사에서 진행된 인터뷰입니다. 맨 왼쪽의 사람이 이번 Google의 OpenID 프로바이더 계획을 진행한 Eric Sachs, 그 오른쪽이 OpenID 스펙을 개발한 사람 중의 하나인 David Recordon입니다.



레퍼런스
[1] http://www.readwriteweb.com/archives/google_is_now_an_openid_provider.php
[2] http://www.readwriteweb.com/archives/google_clarifies_openid_implementation.php
[3] ?
[4] http://code.google.com/apis/accounts/docs/OpenID.html
[5] http://google-code-updates.blogspot.com/2008/10/moving-another-step-closer-to-single.html
[6] http://thenextweb.org/2008/10/30/google-openid-fail/