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

["Scott Cantor" <cantor.2@osu.edu>]

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

Maybe we can add it to the list of poorly understood XMLSig rules and get
rid of it altogether. ;-)

> We already have such an extension for standalone attribute requesters.

With respect to Ari's statement, if people are using metadata *at an IdP/AA*
in support of this profile, they're doing something undefined (as Tom says)
because there's no role defined that could be used apart from
SPSSODescriptor (and ignoring all the endpoint elements).

In fairness, I advocated a general SP/RP role and just including optional
web SSO bits, but that wasn't adopted, so...

The flipside is different. It's likely, and not really "wrong", to use
existing AA metadata.

> A general-purpose attribute responder can not legally use SAML V2.0
> metadata to advertise a location endpoint that supports this profile.

That's an interpretation that depends on the "compatibility" of the new
profile with the base profile. My interpretation is it's a restrictive
subset that consists of messages legal in the base profile and so it's legal
to just treat the rest as OOB information, as with all the hundred other
things not included in metadata.

OTOH, yeah, if the new profile is just not even legal SAML queries, uses
extensions, different messages, etc, that's another matter.

> An SP looking at this metadata can not tell if the endpoint location
> supports this profile.

Yep. So it's OOB.

-- Scott