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

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

Tom Scavo wrote on 2009-02-13:
> In the previous sentence, when you use the term "PKI," do you mean
> "X.509-based PKI"?  The lone term "PKI" is ambiguous since obviously
> you're trying to profile a (SAML-based) PKI.

Yes, I noted that after I sent it, but I figured you'd get what I was
suggesting.

> But yes, the profile assumes the existence of a SAML-based PKI or the
> willingness to build out a SAML-based PKI.

That isn't quite how I would put it, because as I have pointed out, this
profile is not really about how you do your PKI. It's only about the SAML
runtime. I can point you to specific cases in which people using or likely
to use this profile will be relying on an X.509 PKI for the exchange of
metadata. Does that make it a SAML PKI or an X.509 PKI?
 
In effect, I don't think you can have a SAML PKI, I guess that's roughly
what I'm saying. SAML can't bootstrap from itself. Something else has to do
it, which might be OOB key exchange (which is what InCommon does at the
moment).

The profile assumes you want predictable, safe, reliable SAML behavior once
you can acquire metadata you trust, and that's about it. The biases of a
deployment would be reflected at the acquisition layer, which is not part of
the profile.

> If your deployment is
> based on any other type of PKI---in particular, an X.509-based
> PKI---then this profile is probably not for you.

This is overstating it, for the reasons I note above. What I guess I would
say is that if your use of SAML is already substantially subservient to
X.509, then the profile is probably redundant. But I tend to believe such
cases will also result in metadata itself being redundant, so that's why I
have a problem seeing the middle ground where the metadata has significant
value but the profile doesn't.
 
> As much as you'd like to assume that use case away, it's not going to
> happen.  It is what it is.

I think you misread me. I'm saying I'd drop out the metadata, not the X.509.
Can you outline for me even briefly what it's used for?

> Specifically, I was referring to the SAML-in-Kerberos proposal, which
> is analogous to the SAML-in-X509 use within TeraGrid.  Again, I'd be
> *very* surprised if the "standard" SAML metadata profile were relevant
> in that case.

I think the metadata itself is largely irrelevant to it, as in the X.509
case. But I was referring to some of the other proposals, obviously.

> Okay, I'll concede that point.  I'm still searching for a proper
> characterization of scope for this profile.

I understand that you have a concern. I'm willing to work on some qualifying
text related to the question of when the profile makes the most sense, but I
haven't really found a good way to do so yet and I'm just responding to what
I don't feel are adequate boundaries.

If anything I wrote strikes a chord, let me know.

I also understand the concern over the name of the profile. Perhaps if the
scoping question can be worked through, that will suggest something there
also.

-- Scott