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] Best practice for embedding complex trees into SAML attributes

On 12/6/11 1:57 PM, "Paul Madsen" <pmadsen@pingidentity.com> wrote:
>      Current proposal is to use an XPath expression as the value of the
>      SAML Attribute Name to represent its position in a notional SCIM
>      XML representation of a user.

I echo Leif's objections to actual use of XPath, but it isn't clear from
the description of the proposal whether actually evaluating them is really
part of the outcome here. It seems more like a convention to establish
names of attributes in a relatively systematic way, and might not even
formally be XPath necessarily.

The proposal to capture the entire structure in one value works on a basic
level, certainly, but the fact is that virtually all implementations will
simply choke on it. Mine won't, but it's an exception, not the rule.

What I will say, since you're asking, is how strongly I object to defining
yet another schema for representing a freaking name and email address. We
have X.500/LDAP schemas for these things, and we have well-defined names
in SAML for those attributes that avoid all the non-stop arguing from
people who should have better things to do with their time. Please use
them. As an IdP, I will most certainly *not* deploy a bunch of made up
names for the same data elements I already support using standard names.

If you do this, then in a SAML context, SCIM will just create extra work
for me. I'm speaking as a deployer, not as a TC member. The whole point of
profiles should be to align to the best practices of the technology you're

-- Scott

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