daeq: quo vadis?

При обсуждении темы о масках в ЖЖ был поднят вопрос об OpenID, достаточно важный в свете разрастающегося вокруг OpenID шума. Что же такое на самом деле OpenID? Что он даёт пользователям и сервисам, а чего не даёт (несмотря на то, что многие думают иначе)?

Популярность OpenID во многом связана с тем, что он, как и всё гениальное, очень прост. Он не требует отдельных центральных серверов, не требует от обеих участвующих сторон никаких дополнительных знаний кроме знания самого протокола. Всё, что нужно для его функционирования уже есть в интернете повсеместно.

OpenID позволяет людям получить уникальный идентификатор, который (если это требуется и если никто ничего не взломает) не может быть использован никем кроме его владельца. Сайтам OpenID предоставляет надёжный способ отличать один идентификатор от другого (ни Cookie, ни IP адрес такой возможности не предоставляют).

Также OpenID позволяет передавать и получать пользовательские данные, что также удобно как пользователю так и сайту.

На этом его возможности, в общем то, заканчиваются.

А теперь немного о заблуждениях, связанных с OpenID:

Почему-то распространено мнение, что пользователю, залогинившемуся по OpenID стоит доверять больше, чем пользователю, просто заполнившему форму “Имя, Емейл, Текст комментария”. Это не так. И это явным образом указывается в спецификации (SRE и AX).

OpenID не отменяет ни одну проверку пользователя, которую он проходит при обычной регистрации. OpenID со стороны сайта – это, грубо говоря, просто строка, введённая в поле “Ваше имя”, ежели такое поле было бы на сайте. Это пользователю он даёт возможность получить уникальный идентификатор (если хотите, имя), который не смогут использовать другие. Для сайта же ничего подобного OpenID не предоставляет. Это пользователь может получить некоторые гарантии своей уникальности, но не сайт. Со стороны сайта основываясь только на OpenID нельзя быть уверенным ни в том, что один пользователь использует только один идентификатор, ни в том, что один идентификатор используется только одним пользователем.

Получить же идентификатор не представляет труда. На сайте OpenID есть большой список OpenID-провайдеров, среди которых есть и анонимные (т.е. не требующие регистрации). Поэтому мысль о том, что пользователь затратил некоторые силы на получения идентификатора и посему не будет хулиганить, не выдерживает критики.

Конечно, можно использовать OpenID для составления белых списков, чёрных списков, уровней доверия и прочего, но в этом плане он ни чем не отличается от e-mail или IP-адреса.

Кратко подводя итог:
OpenID даёт сайту возможность надёжно отличать один идентификатор от другого (т.к. URL уникальны) и стандартным образом получать пользовательские данные
OpenID даёт пользователю возможность получить уникальное имя в сети и передавать сайтам свои данные стандартным образом.

Period.

У многих дорогих авто в комплекте есть специальный ключ, который вы можете дать парковщику. С этим ключом нельзя проехать больше нескольких километров, нельзя открыть багажник или посмотреть адресную книгу телефона в машине. Это замечательная идея.
Описание с сайта oauth.net

OAuth – стандарт для аутентификации и получения доступа одними сервисами к данным других. Эта идея не нова. Похожие системы существуют у многих крупных и не очень сервисов. Google AuthSub, AOL OpenAuth, BBAuth Yahoo, Facebook Auth. Но пока никто не создавал стандарт, который позволит существенно повысить взаимодействие между сервисами в сети.

4 декабря 2007 года была принята спецификация OAuth 1.0.

OAuth предназначен для предоставления пользователем доступа к своим данным на одном сервисе другому сервису. Если вы хотите дать некой социальной сети доступ к адресной книге вашего почтового сервиса чтобы он мог поискать ваших знакомых, вам не обязательно предоставлять свой логин и пароль для почты этому сервису. Ведь можно предоставить доступ только к адресной книге и ни к чему больше. Именно для таких целей OAuth и создаётся.

Принцип его работы достаточно простой (и он во многом повторяет принцип работы систем API, ссылки на которые даны выше). Если один сервис (клиент) хочет получить доступ к вашим данным на другом сервисе (сервере), поддерживающем OAuth, то он запрашивает у сервера ключ, перенаправляет вас на сервер чтобы вы разрешили доступ к данным (авторизировав полученный ключ) и далее с помощью авторизированного ключа может получить данные, которые он запрашивал, и запрос на которые вы подтвердили.

