OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] comments re draft-sstc-metadata-iop-03

Tom Scavo wrote on 2009-02-12:
> As a very specific example, the Metadata Interoperability Profile does
> not work within TeraGrid, a large grid deployment in the US.

Would it help if I added language essentially stating "if you think X.509
works, stop reading"?

More seriously, it sounds like it would help if there was language in the
motivating text that talks about the overlap and explains that the profile
is essentially aiming at deployments that don't have a PKI that they have
confidence in the runtime behavior of.

Speaking to your example directly, I don't really see what the use of
metadata buys you at all. It makes sense that you would align the metadata
to the naming that is already present at the layer of the credentials that
already have to be trusted. But I think it makes more sense to just drop the
layer out, actually...

> Nor do I think X.509-based grids are an isolated example.  If you look
> at the Kerberos white paper that we discussed on the last concall, one
> of the stated objectives is to "Leverage SAML metadata to enable
> large-scale Kerberos cross-realm communities."  Of course it's too
> early to say exactly what that might look like, but coming off my
> experience integrating SAML with X.509, I'd be willing to wager that
> SAML metadata in a Kerberos environment can not be shoe-horned into
> the Metadata Interoperability Profile.

No, I would have to disagree. On the contrary, it would be *because* of that
profile that one could simplify the use of Kerberos by leveraging the trust
mechanisms the metadata can supply. If one were to go back to the use of
X.509, well, Kerberos already supports that, I believe.

I think we also see the strategies for integrating these things in virtually
the opposite way, which is perhaps why we're not meeting minds on this.

> But there is no evidence to the contrary.

The query extension you mentioned
Use of SAML within ID-WSF

All of those protocols and profiles, where they have touch points with SAML
trust evaluation, can be implemented more cleanly via this profile.

> The SAML metadata
> specification, like much of the SAML specification set, is biased
> towards Web Browser SSO. The fact that we have a "Metadata Extension
> for SAML V2.0 and V1.x Query Requesters" is testimony to this fact.

No, it's testimony to the fact that we had a whole lot of work to do and
stuff got missed that wasn't as important to the authors. What it proves is
*my* point. You add that extension and it has no impact on the validity of
the profile.

> Once you move away from Web Browser SSO, you find less of what you
> need in the SAML specifications and end up rolling your own.

The metadata roles are specific to the profiles that were developed in the
TC at the same time. That has nothing to do with this profile, which is
extensible to roles that didn't even exist (at least schematically) when the
ideas were being developed.

As you've noted many times, it's a stretch as currently written to even call
it a metadata profile, when it basically just deals with KeyDescriptor. That
element is in the role base type, which by definition means it applies to
any role in the same way.

> So I think the onus is on you to show that the scope of the Metadata
> Interoperability Profile transcends Web Browser SSO.

I could say that I think I just did, but I don't really believe your premise
is valid. There's nothing in SAML metadata as a framework that is specific
to the SSO profile, and this profile doesn't even mention it (I don't
-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]