On Tue, Feb 16, 2010 at 1:34 PM, Allen Tom <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected] < > http://[email protected]> > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<oauth-wrap-wg%[email protected]> > . > 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
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
