Use of Qworum for indirect communication
Paul Madsen
paulmadsen at rogers.com
Wed Dec 17 17:11:52 UTC 2008
Duty compels me to point out an existing XML-based architecture for SSO
that has support for smart-clients
http://en.wikipedia.org/wiki/SAML
paul
Dick Hardt wrote:
> Designing OpenID around a particular product is clearly a non-starter.
>
> Enabling smart clients was discussed as part of OpenID 2.1 at IIW.
>
> Smart clients can:
> reduce the phishing risk of malicious RPs
> improve the user experience by simplifying the flow
> improve the performance by reducing the number of HTTP calls.
>
> We will still need to continue to support dumb browsers and hence
> browser redirects and form submission.
>
> -- Dick
>
>
>
> On 17-Dec-08, at 7:38 AM, Doğa Armangil wrote:
>
>> I think that OpenID auth would benefit from Qworum in a broad sense,
>> because Qworum aims to address the needs of a class of services
>> called "multi-phase services", which includes OP-type services.
>>
>> Having said that, two concrete benefits immediately come to mind:
>>
>> 1. Simplified OP
>> Currently the OP does two things: (1) it provides core authentication
>> functionality, and (2) it takes care of integrating itself into the
>> calling RP by keeping track of the return address.
>> When Qworum is used, the non-core task (2) is handled by the user
>> agent, and the OP can concentrate on providing only the core
>> functionality.
>>
>> 2. Robust message semantics
>> With Qworum, authentication request and response messages are XML
>> documents. Needless to say, XML is a mature and powerful messaging
>> format. The one benefit of XML that I will mention here is that it
>> allows the use of namespaces for qualifying OpenID request parameters
>> and response fields (instead of the "openid." prefix). Example:
>>
>> <message xmlns:openid='http://openid.net/'>
>> <openid:mode>checkid_setup</openid:mode>
>> ...
>> </message>
>>
>> My general impression regarding the OpenID-Qworum link is that it
>> just makes sense.
>>
>>
>> 2008/12/16 David Fuelling <sappenin at gmail.com
>> <mailto:sappenin at gmail.com>>
>>
>> Cool idea, although I wonder what benefit this would bring to
>> OpenID auth? Seems like HTTP redirects and form submits work
>> pretty well today. Would Qworum enable any sort of new features
>> that aren't possible today because we're not using XML between
>> RP/OP/User-agent?
>>
>> Thanks!
>>
>> david
>>
>> 2008/12/15 Doğa Armangil <doga.armangil at gmail.com
>> <mailto:doga.armangil at gmail.com>>
>>
>> The OpenID Authentication 2.0 specification states in section
>> 5.2 that "There are two methods for indirect communication:
>> HTTP redirects and HTML form submission". It is worth noting
>> that a third method might be added to this list: Qworum (
>> http://www.qworum.com/ ).
>>
>> Qworum is a fairly new technology (a couple of years old)
>> that aims to solve precisely the problem of indirect
>> communication between interactive web services (such as
>> between Relying Parties and OpenID Providers). Qworum
>> mandates that the caller (i.e. RP) and the callee (i.e. OP)
>> communicate through XML documents.
>>
>> Here is one possible authentication scenario involving Qworum:
>>
>>
>> 1. The RP calls the OP by sending the following Qworum
>> message to the user agent:
>>
>> <!-- Return to the RP after calling the OP -->
>> <qrm:goto href='/auth_complete'
>> xmlns:qrm='http://www.qworum.com/'>
>>
>> <!-- Call the OP -->
>> <qrm:call href='http://openid-provider.net/my_id'>
>>
>> <!-- Authentication request message -->
>> <message xmlns:openid='http://openid.net/'>
>> <openid:mode>checkid_setup</openid:mode>
>>
>> <openid:identity>http://openid-provider.net/my_id</openid:identity>
>> ...
>> </message>
>>
>> </qrm:call>
>>
>> </qrm:goto>
>>
>> This message instructs the user agent to call the OP and to
>> send the result back to the RP.
>>
>> 2. The user agent then calls the OP (i.e.
>> http://openid-provider.net/my_id ) by POSTing it the
>> following XML document:
>>
>> <message xmlns:openid='http://openid.net/'>
>> <openid:mode>checkid_setup</openid:mode>
>>
>> <openid:identity>http://openid-provider.net/my_id</openid:identity>
>> ...
>> </message>
>>
>> 3. The OP interacts with the end user.
>>
>> 4. The OP sends the following Qworum message to the user agent:
>>
>> <!-- Authentication response message -->
>> <message xmlns:openid='http://openid.net/'>
>> <openid:mode>id_res</openid:mode>
>>
>> <openid:identity>http://openid-provider.net/my_id</openid:identity>
>> ...
>> </message>
>>
>> 5. Finally, the user agent then POSTs the authentication
>> response message back to the RP. Note that the RP return
>> address is handled by the user agent, not the OP.
>>
>>
>> Adding Qworum as a third communication method would not break
>> existing methods, it would just offer one more choice to RPs:
>> * The RP can check whether the user agent has Qworum
>> capability by inspecting the Accept header of the HTTP
>> request. The RP can then choose to use Qworum.
>> * The OP would understand that the RP is using Qworum to call
>> it if the Content-Type of the HTTP POST request is
>> application/xml.
>>
>> So my question is this: Has Qworum been considered for
>> indirect communication, or could it be considered in the
>> future? (As the lead developer of Qworum, I can affirm that
>> Qworum would do all it can to facilitate this process.)
>>
>> --
>> Doğa Armangil
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net <mailto:specs at openid.net>
>> http://openid.net/mailman/listinfo/specs
>>
>>
>>
>>
>>
>> --
>> Doğa Armangil
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net <mailto:specs at openid.net>
>> http://openid.net/mailman/listinfo/specs
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.552 / Virus Database: 270.9.19/1853 - Release Date: 17/12/2008 8:31 AM
>
--
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com
ConnectID <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081217/3dab59e9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gMwy.1.gif
Type: image/gif
Size: 7461 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081217/3dab59e9/attachment-0002.gif>
More information about the specs
mailing list