[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