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

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

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

-- Scott



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


Powered by eList eXpress LLC