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

["Tom Scavo" <trscavo@gmail.com>]

On 8/29/06, Ari Kermaier <ari.kermaier@oracle.com> wrote:
> >
> > 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.

Since we specify the X509SubjectName format, I agree.  If we were to
invent our own format, it would be an interesting question whether RFC
2253 should be SHOULD or MUST, and whether the poorly understood
encoding rules of XMLSig are really necessary.

> 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.

I respectfully disagree, as detailed below.

> 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.

We already have such an extension for standalone attribute requesters.

> 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.

A general-purpose attribute responder can not legally use SAML V2.0
metadata to advertise a location endpoint that supports this profile.
Consider, for example, the following metadata descriptor:

<md:AttributeAuthorityDescriptor
  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

  <md:AttributeService
    Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
    Location="https://idp.example.org:8443/saml-idp/AA"/>

  <md:NameIDFormat>
    urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
  </md:NameIDFormat>

</md:AttributeAuthorityDescriptor>

An SP looking at this metadata can not tell if the endpoint location
supports this profile.  Indeed, the SAML V2.0 spec says that the
AttributeService element above supports "the profile of the Attribute
Query protocol defined in [SAMLProf]" so clearly something new is
needed, and it needs to be defined in this document.

Tom