This is meant to be a technical design for PEER to be used by implementors. It is meant to be read together with the PEER Architecture.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
Introduction
PEER is described in the PEER Architecture. An instance of PEER consists of a user-interface that communicates with a back-end storage engine. The user-interface uses the storage engine to store and retrieve SAML metadata.
Storage Engine Protocol
The PEER Storage Engine Protocol is a protocol for accessing a PEER storage engine. The responsibility of the storage engine is to provide a store and retrieve subsystem for SAML metadata. The storage engine MUST expose a WebDAV interface which SHOULD support https and at least BASIC authentication for WebDAV clients. A storage engine client is a WebDAV client which conforms to this specification. The storage engine protocol is then a profile of WebDAV.
A PEER storage engine client (abbreviated as a "client" below) MUST store each EntityDescriptor element as a separate resource (in the sense of RFC4918) but apart from this SHOULD NOT assume any particular organization of SAML metadata as collections (in the sense of RFC4918). It MUST be possible to configure a client to store all SAML metadata in a single collection where each resource is named by a hash of the @entityID attribute of the EntityDescriptor element stored in the resource. A client SHOULD allow the hash algorithm to be configurable on a per-collection basis but MUST support at least sha1. For more information on naming EntityDescriptor resources using a hash of the @entityID attribute see draft-lajoie-md-query-00 (this is a non-normative reference).