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

On Thu, Feb 12, 2009 at 9:11 PM, Scott Cantor <cantor.2@osu.edu> wrote:
> Tom Scavo wrote on 2009-02-12:
> 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.

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.

But yes, the profile assumes the existence of a SAML-based PKI or the
willingness to build out a SAML-based PKI.  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.

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

As much as you'd like to assume that use case away, it's not going to
happen.  It is what it is.

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

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.

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

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


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