OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Revising PE25 SAML Metadata Feature in SAMLConf


No sooner did I get off of today's call than I realized that the 
changes I'd agreed to make would return this proposal to, materially 
(but improved), the same as the proposal I'd made before 
(in <http://lists.oasis-open.org/archives/security-services/200506/msg00102.html>.

So it seems to me there are two approaches:
1. One is to combine the structures with a minimal interchange, assuring
   some form of dynamic interoperability, as discussed today.
2. T'other is to leave the proposal as it is in saml-errata-2.0-draft-12: 
   metadata structures only, without reference to how the information 
   is interchanged;


APPROACH #1
As I favor including the interchange aspect, I update here the
text for Proposed Errata #25. 

The substantive change is contained in errata lines 613-615 and the two 
lines marked +a622, below. 

You'll note that rather than require a particular minimum (e.g, the WKL), 
I've proposed that an implementation electing this conformance option 
support any of the SAMLMeta methods for publishing and discovery. This 
seems to avoid any change to normative priority between the methods.

(It may turn out, however, that should LAP/whomever conformance testing
undertake testing of the Metadata claim that they'd require the WKL 
method.) 

I figure that if the POV runs strong towards requiring the minimum of 
the WKL method we can easily make that change.


APPROACH #2
This is for those who would support an errata to SAMLConf on metadata, but 
would not like to see the interchange aspect (in other words, those interested 
in the bare "Metadata Structures" errata proposed in saml-errata-2.0-draft-12). 
I've included, further below, a brief paragraph just relaying what was
discussed on today's call, sort of.

HTH,
--Nick 

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

APPROACH #1
Interchange included
Selective diff on saml-errata-2.0-draft-12 Proposed Errata #25
(I have not marked the minor changes):
   587 
   588 Document: Conformance 
   589 Description: Conformance document does not specify any requirements with respect to 
   590 metadata. It is suggested that the conformance document be updated as follows. 
   591 
   592 Change to Table 2: Feature Matrix
   593 FEATURE               IdP    IdPLite   SP   SPLite   ECP
   594 Metadata              OPT      OPT    OPT    OPT     N/A  
   595
   596
   597 Change to Table 4: SAML Authority and Requester Matrix
   598                       AuthnAuth AttribAuth AuthZDcsnAuth Requester
   599 FEATURE
   600 Metadata                 OPT      OPT          OPT          OPT
   601
   602
   603 New sub-section to Section 3 (Conformance):
   604
   605 3.6 Metadata 
   606 Implementations claiming conformance to SAMLv2.0 may declare each operational mode's 
   607 conformance to SAMLv2.0 Metadata [SAMLMeta] through election of the Metadata
   608 option.
   609
   610 With respect to each operational mode, such conformance entails the following:
   611 * Implementing SAML metadata according to the extensible SAMLv2.0 Metadata format in all 
   612 cases where an interoperating peer has the option, as stated in SAMLv2.0 specifications, of 

-  613 depending on the existence of SAMLv2.0 Metadata. Although electing the Metadata Structures
-  614 option has the effect of requiring such metadata be available to the interoperating peer, no
-  615 requirement is established for a specific method of distribution, publication or resolution.

+  613 depending on the existence of SAMLv2.0 Metadata. Electing the Metadata
+  614 option has the effect of requiring such metadata be available to the interoperating peer.
+  615 The means of satisfying this requirement is detailed below.

   616
   617 * Referencing, consuming, and adherence to the SAML metadata, according to [SAMLMeta], of
   618 an interoperating peer when the known metadata relevant to that peer and the particular
   619 operation, and the current exchange, has expired or is no longer valid in cache, provided the
   620 metadata is available and is not prohibited by policy or the particular operation and that specific
   621 exchange.
   622

+ a622 Election of the Metadata option requires the implementation offer, in addition to any other 
+ a622 mechanism, at least one of the two publication and resolution mechanisms described in SAMLMeta. 

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

APPROACH #2
Interchange unstated

In this case, the text in saml-errata-2.0-draft-12 Proposed Errata #25 would
remain unchanged (clarifications welcomed, however).

The sentence starting in line 613, declaring that no requirement is established
for a specific method of distribution, publication or resolution, means that
an implementation can choose whatever means is convenient and appropriate. Of
course customers will want to know how distribution etc is done ... but this is 
not prescribed here. It could be that the IdP/SP/etc simply exports the data, for 
use by sneakernet, as Conor mentioned. Or the data could be one-time injected at 
a GUI configuration interface for all entities to hold, statically, an identical 
complete tree. Any innovation would be allowed (although perhaps it would not be
all that interoperable).




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]