В принципе, после авторизации клиент может не только запрашивать ваши данные, но и изменять данные на сервере. Т.е. делать всё, что позволит ему пользователь и сервис, предоставляющий API.

Преимущество такого стандарта перед существующими API в том, что сервисам, которые хотят предоставлять свои данные по требованию, будет проще это API писать (т.к. существуют серверные библиотеки на разных языках), а сервисам, которые хотят данные получать, будет проще это сделать благодаря стандартизации процесса.

Стандарт не определяет сам процесс получения данных. Он определяет только процедуру авторизации. Остальное остаётся на усмотрение сервиса, предоставляющего данные. Также на его усмотрение он может потребовать различных механизмов проверки подлинности (подписи). Существуют рекомендованные механизмы (HMAC-SHA1, RSA-SHA1), но можно использовать и другие.

Список сервисов, поддерживающих OAuth, пока невелик. Обновлённую версию можно найти в вики.

Набор библиотек для OAuth внушительнее, чем список использующих его сервисов. Доступны библиотеки на PHP, Ruby, Python, Java, C# и Perl. Ссылки на них можно найти здесь: http://oauth.net/code/

У OAuth, как и OpenID, на мой взгляд, большое будущее. Стандартизация механизма обмена данными между сервисами требовалась уже давно.

Многие из тех, кто уже слышал слово OpenID, считают его всего лишь парой логин-пароль, которую при некоторых условиях можно использовать на нескольких (а в идеале – почти на всех) сайтах. Но это не совсем так. OpenID позволяет делать другие не менее полезные вещи.

Почему я должен вводить свои данные снова и снова на каждом сайте, где регистрируюсь? Без этого вопроса обходится мало обзорных статей об открытых форматах переносимых данных (одним из которых является и OpenID). И, как и некоторые другие стандарты, OpenID может помочь вам в этом. Не обещаю, что вам не придётся вводить вообще никаких данных о себе, но с большей частю основных данных OpenID сможет справиться.

В первой версии OpenID существует расширение Simple Registration Extension (спецификация). Во второй версии, которая наконец появилась официально 5 декабря, предусмотрен значительно расширенный функционал передачи пользовательских данных, называемый OpenID Attribute Exchange (спецификация). Attribute Exchange (AX) уже поддерживают многие OpenID-провайдеры (OP). Очередь за сайтами и сервисами.

Рассмотрим оба способа подробнее:

OpenID Simple Registration Extension

Возможности этого расширения достаточно скромные, но оно позволяет передавать 9 полей персональной информации при логине пользователя с помощью OpenID.

Для того, чтобы получить эти данные, сайт или сервис (по официальной терминологии – Relying Party, RP) должен отправить некоторые дополнительные параметры к запросу при перенаправлении пользователя на сайт OpenID-провайдера. RP может указать, что некоторые параметры являются обязательными (например, nickname), а некоторые – опциональными (например, почтовый индекс). При этом проверка введённых данных и их наличия полностью лежит на RP. В спецификации указано, что сайт должен обращаться с данными, полученными от OpenID-провайдера так же, как если бы пользователь ввёл их в ручную и отправил форму.

С помощью Simple Registration Extension можно получить следующие данные о пользователе (если он их ввёл и разрешил отправлять):

• nickname
• email
• fullname – полное имя
• dob – date of birth – дата рождения
• gender – пол
• postcode – почтовый индекс
• country
• language
• timezone

Эти поля уже понимают многие OpenID-клиенты и большинство библиотек умеют с ними работать (вряд ли можно считать полноценной библиотекой ту, что не умеет).

OpenID Attribute Exchange

Поскольку возможности SRE сильно ограничены, был создан протокол OpenID Attribute Exchange. Принцип его работы похож – при OpenID-запросе посылаются дополнительные параметры с указанием полей, которые желательно получить от OpenID-провайдера.

Attribute Exchange отличается в лучшую сторону следующим:

• Можно запрашивать произвольные параметры с указанием желаемых типов данных.
• Возможность сохранять и обновлять параметры на OpenID-сервере (с запросом пользователя, конечно).
• Обмен данными не только при логине, а в любое удобное время.

