[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] LDAP Attribute Profile (saml-profiles-saml2.0)
> I'm willing to believe that the intention was to include the ASN.1 > octet string wrapper, but I won't say that I'm not disappointed. One way to look at it is that if a majority of people interpreted it the other way, then they're right, particularly if that's the better way. > Perhaps I'm missing the value that it adds (none that I can see). > > I assume that, following LDAP, the basic encoding rules (BER) would > be used for the octet string wrapper. e.g. > 05 <len> <bytes> > > Of course, <len> is a variable byte encoding (<128 fits in one byte). I'm assuming the reasoning, if any, was that it would be easier to extract the data from LDAP and embed it in XML if the wrapper was included. If that's not the case, then the errata should clarify that it *not* be done. Or we should simply publish a v2 profile, change the encoding attribute value, and define an encoding that works. > This strikes me as a very poor design pattern. It would be much > better to have a well known Format/Encoding attribute on > AttributeValue that unambiguously instructs the receiver on how to > process the value. Fundamentally, I believe this is simply the basic argument over whether attribute value syntax should be communicated clearly in-band (either with metadata or by relying on unique attribute naming as an implication of syntax, which I believe is what LDAP does) or should require OOB knowledge. I argued long and hard for the first, and was overruled. I think what we have now is just a half-way step of embedding hints and reusable constants that vary by use case. I think things end up much the same as they were in SAML 1.1. You build rules based on Name/NameFormat (much as SAML 1.1 used AttributeName/AttributeNamespace) and within that, you really don't bother allowing the same Name/NameFormat to mean 2 different things in a single deployment because that's complete madness. In other words, an OID that corresponds to some LDAP profile attribute is going to be expressed with the LDAP profile, and ok, there might be an XACML DataType thing sitting in there also because they're basically orthogonal profiles. It's all worthless if I can't tell from the OID that I should process it with the LDAP profile, which is your point. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]