Управление идентификацией посредством PGP

Лучше бы Вы задавали вопросы непосредственно на странице статьи, чтобы не множить темы форума.

каким образом ПОСТАВЩИК проверяет подлинность этого ключа?

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

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

Есть ли примеры, которые уже работает по этой или схожей схеме?

Реализаций именно для PGPticket я не встречал, скорее всего их просто нет. Особенность этой схемы в том, что требуется реализовать специфический тип PGP-подписи, определив идентификатор пакета в частном/экспериментальном диапазоне (поскольку стандарт OpenPGP вряд ли в скором будущем получит поддержку подобной идеи... если вообще получит); соответственно, придётся писать собственный софт или модифицировать существующий, что, опять же, повышает сложность реализации схемы.

Правда, лично на мой взгляд это всё слишком тяжеловесно и избыточно. Иан Григг и его "Рикардианские контракты" показали, что можно использовать гибкость семантики PGP-подписи во благо, определяя её непосредственно в подписываемом тексте. (Расширение этой концепции на инструменты платёжной системы выполнили недавно Даня Надь и Надежда Шакель, показав могучий потенциал стандарта и существующих реализаций OpenPGP. Надеюсь, их работа попадёт на Financial Cryptography 2008.)

Возможно, такие сайты предлагают своим пользователям загрузить плагин для браузера, и пользователи вообще не испытывает затруднений.

Как бы я предпочёл видеть реализацию этой идеи?

Вместо всей этой возни с написанием спецификации собственного OpenPGP-пакета (а потом встраивать его поддержку в ПО, не получая при этом никакой совместимости), можно просто определить ряд текстовых полей, заполняемых соответствующими данными PGPticket'а. Далее, весь этот текст заверяется ключом поставщика, а полученный подписанный текст передаётся в плагин браузера пользователя, где и сохраняется. Теперь при посещении ресурса, требующего предъявить PGPticket, плагин передаёт его автоматически. Заметьте, в большинстве случаев всё это будет происходить без обращения к связке ключей пользователя (которое иногда может расцениваться небезопасным). В принципе, то же самое описано и в статье, идею портит только упоминание о формате собственного пакета, от которой, впрочем, можно легко отказаться.

Идеи PGPticket'а/PGPcoupon'а хороши до тех пор, пока их реализация не предполагает расширений/изменений спецификаций OpenPGP. Всю её можно сделать, полагаясь на существующие инструменты.

А чем PGPticket принципиально отличается от SSL?

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

Далее, весь этот текст заверяется ключом поставщика, а полученный подписанный текст передаётся в плагин браузера пользователя, где и сохраняется. Теперь при посещении ресурса, требующего предъявить PGPticket, плагин передаёт его автоматически.

PGPticket можно попытаться отправлять через http redirect, как это делается в OpenID. И обойтись без плагина. Правда, тогда PGPticket могут украсть из истории броузера...

И кажется, PGPticket не обязательно подписывать, если сервер, который выдаёт PGPticket и сервер, который принимает, могут связаться напрямую.

Без плагина не получится, шифровать то трафик от браузера что-то должно.

Без плагина не получится, шифровать то трафик от браузера что-то должно.

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

Отличие от SSL в том, что они в принципе решают разные задачи.