RE: [security-services] Groups -sstc-saml-x509-authn-attrib-profile-draft-10-diff.pdf uploaded

["Ari Kermaier" <ari.kermaier@oracle.com>]

> > Are we sure, though, that this is a question that must be 
> disposed of in the profile spec, rather than by agreement 
> between participants in a given CoT? As far as I can see, 
> this would be the only reason to upgrade RFC 2253 conformance 
> from SHOULD to MUST in this profile -- is it necessary?
> 
> Our experience suggests that RFC 2253 is a requirement, yes.  We will
> not be able to interop with a deployment that uses some other format.
> Indeed, I don't see how to implement this profile without making that
> assumption.

I still don't see why the spec should preclude adoption of this profile by a community of providers who agree among themselves to use a particular DN format. A rule that only RFC 2253 conformant DNs may be used should be left up to individual deployment scenarios and the participating providers.

> 
> > > > [lines 360-450] I would hesitate to introduce new normative
> > > MUST requirements here that might break existing
> > > implementations' conformance with the profile spec. I think
> > > metadata usages should be RECOMMENDED, as in previous drafts,
> > > except insofar as the SAML 2.0 metadata spec already 
> contains MUSTs.
> > >
> > > As stated on lines 327--329, metadata MAY be used and SAML 2.0
> > > metadata is RECOMMENDED.  If an entity chooses to use SAML 2.0
> > > metadata, then (and only then) do the new MUSTs take 
> effect.  (I think
> > > this is the correct way to handle it, but I could be wrong.)  I
> > > believe cd-02 is broken since it fails to include any relevant
> > > metadata bits.
> >
> > My concern with adding new requirements for metadata users 
> is similar to my issue with using NameQualifier. It takes 
> already existing SAML 2.0 IdPs -- that were originally just 
> fine for interop using this profile, and that used metadata 
> as per SAML 2.0 to describe their attribute responder 
> capabilities -- and tells them the rules have changed and 
> they need to be modified. I think we need to have a truly 
> compelling reason before we contemplate such changes, and I'm 
> not yet convinced that the benefits of the proposed schema 
> extensions and MUSTs rise to that standard.
> 
> First, I don't believe there are any deployments of this profile in
> existence today.  Second, if there are, and they are using standard
> SAML V2.0 metadata, they are most assuredly broken.  Schema extensions
> to both SP and IdP metadata are required for standalone attribute
> query.  That's why Scott and I proposed a metadata extension for SPs,
> and why I'm proposing a metadata extension for IdPs.  Without the
> latter, an SP would not know what endpoints support this profile.
> 
> Let's not forget that the driving use case for this profile is an
> X.509 authentication-based SP.  This use case leads to some
> interesting issues regarding name identifiers and metadata (as we have
> seen).  There's no question existing deployments will have to be
> modified to participate in this profile.

Proposing metadata extensions to make implementing this profile easier is fine. But saying that users of metadata MUST employ those extensions to be conformant with this profile is not OK at this point, IMO.

In any case, it seems to me that a better idea would be to propose general-purpose metadata extensions -- in a metadata extension spec -- that could be used to facilitate the X.509 attribute profile. For example, extending metadata to allow providers to call out whether they support/require encrypted NameIDs, Attributes and/or Assertions might be a good thing. But requiring that a profile specific attribute like hasEnhancedSupport be used puts an unnecessary burden on a general-purpose attribute responder.

::Ari

Ari Kermaier
Oracle