Use of Qworum for indirect communication

Doğa Armangil doga.armangil at gmail.com
Fri Dec 19 10:13:10 UTC 2008


Here are some additional pieces of information about Qworum, which hopefully
address your comments:

1. Qworum is an open web specification
At its heart, Qworum is a web format rather than a product. We intend to
make sure that this is and remains an open format, and we welcome
constructive criticism in this regard. We are likely to resolve any
shortcomings in a matter of days. As an indication of our openness, let me
mention that browser providers are free to integrate Qworum capability into
their software; we provide certification services to support this process.
Qworum intends to always maintain a clear separation between this open
format and any products that may be derived from it.

2. Qworum-enabled browsers as "dumb" clients
Qworum provides a general purpose web format (comparable to HTML) rather
than a special purpose one. A browser with Qworum capability is then
arguably a "dumb" client, and would not qualify as a smart client.

Finally, the use of Qworum for indirect communication would be optional,
which greatly reduces the reliance of OpenID on Qworum.


On Wed, Dec 17, 2008 at 5:59 PM, Dick Hardt <dick.hardt at gmail.com> 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>
>
>> 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>
>>
>>>  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
>>> http://openid.net/mailman/listinfo/specs
>>>
>>>
>>
>
>
> --
> Doğa Armangil
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>


-- 
Doğa Armangil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081219/c95920ab/attachment-0002.htm>


More information about the specs mailing list