hCard и SREG как источники данных о пользователе

Мой диалог в Твиттере с Михаилом Гусаровым (1, 2, 3, 4, 5, 6) о hCard и SREG сподвиг меня раскрыть тему подробней, потому что нюансов я успел с тех пор обдумать существенно больше, чем на сообщения по 140 символов.

Предыстория

В процессе выдирания из Cicero его OpenID-консумера в отдельное приложение я запланировал одну фичку: автообновление никнейма пользователя. У форума есть OpenID URL пользователя, из которого можно этот никнейм достать. Причём несколькими способами:

• прочитать из SREG-данных, пришедших вместе с OpenID-аутентификацией
• прочитать из hCard
• (внимание, экзотика!) прочитать из vCard, запросив URL c заголовком Accept: text/x-vcard

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

Privacy

Дальше Михаил высказался о том, что у hCard существует проблема с security и сослался на "facet своей identity".

Если я правильно понимаю, речь идёт о неком очень специальном понятии, которое последнее время любят обсуждать в OpenID-сообществе. Идея состоит в том, чтобы дать юзеру возможность выставлять разные данные о себе разным сайтам. Например, для всяких случайных порно-сайтовинтеренет-магазинов юзер хочет показать только свой email для спама, а для дорогого его сердцу форума переводчиков хайку он не против показать полное имя, фотографию и сеть его друзей-фанатов хайку. Вот эти разные виды профиля принято нынче называть "персонами". Некоторые OpenID-провайдеры уже, кстати, реализовали у себя интерфейс, позволяющий такими персонами управлять.

Надо заметить, что утверждение о том, что hCard с этим не работает, никак не противоречит тому, о чём я говорил — о возможности считывать его автоматически. Больше того, я даже не согласен с тем, чтобы называть это "security проблемой". Просто потому, что она не существенна для большинства совершенно обычных применений типа того, которое нужно мне. Форум попросил у юзера какой-нибудь никнейм. Если он смог его получить — чудесно. Если же юзер беспокоится о своей privacy, то он может просто не отдавать никаких данных, и тогда форум придумает какой-нибудь дефолтный никнейм или выдаст форму, куда юзер сам напишет, что захочет. Однако по правде говоря, большинство юзеров будет совсем не против. Даже если они в курсе, что такая проблема вообще сущестувет :-).

Именно к этому относилось моё замечание о пресловутых 80% случаев, в которых hCard является вполне себе живучим способом делать вещи.

Причём тут OAuth

OAuth — это протокол, который позволяет юзеру выдать какому-нибудь веб-сервису (например индексатору списка контактов) ограниченные права для работы от имени аккаунта юзера на другом сервисе (например Gmail). "Ограниченные права" означают, что юзер не выдаёт чужому сервису свой Gmail'овый пароль, а вместо этого получает на Gmail некий ключик (токен), сгенерированный специально для этого случая, и отдаёт его индексатору списка контактов. Когда индексатор идёт на Gmail, тот этот ключик узнаёт, позволяет читать адресную книгу, но не позволяет делать ничего больше. Ещё один бонус: юзер может отозвать ключик в любой момент.

Так вот эту же самую идею можно легко обобщить на случай управления персонами!

Если OpenID-провайдер пользователя умеет управляться с разными персонами, то ничто не мешает ему сгенерировать для каждой такой персоны отдельный случайный токен. Этот токен юзер может указать на форуме, в котором он зарегистрирован по OpenID, с тем, чтобы форум, когда пойдёт ночью читать пользовательский hCard, указывал этот токен в заголовке Authentication. И по этому самому ключику OpenID-провайдер сгенерирует hCard именно для той персоны, к которой тот относится. А если форум пришёл к нему без ключа, может или выдать дефолтную персону или вобще сказать "401 Authorization required".

Самый большой кайф в том, что OAuth, являясь расширением стандартных заголовков HTTP-авторизации, не требует от юзера никаких телодвижений в момент доступа к его профилю. И мы получаем лучшее из двух миров: управление privacy и автоматизм.

Н-да, кажется я только что придумал себе много работы :-). Реализовать показательный OpenID-сервер с персонами и OAuth-ключами и поддержать клиентскую часть OAuth-авторизации в OpenID-консумере... Или лучше я подожду, когда это сделает кто-нибудь другой :-).

P.S. Мне периодически жалуются, что тут комментарии не всегда работают. Попробую разобраться в ближайшие несколько дней, как время повзолит. Прошу прощения за неудобства!