[mdx] Metadata Retrieval From Aggregate Protocol

[Thomas Lenggenhager]

This all looks pretty simple and great to me. Some typos and a question
in-line.

Chad La Joie wrote:
> Sorry, this is later than I wanted, but here are my initial thoughts on
> the protocol for retrieving metadata from an aggregate:
> 
> First, I decided to go for a RESTful protocol currently supporting two
> resources. A singular entity descriptor and a collection thereof.
> 
> Base URL:
> In the following descriptions of HTTP GET retrieval operations a URL
> path format is given.  This path is assumed to be relative to a single
> base URL which MUST include at least a URL scheme and hostname.  A port
> and path are allowed, but not required.  Query parameters and fragements

fragments

> are not allowed.  If a path is provided the URL path for operation is
> appended to the end of that path.
> 
> Retrieval of Unique Descriptor (RUD) Operation:
>   - URL Path Format 'entity/{id}'
>      The 'id' is a unique identifier for the entity.  In our case this
> may be either the URL encoded entity ID or the sha1 hash thereof.  All
> IDs starting with an '@' are reserved.
> 
> Retrieval of Descriptor Collection (RDC) Operation:
>   - URL Path Format 'entity-collection/{id}
>      The 'id' is the unique identifier for the collection.  All IDs
> starting with an '@' are reserved.  The id '@all' designates the entire
> collection of entities within the aggregate.

Should we have some distinction between global and publisher specific id
namespaces?
In case an SP admin could define his 'own' collection via some web based
interface on the aggregator, the id could be publisher specific random
number or hash.
The id for the WebSSO use case of Josh could use e.g. websso.edugain.org

> Common Query Parameter:
>   - requester - optional - The ID of the requester.  This ID should be
> treated as informational only
> 
> Headers:
>   - Content-Type - required - Only SAML metadata content type
> (application/samlmetadata+xml) would be supported initially
>   - etag - required for RUD, optional for RDC operations - Supports
> intelligent caching and more efficient retrieval given our pull model
> 
> Efficient Retrieval:
> ETags in conjunction with the 'If-None-Match' header in the request are
> the preferred method for performing conditional retrieval of data.  The
> 'Last-Modified' and 'If-Modified-Since' headers provide an additional,
> but less preferred, method of conditional data retrieval.
> 
> Caching:
> All responses SHOULD carry the header 'Cache-Control: no-cache' such
> that any intermediary, transparent, HTTP caches between the aggregate
> and requester are instructed not cache this information.
> 
> Content Encodings:
> All aggregate publishers MUST support gzip compression of transfered data
> 
> Authentication:
> All aggregate published MUST support HTTP BASIC authentication and

'publishers' instead of 'published'

> SHOULD support mutual SSL/TLS authentication.
> 
> Security Considerations:
>  - Any identity claimed by the requester via the 'requester' query
> parameter should not be trusted until it can be verified.  Transport
> level authentication provides one possible mechanism for this verification.
>  - A metadata entity, or a collection entities, may be restricted such

'collection of entities' or 'entity-collection'

> that only a subset of requesters may view them.


-- 
SWITCH
Serving Swiss Universities
--------------------------
Thomas Lenggenhager
P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 1505  direct +41 44 268 1541
http://www.switch.ch