[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]