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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] [OASIS Issue Tracker] Created: (SECURITY-18) PE: Discussion of metadata caching mixes in validity and is overly strict


This issue came about because we have implementations in our communities that have been led to interpret the cacheDuration fairly badly (Shibboleth included until we changed out of necessity) because the spec in this area is really not good right now. Caching is not validity and cacheDuration is not validUntil, so we believe that implementers need help cleaning this up without feeling like they're violating a spec.

The current text that's causing the worst trouble is:

"Document caching MUST NOT exceed the validUntil or cacheDuration attribute of the subject element(s)."

This is really bad text. Caching of documents is meant to be much more flexible than this, and it even calls out to HTTP 1.1 in the same section, which has much saner modeling of the concept. But taken literally it means that once a document is stale, a network failure takes out your system, which is not what anybody wants. It also conflates validUntil with caching, which is equally wrong; validity is a much more strict standard that is *meant* to take out your system.

The way we find this implemented in systems that have evolved past this language (without having a spec to back them) is to separate caching from validity and use cacheDuration as a hint to help with refresh policy. But NOT to forcibly eject valid but stale information even when no update can be done because of a glitch.

While modeling that in the spec may mean changing a MUST NOT, I think we can do that without rendering implementations non-conformant. It's still allowable to be that strict on cacheDuration, it just shouldn't be required.

I suggested some text on this that I think is reasonably balanced:
http://tools.oasis-open.org/issues/browse/SECURITY-18

I'm hoping to get us approving the draft errata for CSD and 15-day review on the next call. Pending any immediate objection, I'd like to get this errata into the uploaded draft for now, and if there are concerns, they can be made up until the vote anyway since the errata draft is just a WD, not a TC approved consensus.

-- Scott



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