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] | [Elist Home]

Subject: RE: [security-services] New Issue: Multi-Valued Attributes

> I'd be much happier if someone did demonstrate the 
> X.500->SAML attribute mapping. IMO, this is an interop issue 
> and so might justify holding 1.0 (mind you, I'm not sure how 
> interop features on the 1.0 exit criteria, so maybe I'm wrong 
> there). OTOH, it shouldn't be that hard to fix either (just 
> add some X.500-> SAML attribute mapping rules to the core doc.)

If there's an existing mapping of X.500 attribute->XML (DSML?), then
there's nothing for SAML to do that I can see. I'm not sure if the SAML
document should mention such mappings, but I suppose it could. As far as
interop goes, I haven't seen the term defined in SAML in terms of what
attributes get used for.

> To demonstrate: say if productX's PDP maps from (inventing syntax 
> here) inetOrgPerson:commonName to Xsaml-attr:XCommonName and 
> productY's PEP expects Ysaml-attr:YCommonName then managing access 
> is difficult for the particular case that SAML was mainly designed 
> to handle - that is cross domain hand-off.

That's a question of defining an "official" XML namespace and schema for
inetOrgPerson or other LDAP object classes. Sounds like a good idea to

> That's why I'd favor the DSML approach, since (I believe, but 
> don't know for sure), it means two SAML codebases will both 
> handle inetOrgPerson attributes in the same way. I'd also 
> argue that supporting (some) inetOrgPerson attributes be a 
> MUST, but I guess that's another issue.

Quite so. I don't think it's needed, since "supporting" attributes isn't
very well defined. If I don't think they provide any value to my
application, I need do nothing to support them since if somebody gives
me one, it will validate (though perhaps laxly) and be ignored. But if I
do want to use them, it should certainly be done with a consistent
attribute format between implementations.

> I've no problem at all with there being a way to include 
> attribute syntaxes which are fancier than X.500 allows 
> (though I can't for the life of me imagine such a beast being 
> useful, given that an X.500 attribute is basically a bucket of
> you're having yourself!).

So is arbitrary text, but for some reason this XML thing seems popular.

I'd like to be able to take full advantage of Schema's expressiveness
and the tools that are emerging to map programming language objects to
schema content models.

> What I want is that different vendors PDPs 
> and PEPs can work together, and a common understanding of, in 
> particular, some basic inetOrgPerson attributes is crucial to this

I agree, it's certainly crucial for PDPs and PEPs that care about

-- Scott

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

Powered by eList eXpress LLC