[mdx] on splitting the spec

[Ian Young]

In my mental roadmap for working through the outstanding issues on the spec, there are a number of issues where it seems like talking about the specific type of metadata is going to be necessary or at least very advantageous. Here are some of them:

* The whole SHA-1 identifier thing ends up as a MUST as a result of a feature within SAML. There does not seem to be a corresponding use case for other forms of metadata, so perhaps implementations could dispense with this potential security issue if they weren't serving SAML metadata. We certainly need to at least mention SAML in the justification for including the feature.

* There's an outstanding issue Leif raised about how to distinguish between EntityDescriptor and EntitiesDescriptor, and one part of the answer is going to have to be that the existing deployed client code has a requirement that a single entity not be returned in an EntitiesDescriptor.

* Entity attributes are very much a SAML-only construct; although in principle one could reuse the concept with other metadata types, talking about entity attributes in a formal way is going to require talking about a stack of SAML specs.

* The security considerations for SAML (which allows for XML DSIG-signed responses) are going to be different than for a metadata type which does not allow for signature but relies instead on TLS integrity guarantees.

There are some others, but I think you get the point. The current spec is *entirely* agnostic about metadata type because we wanted it to be generic. I think the rope has run out on that.

There are three obvious alternatives here.

1. Just mix in SAML processing rules throughout the spec.  I think this is the least desirable option, frankly, as it will make it less easily reusable for other metadata formats.

2. Add a section on "Processing Rules for SAML Metadata" to hold the SAML-specific material.  If we get enough traction that a similar section is required for something else before publication, add a separate section for that.

3. Have a second document that splits out the SAML-specific material.  Publish both documents at the same time so that they can refer to each other, and make it clear that other profiles could also have their own document.

Option 3 is, of course, what you'd have to do if you wanted to profile rules for an additional metadata content type  after publication for a combined base+SAML document under option 2.

In thinking about this I initially leaned towards option 2 on the basis that I didn't have any evidence that we'd be profiling for other metadata types soon and one document is less work. Heather, however, says that the publication of clusters of related documents is pretty common these days and recommends option 3 for the added flexibility given that it means the two documents can be published and updated independently.

I am therefore now leaning towards option 3.  I guess it would want to be called something like "Metadata Query Protocol for SAML Metadata" and named draft-young-md-query-saml.

As I say, I think we need to do something along these lines in order to be more prescriptive about behaviour for SAML clients while not making the base specification SAML-specific. I don't think creating the boilerplate for a new document will be particularly time-consuming.

Comments, please, on the general approach and on any specifics that attract your attention.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20131001/828cbad5/smime.p7s>