RE: [security-services] Draft SSTC Meeting Minutes - 15-Jul-2008 w/Roll Call (attendance)

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

> We already traveled down this path:
> 
> http://wiki.oasis-open.org/security/SstcSaml2X509ProfilesDeploy
> 
> In that profile, we chose to define two new XML attributes for IdP
metadata:
> 
> <xs:attribute name="supportsX509Query" type="boolean" use="optional"/>
> <xs:attribute name="supportsX509SelfQuery" type="boolean" use="optional"/>
> 
> I'm not saying that's the right way to do it (although the benefits of
> a consistent approach are obvious), I'm just pointing it out.

Yes, that's a reasonable approach when your goal is to take an existing
endpoint and "overload" it with an extended profile that is compatible with
the old one. The boolean allows a consumer of the new profile to tell
whether the existing endpoint supports the extension, without affecting
older consumers of the old profile.

If that's the model here, then it works. If not, it doesn't. I confess I
don't know the answer here, I'd have to think about the security
implications. In principal, I don't *think* there are insurmountable
problems, but the question is whether you want to *force* overloading of the
endpoints or not. Because if you profile it such that the existing SSOS or
ACS elements are used, then by definition any older IdPs/SPs will find and
use those elements for their purposes.

Again, the model we used in the metadata has its drawbacks. In principal, I
would have preferred the more "exploded" model where the profile was
explicitly identified in an endpoint attribute, but people didn't want to
have to go digging for the endpoints, and it was different from the input
spec, so we left it alone.

-- Scott