Re: Use of Qworum for indirect communication
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.ha...@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:modecheckid_setup/openid:mode ... /message My general impression regarding the OpenID-Qworum link is that it just makes sense. 2008/12/16 David Fuelling sappe...@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.arman...@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:modecheckid_setup/openid:mode openid:identityhttp://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:modecheckid_setup/openid:mode openid:identityhttp://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/'
Re: Use of Qworum for indirect communication
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:modecheckid_setup/openid:mode ... /message My general impression regarding the OpenID-Qworum link is that it just makes sense. 2008/12/16 David Fuelling sappe...@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.arman...@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='' xmlns:qrm='http://www.qworum.com/' !-- Call the OP -- qrm:call href='' !-- Authentication request message -- message xmlns:openid='http://openid.net/' openid:modecheckid_setup/openid:mode openid:identityhttp://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:modecheckid_setup/openid:mode openid:identityhttp://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:modeid_res/openid:mode openid:identityhttp://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
Re: Use of Qworum for indirect communication
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:modecheckid_setup/openid:mode ... /message My general impression regarding the OpenID-Qworum link is that it just makes sense. 2008/12/16 David Fuelling sappe...@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.arman...@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:modecheckid_setup/openid:mode openid:identityhttp://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:modecheckid_setup/openid:mode openid:identityhttp://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:modeid_res/openid:mode openid:identityhttp://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@openid.net http://openid.net/mailman/listinfo/specs -- Doğa Armangil ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Use of Qworum for indirect communication
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:modecheckid_setup/openid:mode ... /message My general impression regarding the OpenID-Qworum link is that it just makes sense. 2008/12/16 David Fuelling sappe...@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.arman...@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:modecheckid_setup/openid:mode openid:identityhttp://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:modecheckid_setup/openid:mode openid:identityhttp://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:modeid_res/openid:mode openid:identityhttp://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@openid.net http://openid.net/mailman/listinfo/specs -- Doğa Armangil
Re: Use of Qworum for indirect communication
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. Cool! I hope this does get added to the specs, it would lay the groundwork for indirect communication directly between users *through OpenID* - we already have multiple direct communication methods, but if OpenID, the UCI technology, can let users communicate by placing temporary documents on their URI page, it would give us another decentralization route :) -Shade ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
