RE: [security-services] LDAP Attribute Profile (saml-profiles-saml2.0)

["Scott Cantor" <cantor.2@osu.edu>]

> 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