Date: Thu, 28 Mar 2024 20:10:59 +0000 (UTC) Message-ID: <1635303345.6921.1711656659035@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6920_815309262.1711656659033" ------=_Part_6920_815309262.1711656659033 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This is meant to be a technical design for PEER to be used by implemento= rs. It is meant to be read together with the PEER Architecture. This is sti= ll work in progress to be discussed with the implementation teams before it= is finalized.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHO= ULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document a= re to be interpreted as described in RFC= 2119.
PEER is described in the PEE= R Architecture. An instance of PEER consists of a user-interface that c= ommunicates with a back-end storage engine. The user-interface uses the sto= rage engine to store and retrieve SAML metadata. The protocol used to commu= nicate with the storage engine is described in the next section.
The PEER Storage Engine Protocol is a protocol for accessing a PEER stor= age engine (abbreviated "storage engine"). The responsibility of the storag= e engine is to provide a store and retrieve subsystem for SAML metadata. Th= e storage engine MUST expose a WebDAV interface which SHOULD support https = and at least BASIC authentication for WebDAV clients. A storage engine clie= nt is a WebDAV client which conforms to this specification. The storage eng= ine protocol is then a profile of WebDAV.
A PEER storage engine client (abbreviated "client") MUST store each Enti= tyDescriptor element as a separate resource (in the sense of RFC4918) insid= e a single collection (in the sense of RFC4918). The name of each resource = MUST be a hash of the @entityID attribute of the EntityDescriptor element s= tored in the resource. Such a resource is called a "SAML metadata resource"= . A client SHOULD allow the hash algorithm to be configurable but MUST supp= ort at least SHA-1.
For more information on naming EntityDescriptor resources using a hash o= f the @entityID attribute see draft-lajoie-md-query-00 (this is a non-norma= tive reference).
A storage engine MUST minimally support the following operations from RF= C4918:
A client SHOULD ensure that updates are done as atomic operations possib= ly by establishing a lock (if the engine supports locking) either the colle= ction or the individual resource before performing an update. A storage eng= ine MUST permit configurable validation of SAML metadata and MUST apply any= configured validation rule upon each update operation and MUST NOT allow t= he operation to success unless validation is successful. At minimum the sto= rage engine MUST support a "schema-valid" validation rule which MUST ensure= that provided SAML metadata is valid according to a predefined set of sche= mas. The storage engine SHOULD allow this set of schema to be configurable.=
When a storage engine receives an update of a resource that does not pas= s the configured validation rules the storage engine MUST respond by return= ing a 409 (Conflict) and include a DAV:error element containing a validatio= n-error element:
<!ELE= MENT validation-error> <!ATTLIST validation-error row CDATA #IMPLIED> <!ATTLIST validation-error column CDATA #IMPLIED> <!ATTLIST validation-error message CDATA #REQUIRED>
Example
<vali= dation-error row=3D"3" column=3D"44" message=3D"missing namespace declarati= on"/>
The @row and @column attribute SHOULD be provided (if applicable) to ind= icate where in the xml the validation error occured. The @message attribute= MUST contain a human-readable description of the error.