OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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

 
__________________________________________________ 
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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]