Если провайдер OpenID не знает каких-то данных пользователя, запрашиваемых сайтом, он может попросить ввести их (с указанием типа данных). Также провайдер может позволить пользователю настраивать политики относительно передаваемых данных (на некоторые сайты передавать всё, на другие – только ник и т.п.). Как частный случай, провайдер OpenID может генерировать одноразовый e-mail для некоторых регистраций.

Кроме OpenID существуют и другие способы получать информацию о пользователе по его URI. Это и representative hCard и связанный со страницей FOAF-файл. У них есть свои преимущества (hCard могут читать и люди, FOAF может хранить большое количество другой полезной информации), и недостатки (требуется дополнительные запросы к страницам и библиотеки для парсинга).

Я думаю, в том, что касается регистрации и получения основных данных пользователя OpenID удобнее и быстрее. А значит у этого механизма большое будущее.

hCard – это микроформат, который выделяет из HTML-страницы данные о человеке. Выделяет в том смысле, что если страницу читает электронный мозг, то он может определить, что, например, является именем человека, что фамилией, а что – домашней страничкой. Пример hCard:

 <div class="vcard">
     <div class="fn">Василий Пупкин</div>
     <div class="org">Рога и Копыта</div>
     <div class="tel">495-564-1234</div>
     <a class="url" href="http://vasya.ru/">http://vasya.ru/</a>
 </div>

Эти данные будут одновременно и отображены на страничке и понятны роботу. Разобраться что есть что просто – по именам классов. fn – это имя, tel – телефон, а url – личная страничка Василия.

Представим, что этот hCard мы нашли на этой самой страничке Василия. И представим, что на этой же страничке находится несколько hCard его друзей. А нам нужно, чтобы робот мог определить, какой из них принадлежит владельцу странички, а какие – нет. Это нужно, например, если Василий указал свою страничку в качестве OpenID-идентификатора и робот хочет получить побольше информации о нём, чтобы Василию не пришлось заполнять многочисленные поля в профайле.

Люди, участвующие в разработке формата, определили два способа, которые, в принципе, можно считать стандартными для этой цели.

1. Поставить ссылку на саму страницу, на которой находится hCard и указать её класс как url и uid одновременно. Пример:

<span class="vcard">
<a href="http://daeq.ru/" class="url uid nickname">daeq</a>
</span>

2. Поставить ссылку на свои профили на других сайтах, используя для ссылки rel="me". Пример:

<span class="vcard">
<span class="nickname">daeq</span>
(<a href="http://daeq.ya.ru" rel="me" class="url">я на я.ру</a>)
</span>

Рекомендуется использовать оба способа сразу.

Роботу, чтобы определить, какой из hCard на странице является hCard её владельца, нужно просто найти тот, который удовлетворяет вышеописанным условиям.

Возможность однозначной идентификации пользователя в сети с помощью OpenID и возможность определить его связи с другими людьми в формате FOAF или XFN может позволить достаточно легко и точно определять степень доверия тому или иному человеку (или программе) в сети и может стать основой простых и потому популярных систем фильтрации спама и просто лишних сообщений как в комментариях блогов так и в любых других областях.

Участники Decentralized Information Group разработали систему “белых листов” для комментирования своего блога. В самой структуре системы ничего нового нет, она была предложена давно (например, Trust Metric от Advogato), но применение OpenID и FOAF выводит её на совершенно другой уровень.

Вкратце, устроено это так: чтобы иметь возможность комментировать блог, вы должны
a) идентифицироваться с помощью OpenID
б) ваш openid идентификатор (адрес) должен быть указан в свойстве foaf:openid foaf:Person, а сам foaf:Person должен либо быть в списке участников группы DIG (Decentralized Information Group) либо быть связанным с участником этой группы через одну или максимум две ссылки foaf:knows

На рисунке это означает, что вы должны быть достижимы по зелёному либо синему пути.

Если вы не удовлетворяете этому требованию, то вы можете попросить любого участника группы или одного из тех, кого он знает (и это указано в FOAF файле) добаветь себя в список “известных” персон. И после этого вы сможете оставлять комментарии.

Для определения связей между людьми может также использоваться XFN, который многие признают более удобным для этих целей.

Конечно, в точности такая система, как описана, выглядит довольно закрытой. Но это не единственный вариант применения OpenID и FOAF для фильтрации вредных сообщений. При достаточной популярности этих форматов построенные системы могут быть достаточно открытыми, и при этом сохранять надёжность.