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

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

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

Although it would be nicer, I claim that it doesn't really matter that the SP cannot tell from the AttributeAuthorityDescriptor whether this profile is supported. If an IdP has two AttributeService elements, one of which describes an endpoint that supports the profile and the other an endpoint that does not, then there's a problem that a metadata extension could solve. But if there is just one such descriptor -- or if there is out-of-band communication/configuration to help the SP select the correct endpoint -- then there is no problem. When an endpoint does not in fact support the profile, I like the language in your proposed draft for section 4.3.2 Error Processing: "If the identity provider does not support this profile, it MAY return the following status code: urn:oasis:names:tc:SAML:2.0:status:UnknownAttrProfile".

My point is that if the existing metadata specs _and/or non-metadata configuration_ are sufficient for two providers to negotiate interoperability for this profile, why force them to implement metadata extensions? It's great to make it available, but why change SHOULD to MUST?

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

That's an interesting question. Does that language in SAMLMeta section 2.4.7 intend to prohibit any profile with a URI not exactly equal to "urn:oasis:names:tc:SAML:2.0:profiles:query" from using that metadata schema? I would think not, unless such a profile was in conflict with the message content or processing rules for the Assertion Query/Request Profile defined in Section 6 of SAMLProf. Since the X.509 attribute profile appears to be a sub-profile of the SAMLProf query profile, I would argue that using SAMLMeta is legal without requiring an extension.

::Ari