RE: [xri] XRIDescriptor/Expires... maybe a TTL instead?

["Davis, Peter" <peter.davis@neustar.biz>]

fragile, yes... well understood and tractable, hopefully... 

agreed.

--- peterd

On Fri, 2004-10-29 at 14:42, Wachob, Gabe wrote:
> I think we are agreeing that "trusted TTL" with proxies and caching is
> complicated and fragile, right?
> 
>         -Gabe
> 
>  
> __________________________________________________ 
> gwachob@visa.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:peter.davis@neustar.biz]
> > Sent: Friday, October 29, 2004 11:30 AM
> > To: Wachob, Gabe
> > Cc: xri@lists.oasis-open.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
> > > 
> > >  
> > > __________________________________________________ 
> > > gwachob@visa.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:peter.davis@neustar.biz]
> > > > Sent: Friday, October 29, 2004 7:43 AM
> > > > To: Wachob, Gabe
> > > > Cc: xri@lists.oasis-open.org
> > > > 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
> > > > > 
> > > > >  
> > > > > __________________________________________________ 
> > > > > gwachob@visa.com
> > > > > 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.
>