[WRAP] Wrap Artifact Binding/Mobile Profile

John Bradley ve7jtb at ve7jtb.com
Tue Feb 16 12:22:39 UTC 2010


I suspect the advantage to extending the association is more political,  that way you can call it an extension.

I think practically it is better to keep the exchange of long term secrets (Association) separate from the artifact resolution process.

If we want to do per request shared secrets say SHA256 vs re-using the long term one I don't have a big problem with that.
I don't yet see a super compelling reason for it though.

John B.

On 2010-02-16, at 3:22 AM, Breno wrote:

> Maybe I'm missing something, but why is it beneficial to re-use the association request?
> 
> The current OpenID spec does not make the association request extensible, so whether you declare an artifact mode or modify the association request you have to modify the core spec.
> 
> 
> 
> On Mon, Feb 15, 2010 at 9:52 PM, Nat Sakimura <sakimura at gmail.com> wrote:
> 
> 
> On Tue, Feb 16, 2010 at 1:34 PM, Allen Tom <atom at yahoo-inc.com> wrote:
> HI Nat -
> 
> Why is association expensive? It should be no worse than issuing an artifact. I guess it depends on the underlying implementation.
> 
> AES or SHA1 is computationally much cheaper than DH, I think. 
> 
> If the main reason for the combining association and artifact request is to save round-trips, it does not save so much. 
> Suppose Association is done only once in a day, and there are 1 million authentication in a day, you are saving only 
> 0.0000001 round trip per authentication, or equivalently, one round trip per day per OP-RP pair. 
> 
> In return, you have sacrificed
> 
> 1) Computational resource (both CPU and storage since now you have to store the association for every user instead of just OP-RP pair)
> 2) Ability to sign the artifact request
> 3) You cannot use different artifact in the request and response, making it rather difficult to implement stateless Artifact mode. 
> 
> Breno - please elaborate on 3). Briefly stating, if request and response artifacts are allowed to be different, the OP can encode all the information into the artifact in a proprietary fashion so that OP can achieve the RESTful artifact mode. 
> 
> See: http://lists.openid.net/pipermail/openid-specs/2009-August/005939.html
> and http://iiw.idcommons.net/OpenID_Artifact_Binding
> 
> =nat 
>  
> 
> The point of the association is to eliminate the extra round trip (aka dumb mode) - however artifact mode by definition requires an extra round trip. I have not thought about this too deeply, however I don’t think the association step adds anything when artifact binding is used.
> 
> What is the point of having different request and response artifacts? I don’t think that’s necessary.
> 
> At least in Yahoo’s case, we can probably get by with artifacts/associations that are well under 255 bytes.  Our OAuth Request Tokens are only 8 bytes, and that’s large enough.
> 
> Allen
> 
> 
> 
> 
> On 2/12/10 10:04 PM, "Nat Sakimura" <sakimura at gmail.com> wrote:
> 
> Hi Allen, 
> 
> That can be done, but there are a few things to be considered as well. 
> 
> 1) Association is a rather expensive operation. We might not want to do it with 
>     every authentication request. 
> 2) Breno wanted to have something like 400 bytes or so to achieve statelessness in  255bytes restriction may be too short for him. 
> 3) Breno (and you I think) wanted to have the request artifact and response artifact different. 
> 3) This would probably mean that we need to touch the core library in many case and arguably has larger impact - which means that we may end up with more adoption friction. (BTW, we actually wrote test code in Java, Python, PHP, and Ruby to see if the draft can be implemented without touching the core library.) 
> 4) In the longer term, I am suspecting that association might be disappearing (like it did in Wrap) so depending on it might not be a good idea.  
> 
> In fact, initially, I was thinking the same with you half a year ago, but after a while, I have abandoned the idea. Assuming that association happens once in every hundreds of authentication request, it just buys me 0.01 round trip per authentication request or less. It is going to be even less for a large provider. I could probably trade that round trip with the benefit gained from the above reasons. That's why I did not piggy back on the association. 
> 
> =nat
>  
> 
> On Sat, Feb 13, 2010 at 1:39 PM, Allen Tom <atom at yahoo-inc.com> wrote:
> Hi Nat -
> 
> As an optimization, can we combine the association request with the artifact request? In fact, why can’t the association handle be the artifact?
> 
> For example, when the RP requests association, it can pass along all the request parameters that it normally would pass via the browser in the authentication request. The OP can then return the association handle/artifact along with the shared secret.
> 
> The RP then redirects the user’s browser to the OP with the association handle. After the user authenticates, the OP redirects the browser back to the RP with the association handle.
> 
> The RP then makes a direct server call back to the OP with the handle (and probably also the shared secret) to fetch the assertion.
> 
> I think this scheme will save a couple round trips.
> 
> Allen
> 
> 
> 
> 
> 
> On 2/11/10 9:55 PM, "Nat Sakimura" <sakimura at gmail.com <http://sakimura@gmail.com> > wrote:
> 
> If you look at my manuscript of the Artifact Binding (http://www.sakimura.org/specs/ab/1.0 ) 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
> To post to this group, send email to oauth-wrap-wg at googlegroups.com.
> To unsubscribe from this group, send email to oauth-wrap-wg+unsubscribe at googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
> 
> -- 
> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
> To post to this group, send email to oauth-wrap-wg at googlegroups.com.
> To unsubscribe from this group, send email to oauth-wrap-wg+unsubscribe at googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
> 
> 
> 
> -- 
> Breno de Medeiros
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
> To post to this group, send email to oauth-wrap-wg at googlegroups.com.
> To unsubscribe from this group, send email to oauth-wrap-wg+unsubscribe at googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100216/a0916b65/attachment.htm>


More information about the specs mailing list