PE: Discussion of metadata caching mixes in validity and is overly strict

    • Hide

      Change lines 320-321, 380-381, 561-562, and 955-956 to:

      "Optional attribute indicates the maximum length of time a consumer should cache the metadata contained in the element and any contained elements before attempting to refresh it."

      Change Section 4.3.1, lines 1396-1400 to:

      "Document caching MUST be based on the duration indicated by the cacheDuration atribute of the subject element(s). If metadata elements have parent elements which contain caching policies, the parent element takes precedence. To properly process the cacheDuration attrbute, consumers must retain the date and time when an instance was obtained.

      Note that cache expiration does not imply a lack of validity in the absence of a validUntil attribute or other information; failure to update a cached instance (e.g., due to network failure) need not render metadata invalid, although implementations may offer such controls to deployers."

      Add new Section 4.3.2, after line 1405:

      "4.3.2 Metadata Instance Validity

      Metadata MUST be considered invalid upon reaching the time specified in a validUntil attribute of the subject element(s). The effective expiration may be adjusted downward by parent element(s) with earlier expirations. Invalid metadata MUST NOT be used. This contrasts with "stale" metadata that may be beyond its optimum cache duration but is not explicitly invalid. Such metadata remains valid and MAY be used at the discretion of the implementation."

      Show
      Change lines 320-321, 380-381, 561-562, and 955-956 to: "Optional attribute indicates the maximum length of time a consumer should cache the metadata contained in the element and any contained elements before attempting to refresh it." Change Section 4.3.1, lines 1396-1400 to: "Document caching MUST be based on the duration indicated by the cacheDuration atribute of the subject element(s). If metadata elements have parent elements which contain caching policies, the parent element takes precedence. To properly process the cacheDuration attrbute, consumers must retain the date and time when an instance was obtained. Note that cache expiration does not imply a lack of validity in the absence of a validUntil attribute or other information; failure to update a cached instance (e.g., due to network failure) need not render metadata invalid, although implementations may offer such controls to deployers." Add new Section 4.3.2, after line 1405: "4.3.2 Metadata Instance Validity Metadata MUST be considered invalid upon reaching the time specified in a validUntil attribute of the subject element(s). The effective expiration may be adjusted downward by parent element(s) with earlier expirations. Invalid metadata MUST NOT be used. This contrasts with "stale" metadata that may be beyond its optimum cache duration but is not explicitly invalid. Such metadata remains valid and MAY be used at the discretion of the implementation."
    • Hide

      Proposal accepted by TC on 2/21/12 conference call.

      Show
      Proposal accepted by TC on 2/21/12 conference call.

      Section 4.3.1 of SAMLMeta includes text that mixes notions of validity with caching, and equates validUntil with cacheDuration in an overly strict way. This is reinforced by the language referencing HTTP 1.1 caching, which implies a more typical caching model that doesn't overlap with expiration of documents.

      I suggest we split the caching discussion into two sections, one on validity and the other on caching, so we properly address each with appropriate language.

            Assignee:
            Scott Cantor (Inactive)
            Reporter:
            Scott Cantor (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: