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



Folks,

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

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

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

Regards,
Stephen.

RL 'Bob' Morgan wrote:
> 
> On Wed, 23 Jan 2002, Stephen Farrell wrote:
> 
> > Did I miss the justification for re-inventing another xml flavor of
> > the ASN.1 Attribute rather than re-using someone else's (e.g.  DSML)?
> > Seems like we're re-visiting a lot that others must have considered.
> 
> As Scott said, SAML Attributes and values need not be restricted to those
> supported in LDAP/X.500 or definable in ASN.1; in fact I think it's one of
> the points of SAML being XML-oriented to not be so limited.  However, I'm
> sure it's the case that many deployments will want to map directly from
> X.500-defined attributes and values to SAML ones (we've talked about this
> quite a bit in Shib), so it would most likely be a useful thing for
> someone to describe a way of doing this, and this would almost certainly
> be based on DSML.  But I wouldn't hold up the 1.0 spec waiting on this.
> 
>  - RL "Bob"

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


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


Powered by eList eXpress LLC