Adding Metadata to SAMLConf? A strawman

This is a strawman proposal to sacrifice in discussion
regarding adding metadata requirements to SAMLConf.

Notwithstanding the collective shrug and variety of
motivations (or lack thereof) ... there does seem to
be good reason to add a bit more weight to this topic 
in the standard.

As it is now, SAMLMeta is a suggested format (and more)
for MAY-be use. This strawman proposal starts with the
idea that IF an implementation or two were to use it,
and were to declare that they do it interoperably, then
it would be good if the two implementations actually
did interoperate, with each other and possibly a third
that might join in.

I am intending only that the base level of this proposal 
set a sufficient baseline for confirming the interoperable 
use of metadata. This interoperability could then be relied 
on however the metadata is stored, shared, referenced, 
discovered. In this respect it would also offer deployers 
who are integrating multiple implementations some tradeoff, 
of *their* choice, between custom or standard formats for 
metadata.

Here are the proposed changes:

To SAMLConf, Table 2, add:
 FEATURE                Operational Mode
                           IdP      SP   ECP
Metadata Structures      Opt/Rqd?   Opt  Opt

Metadata Interoperation  Opt/Rqd?   Opt  Opt


To SAMLConf, Table 4, add:
 FEATURE               Operational Mode
                      AuthnA  AttribA  AuthzDA  Rqstr
Metadata Structures     Opt     Opt     Opt      Opt

Metadata Interoperation Opt     Opt     Opt      Opt


I suspect we'll need a new section with explanations,
3.6 Metadata Conformance Requirements including something
about:

Metadata Structures: 
The implementation implements SAMLMeta types, elements and 
attributes for organizing metadata, according to the SAMLMeta 
schema (urn:oasis:names:tc:SAML:2.0:metadata).

The method or extent of publishing or utilization is not
specified.

The purpose of the "Structure" feature is twofold. One to
provide a basis for the Metadata Interoperations feature. 
Two to provide improved assurances to application architects, 
those deploying interoperable API and implementations, and so 
on, that they will not, necessarily, have to design their own 
metadata translators, however they intend to make use of 
metadata. Constrained, of course, but the extent to which
the implementation uses such metadata at all.

and,

Metadata Interoperation:
The implementation offers, in addition to any other mechanism,
at least one of the two publication and resolution mechanisms
described in SAMLMeta. 

Further, the implementation provides the ability to satisfy
through this chosen SAMLMeta mechanism every required or 
optional instance described in SAMLv.20 for the use of SAMLv2.0 
metadata, for every feature supported by the respective SAML 
Operational Mode (e.g., as an IDP, or ECP, or SAML Requester).

Therefore the Metadata Interoperation feature is inclusive of 
the Metadata Structures feature.

------------

An additional factor in this change is the support it provides
for interoperability testing, provided an implementer chooses
to declare that optional capability. 

I am not suggesting a particular policy here, for whatever 
party ... but there's the complicating factor that any
party declaring that optional capability, for interoperability
testing, would need a peer for certain/many such operations.
I do not know what specific tests should be recommended.
It's possible that additional requirements might be levied
for the purpose of that testing.

------------

Thoughts? Can this, or another suggestion, bring metadata into
the SAML conformance picture?

--Nick