Allen, A shared secret is still required, for artifact.
In the artifact case it is being used to authenticate the RP to the OP fro artifact resolution. I agree that the IdP signature over the token is not all that useful if you have just directly retrieved the token from the OP. I suspect that association is only expensive if you are doing DH. I think we should be realistic and require OP to use SSL to avoid DH associations. When the RP asks for an artifact handle in the direct request you could return the handle and a handle secret. Effectively a per request association. I suspect that Nat didn't propose that to keep the amount of changes to the core library down. Getting rid of the association is only saving about one request /4h per RP. I suspect the idea in allowing a different response is so that an OP could encode the actual response in the artifact. Sort of a compressed token. It adds complexity to the RP. I personally think having a very small artifact, that stays the same in the request and response is better. There could be an optional value/token that gets returned in the indirect response and passed back to the OP as part of the direct query. That might be a better compromise between the approaches. This is probably something that should be discussed in the WG. John B. On 2010-02-16, at 1:34 AM, Allen Tom wrote: > HI Nat - > > Why is association expensive? It should be no worse than issuing an artifact. > I guess it depends on the underlying implementation. > > 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 ) >> >>
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
