[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRIDescriptor/Expires... maybe a TTL instead?
I think we are agreeing that "trusted TTL" with proxies and caching is complicated and fragile, right? -Gabe __________________________________________________ firstname.lastname@example.org Chief Systems Architect Technology Strategies and Standards Visa International Phone: +1.650.432.3696 Fax: +1.650.554.6817 > -----Original Message----- > From: Davis, Peter [mailto:email@example.com] > Sent: Friday, October 29, 2004 11:30 AM > To: Wachob, Gabe > Cc: firstname.lastname@example.org > Subject: RE: [xri] XRIDescriptor/Expires... maybe a TTL instead? > > > if the TTL and the signature applied (with keys from the XRIAuthority) > to the xrid in trusted res, how would this affect caching proxies? > their cache MUST expire and refresh from the authority anyway? > > --- peterd > > On Fri, 2004-10-29 at 14:07, Wachob, Gabe wrote: > > The other issue with "trusted" TTL (instead of what is currently > > implemented) is that it gets complicated to impossible when > there are > > proxy resolution steps involved. You end up having to calculate the > > TTL relative to the original resolution, not relative to the time at > > which the proxy returns a result.. > > > > -Gabe > > > > > > __________________________________________________ > > email@example.com > > Chief Systems Architect > > Technology Strategies and Standards > > Visa International > > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > > > > > -----Original Message----- > > > From: Davis, Peter [mailto:firstname.lastname@example.org] > > > Sent: Friday, October 29, 2004 7:43 AM > > > To: Wachob, Gabe > > > Cc: email@example.com > > > Subject: Re: [xri] XRIDescriptor/Expires... maybe a TTL instead? > > > > > > > > > so, in early drafts of the trusted res spec, the processing > > > for Expires > > > expected to leverage (for examle), the SAML notBefore and > > notOnOrAfter > > > attributes on the assertion, and SAMLs signing capabilities. > > > This allows > > > for pre-signing XRID's, for authority optimizations. > > > > > > the notion of cache duration, however, is a bit more > problematic, as > > > duration is based on the context of the request time... > which would > > be > > > outside the signature envelope if you still want to pre-sign the > > > XRID's. placing the cache duration outside the envolope > > significantly > > > reduces the validity of the cached XRID. > > > > > > There may also be optimizations using the detached signature > > > profile of > > > XMLDSig... but i have not looked carefully at that recently. > > > > > > --- peterd > > > > > > On Thu, 2004-10-28 at 14:12, Wachob, Gabe wrote: > > > > Mike and I have been discussing the implementation of XRI > > > directories > > > > and one issue with the current XRI Descriptor format is the > > Expires > > > > header. If your policy, as a directory, is to put in Expires > > headers > > > > to enable caching for a period of time, then you'll be updating > > the > > > > Expires header on a regular basis (perhaps even every > request???). > > > > > > > > If you happen to be signing the XRIDescriptor, however, you > > > could get > > > > into a new world of hurt. If the Expires header changes > > > every request, > > > > then you need to re-sign the response XRIDescriptor > every time. It > > > > would be really nice to be able to keep a signed copy of the > > > > XRIDescriptor for a particular authority resolution and reuse it > > (at > > > > least for a while) to siginficantly reduce the digsig > processing. > > > > Using a TTL instead of the Expires header (which would > cause some > > > > extra work on the client side in computing the expiry > time) would > > > > allow (at least as far as Expires is concerned) caching > of signed > > > > responses on the server side. > > > > > > > > Now, given the fact that we will have lookahead and proxy > > > resolution, > > > > and the fact that the Resolved header could change on a > > > regular basis, > > > > I'm not sure this change would have a large impact. But > it might. > > > > > > > > Thoughts? (Especially from Dave McAlpin who is writing > the trusted > > > > resolution spec). > > > > > > > > -Gabe > > > > > > > > > > > > __________________________________________________ > > > > firstname.lastname@example.org > > > > Chief Systems Architect > > > > Technology Strategies and Standards > > > > Visa International > > > > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > > the roster > > > > of the OASIS TC), go to > > > > > > http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php. > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php.